Какой язык программирования учить

[yacc]

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

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

Потом уже роботы будут обучены на идеях из гитхаба и будут помогать прогресу

Можем глянуть на гитхаб
https://madnight.github.io/githut/#/pull_requests/2024/1
https://github.blog/news-insights/octoverse/octoverse-2024/
Паскаль там в хвосте - на 50 месте по первой ссылке.
На чем будет учиться ИИ ?

[Karagy]

Да это всё ещё с фортрана и алгола давным давно перекочевало на Паскаль

Большинство кода который что-то численно молотит - до сих пор создается компиляторами фортрана.
Стыдно такое не знать.

[Павел Васильев]

Большинство кода который что-то численно молотит - до сих пор создается компиляторами фортрана.

Где-то, кто-то, что-то ещё какие-то библиотеки на фортране для параллельных вычислений применяет, да, но точно не большинство, не несите бред. Открою большой секрет, сам когда-то начинал программировать на фортране, потом перешел на си и только когда появился OOP перешёл на Delphi и C++Builder. Так что есть с чем сравнить.

[Ph_user]

который что-то численно молотит - до сих пор создается компиляторами фортрана.

Это типа крипту майнят и роботов учат и порнуху перекодируют для стримов только на топовых фортрановых програмах. Так и запишем - фортран начинает и продолжает побеждать в хайенд счете чисел для практических потребностей планеты.

[Karagy]

который что-то численно молотит - до сих пор создается компиляторами фортрана.

Это типа крипту майнят и роботов учат и порнуху перекодируют для стримов только на топовых фортрановых програмах. Так и запишем - фортран начинает и продолжает побеждать в хайенд счете чисел для практических потребностей планеты.

Ты в интернет выйди, спроси, например, у DeepSeek.com

Код: [Выделить]

Покажи список популярных библиотек которые до сих пор используют объектные файлы созданные компиляторами фортрана.А потом уже рассказывай всем что ты там записывать собрался.

[Вантуз]

Неважно на чем, важно чему и как

Важно, по аналогии, вам всё равно на каком языке говорить и писать?

Было бы чтО писать. Язык вторичен.

[Ph_user]

Про это науке низя. Она только должна изучать как работает дозволеное властями.

[Павел Васильев]

Было бы чтО писать. Язык вторичен.

Вы эту мантру зря твердите, она неверна. Просто многие  языки высокого уровня близки по синтаксису и функциональности. Но некоторые более близки к человеческому английскому, понятнее и эффективнее в программировании. Вторичен язык? Библия глаголет - "вначале было слово". В один байт.

[yacc]

и эффективнее в программировании

"Эффективность" - не абстрактное понятие,  а контекстно-зависимое.
Без контекста это спекуляция.
Откровенно глупо считать что более эффективно - алгебра или геометрия.

[Павел Васильев]

"Эффективность" - не абстрактное понятие,  а контекстно-зависимое.

Блеснул глубокими познаниями в эффективности. Молодец, выучил урок, садись, пять. А по языкам то что, все одинаковые? Или всё же есть критерии, раз народ изобретает чтото новое? Но, по большей части, делает другую обёртку хорошо забытого старого. Запатентовать какой-нибудь си-подобный диалект, как правило. Но переплюнуть скорость компиляции языка Object Pascal никак не могут, чайники.

[yacc]

А по языкам то что, все одинаковые? Или всё же есть критерии, раз народ изобретает чтото новое?

Без критерия сравнения пофиг какой использовать ибо не определено какой лучше и почему.

[Karagy]

мне очень понравилось как вот такие вопросы решаются на Julia
https://github.com/EnzymeAD/Reactant.jl

[Павел Васильев]

Без критерия сравнения пофиг какой использовать ибо не определено какой лучше и почему.

Критерии есть, но вам, судя по всему, всё равно будет ли программа с либами собираться за 5 секунд, либо за 5 минут. А по интерпретатору скриптового языка Питон вообще всё очень печально - на Хабре есть статья  сравнения скорости расчёта бигдата в сопоставлении с другими языками, так тест показал в сотни раз медленнее. Непонятно как там сложные нейронки считают. Так что юзайте эту змеюгу сами, и без её скриптов вполне можно обойтись.

[yacc]

Критерии есть, но вам, судя по всему, всё равно будет ли программа с либами собираться за 5 секунд, либо за 5 минут.

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

Но вот человек просто доверил компилятору собрать самого себя и свои библиотеки. Измерив сколько там строк кода исходного.
Для того же С разумеется входил размер того, что в заголовочных файлах - а это то, что подается на вход компилятору.
Результаты не в пользу Паскаля ( FPC )
Pascal - 45k loc/sec
C ( tcc ) - 125k loc/sec
Go - 44k loc/sec

loc - lines of code
https://wiki.alopex.li/LanguageCompilationSpeed

А вот по скорости выполнения Паскаль как-то вообще не смотрится на той же перестановке чисел для получения правильной последовательности.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html
Паскаль обогнали и Ада и Свифт и F# и Фортран и Ocaml и Лисп и Хаскель. Разумеется питон дольше выполняется.
Разумеется все опен-сорсное и на дебиане
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html

Free Pascal Compiler ну вообще никак не выделяется.

[Павел Васильев]

Особенно в облаках. Более того - пересобирать постоянно ВСЕ - откровенно плохой тон - программы разбивают на части и то, что не менялось, перекомпилировать и не надо.

Этот бред обычно повторяют те, кто никогда не разрабатывал сам программ больше килобайта. Не говоря уже про интенсивный апгрейт и поддерку  либ. Ну замени ты какой-то ошибочно названный джуном глобальный илентификатор, обращение к новым данным, ассетам, внешним файлам или классам после рефакторинга или простой замены. В живом проекте это происходит постоянно, по сто раз в день. Да, в идеале можно разбить на части, закатать в dll, в пакеты, но на практике это не работает. Витаете в облаках. По поводу скорости компиляции вообще враньё, ахинея несусветная - возьмите сами компиляторы 32/64 в средах vscode, vstudio и rad studio и на консольной проге, написанной на разных языках (скажем,  на с/с++/с#/pascal) реально откомпилируйте одинаковый расчётный проект. Не говоря уже про сложную программу с gui и 3d графикой. Почувствуете разницу без подгонки под интересы Майкрософт.

[yacc]

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

У меня опыт разработки 33 года. Так вот - интенсивный апгрейд делают те, у кого руки кривые в архитектуре и кто ее сразу грамотно продумать не может. Интенсивная переделка разве что пока проект маленький делается, при поиске и апробации архитектурных решений на небольших тестах, далее это просто достраивают и компиляция и линковка - исключительно инкрементальная.
Постоянно менять интерфейс - а только тут может потребоваться пересборка в библиотеке - вообще откровенно порочная практика.
Более того - библиотеку по-грамотному бьют на части.

И теперь самое веселое - если архитектура проекта разработана, то в целом пофиг на чем писать - хоть на С хоть на GO - ООП в общем-то и не нужен в виде классов С++. Это разве что джунам удобно - разработка через брутфорс компиляцию и отладку делать - грамотность заменяется работоспособностью и долбанием одного и того же в комбинаторике пока работать как надо не начнет

возьмите сами компиляторы 32/64 в средах vscode, vstudio и rad studio

А чем дебиан не понравился ?
Вот возьмите рад студию c дельфи и сделайте проект на ардуино - для монтировки например. Или для Raspberry - на том же Дельфи

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

[Karagy]

В живом проекте это происходит постоянно, по сто раз в день.

Эта фраза очень много рассказывает о авторе!
100 раз в день - это (10 часов * 60 минут) / 100 = билд за 6 минут. Это очень маленький проект.
Для тех у кого вселенная не закончилась на паскале, реальные проекты собираются по 6-10 часов. Т.е. они не могут собраться чаще чем 2 -  3 раз в сутки.
Это при условии что их таки не разбили на отдельно собираемые части не требующие взаимной перекомпиляции. Но вы называет такой подход бредом и оскорбляете собеседников.

[Павел Васильев]

Постоянно менять интерфейс - а только тут может потребоваться пересборка в библиотеке - вообще откровенно порочная практика.
Более того - библиотеку по-грамотному бьют на части.

Скажем так, у нас с вами разные приложения и подходы к проектированию. По части разбиения на части никто с этим не спорит, но это не всегда возможно, особенно для ООП с иерархией объектов, наследуемыми типами классов и перезагружаемыми методами. Добавил что то новое, полезное родителю, плиз, перекомпилируй всё дерево классов или визуальных компонентов. Конечно, совсем дохлые или устаканившиеся либы можно не трогать и подключать без перекомпиляции. Добавлю, у меня в работе есть графический движок с миллионом строк кода, накопилось за 25 лет. Конечно, он разбит на части, десяток пакетов, причём отдельно пакеты для дизайн тайма (GUI, визуальные компоненты) и рантайма (невизуальные классы и компоненты). Да, если инсталлировал пакеты в IDE, то перекомпилировать можно только те, которые не обновляются иногда подолгу. Но и для них поддержка версий IDE требует частой перекомпиляции - те же версии RAD Studio выходят по 2 раза в год, не считая многих патчей. Всё надо перепроверить и устранить возможные глюки. Вопрос, а почему сама американская компания Embarcadero не перейдёт полностью на c/c++, не пошлёт подальше компилятор Delphi? Ответ простой, по причине его скорости, эффективности и надёжности. Однопроходной и нечувствительный к регистру, этого уже достаточно, чтобы его сиподобные компиляторы никогда не догнали по скорости парсинга кода, линковке и сборке больших проектов. Они могли бы на эту тему дать разгромные тесты, но не будут, так как им самим надо продавать свой С++Builder и от Microsoft они сильно зависят.

[Karagy]

А зачем Эмбе бросать нишу где единтвенный конкурент - полукривые FreePascal + Lazarus + LCL, и пытаться вкатываться на IT рыночек уже занятый (бабло, комъюнити) реализациями  C++ от крупных игроков?

[yacc]

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

Вот именно ! - устаканившийся интерфейс не меняется годами. И перекомпиляцию вполне можно подождать, оставив билд на ночь, если очень уж совсем нужно. Быстрая перекомпиляция всего проекта тут не нужна.

Но и для них поддержка версий IDE требует частой перекомпиляции - те же версии RAD Studio выходят по 2 раза в год, не считая многих патчей.

Кто работает на легаси проектах прекрасно знает что узкое место - вовсе не компиляция, а QA и тестирование.
Взял новый компилятор, пересобрал - проверь функционал ВСЕГО проекта - а это ОЧЕНЬ дорого. Поэтому разработчик может долго сидеть на одном компиляторе запросто - потому что стабильность важнее новых фич новой версии компилятора. А с новым компилятором то, что работает, может начать косячить.
Пересаживание на новый компилятор - не быстрый и затратный процесс - надо ВСЕ перепроверить.

Вопрос, а почему сама американская компания Embarcadero не перейдёт полностью на c/c++, не пошлёт подальше компилятор Delphi? Ответ простой, по причине его скорости, эффективности и надёжности.

Причина более прозаична: 1) потому что есть легаси проекты на дельфи и за них готовы платить деньги - зачем закрывать это направление, учитывая что конкурентов на коммерческий Паскаль у них и нет? 2) даже в С++ многие легаси библиотеки у них завязаны на паскаль - тот же VCL - это все нафиг переписывать надо на С++ и далее смотри выше про QA и тестирование. Дешевле поддерживать паскаль-компилятор и чуть его улучшать.

Они могли бы на эту тему дать разгромные тесты

Я предоставил тесты выше. Паскаль если хоть и обгоняет плюсы в компиляции, то уж точно проигрывает ему в производительности самих приложений.
И да - это сам компилятор влоб однопроходный, а вот оптимизатор ВСЕГДА многопроходный - даже для Паскаля. И скорость приложения определяется в значительной степени именно оптимизатором. И тут С/С++ оставляет дельфи позади - даже clang в самом С++ Builder. Конечного пользователя не интересует сколько компилируется проект - важно как быстро работает приложение.