Изящность ага, но эффективность?.. Всё заоптимизировано по-взрослому.

По быстродействию — готов согласиться, хотя и с трудом. А по размеру исполняемого файла? А по занимаемой памяти? Особенно если (т-сссс!) линковаться статически.

musl - это же игрушка в сравнении

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

Классический учебник K&R был предназначен для тех, кто программировать уже умеет. Утверждение из его же предисловия, тут я ничего от себя не выдумал.

Да. Цитирую:

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

(выделение жирным моё).

Я изучал Си именно по этой книге, и проблем не было (т. е. были проблемы с указателями и выходом за границы массивов, но тут уже книга не виновата, это особенности языка). Правда, что такое «переменная», «присваивание», «цикл» и «функция» я на тот момент уже действительно знал. Но помимо этих базовых знаний ничего за душой больше не было. Была информатика в школе, которую вела математичка, закончившая недельные курсы, и халявный бейсик в ВУЗе, который никто толком не учил, потому что зачёт и так ставили, а бейсик уже тогда всерьёз никто не воспринимал.

Я изучал Си именно по этой книге, и проблем не было

Когда я Си изучал, у меня даже этой книги не было (ибо 1992 год, тогда книги всё ещё не покупали, а «доставали»). И ничего. Ну так то вы, то я, а то — все остальные. Как я уже много раз говорил, среди изучающих программирование есть прослойка процента эдак в три, которая в услугах преподавателей не нуждается, информацию извлекает (самостоятельно) из всего, в чём её хоть чуть-чуть есть, и ухитряется ещё и фильтровать правильно, так что ни бейсиком, ни джавой этих людей не испортить.

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

Зато для человека, не входящего в эту прослойку, обычно попытка изучить Си самостоятельно по K&R (особенно в роли первого языка) приводит к намертво впечатанному в подкорку убеждению, что массив и адрес — это одно и то же. И неважно, что в книге явным образом написано иное, на всё «заумное» можно не обратить внимания.

джавой этих людей не испортить.

По-моему ява именно для обучения (а не для серьёзной разработки) - идеальный язык.

1. Строгая, как паскаль, а то и ещё строже.

2. Изначально навязывает ооп-подход (обязательно надо создать класс). В object-pascal же ооп хоть и поддерживается, но не полностью из-за необходимости обратной совместимости.

3. Синтаксически похожа на си/си++, что упрощает переход на эти языки в будущем.

4. Нет указателей (но есть безопасные ссылки), невозможно выйти за границы массива без получения ошибки времени исполнения и не надо заботиться об освобождении памяти. Эти 3 момента можно рассматривать и как плюс, и как минус. Но, имхо, при начальном изучении это скорее плюс: человек может сосредоточиться на изучении конструкций языка, стандартных библиотек и алгоритмов, не отвлекаясь на труднообнаружимые ошибки, связанные с неправильным обращением к указателям и утечками памяти. А потом, изучая си/си++, доучить всё это, но ему уже будет проще, т. к. синтаксис он уже знает (в ява и си они очень похожи) и имеет какой-то опыт учебного программирования. Да и массив с адресом уже не спутает.

По-моему ява именно для обучения

Смотря что хотим на выходе. Если макаку, которая ничего не умеет и НЕ БУДЕТ уметь (то есть никогда, от слова совсем), то да, просто-таки идеальный язык

1. Строгая, как паскаль, а то и ещё строже.

Даже интересно, в чём это выражается

2. Изначально навязывает ооп-подход

Пока у человека нет опыта (личного!) написания программ на 2-3 тысячи строк, любые попытки рассказывать ему про ООП превращаются вот в это вот «не хочешь — заставим». Это не обучение, это дрессировка.

3. Синтаксически похожа на си/си++,

Если в ответ на вопрос, чем Си отличается от Паскаля, человек первым делом вспоминает про скобки vs. begin/end, то минимум одного из двух языков он не знает (а чаще — не знает оба). Я это к тому, что синтаксис (а точнее — лексика, поскольку синтаксически как раз джава на Си не похожа) вообще дело десятое, на адаптацию к другому виду операторных скобок уходит как максимум один день.

4. Нет указателей

Вот именно. И garbage collector. То есть если предполагается в будущем изучение низкоуровневых языков (тех же C/C++), то при обучении на джаве мы выработаем у обучаемого вредные привычки, с которыми нам же самим потом придётся жёстко бороться, в большинстве случаев, кстати, безуспешно.

Это я уже не говорю о том, что вообще сочетание императивного программирования со сборкой мусора есть заведомый нонсенс. Если нас устраивает gc, то, значит, про машину фон Неймана мы уже готовы забыть, и тогда нет никакого смысла тащить за собой присваивания, циклы и прочие (противоестественные) фоннеймановские примочки. Добро пожаловать в Лисп, а то и сразу в Haskell, чего уж там.

Был очень непродолжительный опыт преподавания информатики в техникуме (колледж, по-нынешнему) в начале 90х. Делал судя сугубо по себе - первым языком давал детям ассемблер х86. Ассемблер можно понять по книжке самостоятельно (кажется автором самой первой учебной книжки был П.Нортон). А вот Си стал более/менее заходить в меня только сидя рядом с опытным наставником в подмастерьях. Правда дальнейшую судьбу детей в программировании не знаю.

изучение низкоуровневых языков (тех же C/C++)

С++, мне кажется, очень зря вы ставите рядом с Си в этом контексте. Я бы детям точно не стал давать его. Как объяснять delete vs delete[] ученикам, не знающим низкого уровня? Только пихать без объяснений, наизусть, как Отче наш.

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

Смотря что хотим на выходе. Если макаку, которая ничего не умеет и НЕ БУДЕТ уметь (то есть никогда, от слова совсем), то да, [java] просто-таки идеальный язык

макаками не становятся, ими рождаются.
если говорить об обучении, я могу, например, заявить, что лучший способ обучить программированию на 2017 год — это игра Factorio. когда человек имплементирует S-R Latch, Schmitt trigger, Min-Max, fifo\lifo queue, просто, чтобы паровозик эффективнее привозил «сотни нефти» по железной дороге которая построена по какому нибудь древнему Prim's algorithm и всё ради решения Transportation theory, поверх ещё можно прикрутить тесты а значит и TDD в итоге, если играть группой, Agile напрашивается сам собой.
макаками не становятся, ими рождаются.

С++, мне кажется, очень зря вы ставите рядом с Си в этом контексте

Вот уж чего никогда не делал, так это не ставил их рядом :-) В обсуждаемой книге часть, посвящённая чистому Си, была второй во втором томе (четвёртой в общей нумерации), второй том уже год как вышел; часть, посвящённая Си++, будет первой в четвёртом томе (т.е. всего девятой), четвёртый том вообще ещё неизвестно когда выйдет, но точно не скоро. И всем неофитам, жаждущим телегу взгромоздить впереди лошади, объясняю, что попытки изучения Си++ без знания чистого Си — это путь в никуда, равно как и попытки изучения ООП при отсутствии опыта написания практически применимых программ, имеющих объём хотя бы 2-3 тысячи строк.

макаками не становятся, ими рождаются.

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

Кстати, должен сказать, что современная средняя школа в этом преуспевает — там просто макакоконвейер.

ява
1. Строгая, как паскаль, а то и ещё строже.

Даже интересно, в чём это выражается

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

Плюс ява-машина одинаково работает на всех платформах (единственное известное мне исключение из этого правила заключается в том, что во время промежуточных вычислений по умолчанию не обрезается плавающая точка на intel/amd процессорах, реализованная через 80-битные регистры, в отличие от большинства других платформ, из-за чего результаты вычислений на этих платформах могут немного отличаться от результатов на других платформах, но и здесь возможно настроить ява-машину так, чтоб все промежуточные вычисления обрезались, в ущерб производительности, разумеется). Т. е. студент может отладить программу дома на 64-битной машине, а потом запустить её в ВУЗе на 32-битной (или наоборот), не опасаясь, что выскочат неожиданные побочные эффекты. Или дома у студента может стоять Windows/Mac/Android, а в ВУЗе Linux (или, опять же, наборот), и об этом тоже не надо беспокоиться. Как и о разных реализациях компиляторов, библиотек и т. д. Со всем этим, конечно, тоже надо учиться справляться самостоятельно, но не при изучении первого языка.

4. Нет указателей

если предполагается в будущем изучение низкоуровневых языков (тех же C/C++), то при обучении на джаве мы выработаем у обучаемого вредные привычки

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

Но в программировании, как только начинается что-то чуть-чуть более сложное, чем hello world, приходится учитывать кучу разных вещей и побочных эффектов. Это касается любых средств программирования, но особенно си. И главный подводный камень тут, как мне кажется, - чрезмерная (для новичка) свобода адресации памяти. Хорошо, если программа просто упадёт с сообщением segmentation fault, - по крайней мере сразу будет ясно, куда копать. Но бывает и так, что из-за неправильной работы с указателями новичок затирает другие переменные, использующиеся совсем в другой части программы. Программа нормально работает, но выдаёт совершенно не те результаты, которые должны быть. Новичок, естественно, проверяет вычислительную часть программы, тратя на это часы или даже дни, и не может понять, где он ошибся. А ошибся он в совершенно другом месте, никак не связанном логически с вычислительным блоком. И это не абстрактная ситуация, а пример из жизни.

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

И да, не так давно я общался (и продолжаю общаться) с одним выпускником, которому сначала давали яву, а на старших курсах - си, причём в режиме галопом по европам. И ему действительно было трудно понять концепцию указателей. Кроме того, как ни странно, были ещё проблемы с побитовыми операциями, хотя они-то в яве присутствуют. Но, насколько мне известно, он успешно преодолел эти проблемы. Было бы только желание. :-)

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

Тогда и распараллеливание не надо изучать, и потоки, и многое другое, без чего современное программирование немыслимо.

Усилим утверждение:

любая современная школа, рассчитанная на массовое образование - макакоконвеер.

а потом кинется с головой в этот омут

Как раз джава с её принудительным ООП и есть «головой в омут», причём ещё и не в тот омут. В смысле, в омут-то занырнуть придётся, только без всякой пользы.

Повторюсь, я не вижу альтернативы Паскалю в качестве первого языка. «Омут» в виде указателей там присутствует, но кидаться в него никто не заставляет — к нему можно осторожно подойти, хорошенько всё взвесить и тогда уже нырнуть. По готовности.

Тогда и распараллеливание не надо изучать, и потоки, и многое другое, без чего современное программирование немыслимо

Всё это надо изучать ровно в одном ключе: чтобы точно знать, почему никогда не следует (НИКОГДА, я сказал!) применять мультитрединг. Да, его для этого нужно знать, увы.

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

любая современная школа, рассчитанная на массовое образование - макакоконвеер.

Аминь.

Как раз джава с её принудительным ООП

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

я не вижу альтернативы Паскалю в качестве первого языка.

Я не говорю, что паскаль плох. Более того, я даже не говорю, что он устарел, т. к. знаю людей, которые кодят на нём. Хотя по сравнению с си и с той же явой или шарпом на рынке вакансий он не очень востребован. Но это другая тема. Я просто сказал, что ява для обучения ничем не хуже и привёл аргументы. И пока не нашёл контр-аргументов, кроме одного: что начинать обучение программированию с ооп - плохо. Я с этим не согласен, но даже если принять это как аксиому, как я уже сказал, на яве можно писать и обычные процедурные программы. Придётся только отдать дань ооп в виде слова class в начале программы.

никогда не следует (НИКОГДА, я сказал!) применять мультитрединг

[skip]

подробно изложено в предисловиях обсуждаемой книги.

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

Ну, обмануть компилятор тоже всегда можно

Обмануть компилятор? В процессе обучения? Больше того, НА ПЕРВОМ ЗАНЯТИИ?! «Уважаемые студенты, сейчас я вам для начала расскажу, как обманывать компилятор, а потом мы начнём что-то писать». Вы вообще в своём уме?

Более того, я даже не говорю, что он устарел, т. к. знаю людей, которые кодят на нём.

Это вообще не имеет отношения к делу.

Хотя по сравнению с си и с той же явой или шарпом на рынке вакансий он не очень востребован.

А это тем более. Предлагая начать с Паскаля, я совершенно не предлагаю никому на нём остановиться. Заметим, и сам я на нём не пишу.

И пока не нашёл контр-аргументов, кроме одного: что начинать обучение программированию с ооп - плохо

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

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

1) наличие указателей «в полный рост», причём, что важно, без сборщика мусора: забрал ресурс — отдай обратно, в компьютере нет добрых гномиков, которые сделают это за тебя;

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

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

-- и Паскаль, собственно говоря, единственный такой язык.

Подробности см. в моём первом томе, стр. 21-26 (в PDF-файле это стр. 23--28). Касаемо моей позиции по параллельному программированию — она изложена, во-первых, там же в предисловии к первому тому, во-вторых, она конкретизирована в третьем томе — см. предисловие к нему и плюс в нём предисловие к части VII (NB: эта часть целиком посвящена параллельному программированию). Кратко — в качестве абсолютного зла я рассматриваю программирование с разделяемыми данными, это то, чего следует избегать до последнего и соглашаться на это разве что под дулом пистолета.

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

Обмануть компилятор? [skip] НА ПЕРВОМ ЗАНЯТИИ?! «Уважаемые студенты, сейчас я вам для начала расскажу, как обманывать компилятор, а потом мы начнём что-то писать».

Можно и по-другому: «Уважаемые студенты, любая программа на java должна начинаться словами public class <далее идёт произвольное имя программы>». Вот и весь обман. И даже слова «обман» произносить нет нужды. Ведь что такое класс, они ещё не знают, для них это просто особенности синтаксиса языка, возможно, слегка избыточные с их точки зрения.

Более того, я даже не говорю, что он устарел, т. к. знаю людей, которые кодят на нём.

Это вообще не имеет отношения к делу.

Это имеет отношение к делу с точки зрения психологического отношения к предмету. Никто не хочет изучать безнадёжно устаревший язык из прошлого века, как и «игрушечный» язык, на котором ничего путного не напишешь. А именно такая репутация закрепилась в нынешнем веке за паскалем (на мой взгляд совершенно несправедливо). Я слышал подобное 10 лет назад и слышу до сих пор.

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

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

С этим согласен.

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

Кратко — в качестве абсолютного зла я рассматриваю программирование с разделяемыми данными

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

Лет 10 назад было интервью с Кнутом «У создателей компьютеров кончились идеи» ( http://www.physics.uni-altai.ru/community/wiki/USozdatelejjKomp'juterovKonchi... ), где он высказывает похожие мысли по поводу параллельных вычислений. Но если идеи, связанные с увеличением тактовой частоты, кончились, то тем более надо по максимуму использовать то, что есть, т. е. многоядерность.

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

С другой стороны, сотни потоков - безусловно перебор. Тут действительно разумнее организовать цикл.

В общем, рецептов на все случаи жизни, имхо, нет. Ко всему надо подходить с умом.

Вот и весь обман.

На первых занятиях в принципе недопустимы любые ссылки вперёд и прочие слова о том, что, мол, «так надо, а почему — поздней поймёте». Это, кстати, одна из причин, по которым я категорически против Си в роли первого языка. Подробности вот тут в своё время свёл воедино: http://www.stolyarov.info/pvt/anti_c

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

Это вопрос не к языку, а к конкретному инструменту. Free Pascal со своей ролью практически применимого инструмента прекрасно справляется. Turbo Pascal в DosBox'е — нет, не справляется. Разница исключительно в том, что с помощью Free Pascal получаются «настоящие» программы, и это стимулирует к проявлению творческой инициативы, тогда как написанную на Turbo Pascal программу невозможно оформить так, чтобы до неё (в нынешних условиях) снизошёл сторонний пользователь.

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

Вообще тут идея совершенно из другой области: «никаких эмуляторов».

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

Вы, видимо, вообще не поняли, о чём идёт речь. Если они все дружно встали, значит они НЕ НУЖНЫ, понимаете? Значит, тот кретин, который писал эту программу, не умеет писать в терминах явных состояний и использует треды со всеми их прелестями в роли хранилища состояний. Никакого распараллеливания не происходит, происходит лишь неоправданное — на ровном месте — усложнение используемого инструментария и в конечном итоге жёсткое усложнение анализа программы.

Си++ не нужен, т. к. кому надо, и сам его изучит, а кому не надо - тому тем более не надо. Но при этом вы не предлагаете никакой ооп-замены си++

Какой толк мне её предлагать, если я сам собираюсь использовать в четвёртом томе именно Си++? Проблема здесь в том, что моя книга предназначена не для «всех», а исключительно для тех, у кого достаточно и способностей, и мотивации, чтобы стать программистом. При этом я остаюсь сторонником выбрасывания Си++ из основных курсов, поскольку далеко не все слушатели этих курсов таковы, а на втором курсе, где у нас на ВМК это читается, давать студентам ООП откровенно рано.

[ООП] А вы фактически предлагаете его не изучать, ограничившись традиционным процедурным программированием

Если говорить о будущих программистах — то вне всякого сомнения ООП им изучать важно и нужно. Если говорить о студентах любой, пусть даже и программистской специальности — то, во-первых, минимум две трети из них программистами не будут; во-вторых, на любой отдельно взятый момент времени три четверти аудитории не имеют опыта написания практически применимых программ на 2-3 тысячи строк и, как следствие, к разговору об ООП не готовы; в-третьих, большинство преподавателей не имеют опыта индустриального программирования и, как следствие, сами не понимают, что такое ООП. В такой ситуации «изучение ООП» неизбежно превращается в позорный фарс, которого следует, несомненно, избегать.

Любое (даже самое безопасное а-ля «форкнутое») параллельное программирование, увы, не может обойтись без разделяемых данных.

Чушь. Функциональное программирование вообще обходится без данных (без глобальных переменных), и ничего. Причём это безотносительно распараллеливания. В Эрланге паралеллизм есть (это там основная парадигма), при этом разделяемых данных нет, отсутствуют как класс.

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

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

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

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

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

Ну, почему? Вот я, например, пишу рогалик, там всем на карте куча монстров, которым надо посчитать обзор и A*. Если это дело раскидать на несколько ядер - то профит в несколько раз.

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

Если они все дружно встали, значит они НЕ НУЖНЫ

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

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

В Эрланге паралеллизм есть (это там основная парадигма), при этом разделяемых данных нет

Принято.

[ООП]

Если говорить о студентах любой, пусть даже и программистской специальности — то, во-первых, минимум две трети из них программистами не будут

Возможно, они не только программистами не будут, но и математиками не будут, а уйдут в бизнес. Но из этого ведь не следует, что на МехМате и ВМК вместо математики и программирования надо углублённо изучать экономику и гражданское право.

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

Кстати, при том, что международные рейтинги МГУ среди российских ВУЗов наиболее высокие, работодатели предпочитают брать it'шников из МИФИ и МФТИ в большей степени, чем с мехмата и ВМК, потому что у первых куда больший упор на практику, в то время как выпускники МГУ больше теоретики.

не имеют опыта написания практически применимых программ на 2-3 тысячи строк и, как следствие, к разговору об ООП не готовы

Значит, им надо дать такой опыт. На то это и университет. Необязательно каждому писать по 2 тыс. строк. Работа может быть распределена внутри группы.

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

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

ядро само от себя защищаться не умеет

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

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

Соглашусь с crutch_master в том, что распараллеливание можно успешно применять в компьютерных играх, и если этого не делается, то только потому, что разработчикам игр лень переписывать работающий код, изначально ориентированный на 1 процессор с 1 ядром. Также его можно применять в САПР, 3D-графике, в кодировании/декодировании видео и т. д. Да взять те же браузеры: каждое окно/вкладка - свой процесс/поток. Конечно, это не совсем распараллеливание, т. к. работа этих нитей не связана между собой, однако вызывать fork()/pthread_create() нужно. Или взять элементарную сортировку. Её тоже можно распараллелить, по отдельности отсортировав небольшие блоки, а потом слить их воедино. Будет от этого реальная выгода в тех или иных ситуациях - отдельный вопрос - это надо тестить, - но это возможно.

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

Скоро будем начинать учить программирование по Rust`у

А смысл?

Не проще чем си, и слишком много того что в си явно видно скрывает. Никаких преимуществ для новичка.

Начал знакомство с первой книги. Написание книги - нелегкий труд и достойно уважения. Требуются не только технические, методические, но и литературные знания и навыки. С последним у автора проблема. Материал изобилует литературными штампами, щедро пересыпан «академизмами», «интеллигентскими» словами-паразитами, частицами, наречиями. Впечатление, будто редактура заключалась в коррекции синаксиса, да словарных слов. Почитайте что-нибудь из Григория Явлинского и вы сразу поймёте о чем я. Всю первую книгу можно легко сократить на 10% просто убрав словесный мусор. А затем положить материал «в стол» и через пару недель убрать ещё 10-15% без потери содержательности, смысла и настроения автора в тексте. Качество технической и методической части оценивать пока не берусь. По многим тезисам полностью согласен с автором, но порой утверждения кажутся голословными и хочется развернутого объяснения. Встречаются взаимоисключающие утверждения буквально в одном предложении. Заметно, что книга писалась сразу «в продакшен» при дефиците времени. В целом же - ценный труд, интересная точка зрения на профессию.

Ну, почему? Вот я, например, пишу рогалик, там всем на карте куча монстров, которым надо посчитать обзор и A*. Если это дело раскидать на несколько ядер - то профит в несколько раз.

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

Если они просто случайно одновременно заблокировались

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

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

Если спроецировать это на математику, получится, что выпускник того же мехмата «должен» знать или ну хотя бы представлять все основные разделы математики. Так вот, вынужден вас разочаровать: даже несчастное тензорное исчисление мало кто из выпускников знает. Больше того, совсем уж разнесчастные неевклидовы геометрии — не знаю как после Мехмата, а после ВМК процентов девяносто выпускников так и остаются в неведении, что там к чему (то есть не то что они не знают этого раздела, они не понимают даже того, откуда оно взялось).

Хотите ещё хуже? Почти никто из выпускников ВМК не знает, что такое «частично-рекурсивная функция» и чем она отличается от «примитивно-рекурсивной». И даже что такое «лямбда-исчисление». И если предыдущий абзац легко объясним (попросту говоря, есть вещи поважнее), то этот факт мне представляется реально позорящим ВМК. Я не могу себе представить факультет computer science в Европе или ещё где-то в цивилизованной стране, выпускник которого не знал бы основ теории вычислимости, это просто нонсенс. Но вот оно так, и я по итогам долгого бесполезного дёргания на эту тему могу сказать, что, наверное, ни черта тут не изменится.

Что касается ООП, то, ещё раз, это БЕСПОЛЕЗНО даже пытаться объяснять человеку, не имеющему пререквизита в виде опыта на 2000 строк. Ну вот не поймёт, и всё, и точка. А опыта этого у подавляющего большинства студентов нет и не будет, это объективная реальность. Здесь дело не в том, что оно якобы «надо» даже тем, кто не будет программистом. Дело в том, что те, кто не имеют достаточной склонности к программированию, чтобы быть программистами, не имеют никаких шансов понять, что такое ООП.

Кстати, с тензорным исчислением и математиками примерно та же фигня. Тот, кто не будет математиком, не поймёт тензоры.

Значит, им надо дать такой опыт.

Дать — можно, впихнуть — нельзя. И если человек не возьмёт (а эти именно что не возьмут), то тут хоть давай, хоть не давай.

Наверно, нужно подготовить преподавателей.

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

Работа может быть распределена внутри группы.

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

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

Да взять те же браузеры: каждое окно/вкладка - свой процесс/поток.

За такое вообще убивать медленно, и желательно — очень, очень, ОЧЕНЬ мучительно. Ногами в область печени за саму идею.

Или взять элементарную сортировку.

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

А ещё попробуйте вот сейчас быстренько вспомнить, когда в последний раз вы сталкивались (на практике, блин!) с сортировкой массива более чем из 20 элементов (на всякий случай: при этом всё ещё наиболее эффективен тупой «пузырёк», а на десяти элементах любые квиксорты оказываются неповоротливы как стадо слонов).

Их и на си писать не обязательно

Открою вам небольшой секрет: на Си пишут в большинстве случаев совершенно не ради эффективности.

Скоро будем начинать учить программирование по Rust`у

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

Не смешите мои тапочки, чтобы рогалик за пользователем не успевал

Ну смотря что за рогалик. Dwarf fortress, например, задумывается, когда в крепости 100+ бород.

Причём тут рогалик? Режим крепости — не рогалик. В режиме приключенца не задумывается.

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

Шикарно про ООП. Несмотря на множество твоих спорных посылов, по отдельным позициям поддерживаю. Желаю, что бы семена твоего преподавания дали всходы. Это в миллион раз лучше того, что делали с нами в Бауманке безумные маразматики

В режиме приключенца не задумывается.

Тормозит еще хуже. Особенно в деревне. Да все они из-за z этажей тормозят.

Да взять те же браузеры: каждое окно/вкладка - свой процесс/поток.

За такое вообще убивать медленно, и желательно — очень, очень, ОЧЕНЬ мучительно. Ногами в область печени за саму идею.

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

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

Есть ещё один вариант: рогалик должен написать какой-нибудь современный модный хипсторокодер, желательно на современном модном языке.

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

Каждая вкладка независима от других.

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

Плюс к тому те вкладки, которые сейчас закрыты, вообще не должны (были бы, если бы нормальный человек писал браузер) грузить проц, их же всё равно не видно. Но даже если делать независимые интерпретаторы JS (напомню, я бы предпочёл, чтобы JS вообще не было, а за его использование топили в дерьме) — так вот, если для каждой вкладки иметь свою независимую виртуальную машинку для JS, как это, судя по всему, сейчас и делают те дегенераты, которые пишут браузеры под диктовку идеологов гугля, — то мне представляется совершенно очевидным, что имеющийся подход (если скрипт работает «слишком долго», нехотя предложить пользователю его пристрелить) ублюдочен по своей сути, там ведь наверняка это «пристреливание» реализуется через pthread_cancel со всеми сопутствующими тормозами и т.д. Правильный подход — сделать интерпретатор в виде пошагового конечного автомата и каждому скрипту давать ограниченное количество шагов на каждой итерации главного цикла, при этом не забывать нырнуть в select или его аналог на тему пришедших событий от GUI и от сокетов; тогда даже сотня «зависших» скриптов не подвесила бы браузер, причём их, эти интерпретаторы, можно было бы даже не пристреливать.

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

те вкладки, которые сейчас закрыты, вообще не должны (были бы, если бы нормальный человек писал браузер) грузить проц, их же всё равно не видно. Но даже если делать независимые интерпретаторы JS (напомню, я бы предпочёл, чтобы JS вообще не было, а за его использование топили в дерьме) [skip] Правильный подход — сделать интерпретатор в виде пошагового конечного автомата и каждому скрипту давать ограниченное количество шагов на каждой итерации главного цикла, при этом не забывать нырнуть в select или его аналог на тему пришедших событий от GUI и от сокетов;

Я согласен с большей частью написанного здесь, но не вижу прямой связи с процессами/потоками. Всё, что вы написали, можно делать/не делать как с ними, так и без них. Да, наверно pthread_cancel требует дополнительного времени и ресурсов, зато и скрипты могут выполняться на разных ядрах, т. е. преимуществ больше. Остальное же (как то повсеместное использование jscript, работа этих скриптов и других процессов, как то видео/аудио и т. д. в неактивных вкладках, запоздалое прибивание тормознутых скриптов и т. д.), как я уже сказал, к проблеме многопоточности не относится.

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

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

Или взять элементарную сортировку.

Попробуйте как-нибудь на досуге. Только обязательно с измерениями быстродействия

Вот это мне самому интересно. Но сейчас нет времени на эксперименты. Однако в недалёком будущем обязательно попробую и независимо от результата отпишусь или здесь, или создам новую тему и кастану в ней вас. А по мелочам отвечу сейчас.

Работа может быть распределена внутри группы.

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

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

на Си пишут в большинстве случаев совершенно не ради эффективности.

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

А ещё попробуйте вот сейчас быстренько вспомнить, когда в последний раз вы сталкивались (на практике, блин!) с сортировкой массива более чем из 20 элементов

Например, в машинном обучении всё время сталкиваются. Лично я 2 года назад, 2+ Гб double'ов сортировалось и было узким местом.

не вижу прямой связи с процессами/потоками

Когда потоков нет, то нет и разделяемых данных, и вообще ничего «неожиданного» (типа «кто-то прямо под руками изменил значение переменной, а я-то и не заметил»). Исполнение программы становится на порядок проще в осмыслении и в контроле над ним. Процессы тут, разумеется, вообще ни при чём. Браузер — это интерактивная программа, она просто не имеет права быть параллельной, потому что, обратно же, не имеет права жрать процессора. Вообще. Как следствие, не должен вообще стоять вопрос о распараллеливании.

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

Ну или скорость выполнения стала бы не сильно отличаться от полного зависания.

Дело в том, что показ (рендеринг) большинства web-страниц до сих пор, к счастью, не требует завершения выполняющихся скриптов. Поэтому если там зацикленный скрипт, то сейчас, выполняясь в треде, он сожрёт проца столько, сколько в системе есть, а в схеме, когда браузер выполнен однопоточно с главным циклом, скрипт получит столько проца, сколько ему браузер даст, а браузер ему не даст столько времени, чтобы всё подвисло (ну, если он нормально написан) — пока есть другие дела, нефиг дёргать слишком много раз «шаг виртуальной машины». То есть страница будет уже видна, её можно будет читать, а где-то там будет выполняться скриптик, никому при этом не мешая.

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

Речь, напомню, исходно шла о том, что рассказывать ООП на втором курсе рано (и тем более с него начинать).

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

Программист — конечно. Я обращаю ваше внимание ещё раз на мой основной тезис: большинство выпускников даже программистских специальностей никогда не будут программистами, потому что у них недостаточно для этого склонности к программированию. Следовательно, в бОльшую часть студентов этот «опыт» просто невозможно впихнуть.

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

на Си пишут в большинстве случаев совершенно не ради эффективности

В основном. А ещё ради доступа к разным системным и аппаратным вещам

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

в машинном обучении всё время сталкиваются

Я не говорю, что с этим не сталкивается никто и никогда :) Мой тезис звучит совершенно иначе: в большинстве задач (нет, не во всех) сортировка требуется для таких массивов, которые эффективнее всего сортировать тупым пузырьком, который (пузырёк) ни в коем случае не нужно писать «в общем виде» со всякой передачей функции сравнения параметром и прочими такими штуками. Но при этом все всем всегда рассказывают, какой же пузырёк «неэффективный» (ну как же, тут эн-квадрат, а там эн на логарифм эн), напрочь забывая при этом уточнить, что для проявления этой «неэффективности» массив должен ну хоть что-то собой представлять.

Когда потоков нет, то нет и разделяемых данных, и вообще ничего «неожиданного»
(типа «кто-то прямо под руками изменил значение переменной, а я-то и не заметил»).

Это понятно. Но оно частично лечится использованием полноценных процессов вместо облегчённых потоков.

Процессы тут, разумеется, вообще ни при чём.

Почему ни при чём? В Хроме, например, каждое окно/вкладка выполняется отдельным процессом, а не потоком.

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

Почему «жрать»? Использовать существующие возможности, т. е. разные ядра. Иначе на 4-ядерном проце можно получить ситуацию, когда загружено 25% всех ядер (т. е. ровно одно ядро), а программа дико тормозит, потому что не догадалась задействовать дополнительные ядра.

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

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

в современных условиях Си — язык (а) наиболее переносимый (да, именно так, несмотря на свою низкоуровневость)

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

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

Для UNIX это верно по историческим причинам, а, например, под Windows компилятор из коробки не ставится. Там хоть для си-программы, хоть для паскаль его нужно ставить. А если си-программа использует гнутые расширения, то ещё и цигвин понадобится.

Почему «жрать»? Использовать существующие возможности, т. е. разные ядра. Иначе на 4-ядерном проце можно получить ситуацию, когда загружено 25% всех ядер (т. е. ровно одно ядро), а программа дико тормозит, потому что не догадалась задействовать дополнительные ядра.

Тут стоит заметить, что на js пишут так, что если скрипту дать 4 ядра, он займёт их все и повешает систему.

на js пишут так, что если скрипту дать 4 ядра, он займёт их все и повешает систему.

Насколько я знаю, в javascript нельзя создавать потоки/процессы. Сейчас посмотрел, — это можно сделать в nodejs, но не в браузере. Получается, что ядра занимает криво написанная виртуальная машина (или несколько машин, т. к. для каждой странички используется свой экземпляр). И, опять же, мы упираемся в кривую реализацию браузера/ява-скрипт-машины. Но даже если говорить о яве, где могут быть потоки, ничто не мешает сделать их в браузерных апплетах зелёными.

Каждая вкладка независима от других.

С какого бодуна они независимы, это же ОДИН на всех гуй!

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

А ещё у нас одна на всех файловая система, а ещё если две вкладки используют один сайт,... Как следствие, при многопоточном решении начинается адЪ и угарЪ...
Но браузеры пишут мультитредовые дегенераты, поэтому [их] так легко заставить встать колом

Ага! Так вот ты где, зараза! — тот, из-за кого у меня в Емаксе до сих пор нет многопоточности, и он регулярно встает колом по-настоящему.

Правильный подход — сделать интерпретатор в виде пошагового конечного автомата и каждому скрипту давать ограниченное количество шагов на каждой итерации главного цикла...

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

частично лечится использованием полноценных процессов

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

В Хроме, например, каждое окно/вкладка выполняется отдельным процессом

Я и говорю, ногами в область печени за такое.

Почему «жрать»? Использовать существующие возможности, т. е. разные ядра.

Ещё раз: коль скоро пишется интерактивная программа, эта проблема не должна вставать вообще. Пользователя перетормозить можно либо на арифмометре «феликс» с педальным приводом, либо, как тут уже отмечали — путём активного использования «модных технологий». Что, собственно, и исполняют авторы «современных» (читай — слепленных без применения головного мозга) браузеров.

то же самое можно сделать с использованием процессов/потоков

Суха теория, а древо жизни того-с. Нет, нельзя этого сделать в параллельной парадигме, потому что за всеми не уследишь.

Компиляторы паскаля существуют

Они могут существовать сколько угодно, положения вещей это не меняет.

например, под Windows компилятор из коробки не ставится

Зато под Windows можно собрать один большой exe-файл, который достаточно куда-нибудь скопировать, и он там будет работать — без инсталляторов, без инфраструктуры, без каких-либо зависимостей и пререквизитов. Из известного — сходу putty вспоминается; из своего опыта — я собственные программы из-под Linux портировал под винду путём их сборки под MinGW, получал именно что монолитный исполняемый файл, про который пользователю достаточно сказать «скачайте его вот отсюда, киньте куда хотите и запустите, а когда он вам надоест, просто сотрите».

Под Linux такое тоже можно... э-ммм... было бы, если бы не монстр по имени glibc и другие долбаные библиотеки, создатели которых слепо веруют в динамическую сборку. Меня откровенно взбесило несколько лет назад, когда я написал несколько мелких программ с GUI, используя wxWidgets, и под Linux так и не смог их заставить статически собраться, ибо GTK статически собираться отказывается (отказывалась тогда, во всяком случае) совершенно наотрез; при этом скопировал свои исходники на винду с MinGW, туда же поставил wxWidgets/win32, и совершенно без усилий получил самодостаточный exe-файл. То есть под виндой мне удалось без малейших жужу то, что я хотел, а под «родным» Linux'ом не удалось. Те части glibc, которые не хотят статически линковаться, я навострился заменять кусками из musl, так что утилиты командной строки обычно статически собрать могу, но вот с wxWidgets аналогичное действие, увы, превышает по степени сложности моё упорство.

Опять же, ну да, FreePascal есть вроде бы под все основные платформы, и всё выглядит хорошо, пока не попробуете реально что-то портабельное написать (из самого эпичного — SeekEof корректно работает с «настоящими» дисковыми файлами и с потоком с терминала, а с pipe и сокетами не работает, потому что для всего, что не является потоком с терминала, оно зачем-то пытается использовать lseek — и эту хрень там не желают фиксить уже лет десять).

от, из-за кого у меня в Емаксе до сих пор нет многопоточности

Судя по тому, что в elisp, написанном в середине восьмидесятых, динамическое связывание переменных — при том что на момент его написания про фунарг-проблему знали уже лет двадцать как (с середины шестидесятых, так-растак), Емакс встаёт раком исключительно из-за того, что его создатели в упор не понимали и не понимают, что такое Лисп и как его надо реализовывать. Я тоже не претендую на то, что хорошо это понимаю, но даже мой убогий InteLib, написанный ради диссера, в сравнении с интерпретатором elisp выглядит как прямо-таки солидная реализация лиспа.

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

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

Иначе говоря, в этой модели нет ничего из того, за что я ненавижу многопоточность.

Ага! Так вот ты где, зараза! — тот, из-за кого у меня в Емаксе до сих пор нет многопоточности, и он регулярно встает колом по-настоящему.

Судя по тому, что в elisp, написанном в середине восьмидесятых, динамическое связывание переменных...

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

Но суть совершенно не в этом. А в том, что я вижу две очень похожие программы (а на самом деле куда больше): ГНУ Емакс и Айскэт-Файрфокс. В одной поток один — и она естественно встает колом; а в другой — неугодная вам многопоточность — и она, хотя и бывает что подтормаживает, но колом не встает никогда.

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

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

Ай-вей, не уследил. Сейчас вот глянул - и вправду доступно, аж с 2012 года (я последний раз emacs щупал в 2002 году, чур меня). Ну то есть формально говоря доступно. Фактически, как я понял, не очень, в том смысле что, задабы им воспользоваться, надо этого очень хотеть и точно знать, чего хочешь; пардон, ставить сейчас свежий emacs для экспериментов не буду, так что более подробного результата не выдам. То, что лексическое связывание появилось аж в 2012 году, для меня само по себе более чем достаточно.

ГНУ Емакс
встает колом

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

Тем более что я тоже на файрфоксе сижу, и у меня он именно что встаёт колом. Вполне возможно, это из-за того, что я считаю ниже своего достоинства тратить деньги на «быстрое» железо и много-много памяти, когда единственное, что у меня тормозит - это долбаный браузер, причём только при включённом JS.

Мне это напоминает тот анекдот про три бутылки водки и ириску.

Интересные у вас, однако, ассоциации. :-)

Я к тому, что найти одну (тем более столь одиозную) однопоточную программу...
одиозную

Ой-ой?

это как-то вот лично меня вообще ни в чём не убеждает

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

И вот что не убеждает — это как раз все эти эмоциональные пассажи про «ногами по печени». Напротив — все это создает впечатление какой-то религиозной ненависти.

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

Куда убедительнее было бы просто поставить в пример программу уровня Емакса или Файрфокса, написанную угодным вам образом. Я уже один раз попросил это сделать — вы ответили на все, только не на это; прошу еще раз.