Як ви обирали мову програмування? Чому саме цю?

Сподіваюсь до пʼятниці пропустять ;) Це не пост холівару, яка мова краще. Це питання — чому саме я обрав саме цю мову?

Бо від мови залежить з якими проектами ви працюєте — Навряд хтось пише веб-застосунки на С, чи драйвери на PowerShell. Доречі, це теж цікава частина питання — ви обрали напрямок — і саме тому використовуєте цю мову, чи ви обрали мову — и саме через свій вибір мови працюєте з відповідними проектами?

Наприклад, я, хоч і цікавився програмуванням з підліткового віку, не планував ставати програмістом чи DevOps (бо такої професії не існувало взагалі тоді :D). Я, скоріше, планував стати електронщіком (бо компʼютера в мене доволі довго не було — а радіодеталей та інструменту — повна кладовка, хоча був калькулятор «електроніка — 52», де я писав якісь програмки — ігри). Та ще й була можливість заробити копієчку полагодивши той чи інший прилад — приймач, плеєр, тощо. Потім я дуже «підсів» на теор. фізику, а після закінчення ВНЗ за цим фахом стало зрозуміло, що фізики в нашій країні не дуже-то і потрібні, судячи з зарплатні та перспектив. Це трохи бекграунду.

Але, повертаючись до мов програмування, за цей час я таки писав на всьому, що було під рукою — Basic (ZX-Spectrum), Turbo Pascal (286/386/486), Pascal (хз яка версія і діалект на DEC-PDP), C (той самий PDP), FORTRAN (linux), Maple/Wolfram Mathematica, Perl... Трошки дивився на Java/C++ — але пішов працювати адміном і треба ж було автоматизовувати все, бо я ж ледачій :D Тож, знову Perl — але раптом виявилося, що Python, як на мене, значно зручніше. І він став основним інструментом на довгі роки. Весь цей час я інші мови тільки «читав» — якщо треба було розібратися як працює, чи чому не працює, чи як коректно встановити, чи зібрати пакет, чи автоматизувати білд... Це до того, що крім Python я бачив і використовував не одну мову. А, ще PHP... Сайти там, отета всьо, а потім глянув на django і помив руці після php (все, все! вибачте, я ж обіцяв — без холіварів! :D)

Тож, можна сказати, що Python я обрав тому, що таке було середовище — як найзручніший для мене інструмент. Але навряд це можна вважати цілком випадковим вибором. Коли я обирав між Python та Perl — одним з головних критеріїв було те, що зібрати якісь сторонні пакети чи ліби в Perl було важче. (конкретно, останньою краплею стало те, що драйвер до MSSQL у Perl збирався і працював дуже нестабільно, в той час як в Python я просто встановив відповідний пакет і все працювало без жодних проблем)

Хоча, коли треба було працювати з Windows/Azure — трошки юзав(ю) PowerShell, terraform (тут не тільки Azure).

І ось пару рочків тому подивився на Rust, почитавши документацію — багато закладених в мову ідей дуже зацікавило, насамперед — робота з памʼятю, звісно. На Go я теж дивився, але щось не виникло бажання пробувати писати.

Зараз заглиблююсь (переписуючи частину пет-проектів та робочих утіліт) в Rust, бо просто цікаво і подобається мова. Тобто — перш за все, мені комфортно з цим працювати. І це вже не вибір через середовище, це, скоріше, навпаки. Бо навіщо DevOps — Rust? ;) Але він дуже підходить, коли є бажання запихнути на Raspberry Zero з 512Mb Ram кілька сервісів одночасно. Воно ніби то і на Python якось працює, але-ж...

А як обирали мову ви? Чому саме цю(і)? Що було раніше (чи важливіше) — вибір мови чи вибір домену?

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

5 лет писал на Delphi, потому что с универа были проекты на нем. В 2006 году работы на нем не стало. Пообщавшись с некоторыми друзьями, которые с него ушли на .NET или Java выбрал Java и ни разу не пожалел.

Дуже просто: домен обрав мову за мене. Зараз це TS/JS.

А для себе пишу на Bash, C та іноді TS/JS. Колись намагався писати для себе на Perl і Lua, але якось не пішло.

Ще зі школи basic, тому що була книга а потім компутер pravetz 8d
інші мови вже з універа, паскалі, c, c++, c#
і хобана дали завдання зробити форум на php і почалось
потім php тому що була робота
в часи універа не знав що обирати web, .net
так от з незнанням і працював що було потрібно на роботі
зараз модний python потрібен
але любов почалась з basic та книги по інформатиці, «програмував» ще без компьютера

Перепробував усі мови програмування, які мене цікавили, та й виснував для себе що для чого годиться і з чим мені приємніше працювати.

Часто висновки виходили анти-стереотипні. Наприклад, мені більше подобається Лямбди писати ДжаваСкриптом, ніж Пайтоном. І взагалі Node.js топчик.

Подобається Haskell, але екосистема в нього моторошна.

Для загальних задач зазвичай беру Джаву. Нею можна що веб-апку, що гру написати, одна мова на (майже) всі випадки життя.

Я колись дуже любив С++, бо те, у що розгортається при виконанні код більш високорівневих мов мене просто лякало своєю неефективністю. Потім побачив, що цілому ряду бізнесів на цей факт плювати і вони продають не ефективність коду, а щось інше. Наприклад, швидкість розробки. І люди купують оце «щось інше». Тоді я став вчити і інші мови і сьогодні я, впринципі, можу сісти і писати код на будь-якій мові з TOP-20, максимум витративши півгодини на згадування синтаксису і основних функцій її стандартної бібліотеки (а з приходом AI-інструментів вже й того не требе пам’ятати).

Коли я обговорюю швидкість та оптимальність виконання, я завжди наводжу 2 приклада:

1. мені треба софт, який оновлює список пакетів та сповіщає мене повідомленням якщо було поновлено конкретний пакет. Тобто, наприклад (цифри майже випадкові):

старт програми — Python — 0.5c, C — 0.01c
читання віддаленого репозиторія та запис у локальну БД — 10с
обробка різниі і створення списків на встановлення — python — 0.1c, C — 0.01c
скачати всі пакети та встановити — 60с
Сформувати та відправити повідомлення — python — 0.1c, C — 0.01c
Доставка повідомлення (електронною поштою чи в месенджер) 1-30с, нехай візьмемо 5с

Загальний час виконання процесу:
Python — 0.5+10+0.1+60+0.1+5 = 75.7c
C — 75.03c

Тобто різниця 0.67с чи 0.9% — людина просто не помітить цього. А різниця в часі на розробку та підтримку — буде значно більше в загальному випадку.

А порівнювати час виконання самої програми 0.7 чи 0.03 немає жодного сенсу — по-перше, людина помітить загальний час. по-друге, все одно не помітить різницю між величинами менше 1с.

2. Обробка складних даних — більшість часу у вас буде читання даних з диску чи з мережевого сховища, і на об’ємах у десятки чи сотні Гб різниця в часі на обробку зі сторони коду буде значно менше, ніж час на передачу чи читання цих даних. Яке ви принципово прискорити не можете, це або затримка мережи (бо швидкість світла не нескінчена, фізика, вона така) чи залізом, яке також не прискориш.

Тобто. Те, що люди купують «щось інше» — цілком логічно. Особливо, коли розробку на умовному Python треба чекати день, а на умовному С — кілька днів (і платити також більше).

Доречі, про ШІ інструменти. Ми тестуємо кілька інструментів для генерації коду. І воно «гарно» тільки на перший погляд.

Коли вам треба зробити просту функцію — воно працює, так. Але ж просту функцію я напишу за той-же час.

Це тільки новачку допомога. І не спеціалісту — дивно.

Коли ж у вас складна система з кількох модулів і кілька взаємозв’язків — все доволі сумно. Бо, наприклад, я пишу код на terraform щоб описати деяку інфраструктуру — з циклами, взаємними посиланнями, дата сорсами і таке інше.

Коли цю ж інфру генерує ШІ — навіть коли воно працює, це «спагетті» — лінійний код, з купою хардкоду параметрів, без взаємозв’язків. І це не дивно — ніякого «розуміння» у ШІ структури системи немає. Підтримувати такий код, коли у вас сотні об’єктів у хмарі — пекло.

Якщо-ж генерувати зі структури — ШІ також не дуже розуміє, що треба винести у змінні, що можна отримати з дата сорсів, що можна, а що не можна хардкодити. Тобто для більш-менш складного проекту час на «налаштування моделі» виходить більше, ніж написати самому. підтримувати цей код, тобто додавати нові об’єкти — воно теж нормально не може. Тільки «лінійно» докидувати «спагетті».

Тож, поки це такий «пре-трейні». І це ж великі корпоративні застосунки, з прямими контрактами і зі хмарними провайдерами.

Як я бачу це зараз — людина не може тримати в голові велику кількість об’єктів, звітси це все — поділення на класи, модулі, цикли — рівні абстракції.

А ось у ШІ проблеми з кількістю об’єктів немає. Але проблема з абстракцією — є. Зовсім інший підхід. І коли кажуть, що дуже скоро ми не зможемо «потягатись» з ШІ — то саме з цього параметру — кількість об’єктів. Ми не зможемо зрозуміти «спагетті» на тисячі строк.

techxplore.com/...​intelligence-grammar.html

Обирати ні з чого було — PL/1 та FORTRAN на перфокартах або магнитній стрічці для мажорів )))) По ітогу, як найулюбленіші, лишилися С (як контрол-драйвен) і G (як дата-драйвен).

У фізиці напівпровідників вистачає челленжів і без програмування, воно потрібне або для суто навчальних цілей, або коли конкретний esge case вимагає масштабних обчислень і їх простіше написати оптимізованим чином вручну, ніж копатись у тонких настройках Maple, Mathematica чи подібних систем.

Років 10-15 назад найкращим компромісом був C — у достатніх для чисельних методів об’ємах, без системного програмування, взаємодії з залізом і всього такого легко вчиться по K&R, сама мова максимально ефективна, код відносно добре переживає десятки років зберігання чи видається на інтеграцію справжнім програмістам у щось більш дружнє до користувача. Fortran має значно замкненішу у собі екосистему і не має особливого сенсу для чогось що робиться з нуля, фічі С++ просто не потрібні на об’ємах коду наукових програм і надмірно складні у освоєнні, більш нові мови з’являлись і зникали надто швидко щоб на них звертати увагу, на той час наприклад Python здавався маргінальщиною проти хайпового C#.

Коли настав час робити екстракшн з науки особливих преференцій по домену не було, але вміння програмувати малось лише у процедурному © і функціональному (Mathematica) стилі, без розуміння ООП, паттернів і всього такого, зате з розумінням всього стеку заліза від квантової механіки, до цифрової електроніки і ця база закономірно завела у ембеддед і Linux Kernel...

В цілому, мову вибирати ніколи не доводилось, вона задавалась предметною сферою — абсолютна більшість ембеддеду це С і С++, всілякі автотести можуть бути на Python/Perl/Lua/Tcl, у високорівневому ембеддеді типу AOSP інколи доводиться вникати у роботу сервісів на Java чи білд-автоматизації на Go, у пет-проектах з вебом теж не вдасться розминутись з Javascript для фронту чи з php/ruby/Go обраного готового рушія. Тобто мати прям релігійні преференції до мов у сучасних умовах нереально, хоча з роками і з’являються певні смаки — хочеться мати легко читабельний код, причому для задач типу code review читабельність не повинна покладатись на IDE, по цим критеріям C і Go виглядають самими приємними, а на протилежному полюсі ставлю Perl і С++ свіжих стандартів.

Дуже люблю Python за його простоту і кросплатформеність.
Обрала свідомо десь у 2013 році.
Коли є можливість, пишу на Python.
Останні кілька років є тенденція писати автотести на рідній мові екосистеми.
Android — Java, Kotlin;
iOS — Swift, Objective-C;
Web — дуже популярно TypeScript.

І якось так іноді доводиться писати на різних мовах. Але не завжди вистачає сил зрозуміти мову глибоко. І тому є відчуття, що все знаю і не знаю нічого одночасно.

Останні кілька місяців мені довелося повністю перейти на TypeScript.
Для написання чогось простого наче вже зрозуміло. Для написання складного — поки що важко.

Сумую за Python.
Намагаюся про нього не думати і не дивитися на PyCharm, щоб не сумувати.

Щоб була не ЖабаСкрипт

помив руці після php

Ось вона мить мого і інших php-шників тріумфу і настала )
За даними Джинні, в топі затребуваних технічних спеціалізацій на зараз — PHP, за ним — JavaScript.

А ви і далі мийте руки і ускладнюйте самі собі заробляння грошей у веб-девелопменті для незрозумілих понтів )

Ось вона мить мого і інших php-шників тріумфу і настала )

Радію, що зміг підняти вам настрій :)

Ну, насправді я нікого не хотів образити, скоріше підстібнути. А щодо понтів... В житті є багато цікавих речей і понти — явно не на першому місті.

От блін, ща думав буде убер-срач а ви виявляється конструктивні ) Аж абідно )))

Я дуже хотів вивчити програмування і шукав будь-які безкоштовні курси. Мені було однаково що вивчати. У той час в Реддіт багато хто писав про курси MOOC та Hyperskill. Так я потрапив у джава. Я трохи пробував вивчати пітон, котлін але не склалося бо оточення було — джавісти. На даний момент я вивчаю мікросервіси. У джавістів не багато шляхів, якщо хочете вивчити ще одну мову: залишитися в бекенді треба вивчати котлiн або скалу. Або почати вивчати фронтенд щоб стати фулстак, тут теж вибір не великий: джаваскрипт/тайпскрипт —> реакт/ангуляр. Я прихильник теорії що потрібно знати одну мову і знати її досканально, також потрібно знати те з чим мова взаємодіє. Далі після мікросервісів я почну вивчати щось зі скриптів потім, реакт або ангуляр. Все просто з вибором.

Я прихильник теорії що потрібно знати одну мову і знати її досканально

Це теорія не витримує випробування практикою :) Мови програмування існують не в вакуумі, це тільки один з гвинтиків в системі. Інші частини пазлу цілком можуть бути (і будуть в загальному випадку) написані з використанням інших мов, і навіть «твоя» мова (якщо це не С) цілком може мати рантайм написаний на чомусь іншому (на тих же сях чи плюсах). Тобто in the long run існує приблизно нульові шанси того, що тобі ніколи не доведеться хоча б на пів-шишечки «пірнути» в іншу мову й екосистему.

До того ж, вивчення інших мов, особливо дуже відмінних від основної за парадигмою та реалізацією, «збагачує» тебе як інженера — бо ти перестаєш дивитись на певні рішення як на істину в останній інстанції, а починаєш на них дивитись через призму переваг/компромісів порівняно з альтернативами.

До того ж, вивчення інших мов, особливо дуже відмінних від основної за парадигмою та реалізацією, «збагачує» тебе як інженера — бо ти перестаєш дивитись на певні рішення як на істину в останній інстанції, а починаєш на них дивитись через призму переваг/компромісів порівняно з альтернативами.

Ладно мова, от що робити з фреймворками до яких звик? Це ж нереально взяти і просто перейти на іншу мову не вивчивши 100500 фреймворків. Чи навіть банальних бібліотек в мові. Як мінімум методи по іншому називаються в різних бібліотеках.

Питання не до мене, але я відповім.

Не має жодної причини вчити фреймворк чи стандартну бібліотеку будь-якої мови на рівні цитування на памʼять. бо все дуже швидко змінюється. Для цього є документація. Все, що потрібно знати — це структуру (що там може бути що — навряд, як і де шукати, загальний підхід до використання). Назву методів можна переглянути в документації.

Вчити всі існуючі фрейворки не тільки не треба, а навіть і неможливо. Це просто за межами обʼєму памʼяті людини. І поки ви «вивчите» всі методи якогось фреймворку — вийде нова версія, де щось буде працювати не так...

Людина яка знає фреймворк зможе пофіксити проблему за 5 хв, тому хто не знає, може зайняти день. В чому тоді сенс?

Ок, що таке «знає фрейворк»? Памʼятає всі методи і класи? Це ж неможливо для більш-менш великого фреймворку.

Я, наприклад, не знаю бібліотеки C#, але вирішую задачі швидше, ніж однокласники моєї доньки, бо я розумію загальні концепції, я знаю де шукати і що шукати. А у них перед очами конспект лекцій, де перераховані методи, що можуть бути використані в програмі, але бракує загального розуміння класів. І це ж не тільки до програмування відноситься — я не памʼятаю всі формули з фізики, але памʼятаю принципи — а формули можна вивести чи подивитись.

Тому все, що треба для ефективного використання будь-якого інструменту, в тому числі мови, не треба знати всі 100500 фреймворків. Так само як не треба знати всі 100500 моделей авто, щоб їздити. Звісно, до кожного авто треба звикнути, але ж те, що ви їздили на БМВ не означає, що ви не зможете пересісти в тойоту чи мерседес.

І, доречі, чим більший ваш досвід водіння різних авто — тим швидше ви пересядете до іншої моделі. Як і з мовою. Про це і річ.

Тому все, що треба для ефективного використання будь-якого інструменту, в тому числі мови, не треба знати всі 100500 фреймворків. Так само як не треба знати всі 100500 моделей авто, щоб їздити. Звісно, до кожного авто треба звикнути, але ж те, що ви їздили на БМВ не означає, що ви не зможете пересісти в тойоту чи мерседес

Якась дивна аналогія.
Швидше мало би порівнюватись пересідання з автомата на механіку, чи з легкової на вантажівку.

Ну, якщо переїзджати з Python на C чи Rust — то так, це автомат на механіку... Але, знов таки, чим більше досвіду різних авто — тим простіше переходити.

Ок, що таке «знає фрейворк»? Памʼятає всі методи і класи? Це ж неможливо для більш-менш великого фреймворку.

Для прикладу є люди які ніби і використовують спрінг, але толком не в курсі як аннотації у спрінгу працюють і потім дивуються чому щось не працює.

От як якийсь супер нінздя пайтоніст має взнати такі нюанси якщо не дуже навіть зрозуміло що саме гуглити?

Я, зазвичай, дивлюсь в код, як реалізовано. Там стає зрозуміло. У більшості випадків. Тому надаю перевагу open source і в мовах — також.

Ну, є люди, які не розуміють щось. І що?

Ще раз. В будь-який області знань є доволі сталий набір базових інструментів, шаблонів, підходів. Якщо ви його знаєте — зазвичай стає зрозуміло, в яку сторону рухатись. Щонайменьше — куди точно не має сенсу дивиись, бо там точно немає. І не витрачати час даремно.

З Мікросервісами і Спрінгом це не спрацює просто подивитися код, бо тут занадто велика система. Потрібно знати ключові моменти: знати шо шукати і як правильно втiлити те, що потрібно, а не просто втiлити щоб працювало. Потрібно знати як реалізувати реактивне програмування, безпеку, контейнеризацію, брокери, відмовостійкість, моніторинг системи, тести та інше. Непідготовлена ​​людина просто заплутається. Я не стверджую, що потрібно знати всі методи і кожен рядок коду, я кажу про те, що потрібно багато знати в цілому щодо екосистеми, з чим і як вона працює. Анотації — це ще не найскладніше, що є в Спрінг. Крім джави ще потрібно зуміти реалiзувати конфігураціi ямл, знати грааль, докер, бази данних. На вивчання других мови не встаче часу, можно вивчати щось схоже, наприклад Котлiн. Або повністю відмовитися від екосистеми і почати вивчати все з нуля, наприклад, пітон або голанг. Тут постає питання доцільності.

Якось виглядає так що свідомого вибору не робив жодного разу, все якось впливали обставини такі як оточення, наявність роботи, наявність інструментів. В решті решт вивчення мови як такої не становить якихось проблем і не потребує забагато часу. Інша річ це екосистема: бібліотеки, фреймворки, інструменти.

за 30+ лет программирования для себя понял две важные вещи:
— язык должен быть статически типизированным, потому что динамические типы и масштабирование объема кода плохо дружат
— язык должен быть с RAII, а не с ручным управлением ресурсами или сборкой мусора

и по итогу остается не так уж и много мейнстрим вариантов

— язык должен быть статически типизированным, потому что динамические типы и масштабирование объема кода плохо дружат

О, так. Я теж помітив, що чим більше проект, що я пишу на Python, тим більше перевірок і вказання типів, щоб хоч лінтером перевірити та спіймати не очевидні помилки...

чим більше проект, що я пишу на Python, тим більше перевірок і вказання типів

Все залежить від людини. Ви собі навіть не уявляєте які комплексні з точки зору архітектури продукти були написані на пайтоні в кінці нульових в компаніях світового рівня з мільярдними ревенью, коли анотацій типів не було (точніше вони могли бути, лише в докстрінгах).

І все працювало (і досі працює, хоча пройшло 15 років), можна сказати, ідеально. Чому? Бо був вотерфолл, дизайн специфікації, функціональні специфікації та адекватне комплексне тестування (а не так як зараз, що Senior QA не знають як протестувати аплоад битих файлів різних форматів, хоч здали ISTQB і задрочують купу мусорної QA-теорії)

Недарма більшість стартапів навіть зараз в Кремнієвій Долині обирають бекенд на Джанго, якщо мова про веб та мобілки.

Я чудово уявляю, які продукти є на Python ;)

І анотація типів чи статичні типи не відміняють а ні грамотного менеждменту, а ні тестування — це все взаємодоповнюючі речі. так само як слідування ПДР ніяк не протирічіть і не заміняє технічної справності авто, чи то адекватного стану водія.

Йшов 2002 рік, спочатку писав на плюсах для себе... а потім звязався з поганою компанією і затягло в хрущовки в вебстудії. Раз попробував, другий, а потім не встиг оглянутись як два роки фігачу на ПОХАПЕ ))
Ну і понеслося аж по сей день

Ну... ідеальної мови не існує, як на мене краще працювати у гетеромовному середовищі.
Cі — повний контроль над перформансом та швидкодією
Python — гарний клей та гнучкість
Haskell — безпека, елегантність
Idris, Agda — верифікація

Java. Меньше всего долбоебов будет окружать))

;D
Ну я не був би настільки впевнений, але я і не працював в колективі Java-програмістів ;)

Golang. товариш підсадив, ну і робота швидко підвернулась де круто прокачав навички.
З часом почало бісити err != nil та відсутність женериків, шукав щось функціональне щоб зістрибнуть, але як не дивно, не знайшов нормальних альтернатив. Але з часом призвичаївся, та і женерики підвезли. Зараз найкраща мова для свого кола задач, альтернатив тим більше не бачу.

Ще вмію у фронт, але тут взагалі я не обирав, а воно якось звалювалось само. Типу на проекті замість фронтенда якийсь жабогадюкінг з жквері та бекбону(?), тут важко втриматись від тому щоб запропонувати переписати на реакті.

Для душі дуже подобається функціональщина типу rescript/ocaml/purescript. якби там була ситуація краще аніж 3.5 контори на ринку — з радістю думаю звалив би.

Так, функціональне програмування то цікаво. Але, як на мене, це більш академічна штука, ніж практична.

У мене є 2 книжки у списку «на почитати» — про алгебру регулярних виразів та функціональне програмування, але все ніяк час на них не знайду ;( Але і зі списка (та й з читалки) рука не піднімається викинути...

З регулярками, доречі, моя улублена шутка на кількох роботах — «ми знаємо, що ти можеш це зробити в одну строку в консолі, але давай ти так робити не будеш, бо крім тебе це ніхто не розуміє» ;) (Насправді, це ще одна проблема Perl — хтось напише короткий код з регулярками який підтримувати — той ще ад, І велика перевага Python — код дуже легко читати).

Але, як на мене, це більш академічна штука, ніж практична

Там є академічні штуки типу хацкеля. Проте Purescript наприклад хоча дуже схожий на хацкель, але відчутно практичніший.
Окамл — то цілком собі практична штука для написання компіляторів наприклад. А ще є ерланг/еліксір. Або скала.
Навіть більше скажу, зараз мейнстрімні мови повально тирять концепти з функціональщини. Як то лямди, імутабельність, чисті функції і так далі.
Але шось функціональщина не спішить додавати фабріки синглтонів фасадів з мейнстрімних мов.

я останній час дуже багато використовую конструктори коли в тебе є функція яка бере якісь параметри захватує стейт і повертає функцію яку можна ще десь використовувати, дуже зручно.

Суттєво сконструйована функція це обʼект зі схованим захваченим стейтом, тому вполне собі ООП 🥰🥰

нуу типу можна сказати, що замикання — це як інтерфейс з одним (анонімним) методом (з сигнатурою функції), де дані заховані через захоплення всередині контексту, а наслідування — коли цю функцію врапиш іншою функцією (результуюча сигнатура така ж сама)
але ж щось тут сильно не так :-)

Я би не назвав Haskell академічним. В принципі є cabal в якому якісно реалізовано трохи більше ніж усе, та досить якісно та практично. Проблема скоріше у тому, що розробники недостатньо освічені.

Але шось функціональщина не спішить додавати фабріки синглтонів фасадів з мейнстрімних мов.

Ой, то ООП, яке без імутабельності дуже важко уявити. Головна перевага ООП, на мій погляд, що воно краще відповідає нашому світосприйняттю, тому приваблює на рівні почуттів. Але...

Хацкель як мова — академічний, бо ставить теоркат задроцтво понад практичністю. Пьюрскріпт прибрав лінивість, прикрутив нормальні рекорди і одразу дихати легше стало, хоча там все ще їде функтор черех функтор :-)

Головна перевага ООП, на мій погляд, що воно краще відповідає нашому світосприйняттю, тому приваблює на рівні почуттів

Так навпаки, писати грамотний ооп код важко, щоб постійно не скатуватись в god objects і слідувати оцим всім SOLID.
Мені особисто гошна модель з інтерфейсами і лямдами, а також функціональщина в принципі здаються більш зрозумілими.

Хацкель як мова — академічний, бо ставить теоркат задроцтво понад практичністю.

Не згоден, як на мене Haskell це доволі практична мова. Від теорії категорій там лише термінологія, і то лише у деяких класах. Ну а так є тенденція, що сучасні розробники на Haskell тяготіють більше до написання більш абстрактного коду. Але це проблема майже всіх розробниців, провина Haskell у тому, що це там працює краще.

Так навпаки, писати грамотний ооп код важко

Я згоден, що писати важко, я кажу про привабливість ідеї. Розробники пишуть монади усе своє життя, але більшість не розуміють, або не здатні зрозуміти швидко ідею монади. А от ідею ООП розуміються досить легко на інтуїтивному рівні: усе об’єкт, у об’єкта можна викликати метод та змінити його стан. Це дуже добре лягає на повсякденне мислення. Але це і є пастка, бо не працює настільки добре.

Чиста функціональщина, а саме ідея, що дані не можна змінювати, вони як раз не дуже лягають на інтуїцію: нам набагато краще уявити, що ми ставимо книгу на полицю, а от ще ми робимо ще одну копію полиці але все з книгою, здається трохи ненатуральною.

Від теорії категорій там лише термінологія, і то лише у деяких класах

Так без теоркату нічого нормального не напишеш. Бо хочеш попрацювати з будь-якийм IO — а там вже монади, і треба іти розбиратись а що воно таке.

А от ідею ООП розуміються досить легко на інтуїтивному рівні: усе об’єкт, у об’єкта можна викликати метод та змінити його стан.

От з теоретичної точки зору я згоден, джава-ооп розуміється легше аніж хацкелівський теоркат.
Але якщо взяти окамл — там теоркату нема, і з власного досвіду писати без підготовки там відчутно простіше.

нам набагато краще уявити, що ми ставимо книгу на полицю, а от ще ми робимо ще одну копію полиці але все з книгою, здається трохи ненатуральною

А яка різниця що там копія полиці чи нє. Код виглядає як щось типу
«get_shelf () |> append (create_book |> customize) |> put_shelf» — тож просто послідовність з обєктами, і в тому то і біда що в процесі можуть створюватись копії полиць, що навантажують GC, для програмера навпаки прозоро.

Так без теоркату нічого нормального не напишеш. Бо хочеш попрацювати з будь-якийм IO — а там вже монади, і треба іти розбиратись а що воно таке.

Ну... не згоден. Це як знати теорію типів, щоб бути програмістом. Більшість не зможуть дати визначення, що таке тип даних, але це не заважає в принципі використовувати їх у повсякденному житті та навіть флудити на цю тему.

Монади у Haskell це суто практичний інструмент. Припустимо, що у нас є деяка лінійна послідовність дій. Якщо брати Haskell, то це, з певною оговоркою, є do-нотація. Монада це інструмент, який дозволяє вставляти власний код у середину між діями.

Наприклад, монада Maybe означає, що кожна дія може повернути статус помилки. Наш код у середині просто не буде викликати наступні дії, якщо була отримана помилка.

Монада List (список) означає, що кожна дія повертає список можливих значень, інколи порожній. Наш код у середині робить backtracking (перебір) всіх можливих послідовностей, щоб отримати таку, де ми дійшли до кінця. Таким чином працюють монадичні парсери: ми просто програмуємо які токени коли можливі, а монада вже сама зробить перебір варіантів та відкине тупіки. Саме тому вирішення задачі про 8 ферзів на шахівниці, які не б’ють один одного, розв’язується у Haskell у 3-4 рядки, бо на треба запрограмувати лише один крок (які варіанти треба розглянути на наступному кроці), а решту зробить монада List.

Монада IO. Ну це просто шлях сказати, що кожна дія може якось взаємодіяти зі зовнішнім світом, тому їх треба обов’язково виконувати строго послідовно.

Думаю, що 90% прикладних Haskell програмістів не знають теорію категорій.

Але якщо взяти окамл — там теоркату нема

Там просто меньше абстракцій. Це як C++ у стилі booost та просто Сі з класами.

А яка різниця що там копія полиці чи нє. Код виглядає як щось типу
«get_shelf () |> append (create_book |> customize) |> put_shelf» — тож просто послідовність з обєктами, і в тому то і біда що в процесі можуть створюватись копії полиць, що навантажують GC, для програмера навпаки прозоро.

Я скоріше про те, що коли у програміста відбирають можливість змінювати змінні, то він почуває себе як боксер, якому заборонили використовувати кулаки

Я скоріше про те, що коли у програміста відбирають можливість змінювати змінні, то він почуває себе як боксер, якому заборонили використовувати кулаки

Ну, насправді, це корисно. Так, це не звично. Але дійсно допомагає виключити деякі помилки. І константами це не заміниш — бо константа відома на стадії компіляції, а тут значення може бути обчислене у рантаймі, але ніколи не повинно бути зміненим. Мені ця штука в Rust подобається.

Хочеш змінювати — визнач явно.

Ну, насправді, це корисно. Так, це не звично. Але дійсно допомагає виключити деякі помилки.

Угу, тільки відразу зникають цикли.

Хочеш змінювати — визнач явно.

Ну... ні, скоріше так: хочеш змінювати — програмуй на Rust. У Haskell у тебе взагалі немає ніякої можливості працювати зі змінними.

2000 рік, 8 клас
Pascal, але швидко розпробував С та С++
Ще були спроби освоіти Turbo ASM під MS DOS

Не жалію, обрані інструменти дали розуміння що таке ПК та архітектура з точки зору заліза

О, так! Я теж вважаю, що будь-який програміст, навіть якщо далі буде працювати з чимось високорівневим, як то SQL чи web повинен освоїти, хоча-б базово, щось нізкорівневе на кшталт C/Rust/C++ — банально для розуміння як працює комп’ютер. Бо потім люди щіро дивуються, що заміна типу даних зі строки на число знатно пришвидшує роботу ;)

ну і плюс “залізні” мови цікави тім що вони близко до реального світу, не так абстрактно все. Якщо б в мене менталка позволяла, я б мабуть в Rust вкатилася. Він на Кложу чімось схож(не можу зрозуміти чім)

доречі є кльовий гайд
gist.github.com/...​akes/4af1023b6c5162c6f8f0

awwwwwwww 🥰🥰🥰
Learning Rust won’t assist you in making the ontological leap from a tired stereotype into something sentient and real. You will remain a replaceable silhouette with no discernible identity. It might even exacerbate the problem. However, it will give you a useful tool for writing low-level software.

О, гайд залишу у себе в закладках.

Навряд хтось пише веб-застосунки на С

Як ембедедд девелоперу ще років 6 тому доводилось, але зараз вже ні, бо дешеве залізо вже дозволяє запускати лінукс з пітоном, або сам пітон.

Ну а так вибору в мене не так багато. Що підходить оптимально під поставлену задачу те і використовую. Колись був С, зараз пітон, бо це пришвидшує розробку в рази.

Тобто — спочатку обрали домен, а вже потім — мову.

Я відштовхувався від того, що хотів створювати сайти. Тому взяв на той час одну з найпопулярніших книжок на цю тему та вивчив все, що там було. Вивчав за тодішнім виданням, зараз вже є 6-те:
www.amazon.com/dp/1492093823

З часом я сфокусувався на тому, що мені більше подобається.

Прості днамічні веб сторінки я теж почав писати саме на PHP — подивитись статус системи чи якоїсь своєї автоматизації. Та й взагалі як універсальна заміна GUI. Але наприкінці 200х Python + Tornado/django виглядало більш ... структурованим... мабуть так. Та й коли всі скрипти на Python то й веб-морду логічніше вже на ньому-ж писати. Тому з 200х я до PHP не торкався, тільки сайти адмінив, налагоджував, всяке таке...

тому що це основна мова домену який мені цікавий

В університеті на першому курсі вчили C++, і тоді я купив у крамниці в одному з корпусів університету книжку зі списку рекомендованої літератури. Коли через рік після отримання диплому магістра вирішив шукати роботу розробником програмного забезпечення, дістав ту книжечку і читав, щоб підготуватися до співбесід. Більшість співбесід були невдалими, оскільки досвіду в програмуванні в мене не було та і у тій книжечці було відсутнє багато що з того, що запитують у С++ розробника на співбесіді (це не єдина причина з якої я не буду рекомендувати ту книжку), та зрештою одна зі співбесід була вдалою і посаду стажера мені вдалося отримати, таким чином було обрано домен.

Я в бібліотеці брав Страуструпа — але далі пари перших глав та кількох консольних прикладів діло не пішло. Сам не розумію, чому. При тому що Кернігана і Річі я прочитав всю як якусь художню і навіть на розвалах шукав і знайшов собі (потім у мене її взяли почитати і потеряли... ;( )

Як ви обирали мову програмування? Чому саме цю?

Спочатку побільше інформації — статті і ютуб на тему "Найкращі мови програмування...

Далі відсів...
мінус старі...
мінус веб-орієнтовані...
мінус супернові та незрозумілі...
мінус вузькоспеціалізовані...
мінус Scratch (подумав, шо буде мало)

Залишилося 2 мови — Java і C#
Далі почав скачувати книжки... пробувати читати... листати...
Подумав, такі дві великі мови мабуть дофіга, треба вибрати одну...
Поставив Visual Studio... усе наче нормально...
Пробував ставити IDE для Java... щось там не дуже зручно... треба знати англійську... якісь перепони від самого початку...
Вирішив, що Java всьо... хай буде комусь іншому...
Видалив усе що було по джаві — книжки, відео

Так залишилася одна мова — C#
(може колись вивчу 🙃)

У мене старша донька в ліцеї вчить C# тож мені іноді теж приходиться допомагати розібратись ;) Але ніт, не вразила, можливо тому, що Mono виглядає як ... щось неповноцінне, а я більше люблю працювати з Linux та Mac

Dot net вже повноцінно на Linux та Mac працює. Моно не треба

Ну, вже мені не актуально. Хоча те, що працює, звісно, дуже гарно. Доречі, відкрита реалізація, чи з ліцензійними обмеженнями якимось?

Доречі, ще до появи Google Music/Spotify у мене була доволі велика колекція музики, десь гіг під 200 у mp3. А десктоп у мене Linux — тож, я шукав плеєри, яки могли індексувати всю цю музику і нормально з нею працювати. І мені здивувало, що плеєр на Mono індексував в рази швидше кількох інших, що були написані на С/C++ в тому числі (я вже не пам’ятаю всі, які я тестив). І інтерфейс був теж швидше.

Выдернуть из mp3 теги ID3 можно очень легко и быстро. А вот чтобы посчитать битрейт и длину mp3, нужно просканировать весь файл целиком. Можно конечно выдернуть какой-то рандомный фрейм из середины, и по нему посчитать длину, но это будет не точно, и если битрейт переменный, то совсем неточно. Так что скорость упирается в этот факт.

Та все це зрозуміло, але я ж не знаю, що саме робила кожна з цих програм. я просто шукав якійсь плеер, який міг проіндексувати колекцію і швидко шукати по назві, автору, альбому.

Не факт, що той, що на моно брав тільки теги, і не факт, що всі інші — робили повне сканування. Я просто не знаю.

Але мені здавалося, що все-ж C++ повинен бути швидше. При всіх інших рівних умовах.

А виявилось, що це не так. І навіть після сканування і створення внутрішнього індексу бібліотеки — інтерфейс на Mono працював швидше, менше лагав. Наприклад, фільтрування списку пісень паралельно з набором у полі пошуку.

Зараз, звісно, це мене не дивує. Я з донькою розбирав її лабораторки на С# - і одну для перевірки переписав на Python (треба було перевірити деякі твердження її викладача, ну і показати їй). Так ось мій код на Python виконався швидше, ніж приклад їх викладача на C# який вже скомпильований. Тобто справа у кривізні рук значно частіше, ніж в конкретній мові.

Я б не сказав, що Java якось орієнтована на web. Скоріше на великі корпоративні застосунки, як, доречі, і C#.

Скоріше на великі корпоративні застосунки, як, доречі, і C#

як видно, що мова орієнтована на великі корпоративні застосунки ? 🤔

(ну от бачу книжку «Изучаем C# через разработку игр на Unity», 5 изд., 2022 ..... це ж наче щось інше? 🤔)

А як видно, що вона орієнтована на web чи Unity? ;)

Чому корпоративні застосунки не можуть включати в себе ігри чи використовувати Unity, але не для ігор? Чи не можуть бути великими, корпоративними WEB-застосунками?

Якщо я не помиляюсь, історично C# був відповіддю майкрософта «а ми зробимо свою Java з іграми та куртизанками».

історично C# був відповіддю майкрософта "а ми зробимо свою Java

тобто при бажанні можна створити свою мову програмування на кирилиці — щоб люди не мучилися з англійською? 🤔

Звісно, можна. Хоч на клінописі.

Щоб люди мучились з кирилицею :)

Так вже ж — не до ночі буде згадана 1ес

_https://xn—80aaf6ah.xn—j1amh/ ;) (мавка.укр)

Ну так ми в школі вчили кириличну, навіть україномовну НАМ.

— пайтон — бо хайп на ШІ
— джс — бо хайп на фронтенд та ЗП в кілобакс після 3-х місячних курсів, ага
— плюси — хтось через любов до ігор, а хтось просто любить страждати
— джава — бо не хочуть страждати там, де страждають любителі плюсів
— раст — бо постраждав на плюсах і більше не хочу (а хочу страждати по-новому)
— все інше — деривативи від попереднього

Python ще всіляка автоматизація, пайплайни, деплой. Доречі, обробку відеопотоків зі супутника в кабельну мережу у нас колись теж Python лопатив. Тож це не тільки ШІ, ох, далеко не тільки. Та й купа веб-проектів на ньому є.

Java прикольна, але таскати за собою JVM... (А-ха-ха, хто-б казав, з Python-то! :D але тим не менш... Python хоч майже всюди є і його можна не компілювати...)

JS (точніше nodejs) — я як попрацював з встановленням пакетів і отета всьо... зрозумів, що переходити з Python сенсу немає.

Python ще всіляка автоматизація, пайплайни, деплой

От тільки це не тому що оте мовне ізвращєніє ліпше, а тому що загальний рівень опустився до нього )) Ну і мода. Це шось на кшталт тіктока ))

Ліпше ніж що? ;)

Щодо загального рівня — це не про мову (хоча той-же Python, щоб там не казали, читати (а також підтримувати) значно простіше, ніж, наприклад, Perl) а про рівень, якщо раніше ви бачили тільки той код, що був гарний і саме тому поширився, то тепер кожен може викласти на git(hub|lab) що завгодно. Як в тому: «раніше про те, що ти дурачок знали тількі рідні, а з поширенням соціальних мереж — всі» © :D

C, мені, наприклад, подобається. Але боже збав на ньому підтримувати якісь парсери складних структур даних, що постійно змінюються (чи постійно змінюються вимоги до того, що треба отримати).

Тож кожній мові своє місце.

Я не застав давніх часів, але високий рівень — це як? Як протилежність до цієї скриптухи уявляється щось типу під кожну лібу робити одним файлом бінарник на С, який буде перевіряти наявність системних бібліотек і вручну через fork()+execve() стартувати компілятор? Чи збірка кожного об’єктного файлу і лінковка взагалі вручну?

То був сарказм і товстий тролінг пітоністів взагалі ))
Але, якщо вже зачіпилися, то колись був такий жарт — «як ти це зробив?» Та «з допомогою sed, awk, shell і якоїсь матері». ) а ще є cat, cut, tr, і безлічь стандартних інструментів, що за допомогою пайпів зроблять усе що треба в плані «скріптінга» чи «парсінга». Для більш сурових речей, є Lex і Yacc, як наприклад. Хоч свою власну мову, або свою БД, або шо завгодно, де треба лексичний аналізатор і компілятор. Про вінду не треба, бо є Cygwin.

У мене є правило — якщо задача не вирішується в консолі «однострічкою» (чи якщо шел скріпт більше ніж 2 екрани, приблизно 60 стрічок) — треба брати «нормальну» мову ;)

А щодо швидкості — github.com/sciguy16/xorfiles , там, наприкінці порівнюються rust/python реалізації. Так ось 6.5М (rust) проти 4.7M (python) — це точно не «dramatically slow». «В РАЗы» (як полюбляють інколи писати, читати з надривом і наголосом на останій слог :D )

з допомогою sed, awk, shell і якоїсь матері

О так, якщо ще доповнити xpath для XML і jq для JSON, то для досить широкого кола задач до пітону просто не доходитимуть руки.

А є ж ще «три в одному»! — yq _https://github.com/mikefarah/yq#readme ;)

Ось тільки підтримувати всі ці «однострічки» — пекельне пекло. Бо ще додати регулярки і часом перестаєш розуміти, де закінчилася твоя однострічка і де вже почався brainfuck :D

А у Sun Microsystem була прикольна скриптова мова Х11 ))

Clojure. Мені подобається REPL, ФП, code as data, те що все є виразом,
іммутабельни структури даних, nil pruning, functional core imperative shell,
JVM

якщо зовсім простий код:
дословно: юзер з кешу, або юзер з бази даних, або с зовнішньой системи
або, зарегать нового та повернуть айді, або, якщо ничого з цього не вийшло то
викінуть ексепшн

(or
  (cached-user)
  (user-from-database)
  (user-from-somewhere-else)
  (when-let [id (register-new-user)]
    (user-from-db id))
  (throw "something really unexpected happend"))

в цілому я дуже швидко на Кложе вирішую задачи,

вот приклад вже більш реального коду, вчора за 15хв накатала штуку
яка компіляє індекс для коллекціі якій дозволяє робити вибірку по проізвольной
кількості полей по хешу за O(1)

(defn hashindex
  [coll match-fn]
  (let [vcoll (into [] coll)
        _     (when (> (count vcoll) 500000)
                (throw (ex-info "collection is too big, use db instead"
                         {:count       (count vcoll)
                          :row-example (pr-str (first coll))})))
        index
        (->> (for [[idx m] (map-indexed vector vcoll)
                   tag     (match-fn m)
                   :when   tag]
               [(hash tag) idx])
          (group-by first))]
    (fn [value]
      (distinct (for [hashed        (map hash (match-fn value))
                      [_ match-idx] (get index hashed)
                      :when         match-idx]
                  (get vcoll match-idx))))))

Ну окей, написалось швидко, а як це потім рефакторить/дебажити/модифікувати?

так що тут рефакторіти це маленька функція чистая не залежить ні від бази ні від чого, ну там є на неї тести, але воно і так очевидно

суттєво вона заменяє кусочок sql апі бо ходити до бази за таким занадто дорого якщо до 30к рядків простіше їх предзавантажити в памʼять в робити матчінг в апці ніж робити раундтріп до бази

це вузьке місце яке показав профайлинг бо цій запит пробивав кеш тому що дані на вході дуже різноманітні

як приклад чогось self contained що не відноситься до nda і не потребує якихось додаткових знань, контексту

Мене в кложі бентежить оця дсльність разом з динамічністю коли в тебе купа функцій з кастомним синтаксисом щось приймають на вхід щось віддають і важко простежити а шоб воно матчилось.
Ця функція наприклад ще відносно проста, а якщо в тебе там щось що приймає-віддає структури чи кастомні типи, і в тебе треба похімічить з мемберами в структурах. А юсаджі по всьому коду розкидані.

> структури та кастомни типи

ніяких кастомних типов (якщо це не щось дуже спеціфичне, чи інтероп з Java)

зазвичай це або примітив в якому з назви має бути все зрозуміло
або коллекція примітивов, або коллекція звичайних мап (хеш мапа, ключ значення), або null(nil)

і далі весь core мови побудован на манипуляціі ціми коллекціями.
таким чином в вас максимально гибки можливости по трансформаціі даних.

це як математика, є аксіоми(або сутністі), їх дуже мало, і є нескінченна різноманитність трансормацій побудована на ціх сутністях
для того щоб зробити те що вам подобається

Я в одной компании поменял 4 языка за год. Не я выбираю языки а компания.

Ну, наприклад, PowerShell я теж не обирав і не обрав-би (мем зі священником «ну нафіг!» :D)...

Невже вам все одно що робити і який інструмент використовувати? Зрозуміло, що платять не за любов, а за роботу, але ж якісь вподобання є?

Я навіть додому інструменти (викрутки, мультітул, таке все) підбирав довго і прискипливо...

Невже вам все одно що робити і який інструмент використовувати? Зрозуміло, що платять не за любов, а за роботу, але ж якісь вподобання є?

Я не могу контролировать обстоятельства и текущие потребности бизнеса. Это просто невозможно. Но я могу изменить свое отношение и в глубине себя принять правила игры. Если меня переведут на проект с VBScript на полгода, то я по этому поводу буду расстраиваться около пары часов — не больше.

Ну додому можеш обирати що хочеш. Я, наприклад, обожнюю LUA, але реально роботи не знайду там.
У компаніях ти або працюєш тільки із інструментами які дає замовник або якщо можеш приймати рішення то обираєш найкращій для цієї задачі. І навіть у другому випадку немає такого "подобається"/"не подобається" — на першому місці економічні штуки типу за скільки часу (читай грошей) ми зможемо порішати цю таску на цій тулзі, скільки людей на ринку та скільки грошей вони хочуть і т/д.
Ти ж як сеньйор девопс маєш розуміти ці штуки, адже полюбасу приймаєш подібні рішення.

Ні, це все зрозуміло. Але.

Чи вплинув ваш професійний шлях на те, з якою мовою ви зараз працюєте, чи навпаки — чи вплинули інструменти , які ви обирали, на ваш шлях? Які особисті вподобання і чому?

Ну, наприклад, якщо б я зараз щось робив (для себе або свій бізнес-проект) і обирав мову — то вибір би був, скоріше за все, між Python та Rust, в залежності від проекту.

Доречі, а чому саме LUA? ;) Пост саме про це.

LUA як базовий набір LEGO — ти маєш прості кубики, а далі робиш щось складніше. Не перевантажена абстракціями і синтаксичним цукром. Має шикарну реалізацію ООП. Корутини з`явились ще до того як це стало мейнстримом
Насправді досить потужний інструмент, який був дуже недооцінений і здебільшого використовується як скриптова мова для чогось.
Сам на ній кодив у CoronaSDK, NodeMcu та трохи Roblox. Також використовую як скриптову мову для Go проектів

В 2000-х годах Lua очень широко использовался для скриптования логики игр, когда были движки с однопоточным рендерингом. Ну а так вообще целенаправленно искать вакансии конкретно на Lua нет смысла, можно просто использовать для скриптования логики. Ну или писать настройки, где возможен ещё какой-то код.

макроси в WoW досі на lua (підозрюю, що реалізація аддонів також, але тут не впевнений)

А ще можна ТУІ для нвіма малювати і плюгіни до нього ж)

:D

Насправді, вивчити сінтаксіс мови можна доволі швидко, скажемо за місяць. Ще кілька місяців піде на вивчення стандартної бібліотеки і шаблонів. Тож вивчити 4 мови за рік на рівні «можу писати і воно працює» — цілком реально.

Ефективно користуватись всіма можливостями та «мислити в парадігмі мови» — це вже складніше, це від року і більше. В середньому. Бо бачив і вундеркіндів.

ну я зараз пишу 90% бекенд на Кложе тобто JVM і тулинг, можу писати бекенд на Го, Питоне, Node.js (чи що там зараз в JS основне) також можу робити фронтенд, розумію Реакт, люблю дізайн (тот що графичний) і тот що системний, в цілому що я тількі web adjacent не робила, вот зараз оптимизую одну складну історію, в якой треба шаріти в аллоакацию ресурсов так щоб еффективно опрацьовувати таски, дуже цікаво.

так до чого я це все 😊
мені здається що досвід решає, а яка само мова це ну не так важливо, мабуть.

Так, досвід рішає, згоден.

Але мова — теж важливо. Наприклад, за рахунок «дінамічності» зробити якийсь «прототип» на Python можна значно швидше, ніж, наприклад, на Rust.

З іншого боку, коли починаєш рахувати і проектувати систему під максимально оптимальне використання «заліза» — то швидкість розробки вже буде приблизно рівною. Бо коли мій бот почав «падати» від недостатку оперативки на Raspberry Zero — прийшлося переписати його оптимальніше. А зараз переписав взагалі на Rust і використання пам’яті зменшилось в рази. Але-ж, поки писав прийшлося додати кілька типів, бо «просто розпарсити в словар з різними типами даних» — вже ж так не працює ;)

Це дуже, дуже залежить від задачі.
Для багатьох потреб прототипування одним із лідерів буде наприклад Вордпрес. Тому сорян, але без контексту які саме задачі треба прототипувати у Вебі, це виглядає ну трошки натягнуто.

Натягнуто що саме? Вас тригернув Python? Ну нехай буде PHP чи будь-яка динамічна мова (доречі, вордпресс — не мова).

Мова з динамічними типами, «автоматичним» приведенням типів і відсутністю необхідності піклуватись про роботу з памʼятью потребує значно менше ресурсів від програміста.

Нє ну просто залежно від прототип чого вам потрібно зробити. Якшо прототип наприклад деплой скрипта, то звісно пайтон чи що там ще луччє. Але якшо це типова для стартапів перевірка Proof of concept якогось веб-сервісу з веб-мордою із більш-менш стандартними полями / формами / кабінетом користувача, то швидше CMS на похапе це навряд чи де можна зробити.

А ще я бачив прекрасний приклад, коли конкуруючий із моїм проектом на Друпалі стартап гордо кидав понти шо ми не будемо робити наш сервіс на CMS, ми кавайно пишемо все на Symphony бо ми тру чуваки. Це кінчилось тим, що вони не могли фільтрувати базу своїх кастомерів по параметрам, бо це ж треба було на початку заморочитись щоб в формі реєстрації зробити select замість input...

А потім коли проект в них розрісся то все, поїзд вже пішов бо база користувачів вже набита )
Як я з них ржав.

Нє, ну так то і я бачив стартапи на Python/Django, отой самий Symphony, Drupal, NodeJS, Ruby (Rails) і навіть щось там мікрософтівське ASP .Net чі шо.

Можу вас сказати, що фейл залежить відь великої кількості причин — і мова там точно не перша. А те, що не змогли зробити там якийсь фільтр — то це ж про кваліфікацію, не про мову чи фреймворк, знову-ж таки.

Нє ну розуміння тоді їм не вистачило, але ж якби під руками був той же Друпал де формочку реєстрації на свій смак наклацати дуже швидко, то може вони б так не лопухнулися. Це ж навіть не питання мови а питання найбільш швидкого зручного дешевого способу втілити потрібні зміни в проекті. І Сімфоні і Друпал то ж всьо пиха.

Причому що в моєму, що в їх випадку, прототип власне і переріс в проект.

Я от, доречі, впевнений що в сучасних умовах бути поліглотом в програмуванні це просто мастхев.

Підписатись на коментарі