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

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

Если человеку нужно, чтобы определение функции начиналось со слова function и т.д. и т.п., то в программировании ему делать нечего. Pascal возник как чисто академический язык, но, к сожалению, в отличии от ЛОГО его восприняли слишком серьёзно. Ущерб от его внедрения в ещё советскую iT-отрасль оценить просто невозможно.

Вы путаете понятия программирования, описания взаимодействия человека с компьютером, и кодирование. Вещи надо называть своими именами, что в Паскале и было сделано Н.Виртом. Не на пустом месте, а на основе Алгола. Мантры насчёт академического языка и бреда о его советском прошлом просто смехотворны. Тогда на больших машинах использовались другие языки, а в начале 90х, после развала, на персоналках стали распространяться Turbo Pascal и  Turbo C.  Потом уже появилась среда Delphi и С++Builder. Объединение двух языков под общей крышей в одной среде программирования отлично показало все многочисленные недостатки языка С++, включая его убогую нечитабельность для самих носителей английского языка. Но за сложность кодирования больше платят, как прищнался сам создатель языка С++.

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

Если человеку нужно, чтобы определение функции начиналось со слова function и т.д. и т.п., то в программировании ему делать нечего. Pascal возник как чисто академический язык, но, к сожалению, в отличии от ЛОГО его восприняли слишком серьёзно. Ущерб от его внедрения в ещё советскую iT-отрасль оценить просто невозможно.

Вы путаете понятия программирования, описания взаимодействия человека с компьютером, и кодирование. Вещи надо называть своими именами, что в Паскале и было сделано Н.Виртом. Не на пустом месте, а на основе Алгола. Мантры насчёт академического языка и бреда о его советском прошлом просто смехотворны. Тогда на больших машинах использовались другие языки, а в начале 90х, после развала, на персоналках стали распространяться Turbo Pascal и  Turbo C.  Потом уже появилась среда Delphi и С++Builder. Объединение двух языков под общей крышей в одной среде программирования отлично показало все многочисленные недостатки языка С++, включая его убогую нечитабельность для самих носителей английского языка. Но за сложность кодирования больше платят, как признался сам создатель языка С++.

[yacc]

Я наслышан, что в астрономия (научная деятельность) на 90% состоит из программирования.

1. Английский. Значительная часть научных статей будет написана на английском

2. Смотрим сюда  - https://ascl.net/
Это большая библиотека астрофизических алгоритмов для моделирования.
Например вот https://ascl.net/2511.010 - интерфейс на питоне, низкоуровневая часть - фортран и Си.
Если немного полистать там найдется много чего на питоне.

Отсюда вывод - надо знать два языка - Питон ( Python ) и С ( Си ).
Причем для Питона надо знать вовсе не IDE  - PyCharm или там VS Code - а Jupyter Notebook - именно он используется учеными для исследований. Запускается в браузере.

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

Все остальные языки -  типа С++ или Java - сугубо вторичны. Все равно вы в университете будете пользоваться теми алгоритмами, что написаны на кафедре - а там может быть и Фортран, и Паскаль ( в 90-е был моден из-за быстрой компиляции и выполнения ) либо что-то более современное.
Решить относительно быстро систему дифференциальных уравнений и вывести график - это именно Jupyter Notebook - я как-то тряхнул стариной и решил численно SEIRD модель эпидемий в нем. На ascl.net значительное количество именно последних алгоритмов сделано именно на нем - это примерно как Эксель, только для ученых.

[e+]

Программирование != кодированию, но кодирование - это часть программирования. И от этого никуда не деться, как от того, что проектирование сверху всегда будет основываться на возможностях среды/языка/... (как угодно можно назвать).
АЛГОЛ, Вирт, читаемость носителями английского, ... 

Приходилось, кстати, работать и с Delphi и Builder одновременно. "Недостатки" С++ как-то не проявлялись.

Язык - это инструмент. И как любой инструмент - имеет ниши где его использование действительно может быть удачным и наоборот. Возможно, что Pascal действительно мог бы стать заменой BASIC для обучения программированию в средней школе, но что-то пошло не так... А по факту - почти всё серьёзное (ОС, вычислительные библиотеки, CAD, и много чего ещё) пишется на С/C++ и его производных. И когда сначала людям с какой-то фанатичность вбивают в голову что это вот единственно верный язык, то столкновение с реальностью потом бывает очень больное.

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

[yacc]

А по факту - почти всё серьёзное (ОС, вычислительные библиотеки, CAD, и много чего ещё) пишется на С/C++ и его производных.

LAPACK - библиотека линейной алгебры, широко используемая в научной среде - это изначально и до сих пор - Фортран - все порты появились позже.
Причем фортран вполне себе отлично распраллеливался и распараллеливается на суперкопьютерах ( MPP ).
Вроде как топикстартер не собирался писать ОС или CAD, а спрашивал про научные вычисления.
А вот мультипарадигменный С++ в науке не так часто используется, как в коммерческом ПО.

[CyberManiac]

всё же настоящий программист должен без проблем уметь учить языки

Не надо делать из людей программистов! Особенно если оно им нафиг не надо. Такое чувство, что первое сообщение темы вообще никто не читал. Человек почему-то решил, что научная деятельность в области астрономии равна программированию. Так ведь не равна. Даже приблизительно не равна. И гвозди забивают Питоном не потому, что он хороший, а потому что Вольфарм, Мэпл и даже Маткад стоят совсем неиллюзорных денег.

[e+]

А по факту - почти всё серьёзное (ОС, вычислительные библиотеки, CAD, и много чего ещё) пишется на С/C++ и его производных.

LAPACK - библиотека линейной алгебры, широко используемая в научной среде - это изначально и до сих пор - Фортран - все порты появились позже.
Причем фортран вполне себе отлично распраллеливался и распараллеливается на суперкопьютерах ( MPP ).
Вроде как топикстартер не собирался писать ОС или CAD, а спрашивал про научные вычисления.
А вот мультипарадигменный С++ в науке не так часто используется, как в коммерческом ПО.

А MKL - уже на C++. И mpicc никто не отменял.
В целом же, потому выше и писал и про Фортран тоже и именно применительно к параллельным вычислениям.

Не надо делать из людей программистов! Особенно если оно им нафиг не надо.

Истинно глаголите!

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

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

[yacc]

А MKL - уже на C++. И mpicc никто не отменял.

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

Я вот matplotlib использую - но это же не значит что я лезу в ее исходные коды.

[e+]

А MKL - уже на C++. И mpicc никто не отменял.

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

Но если вам нужно будет написать непосредственно сам ресурсоёмкий расчётный алгоритм, то его будет иметь смысл писать уж точно не на Питоне. А вот на C/C++ это возможно. Понятное дело, что необходимость использования тех или иных библиотек может привести к выбору например Фортрана. Каждому инструменту - свою задачу.

[yacc]

Но если вам нужно будет написать непосредственно сам ресурсоёмкий расчётный алгоритм, то его будет иметь смысл писать уж точно не на Питоне.  А вот на C/C++ это возможно.

Как правило подобные алгоритмы разрабатываются на специализированных кафедрах - например вычислительной физики. Где народ учат именно писать быстрые алгоритмы числовых математических методов. На прикладных кафедрах - типа астрономии - берут готовые расчетные алгоритмы типовых блоков - типа LAPACK - и свои дифференциальные уравнения моделей или чего еще, сводят к ним.
Если что-то мелкое надо посчитать быстро  - тут достаточно С - я его и указал.
А вот С++ сильно избыточен.

[e+]

Но если вам нужно будет написать непосредственно сам ресурсоёмкий расчётный алгоритм, то его будет иметь смысл писать уж точно не на Питоне.  А вот на C/C++ это возможно.

Как правило подобные алгоритмы разрабатываются на специализированных кафедрах - например вычислительной физики. Где народ учат именно писать быстрые алгоритмы числовых математических методов. На прикладных кафедрах - типа астрономии - берут готовые расчетные алгоритмы типовых блоков - типа LAPACK - и свои дифференциальные уравнения моделей или чего еще, сводят к ним.
Если что-то мелкое надо посчитать быстро  - тут достаточно С - я его и указал.
А вот С++ сильно избыточен.

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

А С или С++... ну формально, если используешь iostream, то уже С++. Конечно, современный С++ последних стандартов разросся по сравнению даже с С++ 1998-го. Но чтобы не закапываться ещё и в этом, просто пишу С/С++. Мне кажется, что смысл понятен.

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

С или С++... ну формально, если используешь iostream, то уже С++

Cегодня на Хабре о взлёте Паскаля.
"Многие считают Паскаль ископаемым из школьного класса информатики, но в 2025 году он внезапно обгоняет Go и Rust в индексе TIOBE. Никлаус Вирт не просто подарил нам язык со строгой типизацией, который «вправил мозги» миллионам кодеров. Он был настоящим визионером, совмещавшим софт и железо, когда это ещё не было мейнстримом."

[Ph_user]

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

Если ученик дожил до *сборки таких проектов* - ему уже лучше многое понятно.

Ущерб от его внедрения в ещё советскую iT-отрасль оценить просто невозможно.

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

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

Оно вроде и было так плохо с сями и плюсами уже давно - но фирмы типа майкрософт продолжали грызть кактус уже больше трети века и писать свои виндусы и примерно все вокруг них на сях. Если бы си были такие плохие для програмильной промышлености - конкуренты на могучем паскале должны были всех опередить и разорить. Но виндус и в 2025 все еще на сях. Да и юниксоводы на сях все еще свое делают. Даже забезплатно продолжают грызть кактус.

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

Фантазии научников вышли уперты в прикладное животноводство. Животинки все разные и даже во времена еще терпимо мощных головой гетерозисов первого-второго поколений от начала конца какая-то часть из обязательно прогоняемых через среднюю школу животинок еще могла выучить и потом сдать на приличные оценки экзамены по бейсику. С паскалем уже могло быть сильно хуже и с более сложными примерно никак. А среднюю школу в теории должны пройти и сдать экзамены все прогоняемые там животинки. Хотя к пониманию в програмирование может быть пригодно меньше 1процента голов из всех. Потому вот министерство образования более разумно оценило перспективы и попробовало засунуть в школьные програмы самое простое из возможных вариантов. Т.к. итоговым продуктом средней школы должны быть приличные оценки вместо кучи двоек от плохо могущих в паскать или еще че похуже для головы. Школа это только комбинат по получению хороших оценок и там все должно быть посильно примерно всем.

А MKL - уже на C++.

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

А вот С++ сильно избыточен.

Когда надо считать быстро на устаревшей уже х86 архитектуре - там надо считать на костыльном ускорителе вычислений чисел. А центральный процесор только чтобы виндус загрузить и програму скомпилировать или прочитать из постояной памяти в ускоритель. А сами ускорители там опен_цл-куда-вулкан-директ_компут - скорее сишные по апи или си+специализация по архитектуре ускорителей типа полуасемблера шейдерного. Даже если упорото заточить все на самый широкий симд об 512бит - те биты только между исполнительными блоками и кешем 1уровня. А дальше тормозная рама. Если астрономическая задача имеет размер больше кешей процесора - это опаньки скорости весьма часто. У ускорителей уже скорость рамы раз в 10 больше жалкой двухканальной ддр5 в товарах для малоимущих. Или думать про покупку зиона макс - но игровой бытовой внешний ускоритель может быть ощутимо дешевле по цене за флоп.

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

Приходилось, кстати, работать и с Delphi и Builder одновременно

О, впервые тут встретился астроном, который оказывается ещё и на C++Builder'e умеет. Вот этот вариант С++ тогда и надо советовать молодому человеку для обучения программированию в области астрономии. Питон и рядом не стоял, интерпретатор графику не тянет. Учиться надо на примерах, в частности по Монтенбруку. У меня в систему AstrobloQ исходники из этой книги добавлены в аддоны проекта Apex. Есть план дать проектам современный интерфейс с 3D OpenGL графикой. Прошло 30 лет, все старые apc проекты на Паскале перекомпилировались в Delphi без проблем, а вот С++ после 20 лет что-то заглючили. Причём в групповом проекте в RAD Studio 13 сборка прошла, а консольные проекты выдают ошибку [ilink32 error] Error: Unresolved External 'Vec3D::Vec3D()' referenced from .... Оригинальные исходники вы могли бы клонировать себе на комп и проверить. Если бы вы нашли в чём причина я был бы очень вам признателен. Это хорошая библиотека для обучения программированию  на С++  по астрономии. 

[e+]

Ошибка Unresolved external возникает если заголовочный файл виден нормально, а вот библиотека, которая должна подключаться на этапе линковки - по той или иной причине не находится. Возможно, что в настройках одного проекте уже есть нужные каталоги (или библиотеки), а у второго - нет.
А астроном я только как любитель.

[yacc]

Питон и рядом не стоял, интерпретатор графику не тянет

Тем не менее у вас достаточно проектов в jupyter notebook в репозитории

а консольные проекты выдают ошибку [ilink32 error] Error: Unresolved External 'Vec3D::Vec3D()' referenced from ....

Скорее всего не подключены библиотеки в проекте - линкер и ругается

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

Скорее всего не подключены библиотеки в проекте - линкер и ругается

Не, сейчас проверил, опции компилятора для проекта Coco указывают на папку исходников cpp, они все в одном директории.

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

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

Все консольные проекты выдают одну и туже ошибку, исходники все в одной папке \cpp. Пока вопрос не решен.

[e+]

Если в групповом проекте сборка проходит, а других - нет, то возникает подозрение, что есть различия в настройках.
Например ILINK_LibraryPath или ILINK_TranslatedLibraryPath.
Или может быть не указан нужный bpi в перечислении LinkPackageImports.
И т.д.

[yacc]

Не, сейчас проверил, опции компилятора для проекта Coco указывают на папку исходников cpp, они все в одном директории.

Не - это немного не так работает: include path - это заголовки.
Библиотеки это library path и зависимости.

Если условно что-общее используется в проекте, то его выносят в библиотеку
Скажем Common

Тогда дерево проектов выглядит так:
+- Common
 -- Vec.h
 -- Vec.cpp
+- Utils
  +- Util1
     -- Util1.h
     -- Util1.cpp
     -- funcs.h  -- использует Vec.h
     -- funcs.cpp

Компилятор для проекта Util1 берет два файла Util1.cpp и funcs.cpp и делает из них объектные файлы Util1.obj и funcs.obj
Далее он линкует их в исполняемый файл, используя стандартную библиотеку, ну скажем msvcrt.lib где много чего
команда будет типа link -out Util1.exe Util1.obj funcs.obj msvcrt.lib
И тут он встречает в funcs.obj что-то из Vec.cpp и в списка подходящего obj или lib ( а это просто набор obj ) где это тело функции/метода - просто нет.
А он - в другом проекте, который скажем собирается в Common.lib
Т.е. вызов должен быть link -out Utils1.exe Util1.obj funcs.obj msvcrt.lib Common.lib
А библиотека Common.lib - указана среди зависимостей либо с полным путем, либо просто именем с указанием пути к ней в library path

Разница с паскалем, ну точнее с объектным паскалем/модулой-2/дельфи в том, что у них нет как таковых заголовочных файлов.

Обновлю: насколько понимаю точно такой же проект описан тут - https://astronomy.ru/forum/index.php/topic,105562.msg2356361.html#msg2356361
если скачать APCe.zip да посмотреть то там есть файл CMakeLists.txt где указано как собирать в явном виде
Собственно там человек и листинг компиляции предлагал

... компиляция одного файла
g++    -c -o APC_VecMat3D.o APC_VecMat3D.cpp
... сборка объектных файлов в библиотеку
ar rc libAPC.a APC_Cheb.o APC_DE.o APC_IO.o APC_Kepler.o APC_Math.o APC_Moon.o APC_Phys.o APC_Planets.o APC_PrecNut.o APC_Spheric.o APC_Sun.o APC_Time.o APC_VecMat3D.o
... компиляция Coco.cpp, линковка с библиотекой libAPC.a в исполняемый файл Coco
g++     Coco.cpp libAPC.a   -o Coco

Т.е. проект Coco это один файл Coco.cpp плюс библиотека libAPC.a в которую и входят 13 файлов  в том числе APC_VecMat3D.cpp где этот вектор и есть