ЛОР, помоги выбрать ЯП для обучения

Ассемблеры для этого более бесполезны

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

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

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

Вот из-за такого бреда весь нынешний софт и представляет собой блоатварь.

Вот из-за такого бреда весь нынешний софт и представляет собой блоатварь.

Вааааще ни разу. Жава куда большая блоатварь, чем тот же гогланг. И была она задолго до виртуалок с докером.

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

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

Вовсе нет. Ассемблер даёт представление о том, что может процессор в реальности, а что нет. Например о том, что нет никаких магических объектов, которые сами по себе появляются и исчезают

Для программиста есть. За него это рантайм делает.

что переменная это не более чем ячейка памяти или регистр

Для программиста есть stack и heap. Оба этих понятия так же не требуют ассамблера. Достаточно рассказать, чем одного от другого отличается.

что без адресной арифметики ничего работать на существующих процессорах не будет

Будет, в asm нет адресной арифметики. Это сишное понятие, лол.

что стек это не более чем кусок памяти

Опять же, зачем для этого ассемблер? Смотри:

0 var x uint32 
1
2
3
4 var y uint32
5
6
7

Вот так занимают стек две переменные в гогланге. Никакой ассемблер тут не нужен.

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

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

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

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

Спроси современного упоротого плюсовика какую алгоритмическую сложность имеет a = new Object(x,y,z);. Они реально не понимают что это не всего лишь одна строчка кода, а процесс, который может быть весьма тяжёлым.

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

Только вот инструкции процессора != ассемблер. А так да, надо знать. Это объясняется двумя предложениями.

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

Зачем? Что это дает сверх знания о том, что бинарный код это набор инструкций для CPU?

Спроси современного упоротого плюсовика какую алгоритмическую сложность имеет a = new Object(x,y,z);. Они реально не понимают что это не всего лишь одна строчка кода, а процесс, который может быть весьма тяжёлым.

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

Для пошагового достижения высокого звания программиста, а не кодировщика определенного языка. Никогда не понимал людей, которые ограничивают себя одним языком - чем больше знаешь, тем больше понимаешь. Эрик Стивен Реймонд рекомендовал изучить 4 языка программирования: системный, ООП-язык, скриптовый и функциональный.

Для пошагового достижения высокого звания программиста, а не кодировщика определенного языка. Никогда не понимал людей, которые ограничивают себя одним языком - чем больше знаешь, тем больше понимаешь. Эрик Стивен Реймонд рекомендовал изучить 4 языка программирования: системный, ООП-язык, скриптовый и функциональный.

Программист – это кодировщик определенного языка. Это, буквально, суть профессии. Все остальное это overqualification для 75% рынка.

кодировщик определенного языка

Это плюсовик, сишник, питонист или шарпник.

Pascal и Python

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

Уффф, ну тогда со мной все фпорядке - я не программист и на это высокое звание давно не претендую;-)

ЯП правда учил и юзал разные - машкоды для калькулятора, бейсик, паскаль, С, C++, питон (не считая LaTeXа и баша). С хаскелем и лиспом не задалось, не прижились они у нас. Питон кстати сразу за три сойдет - скриптовый, ООП, функциональный;-)

По моему скромному опыту идеальный сферический программист в вакууме со знанием 100500 ЯП как правило нафик ненужен. Нужен человек знающий предметную область где он работает, структуры данных/алгоритмы что бы решать в этой предметной области задачи, ну и ЯП что бы эти решения воплощать на приемлемом уровне. И знание предметной области является чуть ли не ключевым - я ХЗ как там в крупных конторах, а в маленьких без этого знания замучаешься объяснять что именно сделать надо.

поэтому пишет блоатварь,

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

Для программиста есть. За него это рантайм делает.

При этом этот «программист» даже не представляет что именно за него делает рантайм. Ага.

Будет, в asm нет адресной арифметики. Это сишное понятие, лол.

mov eax, [ebp+ebx+0xF8] Никакой адресной арифметики. Ага.

Опять же, зачем для этого ассемблер?

Вот так занимают стек две переменные в гогланге. Никакой ассемблер тут не нужен.

А потом «программист» занимается рекурсией или 100500 вложенных вызовов устраивает. И опа. Hello world сжирает гигабайт.

его первый элемент — функция

Не функция, а команда. Которая может быть функцией, а может и не быть. И вот тех которые не могут быть там на целый талмуд.

Только вот инструкции процессора != ассемблер.

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

Зачем? Что это дает сверх знания о том, что бинарный код это набор инструкций для CPU?

Затем, что это даёт понимание что какое-нибудь a = new Object(x,y,z) или там Object b = a; это не одна строчка и не элементарная операция, а иногда весьма сложный и затратный процесс. Понимание того, что какая-нибудь абстракция или синтаксическая вкусняшка может легко вылится в мегабайты памяти и миллиарды циклов.

там рантайм под капотом, который много всего делает.

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

И самое смешное, что знание что именно делает рантайм в этой ситуации

Знание знанию рознь. То, что обезьяна знает что рантайм делает сортировку если написать a.sort();, совершенно не означает что он понимает как на самом деле эта сортировка работает и сколько циклов и памяти она занимает. А вот когда он ручками напишет сотню-другую строк на ассемблере и реально увидит какое-нибудь O(n^2), то 1000 раз подумает прежде чем пихать sort на каждый незначительный чих.

При этом этот «программист» даже не представляет что именно за него делает рантайм. Ага.

Так и ты не представляешь, если не читал код. И чаще всего тебе и не надо. Если я сейчас спрошу как работает аллокация памяти в линуксе, включая mm/ из ядра, я услышу пук-среньк mmap page fault без критически важных деталей. Чем это отличается от людей, которые не знают какие там детали аллокации объекта в плюсах? Ты всегда работаешь с какой-то абстракцией и это абсолютно нормально.

mov eax, [ebp+ebx+0xF8] Никакой адресной арифметики. Ага.

Никакой. То что ты называешь адресной арифметикой, называется pointer arithmetics и вообще про другое. В примере выше ты тупо массив проиндексировал. В asm нет указателей, лол. Есть операции чтения по адресу и записи по адресу. Они есть в любом языке, где есть индексируемые массивы.

А потом «программист» занимается рекурсией или 100500 вложенных вызовов устраивает. И опа. Hello world сжирает гигабайт.

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

Не функция, а команда. Которая может быть функцией, а может и не быть. И вот тех которые не могут быть там на целый талмуд.

Э, что? Либо функция, либо специальная форма. Других вариантов нет. Специальных форм всего несколько штук и учатся они по мере необходимости.

предлагаешь инструкции процессора в шестнадцатеричном виде изучать?

почему обязательно в шестнадцатеричном?

Никакой. То что ты называешь адресной арифметикой, называется pointer arithmetics и вообще про другое. В примере выше ты тупо массив проиндексировал. В asm нет указателей, лол. Есть операции чтения по адресу и записи по адресу. Они есть в любом языке, где есть индексируемые массивы.

Расскажите что делает команда lea? Можете расшифровать аббревиатуру?

Вы ученый судя по поведению - любите похвастаться о себе любимом :)))

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

Мое определение идеального программиста – это дзен-программист, который код не пишет: ненаписанный код работает идеально!

-Operation_ ¶

IF OperandSize = 16 and AddressSize = 16
    THEN
        DEST := EffectiveAddress(SRC); (* 16-bit address *)
    ELSE IF OperandSize = 16 and AddressSize = 32
        THEN
            temp := EffectiveAddress(SRC); (* 32-bit address *)
            DEST := temp[0:15]; (* 16-bit address *)
        FI;
    ELSE IF OperandSize = 32 and AddressSize = 16
        THEN
            temp := EffectiveAddress(SRC); (* 16-bit address *)
            DEST := ZeroExtend(temp); (* 32-bit address *)
        FI;
    ELSE IF OperandSize = 32 and AddressSize = 32
        THEN
            DEST := EffectiveAddress(SRC); (* 32-bit address *)
        FI;
    ELSE IF OperandSize = 16 and AddressSize = 64
        THEN
            temp := EffectiveAddress(SRC); (* 64-bit address *)
            DEST := temp[0:15]; (* 16-bit address *)
        FI;
    ELSE IF OperandSize = 32 and AddressSize = 64
        THEN
            temp := EffectiveAddress(SRC); (* 64-bit address *)
            DEST := temp[0:31]; (* 16-bit address *)
        FI;
    ELSE IF OperandSize = 64 and AddressSize = 64
        THEN
            DEST := EffectiveAddress(SRC); (* 64-bit address *)
        FI;
FI;

Учите, детушки, АЛГОЛ-68! Это самый лучший язык!

Вы ученый судя по поведению - любите похвастаться о себе любимом :)))

Ученым может быть пудель, а я научный сотрудник (с) Ландау. Нет, я не хвастаюсь, просто озвучиваю свой путь тык-скыть. Хвастаться тут особо нечем, у ровесников это была программа минимум. У кого был спектрум те вообще звери… я ж вот честно говорю - не программист я.

приходилось в процессе исправления критических падений приложения находить источник проблем…

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

ненаписанный код работает идеально!

Если работает.

Если я сейчас спрошу как работает аллокация памяти в линуксе

Начать можно с MMU, page tables и всего такого. Сделать упор на то, что физической памяти в компьютере ограниченное количество.

Ты всегда работаешь с какой-то абстракцией и это абсолютно нормально.

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

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

Как это связано с ассемблером, опять же? Концепцию стека показали (без ассемблера, заметь).

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

Все, никакого ассемблера снова не потребовалось.

«А чо такого-то, я всего лишь один объект в функции локально объявил - всего-то одну ячейку стека занял.»

почему обязательно в шестнадцатеричном?

Традиция такая.

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

Однозначным отображением в каком направлении?

Однозначным отображением в каком направлении?

В обеих.

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

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

Расскажите что делает команда lea? Можете расшифровать аббревиатуру?

Load Effective Address

Позволяет использовать вычисление адреса для арифметики. Например умножение на 3, 5, 9 можно сделать этой командой, и компиляторы делают. Могут и две команды скомбинировать. Еще и константу заодно можно добавить.

Э, что? Либо функция, либо специальная форма. Других вариантов нет

Причём специальная форма — это тоже функция, только встроенная в интерпретатор и с особенными правилами вычисления.

Стыдно этого не знать, товарищ no-such-file. А ещё лисповую аватарку надел.

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

(define var value)
(define (func args) …)
(let ((local-var value)) …)
(lambda (args) …)
(if cond yep nop)

По три минуты на каждую — за 15 минут уложишься. Т.е. вообще не вижу повода заламывать руки.

IF не получится сделать «обычной» функцией?

Нет, конечно. Пусть мы, например определим if через cond как

(define (my-if pred true-clause false-clause)
  (cond ((pred true-clause)
         (true false-clause))))

что случится, при вычислении?

(my-if true 1 (/ 1 0))

https://en.wikipedia.org/wiki/Advent_of_Code

https://adventofcode.com/2024/

тоже функция, только встроенная в интерпретатор и с особенными правилами вычисления

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

По три минуты на каждую — за 15 минут уложишься

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

Тут суть в том, что в любом другом языке ты можешь изучить синтаксис и на этом всё – любой код можно читать. Не обязательно ты его при этом поймёшь, т.к. будут неизвестные слова-функции. Но в ЛИСПе и этого нет. Ты можешь открыть код и несмочь его даже прочитать, потому что «особенные правила вычисления».

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

Мнемоника MOV никогда не используется без операндов, поэтому полная команда ассемблера всегда соответствует конкретной инструкции. И наоборот - инструкция имеет единственное отображение в виде мнемоники с операндами.

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

Дизассемблированный код скормленный ассемблеру всегда даёт тот же самый код. Если это не так, то либо в ассемблере, либо в дизассемблере ошибка.

На один только loop можно потратить несколько занятий.

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

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

Нормальный такой заход. Если чтобы читать лисп, нужно знать loop, то чтоб java-код читать, нужно знать назубок всю стандартую библиотеку и Spring, как-минимум. Про javascript вообще молчу.

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

Не открывайте такой код вашим студентам, пока они к нему не готовы. Это просто. Я вообще не понимаю о чём вы спорите и зачем. Чтобы вести курс программирования, взяв схему в качестве основного языка, нужно на объяснение синтаксиса и семантики схемы потратить 15 минут. Всё. Этого достаточно. При этом останется за кадром куча интересных макросов, библиотек и фреймворков. Но они для обучения программированию совершенно ненужны.

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

Как и любой фреймворк или крупная библиотека на менее выразительных языках.

Python. Всех, кто советует Pascal или Oberon, вы смело можете обозвать идиотами. Pascal давно вышел из употребления, а Oberon никогда и не применялся. Альтернативные варианты:

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

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

Python. Всех, кто советует Pascal или Oberon, вы смело можете обозвать идиотами. Pascal давно вышел из употребления, а Oberon никогда и не применялся.

Вы тоже не различаете «учить языку» и «учить программированию»?

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

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

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

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

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

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

память это отложенное вычисление и даже может ленивое

это граф конфигурации

а может какая копрограмма али yield lazy

копро.грамма, гы-гы. ковыражения как в icon, например

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

man мемоизация

man суперкомпиляция и прогонка

man сворачивание графа конфигурации

У ФП (лямбда-исчисления) есть некоторые проблемы со сложностью (вроде NP-полная) в проецировании в гарвардскую архитектуру (машину Тьюринга). Из-за этой сложности ФП программирование выпало из практического употребления на целое поколение учеников (1980-2000 годы).

машина Ландина aka SECD-машина из LispKit «механизация лямбда-исчисления» который ещё на паскале – это, внезапно, примерно как форт-машина только с 4-мя стеками, а не с двумя.

не вижу тут особых сложностей «в проецировании в фон-неймановскую архитектуру», всё брутально тупо и буквально

категориальная машина типа ZAM или CAM из Ocaml, например – это уже абстрактная, а не виртуальная машина.

опять таки, не вижу особых сложностей по сравнению с SECD или форт-машиной.

это, конечно – если эти сложности подавать последовательно.

например, взять того же Лео Броуди «Thinking Forth!» и реализовать например, форт-машину либо «саму на себе» в духе того же jonesforth или метакомпилятором типа lbforth,

ну или для простоты – на том же конпелируемом nim например.

а потом уже на этот форт натягивать SECD аналогичное LispKit, либо ZAM или CAM.

или вообще взять рефал-5 какой-нибудь, только не на сишке от маздайщика а на том же nim для наглядности.

и потом последовательно реализовать на нём:

• форт-машину с 1,2 стеками;

• лисповую SECD машину Ландина из LispKit, хотя бы – на этом форте; – с 4 стеками

• ZAM- или CAM абстрактную машину в духе окамла – и переписать свой недоязычок реализации с nim на kaleidoscope и ocaml и LLVM, например;

просто тут тоже самое – это ФП нужно подавать последовательно, с мащины на машину через машину реализовывая интерпретатор и копелятор учебного недоязычка – а не начиная с факториалов, как это обычно бывает.

Ряд ораторов уже отметили, что образовательный маршрут сильно зависит от того, кого учить, как долго и для чего?

Как долго — важно, да.

«Кого?», «Для чего?» — хотя уже поздновато отвечать, но кого угодно и для любых целей. Это же введение в программирование. Это всё равно что преподавать основные правила русского языка: полезно будет как школьнику, так и таджику. Ну да, можно придумать индивидуальный план, учесть прошлое и будущее, но я не хочу этим заморачиваться. Мне главное преподавать в порядке нарастания сложности, чтобы в голове строилась правильная иерархия, а там пусть сами разбираются.

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

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

Скорее всего, C. Это современный паскаль - ни для чего серьёзного не годится, зато прост как пробка для объяснения основных концепций и не портит опыт отсутствием типов. Потом наверное плюсы, переход на них с C прозрачен, и они открывают ООП и мир готовых библиотек, в т.ч. для геймдева и gui. А умея самостоятельно написать калькулятор на Qt и крестики-нолики на SDL, можно уже в любую сторону развиваться.

Это всё равно, что спросить «как обучать физике» и умолчать о такой детали, речь ли о шестиклашке (или её в седьмом начинают?), подготовке к ЕГЭ или углубленном курсе квантовой физике для профильной магистратуре.

P.S. А мы в ответ обсуждаем, обязательно ли давать кватернионы или тензорное исчисление по верхам пробежать, да и достаточно.

Пара слов о «правильной иерархии».

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

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

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

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

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