Почему многим не нравятся следующие ЯП?

А как на счёт академического R? Например, среди медиков и биологов (специалистов, а не «я у мамы хакер») он весьма популярен.

С Python всё понятно, он простой и популярный, множество библиотек для не академической аудитории. Perl/Raku всё же для специалистов. Shell тоже для специалиста по администрированию системы (автоматизации задач). Сейчас у Shell есть конкурент - Python, но он не для специалиста.

прошивки для клиентского ТСД

Basic

Уж не Denso что ли?

Клоун, который после сорока возомнил себя дедом-всезнайкой, по существу тебе никогда не ответит.

Ты ж это знаешь, ведь ты старше и его, и меня.

как же прав был Дейкстра насчет когнитивной травмы от васика…

При этом массово пишут программы на Python (странный ЯП, логику написанной программы можно сломать одним пробелом и даже не пикнет, что программист ошибся).

Потому что дебилы

abi изменили в питоне 3.13

Нет. ABI изменится, если собирать питон с опцией –disable-gil.

Если собирать без неё, то всё останется как было и не сломается. Если у тебя C-api библиотека и ты хочешь, чтобы она работала без gil, то придётся это обеспечить, да. Если не хочешь, то просто оставляешь всё как было. Что тут не так?

Абсолютно все внешние библиотеки надо будет перекомпилировать, но сначала отредактировать.

Естественно это не так. Трогать нужно будет только библиотеки, самостоятельно управляющие памятью (их нужно будет сделать потокобезопасными) и только если хочется поддержать работу без gil.
Если хочешь, чтобы твоя библиотека была потокобезопасной, её нужно сделать потокобезопасной. Вот это неожиданность.

Что касается numpy, то в 2.0 они поменяли намного больше, чем того требовал флаг –disable-gil, так что это явно назревшие изменения. А работа без gil разве что поводом для их внедрения выступила, не более.

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

This PEP poses a number of backwards compatibility issues when building CPython with the --disable-gil flag, but those issues do not occur when using the default build configuration. Nearly all the backwards compatibility concerns involve the C-API:

    CPython builds without the GIL will not be ABI compatible with the standard CPython build or with the stable ABI due to changes to the Python object header needed to support biased reference counting. C-API extensions will need to be rebuilt specifically for this version.
    C-API extensions that rely on the GIL to protect global state or object state in C code will need additional explicit locking to remain thread-safe when run without the GIL.
    C-API extensions that use borrowed references in ways that are not safe without the GIL will need to use the equivalent new APIs that return non-borrowed references. Note that only some uses of borrowed references are a concern; only references to objects that might be freed by other threads pose an issue.
    Custom memory allocators (PyMem_SetAllocator) are required to delegate the actual allocation to the previously set allocator. For example, the Python debug allocator and tracing allocators will continue to work because they delegate the allocation to the underlying allocator. On the other hand, wholesale replacing of the allocator (e.g., with jemalloc or tcmalloc) will not work correctly.
    Python objects must be allocated through the standard APIs, such as PyType_GenericNew or PyObject_Malloc. Non-Python objects must not be allocated through those APIs. For example, it is currently acceptable to allocate buffers(non-Python objects) through PyObject_Malloc; that will no longer be allowed and buffers should instead be allocated through PyMem_Malloc, PyMem_RawMalloc, or malloc.

There are fewer potential backwards compatibility issues for Python code:

    Destructors and weak reference callbacks for code objects and top-level function objects are delayed until the next cyclic garbage collection due to the use of deferred reference counting.
    Destructors for some objects accessed by multiple threads may be delayed slightly due to biased reference counting. This is rare: most objects, even those accessed by multiple threads, are destroyed immediately as soon as their reference counts are zero. Two places in the Python standard library tests required gc.collect() calls to continue to pass.

для не академической аудитории

Лол. Как раз таки у академической аудитории питон популярен. Насколько я в курсе популярнее R (и в data science, и в calculus), хотя возможно есть области, где это не так.

для специалиста

Ну и если под специалистами ты подразумеваешь unix-вытиранов, то там у них всё так.
Но современное линукс-администрирование и devops - это в первую очередь питон, ну и шелл для чего-то совсем простого, остальное только в качестве наследия.

GOSUB помню такой вызов процедуры в бейсике, но не помню где и в каком.

В классическом бейсике, скорее всего, ещё от Курца и Кемени. И в Microsoft Basic (не путать с VB и VBA) тоже был.

В эпоху БК главными операторами бейсика были poke и peek, поэтому не считается.

Я про всех, кто его не использует и творит дичь с npm зависимостями, причем, агрессивно.

RANDOMIZE USR …

Потому что разные люди решают разные задачи, а под разные задачи нужны разные ЯП. Если пытаться решать свои задачи на неподходящем для них ЯП то конечно он будет тебе не нравится.

А как на счёт академического R? Например, среди медиков и биологов (специалистов, а не «я у мамы хакер») он весьма популярен.

Потому что R удобен для их типовых задач?

С Python всё понятно, он простой и популярный, множество библиотек для не академической аудитории.

В академической среде Python не менее популярен чем в не академической.

у академической аудитории питон популярен

да, но в англоязычном смысле «academic», т.е. все от студентов-первокурсников до матерых академиков.

R популярен у тех, кто постоянно стат обработкой занимается, а это очень небольшое относительно всего academic аудитория.

С одной стороны это удивительно, как такие всратые языки (как с т.з. классических теорий, так и с т.з. банальной логики), как python и javascript захватили почти весь рынок, а с другой, оно и понятно, скорость добавления фич, возможность писать не думая, массовое и бездумное повышение выразительности языка и т.д. Пока одни думают как сделать хорошо надолго, другие захватывают рынок.

Те, кто выбирает python и nodejs для своих проектов не думают о будущем, у них горизонт планирования пару лет, и для этого срока это нормальный выбор. Но если проект живет дольше, если они его не скинули, то там ТАКОЙ технический долг будет, что в какой-то момент проект проще будет полностью переписать (на новой версии языка и библиотек, и попытаться его выгодно скинуть, пока не повторилось)…

Есть ли альтернативы для популярных скриптовых языков? Не знаю, от задач зависит. Когда то я много писал на perl, потом на волне популярности питона перешел на него… Сейчас считаю, что сложные вещи лучше делать на С++ (он сильно развился, С++ конца 00х и сегодня это совершенно разные языки по выразительности), а для скриптов – bash для несложных системных вещей, perl для более сложных и веба (может даже в связке с С++). В perl мне не нравилось отсутствие ООП, и соотв. невозможность выразительно организовывать код в классы, но сейчас считаю, что если код настолько сложный, что нужны классы, то лучше C++, а для простых вещей достаточно словарей и замыканий.

PS: в моем комменте везде C++ можно заменить на Java (но я ее не люблю).

от студентов-первокурсников до матерых академиков

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

В конторах, где обитают всякие HR, DevOps и бизнес-аналитики, там сама цель бабло и им нужны любые специалисты, на которых можно снизить себестоимость программного продукта. Само собой, они не будут использовать что-то сложное и оригинальное, чтобы не делать ценным грамотного сотрудника. И тут что массово изучают, то и будет востребовано такими конторами. И на каком ЯП можно быстро тяп-ляп состряпать, тот и запросят знать. А как я вижу, программисты в России такие трудоголики, что хоть часы сверяй, когда они в чатике появляются. Раз в чатике трындит, значит на работе.

Java 7 спасѣт тебя!

Те, кто выбирает python и nodejs для своих проектов не думают о будущем, у них горизонт планирования пару лет, и для этого срока это нормальный выбор.

У меня есть питоновский код которому лет 20ть, до сих пор актуален. Давеча такую вот утилиту переписал на питон3 (уже конечно по другому, с учётом 20ти летнего опыта) и она наверное будет жить пока опять совместимость не сломают. ЧЯНТД?

Раз в чатике трындит, значит на работе.

Внезапно любая когнитивно сложная деятельность требует периодов расслабления, когда задача крутится в подсознании, в это время можно и в чатике потрындеть и по улице погулять. Если у Вас не так то значит Вы просто вечный джуниор-эникейщик которому нельзя доверить ничего серьезного.

Мне кажется Вы путаете программирование с копанием земли, от забора до обеда.

Начнём с того, что я не программист. У меня нет такового образования и я не работаю на такой работе, для меня это всего лишь хобби. Но если я пишу, с меня все в шоке. А если интересное, то пишу как отсюда, так до помутнения рассудка. В это время меня вообще не нужно отвлекать чем либо. Потому, мне нельзя работать в конторе. Также когда читаю чужой код (а как иначе? или вы на естественном языке не читая ничего научились писать?), я въедаюсь в ход мыслей того, кто эти тексты написал, а не где-то там комментарии или подобные описания прочитал и хватит.

Тут goto вспоминали выше. Я ради прикола писал с ним код на си в стиле ближе к асму. Код назвали адским адом, но он невероятно быстро работал. Лично мне эта конструкция безумно нравится.

На C++ написан

У меня есть питоновский код которому лет 20ть, до сих пор актуален. Давеча такую вот утилиту переписал на питон3 (уже конечно по другому, с учётом 20ти летнего опыта) и она наверное будет жить пока опять совместимость не сломают. ЧЯНТД?

Утилита это не проект. И скорее всего, она небольшая и ее сравнительно легко было переписать. Наверное, она не сильно завязана на внешних библиотеках. Сравни с с каким-нибудь вебсервисом с кучей функционала, «киллер-фишек», интеграцией в мобилы, с подтягиванием данных из nosql, и прочими прелестями.

PS: и да, ты же переписал ее, это и есть решение технического долга. А теперь представь, что нужно переписывать не одну утилиту, которую ты написал за пару вечеров, а проект, над которым трудилось 10-20 человек в течении 2х лет, каждый рабочий день.

Те, кто выбирает python и nodejs для своих проектов не думают о будущем

Те, кто выбирает Java для своих проектов не думают о будущем

Те, кто выбирает PHP для своих проектов не думают о будущем

Те, кто выбирает Go для своих проектов не думают о будущем

Те, кто выбирает Perl для своих проектов не думают о будущем

Аргументация 80-го уровня. Все языки умрут… На C тоже никто уже не пишет, Perl умер, а на Go больше бекенды не пилят, лишь допиливают созданное в эпоху бума

Сейчас считаю, что сложные вещи лучше делать на С++

Я бы тебя уволил. Проще на условном пхп проект сделать и потом переписать чем поддерживать что-то на C++, если про веб речь

Утилита это не проект

Не пиши бред, дядя, проект на условном python 2 очень-очень просто портировать на python 3, и многие это делали. Занимает оно не больше 2 дней, если в проекте 50-100k строк кода. Те ни себя, ни тебя никто тут не пытается обмануть

Вообще-то то она большая (по нашим меркам, под 1000 строк очень плотного кода) и переписывал я её месяц. И там заложено очень много идей.

Я не согласен с тобой по поводу того что питон подходит только под небольшие скрипты которые написал-забыл-переписал. На питоне даже у нас пишут очень долгоживущий код. Технический долг - а где его нету? У нас технический долг в таких вещах обусловлен не кривой изначальной реализацией а скорее изменением внешних условий/требований и ростом личного мастерства:-)

Так и я не программист:-)

Но в описанном Вами режиме (кажется это называется состоянием потока) не выйдет работать долго, и написанный в таком режиме код обычно невозможно рефакторить. Т.е. так можно написать что то небольшое за один присест, или сделать какую то очень сложную изолированную штуку на которую потом дышать боятся. Что то большее так сделать не выйдет.

При чем здесь аргументация 80-го уровня?

И почему не думать о будущем это плохо? Если нужно быстро здесь и сейчас, то надо брать тот язык, на котором можно это сделать. А там видно будет, может можно будет зафиксировать окружение на текущих версиях интерпретатора, нужных библиотек, операционки и жить с этим много-много лет, а может напротив, проект потребует быстро адаптироваться под изменения среды и тогда нужно будет подбирать инструменты, включая язык, которые позволят это делать с минимальными усилиями. Опять же, количество доступных для найма специалистов играет не последнюю роль в выборе языка.

Рост личного мастерства и дисциплинированная команда сильно уменьшают рост технического долга. Поэтому надо вкладываться в личностное мастерство :).

Один человеко-месяц это все-таки не так уж и много, по трудоемкости я это отношу к небольшим утилитам / проектам. Но это уже тот порог, выше которого, я бы на питоне проект бы не делал. Хотя, конечно, от структуры проекта зависит, от сложности его архитектуры, и взаимодействия с чужими библиотеками. Опять же, если можно зафиксировать окружение на много лет, то это нормально.

Если что, я не считаю свою точку зрения единственно правильной, но при наличие выбора я руководствуюсь ей.

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

Все знают PHP, Node.js, Python, Java

Те, кто выбирает python и nodejs для своих проектов не думают о будущем

И почему не думать о будущем это плохо?

🤯

С++ в вебе используется редко. После слива исходников всех сервисов Яндекса я их изучил, там на C++ [написан] только поисковой движок наполовину, да и то как я подозреваю, потому что начал писаться в 1998 году, а все остальное у них Python/Django

проект на условном python 2 очень-очень просто портировать на python 3, и многие это делали. Занимает оно не больше 2 дней, если в проекте 50-100k строк кода.

100к строк портировать за 2 дня. Ну-ну.

Можешь не верить, реальность от этого не меняется. Показательно, что в последнем питоне даже u-строки все так же «работают»:

>>> u'тест'
'тест'

❯ python --version                                                                                              
Python 3.12.4

Это к слову об обратной совместимости, когда поддержка python 2 прекратилась лет 5 назад. Он официально давно мертв

порог, выше которого, я бы на питоне проект бы не делал

Ну на другом ЯП это бы заняло человеко-год;-)

Ну на другом ЯП это бы заняло человеко-год;-)

Да, поэтому я когда-то и начал использовать скриптовые языки… А вот сейчас мне уже начинает казаться, что если хорошо знать современный С++ в нужной области, то времени займет столько же, если писать надежный код.

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

В задаче о которой я говорю на плюсах бы пришлось писать/искать минипитон, со структурой виртуальных классов и парсером AST. Не факт бы что и за год бы управились…

если писать надежный код.

WTF надежный код? Да, статическая типизация спасает от многих ошибок - но не в случае когда в рантайм создается развесистое дерево из обьектов с виртуальными методами. С другой стороны чем лаконичнее код тем меньше в нем ошибок, так что до какого то размера проекта питон может и плюсы по надежности превосходить, если конечно писать код прямыми руками;-)

Не буду спорить. Наверное, так оно и есть. Я сужу по задачам с которыми я имел дело.

PS: наверное, я просто слишком устал от питона. Меня в нем бесит, что все как-то нелогично, какие-то обряды, какие-то хаки, постоянные особенности синтаксиса и реализации разных библиотек, смесь императивщины и функциональщины в которой не особо поймешь где что кончается и где начинается. И еще эти треклятые отступы, опечатких в которых могут приводить к неправильной работе, но правильному коду… Да куча всего. Пишешь, пишешь, узнаешь что-то регулярно, а прогресса нет – как не знал качественно языка, так и не знаешь, еще и библиотеки раз в несколько лет сильно меняются, нет роста навыков, которые бы качественно ускоряли работу. А в С++ в этом плане мне кажется более логичным и есть накапливание знаний, со временем понимаешь как какие вещи делать быстрее и надежней и эти знания не устаревают, хотя и появляются новые способы с новыми стандартами….

Дык плюсы не меньшая помойка. Не надо юзать все возможности ЯП, надо юзать только то что нужно.

Возможно я люблю питон потому что сам когда то чуть не написал питон, Гвидо опередил:-)

Не понимаю почему у мну нет проблем с отступами?!

gawk ещё и быстрый. Плюс, всегда можешь накатить one true awk

Не надо юзать все возможности ЯП, надо юзать только то что нужно.

А разные библиотеки предлагают разные стили в использовании их функционала.

В целом все озвученные проблемы, наверное, нивелируются до приемлимого уровня, если каждую неделю приходится писать несколько сотен строчек кода. Но я уже много лет использую питон occasionally, бывает что по несколько месяцев ничего на нем не пишу, даже самых маленьких скриптов. Поэтому в быстрой памяти его синтаксис, чуть больше начального уровня, у меня не хранится, а для долговременной он слишком хаотичен, нет фундаментальности.

А разные библиотеки предлагают разные стили в использовании их функционала.

ну дык йопрст… надо юзать те либы которые удобны/привычны.

я уже много лет использую питон occasionally, бывает что по несколько месяцев ничего на нем не пишу, даже самых маленьких скриптов.

тогда понятно. Но это не питоньи проблемы;-) У меня с башом примерно так же, for активно юзаю а всякие if и и сложные перенаправления вывода уже приходится подсматривать.

он слишком хаотичен, нет фундаментальности.

Плюсы гораздо более наркоманские, тех вообще солид рок с его этими бэкслэшами - ничего, живем как то.

Да, man bash регулярно приходится смотреть, как что-то не самое простое нужно сделать. Впрочем для таких случаев у меня хранятся какой-то мой старый код, небольшого объема, как примеры, в который я иногда смотрю (по разным языкам).

Плюсы, конечно, наркоманские, но для меня там видна логическая линия, вокруг которой, конечно, много, гм, странных блужданий и ответвлений. Зато благодаря этой линии мне С++ представляется вполне разумным и ясным, а также понятно, как научиться писать код лучше. Ну и к железу они сильно ближе, что для меня очень важно, как в плане восприятия языка, так и в плане практических интересов.

Тех – да, так я с ним на приличном уровне и не разобрался. Стилевые файлы когда то делал, но вот детально вникнуть как он внутри устроен, как что делает на низком уровне – так руки и не дошли. Впрочем, сейчас это уже мне и не нужно.

Вангую, что тебя скоро забанят.

Чувак, там только Бейсик или Си. […] Это же 80е!

Даже TurboPascal появился уже в 1983 году! Так что не коси под седожопого старпёра, молокосос! :-D

Не пиши бред, дядя, проект на условном python 2 очень-очень просто портировать на python 3, и многие это делали.

Переход со 2-го на 3-ий пыстон занял 15 лет, видимо от исключительной лёгкости переписывания :-/

Занимает оно не больше 2 дней, если в проекте 50-100k строк кода.

Не болтайте ерундой!(С) Трепло …

Те ни себя, ни тебя никто тут не пытается обмануть

Я тебе конечно верю, как же может быть иначе (С) :-D

Трупопоцкал не запускается на ынтврпрайс эмбеддед мобилити.

Поэтому он труп.

А Бейсик - работает в 2024м году.

Так что доставая Мартузана и представляй себе как Петя Бейсиков наконец то смог замутить с Тоней Соображалкиной.

Те, кто выбирает python и nodejs для своих проектов не думают о будущем, у них горизонт планирования пару лет

За ноду ничего не знаю, благо я в неё не погружался. Но про питон это херня полная. Там всё абсолютно нормально с горизонтом планирования. Да, в питоне могут быть значительные ломающие изменения, но их сроки - это десятилетия, а не пара лет. Сколько лет питон 2 сопровождался после выхода третьего?

У java в этом плане дела обстоят лучше, но не принципиально лучше. Да и боли при переходе на новые версии у джавистов больше, по ощущениям.

Плюсы, понятное дело, мамонт обратной совместимости. Но и трудозатрат будет в разы больше. Тут реально питонистам можно раз в 2 года целиком проект переписывать с нуля, просто по фану, и при этом всё равно меньше времени потратят на разработку, чем плюсовики.

Не понимаю почему у мну нет проблем с отступами?!

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

А как на счёт академического R?

Как насчёт ты хотя бы прочитаешь, что такое R? Нет, он не «академический» ни разу.

С Python всё понятно, он простой и популярный, множество библиотек для не академической аудитории.

Что за херню я прочитал? Python — один из основных языков в научной среде, это противопоставление вынуто из заднего прохода.

Переход со 2-го на 3-ий пыстон занял 15 лет

у кого занял?

Почему многим не нравятся следующие ЯП?

Почему тебя это так беспокоит?

ну эт просто, процессор ничего более умного чем goto (jmp) и не знает.
все мудренности абстракций, заумности объектов, и прочие потоки человеческого мышления компилируются в тупые jmp и jump с условием которые и скармливаются камню.
проц покамест вещчъ тупая и простая аки каменный топор