> Чем вам так плох Паскаль?

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

> Мы ведь учимся выражать свои мысли в форме готовой программы.

Нет, с языками всё несколько сложнее. Осваивая язык, мы учимся не только выражать мысли на этом языке, мы ещё учимся думать мысли, которые можно выразить на этом языке. Об этом педагоги от информатики часто забывают, и потом бьются в истерике от того, что студенты им попались тупые. Это не студенты тупые, это педагог бездарный, который не понимает того, чему учит. Если студент не умеет думать такие мысли о том, как надо отсортировать массив, которые можно выразить на языке программирования, то он не напишет программу, которая сортирует массив. А для того, чтобы научиться думать мысли, выразимые на выбранном языке программирования, надо писать на этом языке программирования, а чтобы писать, надо уметь думать как надо. Это замкнутый круг, единственный способ этот разомкнуть -- растянуть его в спираль, когда обучение идёт шажками: новые абстракции/конструкции языка -> новый опыт -> дифференциация опыта и обобщение его -> новые мысли -> новые абстракции/конструкции -> ...

> Сам язык вторичен. С, С++, Асм - сложные языки и довольно "недружелюбные" к новичкам.

C не более недружелюбен, чем Pascal. C++ -- смотря как его излагать, он удобен тем, что позволяет использовать лишь подмножество себя, которое не сильно-то отличается от паскаля да C, и таким образом он не более недружелюбен к новичкам, чем C и Pascal. Насчёт же недружелюбности ассемблера ты глубоко заблуждаешься, впрочем, следом за подавляющим большинством профессуры.

> Сам язык вторичен.

В том-то и дело, что язык вторичен. С точки зрения простоты изучения программирования единственное свойство языка, на которое следует обращать внимание при выборе его -- это то количество понятий, абстракций и синтаксических конструкций, которое придётся изучить для того, чтобы в голове сформировалось бы полное по Тьюрингу подмножество языка. Как только такое подмножество сформировалось, как только оно было освоено, можно заниматься накоплением опыта, и новые понятия усваивать как обобщение уже накопленного опыта. До того, как это подмножество сформировано, подчастую приходится усваивать новые понятия и абстракции без опоры на конкретный опыт, а вот это сложно. Я сравнительно недавно переживал эту сложность в своей жизни ещё раз: я осваивал rust, на котором очень сложно писать программы, пока понятия lifetime'ов и borrowing'а не освоены на уровне автоматизированных навыков, обрести такие навыки можно исключительно через опыт программирования на rust'е, но когда эти понятия не освоены, опыт программирования на rust'е сводится к борьбе с борроу-чекером компилятора. К борьбе, которая эпизодически скатывается в партер метода Монте-Карло, когда в программу вносятся рандомные изменения, отбираются те, которые уменьшили количество ошибок и отбрасываются те, которые количество ошибок увеличивают. Так вот, это был не первый раз в моей жизни, когда я оказывался в столь непростой ситуации, со мной такое случалось неоднократно. И, отмечу, не всегда я выходил победителем. Но с растом мне удалось справиться, и, что более интересно, этот опыт оказался последней каплей, которой мне не хватало для перехода к обобщениям, из которых вытекают, в том числе, и совершенно неожиданные последствия: я перестал ненавидеть бейсик. Вот тот древний бейсик с номерами строк. Потому что я понял, что мои успехи на первых шагах знакомства с программированием были обусловлены именно тупизной того бейсика, тем что в нём минимум абстракций, которые надо понять, для того, чтобы начать писать осмысленные программы. Там не было циклов, не было условий в смысле структурного программирования. Не было блоков команд, не было ничего лишнего. Там было последовательное выполнение строк программы, на каждой строке какое-нибудь одно выражение либо "IF condition THEN выражение". Ещё был GOTO, который при желании можно было использовать вместе с IF. Ну и несколько команд -- для ввода/вывода текста с/на экран, и вывода простеньких графических примитивов. Чуть позже меня познакомили с массивами. И этого было достаточно для всего.

Когда же я перешёл к C, то нового я там увидел только в типизации -- struct, union, enum. Всё остальное -- циклы, условия и даже функции, были для меня не новыми понятиями, которые надо освоить теоретически, а потом научиться применять практически -- нееет, они были для меня охрененно удобным способом записи того, что я и без того мог налабать на бейсике и более того неоднократно лабал. Я тогда в десятом классе влюбился в C по уши.

И на фоне всего этого, я вот думаю, что ассемблер -- это отличный способ изучать программирование. Он не особо сложнее бейсика -- там только что со строками работать сложнее, да математические выражения приходится расписывать в виде последовательности команд. Зато изучение ассемблера реально полезно. При этом со строками можно выкрутиться -- есть разные дурацкие способы работы, которые неудобны в реальной программе, но вполне покатят в студенческой поделке. А математические выражения расписывать -- это не так сложно, если человек умеет пользоваться калькулятором, в котором нет скобочек. Причём, я отмечу -- с языком ассемблера я познакомился, может быть даже раньше чем с бейсиком: у моего отца был МК-61. И с программированием того калькулятора у меня была ровно одна проблема: мне было не придумать задач, которые я мог бы решить программкой для калькулятора.

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