Как стать автором
Обновить
@richman5read⁠-⁠only

Пользователь

Отправить сообщение
Его использовали, потому что на тот момент он был почти что единственным удобным ЯП для многопоточных задач. Но даже теперь мы видим, что его охват не растет. Конечно, там и синтаксис не очень привычный и еще что-то, но динамическая типизация — это тоже его минус. А развиваются сейчас (или хотя бы хайпятся) ЯП с многопоточностью и статической типизацией.

На заре массового промышленного программирования ЯП с динамической типизацией сыграли свою полезную историческую роль. Но в будущем их ниша — это вспомогательные, простые, с коротким циклом разработки вещи.
UPD
Как насчет Erlang?
А он что, широко распространен?
это где она была закреплена?
В жизни

Вот например что такое «Rocket Science»?
Это разработка больших и крутых систем, куда динамические ЯП не подпускали и близко.

Большинство нейросетевых приложений пишется отнюдь не на Хацкеле/Расте/etc
А при чем здесь ФП?

А, да-да, на банальных Python/Java/etc а низкий уровень на банальном С/С++
А Java и С/С++ это уже динамические языки???
Во-первых, Python растет только последние года два. Во-вторых, динамические языки проще для не-программистов, которые делают небольшие программки для себя, с коротким сроком жизни (о чем я и говорил). И сейчас это стало востребованым. В-третьих, только в последнее время стали активно внедряться мощные и одновременно гибкие системы типов в статические ЯП. В-четвертых, раньше за статическими ЯП прочно была закреплена ниша «rocket science» разработки, и только в последнее время стали появляться и простые статические ЯП (Kotlin, Go), но пока у Python все еще есть гандикап и он этим пользуется.
Python будет прочно сидеть в качестве второго языка для простых разработок. А в остальных областях посмотрим. Но описанное выше замечание все равно будет работать.
у него большая проблема: многое из того что он говорит базируется не на научном подходе, а на религиозных предпочтениях/взглядах
Ну хоть с тем, что ЯП со статической типизацией убирают множество проблем с ошибками типов вы согласны?
Просто стоит предусмотреть эти приятные, но трудоемкие вещи, чтобы потом, при необходимости их воплощения, они выглядели приятно консистентно.
Что-то я кэпом становлюсь…
Настало время собирать камни отзывы и думать, чем его расширять
Если вы захотели делать типобезопасный скриптовый ЯП, то может стоит усилить его и с других сторон? Например: добавить элементы ФП, паттерн-матчинг, метапрограммирование и т.д. Но при этом, чтобы он был прост в освоении, быстр и продуктивен.
Существуют и другие (Terra)
Уже нет.
наследование
Вот здесь хочется вспомнить о сообщениях в Smalltalk.
Так речь же не только про тех разработчиков, которые думают поменять Python на что-то другое. Есть огромное количество разрабов на других ЯП, которые посматривают на Python как на второй ЯП для узких нужд.
Как раз другие технологии понятно почему не взлетают — ниша занята теми, кто ничего менять не хочет. А я говорил про замену JS на основе такой же модели взаимодействия с браузером (впрочем можно и из любого другого ЯП транслировать код в JS). TypeScript вроде подтягивается, но как-то медленно (хотя за ним такие силы стоят).
Да даже если просто JS переписать с нуля, то это будет лучше того что мы сейчас имеем.
Вот и вопрос, почему это никто не смог сделать.
любое увеличение времени разработки воспринимается бизнесом в штыки, его нужно этому бизнесу «продавать»
Было бы еще это желание.
Сомневаюсь, чтобы один и тот же разработчик одинаково эффективно лабал на статике и на динамике. Чисто даже из-за вкусовых предпочтений.
Короче говоря, «динамисты» это гопники, желающие побыстрей срубить бабла и свалить? Ок, я доволен этим определением и замолкаю.
Куда смотрят moderator?
Иногда приходит усталость от толерантного не черно-белого мира, и просто хочется назвать вещи своими именами.
Не из незнания, а из лени, за которую потом приходится платить уже другим.
поэтому люди часто (целых 8% случаев) сталкиваются с проблемой несоответствия типов
Вы не не до конца прочитали это исследование — «отчёты об ошибках несоответствия типов составляют для некоторых проектов большинство отчётов об ошибках, которые можно найти автоматически».
И статическая + строгая типизация — это принципиальное решение этой проблемы, а «устранение базовых коллизий из языка» здесь костыли.
Ах ты ж боже мой, всего лишь Python и JavaScript! А вот ниже в комментариях говориться, что это составляет от 71% до 122% требуемых на данный момент скилов.
Вопрос стоит не «сможет-несможет», а «надо ли это делать?». Ответ очевиден ведь, или нет?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность