Будущее g++

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

случилось что-то, что мне до конца не понятно

ИМХО случилось Borland и её тотальное страдание фигнёй после Dephi7. D6/7 были ещё вполне популярными и рынок был большой и у нас и забуграми, а за ними хвостом и FPC/Lazarus. Потом пошёл какой-то трэш и угар и среда вернулась в во что-то более-менее внятное где-то к XE2, когда уже и Borland издохла и коммюнити поразбежалось и Embarcadero убрало бесплатные редакции и задрало цены в потолок.

А тем временем случилось x64, которое Делфи не умел ну очень долго, Unicode, ARM, Android. Новые концепции, которые только в новых Дельфях / FPC появляются aka дженерики, дин.массивы нормальные и т.д.

Тем не менее, насколько я знаю, у embedded FPC довольно популярен.

Больше интересен другой факт, откуда взялись паскаль программисты с опытом написания ОС пусть даже в то время когда на рынке была только одна успешная ос и это Юникс

Ты про какое время? Тупо по количеству машин в середине 80-х MS-DOS уделывал все остальные, а MS-DOS писан на асме и переписан с CP/M. Unix был популярен как бесплатная ось, которую много кто щупал в институте, но именно потэтому данная популярность была весьма ограниченная, хоть и не так ограничена, как вендорлокнутые платформы, которым тоже обучали в инстах.

ИМХО случилось Borland и её тотальное страдание фигнёй после Dephi7

Беда случилась где-то в конце 90-х, поскольку еще в 1995 году паскаль был там, где сейчас питон и Си:

https://www.tiobe.com/tiobe-index/

Что случилось между 1995 и 2000 — ума не приложу.

Потом пошёл какой-то трэш и угар и среда вернулась в во что-то более-менее внятное где-то к XE2

Да, XE2 заметно подняло престиж.

А тем временем случилось x64, которое Делфи не умел ну очень долго

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

Unicode, ARM, Android

Надо сказать, что проблема юникода не так уж и проста, и многие языки/либы решают ее неоптимальным способом. В итоге в стандартной либе добавили поле кодировки и размера элемента всем строкам, плюс наклепали кучу функций для работы с ними и преобразования между форматами, а это есть весьма большая работа, но результат мне намного симпатишнее костыльных приемов многих сей, вроде utf-8. В частности, ты можешь сделать str[i] и быть уверенным, что пока у тебя в строке обычный печатный текст, то ты получишь символ с этим самым индексом. Отсюда хорошая производительность работы со строками в любой кодировке — а ведь именно это является коньком паскалевых строк.

Тем не менее, насколько я знаю, у embedded FPC довольно популярен

Он популярен там, где нужен Си, но на самом деле не нужен и тяжести наследия нет, а C++ избыточен. Все-таки писать на паскале намного приятнее, чем на Си.

Что случилось между 1995 и 2000 — ума не приложу.

Гы-гы-гы.

Случился Linux.

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

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

Неа: https://ru.wikipedia.org/wiki/CP/M

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

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

Тут скорее всего как раз инертность, весь стоящий опыт написания ОС на тот момент это либо какие-то узкоспециализированные ОС на узкоспециализированные аппаратные платформы, либо семейство юниксов всех мастей которые смогли появиться до 80х и все это С

В данном случае это не «весь опыт», а тупо выпускники институтов, которым преподы щедро докидывают еще 5 лет инерции.

Удивительно что вообще какие-то попытки были не делать ОС на С

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

Тем не менее, clang++ справляется там, где g++ сжирает всю память и процессорное время заодно.

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

мсдос хоть и принято считать cp/m клоном, но та же вики говорит что базовые функции это юникс. В общем-то мне все-таки кажется что именно системные программисты которые с 70 по 80 писали на юниксах с собой и притащили С. И случилось это тогда, когда скорее всего выстрелили первые версии, и все кто попал на волну начали судорожно искать новых специалистов на то чтобы продлить волну и начавшуюся эру персональных пк для каждой домохозяйки, и тут выбор был между теми кто писал вендор вылосипеди каждый на своем языке потому сколько велосипедов столько и языков, и каким-то более менее общим С стеком и С программистами от юниксов, я бы тоже выбрал унифицированных специалистом и их язык, вместо кучи программистов которые все писали на разных языках.

Так к моменту выпуска первых версий оконных ос, он уже был очень ничего видимо. C c классами это 80й год первые версии, но официально язык датируют 83 годом, а это еще не одной графической ос не было (кроме того что сделал ксерокс но там и свой вендор-велосипед), и это уже надстройка над С. Так что вполне нормальный там был С...
В общем-то мне все-таки кажется что именно системные программисты которые с 70 по 80 писали на юниксах с собой и притащили С

В 80-е годы юникс кнонировали примерно так же, как нынче клонируют линукс. А ядро и системные утилиты к нему писались на Си, отсюда и популярность среди мух. Вирт вполне прямо говорил, что Си прошел в массы потому, что на нем написан юникс. Со стороны паскаля просто не было аналогичного движения, которое бы создавало хоть какие-нибудь системные утилиты для юникса на паскале. Не в последнюю очередь причиной было отвлечение части усилий от системного паскаля на кроссплатформенный прикладной — это именно та ниша, которую позже заняла Java.

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

Она может говорить что угодно, но ни CP/M, ни MS-DOS не имеют ничего общего с юниксом, в том числе у них совершенно различная организация файловой системы и системных утилит, и они написаны на разных языках программирования (причем, все три).

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

Вот это точно не юникс. До самых 90-х годов программы для ПК и игровых приставок писали в основном на асме. И даже NeXTSTEP был ни разу не для домохозяек, а для мажоров и комерсов.

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

Вполне возможно, что менеджеры AT&T примерно так и думали. По крайней мере пока эта фирма еще была гигантом и основным потребителем софта в США, а не скромным провайдером телекоммуникации. Но практика очень быстро показала, что Си не позволяет писать прикладной софт в какие-то более-менее приемлимые сроки и с гарантией надежности. Отсюда огромные перерасходы на разработку, и, в частности, тестирование. Оправдываются ли они каким-то там единообразием? Соменваюсь. Много кто по этой причине предпочел прикладной софт писать на каком-нибудь лиспе или паскале (в том числе MS и Apple). И дело в том, что системщики и прикладные программисты слабо пересекаются, потому нет особого смысла пытаться их брать под одну гребенку.

Она может говорить что угодно, но ни CP/M, ни MS-DOS не имеют ничего общего с юниксом

DOS и UNIX во многом схожи в плане базовых концепций. В обеих системах есть исполняемые файлы, при запуске которых передаются аргументы командной строки, есть потоки ввода-вывода, переменные окружения. UNIX это по сути многозадачный DOS. Сравните с Mac OS Classic или Oberon где концепция командной строки и потоков ввода/вывода вообще отсутствует. В Oberon отсутствует концепция исполняемых файлов, вместо них динамически загружаемые модули со многими точками входа, запуск происходит с помощью указания имени модуля и процедуры, например Edit.Open.

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

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

Ты не понял. clang - это для Google + Apple + Microsoft. gcc ковыряет RedHat и эмбедщики. Задачи разные и круг интересов разный. А ты чего хочешь то и пользуй, и другим не мешай. Конкуренция.

DOS такой потому что UNIX такой. И до него был CP/M.

Ни Apple ни Microsoft не писали на Lisp’е и Pascal’е. И вообще все это чушь. Lisp древний как холмы, а Pascal язык Вирта и его адептов.

https://ru.wikipedia.org/wiki/Microsoft_Pascal

Ну логично, UNIX была одной из немногих «взрослых» ОС в те времена, ПКшки только начинались, и их было много разных, а что-то большое посчитать или смоделировать или нарисовать это всегда UNIX. Даже софт для ПК кросс-девелопили на UNIX, так как было все дохлое. Но цена в итоге стала побеждать и фокус внимания бизнеса стал смещаться на ПКшки. Так как зачем ставить один хороший комп за $25000 когда можно поставить 5 по $5000.

То что были компиляторы я знаю. Но фактов их использования в продуктах от Microsoft не обнаружил. Просто Борланд сделал визуальные среды Turbo C и Turbo Pascal и Turbo Basic по дешевым ценам для того, чтобы простые энтузиасты могли программировать и несли в Borland кровно заработанные, Microsoft также хотела снять сливки с этого дела, так как их штатный набор стоил слишком дофига денег и был рассчитан на большие конторы, а не энтузиастов и мелкий бизнес. Ну и на почве этих продуктов завелось много паскалистов, так как это все хорошо работало на ПК и не надо было вставать в очередь на машинное время, чтобы накодить что-нибудь на посчитать.

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

Скажи мне пожалуйста, зачем нужна операционная система без запуска пользователем внешних программ? Ну то есть какая вообще была альтернатива? У тебя есть видеоадаптер, который кроме букав вообще ничего не умеет, и в рамках этого адаптера ты пляшешь. Если тебе нужно дать пользователю возможность запустить внешнюю команду, то неизбежно ты приходишь к «введите название программы для запуска» и «введите параметры запускаемой программы».

есть потоки ввода-вывода, переменные окружения

Конкретно эти детали реализации были позавимствованы совсем не из юникса:

https://en.wikipedia.org/wiki/OS/8
https://en.wikipedia.org/wiki/RT-11

Посмотри на этот скрин, например:
https://ru.wikipedia.org/wiki/Файл:RT11UKNC.png

Сравните с Mac OS Classic или Oberon где концепция командной строки и потоков ввода/вывода вообще отсутствует

Ты бы еще с виндой предложил сравнивать. Это всё поздние ОС-и, а еще был Smalltalk, который выпущен на несколько лет раньше них обоих, и даже раньше MS DOS.

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

Где победил? В рейтинге поисковых запросов Tiobe? Индустрия сейчас использует Си ненамного больше, чем паскаль. Ты думаешь зачем Аду делали? Потому что Си был несостоятелен. Он подходил для институтских поделок, где студента, который угандошил всю институтскую сеть компов, просто отчисляли. Но потом сети разрослись за пределы институтов, подобные административные меры перестали работать, и пришлось придумывать
https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

Unix того времени был дырявейшим друшлагом — это прямое следствие использования Си:
https://en.wikipedia.org/wiki/Morris_worm

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

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

Lisp, не? Под него даже компы были, где лисп прямо на железе исполнялся.

Ни Apple ни Microsoft не писали на Lisp’е и Pascal’е. И вообще все это чушь. Lisp древний как холмы, а Pascal язык Вирта и его адептов

Classic Mac OS написана на паскале с асмом, и всё API к ней было паскалевое. Object Pascal именно в Apple и появился. С Microsoft я ошибся, действительно, на паскале они свой софт не писали, а только копилятор выпустили.

Ну то есть какая вообще была альтернатива?

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

С Microsoft я ошибся, действительно, на паскале они свой софт не писали, а только копилятор выпустили.

Тем не менее API и ABI Windows были спроектированы под влиянием паскаля.

ПКшки только начинались, и их было много разных, а что-то большое посчитать или смоделировать или нарисовать это всегда UNIX

Это уже позднее время, примерно 1985. А до этого не было ни рабочих станций SunOS, ни рабочих станций SGI с Unix V — было OS/360 и аналоги, которые ни разу не Unix.

Как в Обероне: в качестве команды указывать пару модуль.процедура и сохранять модуль в памяти после завершения выполнения для большей эффективности и возможно фоновой активности

Даже предшественник юникса был однозадачным. Я еще раз повторяю, что ты пишешь про довольно позднее время, когда появились мощные компы и потребность в многозадчности. До этого сохранять было просто нечего и негде: 64 килобайта оперативы на топовых микрокомпьютерах и 320 килобайт дискеты.

Тем не менее API и ABI Windows были спроектированы под влиянием паскаля

Чот не заметил. Не подскажешь в каком месте?

Чот не заметил. Не подскажешь в каком месте?

В Windows используется CamelCase для имён функций, например CreateWindow, в Си принято использовать подчёркивание или вообще писать слитно. В Windows используется соглашение вызовов stdcall как в паскале когда аргументы функции удаляются вызываемой функцией, в Си используется cdecl когда аргументы удаляются вызывающей функцией. Для stdcall даже есть псевдоним PASCAL.

Даже предшественник юникса был однозадачным.

В Multics (1969) была многозадачность, динамическая линковка и вызов процедур из другого процесса: https://multicians.org/exec-env.html.

В Multics (1969) была многозадачность, динамическая линковка и вызов процедур из другого процесса: https://multicians.org/exec-env.html

Да, я ошибся. Однозадачной была не Multics, а Unix.

В Windows используется CamelCase для имён функций, например CreateWindow, в Си принято использовать подчёркивание или вообще писать слитно

Да, Win16 выпущен с паскалевым интерфейсом, это правда, и по названиям, и передачей параметров. Правда, паскаль того времени использовал то, что сейчас называется stdcall, а win16 — fastcall, где первые аргументы передаются в регистрах. Потом они поменялись местами: win32 начал использовать stdcall/pascal, а паскаль борланда — fastcall. Правда, в win32 все равно объявления были в заголовках с макросами, которые не так гладко транслировались в паскаль, как хотелось бы.

Сейчас есть языки на которых проще и удобнее писать под почти любые задачи. Победил т.к. у вас все текущие разработки так или иначе базируются на наследии С. Вы даже эти строки пишите из под браузера на С в операционной системе на С какие еще признаки победы С вам нужны? Любая новая железяка первым делом старается под себя заиметь именно С компилятор, любое системнозначимое ПО продолжают писать на С.

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

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

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

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

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

... особенно Java и JavaScript. Если кто не понял сарказм — там от Си только целенаправлено хайповый синтаксис.

Вы даже эти строки пишите из под браузера на С в операционной системе на С какие еще признаки победы С вам нужны?

Из браузера на крестах в операционной системе с ядром на Си и системными тулзами на C/C++. То есть с оффтопа. Мой опыт разработки гнома говорит, что этот проект всегда будет отставать от крестовой KDE: пока в Виллабаджо ищут баги, в Вилларибо уже пользуются стабильным релизом.

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

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

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

Не, не так. Юникс выжил, оставил после себя огромное наследие, с которым мы по сей день мучаемся. А Си уже в в нутрях Юникса прошел.

если сейчас изъять все то, что так или иначе прибито гвоздями к С получится что ничего не останется кроме этих нишевых вещей которым просто негде будет исполняться, разве что на тех операционных системах на паскале и подобных им

Я вроде упоминал уже пример с питоновыми модулями на паскале. Библиотеки на Си бесшовно присобачиваются к паскалю, потому всё, где есть сишный интерфейс, может быть использовано в паскале. Даже функции с переменным числом аргументов. Даже модули ядра Linux пишут на паскале:
https://wiki.lazarus.freepascal.org/linux/kernel/module_development

Так что здесь нет никаких барьеров, единственное препятствие — это «диды так писали, и я буду писать». Никто не будет переписывать линукс или BSD или винду на паскале — очевидно. А вот новую ОС написать можно, но сейчас системное программирование не востребовано, новые ОС выходят очень редко, вот потому мы и не видим ОС на паскале. Вот делает гугель Zircon, но базирует его на линуксе и при этом использует помесь C и C++, поскольку гуглем не руководят ретрограды. Почему не могли написать на паскале? Потому же, почему они используют питон — проще найти массовых индусов с рынка, которые и составляют основную массу рабочих рук компании, как ни странно.

По поводу дырявости реализаций на С, все они являются следствием его низкоуровневой природы и размазанной на него аппаратной сложности и как следствие от требует очень много внимания к «мелочам»

Ну вот объясни мне, почему в паскале кучи сишных проблем нет. Ни переполнения буфера, ни записи кода в стэк, ни доступа по кривому индексу массива, ни аномальных операций с числами. И при этом он точно так же позволяет писать ОС. А я тебе скажу почему — потому что Си прямо-таки заставляет пользователя делать ошибки благодаря самому дизайну языка. Так было модно среди индусов того времени: плевать на стабильность, херак-херак — и в продакшн. А вы думали, что это только недавно подобный прием появился? Эта история повторяется снова и снова, взять какой-нибудь PHP, MySQL, Mongo, Docker — это первые и самые известные, которые пришли на ум.

И да, создатели юникса были индусами, и меня забавляет, как люди на серьезных щас слушают их лекции и читают их книги, хотя уже всем ясны проблемы принятых ими решений, но, кажется, только не им самим, что они оправдывают чем-то вроде «we had to». Я месяц-другой назад со ссылками на факты доказывал, что никаких мучений архитектурных решений создатели юникса не испытывали — они просто сделали реализацию наспех как попало. У нас есть нуль-терминированные строки в готовых кусках кода? Ну и будем дальше их использовать. Ты думаешь, что C придумали Керниган и Ритчи? Нет, идею языка придумал Ричардс. Собсвенно, сами K&R признавали, что Ричардс посмышленее них был, но каким-то образом остался за кадром. Язык B стал BCPL с костылями, а язык C — B с костылями. Сам посуди: система макросов в Си — это и есть один сплошной костыль, внешний по отношению к компилятору инструмент. То есть, уже тогда они имели два слоя костылей, создатели были просто неспособны пересмотреть имеющуюся архитектуру. Но они были способны сделать херак-херак и разослать исходные коды по институтам. Семидесятые годы — это годы дефолта США, тогда всей стране было не до жира. Но эта чёрная полоса растянула свое наследие на полвека.

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

Кстати что такое аномальные операция с числами? Это про какой-то вид переполнения? Если да, это тоже есть в паскале.

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

Вообще я все же склонен думать, что если бы вместо С был паскаль ничего бы существенно не поменялось, был бы все тоже самое, только на паскале.

Вообще я все же склонен думать, что если бы вместо С был паскаль ничего бы существенно не поменялось, был бы все тоже самое, только на паскале.

Как минимум была бы нормальная модульность вместо костылей с #include. Отпала бы необходимость в сложных системах сборки.

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

Опять же ругается препроцессор как костыль, а какие были варианты у альтернатив в 70e? Препроцессор хоть и не знает ни черта ни о синтаксисе, ни о семантике, но тем не менее здорово бустит язык по возможностям и в мету(кодоген) и в любые другие подстановки, что предлагал паскаль в те годы?

в том паскале времен 70 модульность была ли?

Модульность в паскале была изначально включая UCSD Pascal.

ну ок, возможно промахнулся ftp://ftp.freepascal.org/pub/fpc/attic/ucsd-pascal/Readme.txt вот у кого это все добро появилось изначально, хотя если просто посмотреть код уцсд то там видно что сам он написан без использования модулей на паскале, до него этих модулей видимо все же не было. Но ваша правда, подвинемся на 10 лет

Первый выпуск: август 1977 г.; несколько (42) лет назад Последний выпуск: IV.2.1 R3.3 / ноябрь 1984 г.; несколько (35) лет назад

И как это помогло бы детектить библиотеки, подбирать флаги итд? В C/C++ ничего не мешает сделать g++ *.cpp

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

В C/C++ ничего не мешает сделать g++ *.cpp

Мешает. В C/C++ необходимо с помощью препроцессора включать заголовочные файлы объявлений, а в паскалеподобных языках никаких заголовочных файлов нет, а объявления генерируются компилятором из исходного кода и хранятся в бинарном формате.

Почему не могли написать на паскале? Потому же, почему они используют питон — проще найти массовых индусов с рынка

Точно, ядра и системные сервисы же индусы пишут. Раскрою тайну непопулярности паскаля, не всем он нравится, и не лучше он чем С/C++, вот так просто, ну а ты его фанат.

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

В паскалеподобных языках бинарники модулей лежат в определённом месте

Так ОС разные, и места разные. И бинарники могут быть собранными по разному. Если бы библиотеки были просты и лежали в одном месте то проблем бы и у С/C++ не было. #pragma lib и вперед.

и места разные

Можно указать при сборке или в переменных окружения.

И бинарники могут быть собранными по разному.

В паскалеподобных языках таких проблем обычно нет.

#pragma lib и вперед.

Нестандартное расширение работающее только в MSVC.

Можно указать при сборке или в переменных окружения.

В C/С++ тоже можно.

В паскалеподобных языках таких проблем обычно нет.

Это потому что их не используют %) В С/C++ таких проблем из за самого языка тоже нету.

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

До него это другой чел из ядра еще год назад говорил, или даже больше.

В C/С++ тоже можно.

В паскале достаточно указать путь до репозитория модулей, а дальше компилятор сам найдёт. Не нужно указывать разные пути для include, library и т.п. Указывать библиотеки при линковке тоже не нужно, потому что эта информация есть в бинарном файле объявлений (*.ppu для Free Pascal, *.osf для Component Pascal). Пример объявления для Free Pascal:

function CreateWindowEx(dwExStyle:DWORD; lpClassName:LPCWSTR; lpWindowName:LPCWSTR; dwStyle:DWORD; X:longint;Y:longint; nWidth:longint; nHeight:longint; hWndParent:HWND; hMenu:HMENU;hInstance:HINST; lpParam:LPVOID):HWND;
  external 'user32' name 'CreateWindowExW';

ну вот, все движется к тому что как только торвальдс отойдет от дел, сдержать потоки альтернативных языков и их любителей уже будет невозможно. Еще немного подержится дядя, а потом как и Гвидо махнет рукой и скажет - «Ой да делайте что хотите!».

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

но как то не пишут особо…

А как же регулярные поломки API ядра? Модули ядра вне репозитория ядра быстро перестанут работать если их постоянно не дорабатывать под изменения API ядра.

А как С/C++ от этого избавляет?