Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова

Хз как ваш оппонент ,есть достаточно проработанный подход у Северенса python зачем частности в сяшке

И есть Уорен(Грег кадацен там и Орен) который воркшом Карпентер - у него питон забавно пригоутавляетя

Сорян , но ты реально( а не для красного словца) не отдупляешь интенции Вирта vs Опоссума?!

При этом обр. Уровень популуса разный межу 50 оборотами земли

Но насколько можно назвать мёртвыми - вопрос. Совсем не мейнстрим явно, но последняя коммерческая (притом совсем не дешёвая) версия Embarcadero Delphi 13 была выпущена менее года назад. FreePascal тоже развивается и выпускаются регулярно версии, как и GUI конструктор к нему - Lazarus.

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

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

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

Не предлагает. У него указатели ближе к концу паскалевской части, а побочные эффекты в середине.

Предлагает. Именно это и предлагает, и ты сам это только что подтвердил.

И ничего сложного в них нет.

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

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

PS: https://htdp.org/ как раз схему и берёт, только режет её ещё на учебные фрагменты.

В питоне синтаксис сложнее чем в паскале.

Нет.

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

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

Ну и нафига он нужен, если он медленный, но в остальном ничем не лучше паскаля?

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

Встроенные структуры данных в самом начале не нужны, а потом скорее вредны.

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

Но зачем? Чем тебе вообще сдался этот питон?

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

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

при всей простоте указателей (котодые просто адреса адресов ) у сяшки прелестный синтаксис a[ b ] === *(a+b*size_of) == b[a] - ибо сяшка изначальна упрощение компилятора фортрана в 4Кслов памяти(Кену верить!) - именно хитровывернутый синтакис сяшки в части оперирования указателями и есть существенная доля когнитивной нагрузки для неофитов

само по себе оперирование адресами адресов не рокет сцнс

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

и ваще real programmer может писать на разном разное.

Потому что в хаскеле невозможно рассуждать о time complexity и memory complexity.

Какое memory complexity у этой программы (как функция от введённого n)?

main = do
    s_n <- getLine
    let n = (read s_n :: Int)
    print $ foldl (+) 0 [1..n]

(Ответ: зависит от желания и флагов ghc.)

И умение в многопоточность на хаскеле не транслируется в умение в многопоточность на императивных ЯП.

Но по удобству формошлёпия (как в хорошем, так и в плохом значении этого слова) к Delphi пока никто даже близко не приблизился. Стоит признать, как факт, что это, пожалуй, единственная полноценная RAD среда.

В Qt формошлепится только в путь.

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

Я про побочные эффекты — ничего сложного нет. Если в выражении (включая правую часть присваивания, заголовки if/while/until) происходит что-то кроме вычисления его значения — это побочный эффект.

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

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

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

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

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

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

Указатели ваще не заметны после школьной начал алгебры где появляются имена чисел тобиш переменные(именно в школьном смысле) - т.е проблема «не понимающих в указатели» - что они софтскилами как-то проскочили в школе 5-7 классов предметы математики и физики - что в очередной раз подтверждает в насколько гуммано время мы живём

Вопрос в слоях абстракции

Ваще у Айверсона(который A Programming Language) есть годная статья лекция : нотация как твоя мыслов.

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

Потому что в хаскеле невозможно рассуждать о time complexity и memory complexity.

Не больше и не меньше, чем в Си. Эквивалентная программа gcc с оптимизацией компилируется в O(1), так как суммирование заменяется умножением.

Какое memory complexity у этой программы (как функция от введённого n)?

По семантике должно быть O(1), так как foldl всегда работает только с головой последовательности, а после foldl эта голова нигде не используется.

Не больше и не меньше, чем в Си. Эквивалентная программа gcc с оптимизацией компилируется в O(1), так как суммирование заменяется умножением.

В Си можно рассуждать, поскольку можно рассуждать о худшем случае и «по семантике». Да, оптимизации могут сработать, но это просто плюшки.

По семантике должно быть O(1), так как foldl всегда работает только с головой последовательности, а после foldl эта голова нигде не используется.

А почему ghc без флагов компилирует не «по семантике» и получается O(n)?

[~]-[%] ghc test.hs
[1 of 2] Compiling Main             ( test.hs, test.o ) [Missing object file]
[2 of 2] Linking test
[~]-[%] echo 100000000 | ./test
zsh: done       echo 100000000 | 
zsh: killed     ./test

[~]-[%] ghc -O2 test.hs
[1 of 2] Compiling Main             ( test.hs, test.o ) [Flags changed]
[2 of 2] Linking test [Objects changed]
[~]-[%] echo 100000000 | ./test
5000000050000000
[~]-[%] 

В Си можно рассуждать, поскольку можно рассуждать о худшем случае и «по семантике».

На Си она тоже в худшем случае O(n).

А почему ghc без флагов компилирует не «по семантике» и получается O(n)?

Потому что сборщик мусора не обязан отрабатывать сразу.

Это примерно эквивалентно следующему коду на Java

for (int i = 0; i < n; i++) {
    int[] myArray = new int[1];
}

Здесь О(1) или О(n)? По семантике О(1), так как каждый массив живёт одну итерацию, а по факту может быть O(n).

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

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

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

Потому что сборщик мусора не обязан отрабатывать сразу.

Получается, сборщик мусора ни разу не запускается до того, как программа отожрёт 3 Gb+?

Нет, он отрабатывает огромное число раз. Он уверен, что эти все данные — живые:

[~]-[%] ghc -rtsopts test.hs
[1 of 2] Compiling Main             ( test.hs, test.o ) [Missing object file]
[2 of 2] Linking test
[~]-[%] echo 100000000 | ./test +RTS -Sstderr -RTS
    Alloc    Copied     Live     GC     GC      TOT      TOT  Page Flts
    bytes     bytes     bytes   user   elap     user     elap
  4163816   2054440   2095496  0.001  0.001    0.005    0.005    0    0  (Gen:  0)
  4128768   4117512   4159880  0.002  0.002    0.008    0.008    0    0  (Gen:  0)
  4128768   6183064   6224128  0.003  0.003    0.011    0.011    0    0  (Gen:  1)
  4125968   4126648   8286352  0.001  0.001    0.013    0.012    0    0  (Gen:  0)
  4128768   4126080  10350736  0.002  0.002    0.015    0.015    0    0  (Gen:  0)
  4128768  12372808  12397440  0.006  0.006    0.022    0.022    0    0  (Gen:  1)
  4128768   4128800  14461824  0.001  0.001    0.024    0.024    0    0  (Gen:  0)
  4128768   4128800  16526208  0.001  0.001    0.025    0.025    0    0  (Gen:  0)
[•••]
  4128768   4128800 2968593312  0.001  0.001    3.855    3.856    0    0  (Gen:  0)
  4128768   4128800 2970657696  0.001  0.001    3.857    3.858    0    0  (Gen:  0)
zsh: done       echo 100000000 | 
zsh: killed     ./test +RTS -Sstderr -RTS 2>&1 | 

Здесь О(1) или О(n)? По семантике О(1), так как каждый массив живёт одну итерацию, а по факту может быть O(n).

Давай проверим на практике.

[~]-[%] cat MyMain.java
public class MyMain
{
    public static void main(String []args)
    {
        int n = Integer.parseInt(args[0]);
        int ptrXor = 0;
        long maxMemoryUsage = 0;

        for (int i = 0; i < n; ++i) {
            int[] myArray = new int[1];
            ptrXor ^= System.identityHashCode(myArray);

            long memoryUsage = Runtime.getRuntime().totalMemory();
            if (memoryUsage > maxMemoryUsage) {
                maxMemoryUsage = memoryUsage;
            }
        }

        System.out.println("maxMemoryUsage: " + maxMemoryUsage);
        System.out.println("ptrXor: " + ptrXor);
    }
}
[~]-[%] javac MyMain.java
[~]-[%] java MyMain 100000000
maxMemoryUsage: 130023424
ptrXor: 1285191720
[~]-[%]

В нормальных языках full scan запускается, когда программа сожрала a * N, где a > 1 — фиксированный коэффициент, N — потребление памяти после последнего full scan.

На Си она тоже в худшем случае O(n).

Щито? Для какой программы?

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

Я немного выше привёл пример, что если даже захотеть в нейросети (куда ещё совремённее), где стандартный язык сейчас - это Python, можно найти рабочие варианты с FreePascal. Более простые вещи там накоплены в огромном количестве ещё с 90-х даже. Есть модули для работы с таблицами Excel, для построения графиков и тд. Для числовых расчётов много чего есть, даже адаптации и биндинги таких вещей как OpenBLAS и OpenCV имеются.

Так что тут вопрос сугубо педагогический. Есть те, кто считают, что Паскаль как первый ЯП проще и прививает правильные вкусы в программировании. При этом, в варианте FreePascal - это достаточно мощный и ЯП и экосистема вокруг него, чтобы не страдать от академичности.

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

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

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

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

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

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

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

можно найти рабочие варианты с FreePascal

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

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

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

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

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

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

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

поэтому я настаиваю на питоне

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

Щито? Для какой программы?

Приведённой: print $ foldl (+) 0 [1..n]

То есть: printf("%i\n", foldl_int(add, 0, range(1, n)));

[~]-[%] java MyMain 100000000
maxMemoryUsage: 130023424

А java MyMain 10 ?

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

Да вот знаешь, фреймворк для нейросетей на котором можно делать не только инференс, но и обучение и чтобы он поддерживал OpenCL, а ещё и просто SIMD-инструкции, включая AVX512 ещё поискать. В ходе общения с тобой я такой случайно нагуглил на FreePascal, на Python похоже нет, во всяком случае, самый массовый и известный PyTorch не умеет. На других языках, вроде TNN от Tencent или MNN (от Alibaba) - это всё для инференса. С точки зрения индустрии тут проблем нет: учим модель на GPU в PyTorch, деплоим для инференса потом подо что-то более конкретное, но для студентов и разных экспериментов может хотеться и обучения с OpenCL, а в некоторых случаях (сочетания GPU/CPU) ещё вопрос на чём быстрее будет.

Надо конечно пощупать будет, а то звучит хорошо, но как на практике выйдет?

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

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

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

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

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

То есть: printf(«%i\n», foldl_int(add, 0, range(1, n)));

Это не идиоматический Си.

Я ошибся, нужно вычислять runtime.totalMemory() - runtime.freeMemory() для получения текущего использования.

Но больше 77 MB оно всё равно не выжирает. Поэтому O(1).

[~]-[%] cat MyMain.java
public class MyMain
{
    public static void main(String []args)
    {
        int n = Integer.parseInt(args[0]);
        int ptrXor = 0;
        long maxMemoryUsage = 0;

        Runtime rt = Runtime.getRuntime();

        for (int i = 0; i < n; ++i) {
            int[] myArray = new int[1];
            ptrXor ^= System.identityHashCode(myArray);

            long memoryUsage = rt.totalMemory() - rt.freeMemory();
            if (memoryUsage > maxMemoryUsage) {
                maxMemoryUsage = memoryUsage;
            }
        }

        System.out.println("maxMemoryUsage: " + maxMemoryUsage);
        System.out.println("ptrXor: " + ptrXor);
    }
}
[~]-[%] javac MyMain.java
[~]-[%]

[~]-[%] time java MyMain 10
maxMemoryUsage: 2630216
ptrXor: 1693969300

real	0.04s
user	0.03s
sys	0.02s
[~]-[%] time java MyMain 100000000
maxMemoryUsage: 77717376
ptrXor: 1285191720

real	6.96s
user	6.93s
sys	0.04s
[~]-[%] time java MyMain 500000000
maxMemoryUsage: 77719184
ptrXor: 753865803

real	33.98s
user	33.89s
sys	0.05s
[~]-[%] time java MyMain 900000000
maxMemoryUsage: 77715584
ptrXor: 1969225014

real	60.34s
user	60.29s
sys	0.06s
[~]-[%] 

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

Что не так с индексами в питоне?

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

Это всё не нужно на этапе алгоритмостроения. Все эти проблемы надуманные и решается корректным составлением учебного материала.

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

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

Что не так с индексами в питоне?

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

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

Значит спор по поводу FreePascal только о распространённости?

А почему ghc без флагов компилирует не «по семантике» и получается O(n)?

Очистка ненужных ленивых списков, оказывается, оптимизация.

Не то, чтобы не так, но я почему-то слегка спотыкаюсь об ::-1 и тп.

Это зачем-то нужно на ранних стадиях обучения?

Значит спор по поводу FreePascal только о распространённости?

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

Нет. Я не понимаю, мы ходим по кругу.

Действительно по кругу ходим.

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

Ни по одному пункту не вижу, чтобы Паскаль в варианте FreePascal не подходил. Конечно, если живой подразумевает, что есть масса вакансий с ним, то тут проблема, но даже вакансии, между прочим, имеются! Если верить https://o-kurse.ru/blog/it-i-tsifrovye-professii/specialist-po-pascal/ то на сегодня (март 2026, дата статьи) на hh.ru имеются 95 вакансий с FreePascal и 300 вакансий с Delphi (вероятно не только их требуют). Конечно это небольшое число и вакансии могут быть мусорными, но всё же.

Для новичков пригоден. Если TP/BP/Delphi были пригодны в 90-х, то чего бы им сейчас не быть пригодным? В том числе для практических задач студента. Лабы считать точно получится. Т.к. FreePascal практический язык, то и интеграция с сями там налажена. Есть нужные типы данных и директивы компилятору с сишными соглашениями о вызове.

Достаточно распространён, чтобы находить в интернете решения проблем.

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

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

Курс в MIT (SICP) рассчитан на специфическую аудиторию: сильных студентов с развитым математическим мышлением. Это не для всех. И этот курс очень высокой интенсивности, быстро добирающийся до весьма сложных понятий без «бытового» программирования. Фактически, хотя он и позиционируется для студентов 1-го курса, но для успешного освоения желательно уже иметь хотя бы начальный опыт программирования.

Так вот не отрицаю возможности, чтобы начать быстро с Python, потом продолжить с Си, но и как бы традиционный академический подход с Паскалем не склонен считать ошибочным с потерей времени.

Ни по одному пункту не вижу, чтобы Паскаль в варианте FreePascal не подходил.

Ну раз спустя 33 страницы всё ещё не видишь, то я уже ничем не могу помочь.

Но по удобству формошлёпия (как в хорошем, так и в плохом значении этого слова) к Delphi пока никто даже близко не приблизился. Стоит признать, как факт, что это, пожалуй, единственная полноценная RAD среда.

Спорно. Я бы назвал Clarion. Clarion for Windows, конечно же: здесь же речь идёт про ху... ээээммм... "гуЁвый интерфейс", верно??.. :)

Хотя, как по мне, и под DOS (CPD v2.1, Clarion Professional Developer) «Клаша» была хороша́. В хорошем смысле этого слова. :))

P.S. «Я так думаю!» © :)

повторюсь у Северенса ( есть диалог с Бомбалом) достаточно проработанная конь-прицепция как python/c (ну там как и у Зеда ещё и упор что под ругой (ba)sh+git ) - это типо аналог-англосферный нашего Столярова А.(В?). - бюджеты(больше в абсолютных чисел привлечённых стороников ибо популюс решает) иные поэтому более проработан и меньше индивидуальных экцентричностей

симметричность n и ~n

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

если сравнивать Oberon-среду с Python+Repl (яркий пример scapy как инструмент который не есть отдельная компильнутость а расширеный интерпретатор python'а подточенный по задачи «исправления» сети) то отличия не большие но значимые для публики почти как acme vs мыcode

ибо популюс решает

А точно не «охлос»??.. ;))

в (до)гон

https://en.wikipedia.org/wiki/Charles_Severance_(computer_scientist) py4e и там же https://www.cc4e.com/

И следовательно https://www.dr-chuck.com/ вполне идеальный http://stolyarov.info/ для liksys ;(

In the context of programming, a function is a named sequence of statements that performs a computation.

http://do1.dr-chuck.com/pythonlearn/EN_us/pythonlearn.pdf

Для него и макра функция - чел самый успешный облучатель при этом

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

сразу с отладчика начать?

сразу с отладчика начать?

Да!.. Напишите сначала отладчик!.. ;P ;))

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

Осталось понять, причём тут Питон? И какая связь между интеграцией с Си (что бы это ни значило) и ОБУЧЕНИЕМ? Переходить от Питона к Си гладко не получится.

Курс в MIT (SICP) рассчитан на специфическую аудиторию

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

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

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

Печально в таком подходе то, что любой другой ЯП потребует полной переделки курса, т.е. победит Rust и курс для C++ выбрасывается, а выбравший в качестве базового ЯП Go преподаватель не сможет опереться на курс с базовой Java.

Либо из любого другого ЯП в качестве базового лепим я-ля уродливый аналог Паскаля и потом доучиваем и… ПЕРЕУЧИВАЕМ, например, писать в Си i++, а не i=i+1;.

ПЕРЕУЧИВАЕМ, например, писать в Си i++, а не i=i+1;.

Дык, вроде в Паскале Inc() имеется? И емнип - испокон веков, не?