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

А современные ОС разве возвращают NULL?

Возвращают, если память не выделена.

Всё равно ведь дают адрес, а прибивают (что-нибудь) только при записи по этому адресу.

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

ad hominem?

Если человек пишет грязный, изобилующий багами, велосипадеми и плохими практиками код - чему он может научить, точно такому же подходу? Это ни разу не ad hominem: чтобы чему-то учить, надо это что-то уметь. И всё было бы ничего, если бы столяров ограничивался сугубо теорией, но ведь нет же, его книги называются «введение в профессию», и касаются не только алгоритмики, но и программирования под юниксы. То есть, он претендует быть именно прикладной литературой. А с прикладным подходом у столярова вообще не задалось, он в него банально не умеет.

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

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

Зайди в любой срач про systemd или wayland. Там тоже примерно такое же пишут.

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

Если бы у Столярова не было аллергии на новшества, мог бы

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

Возвращают, если память не выделена.

Ладно переформулирую. Разве современные ОС не всегда выделяют память?

https://www.opennet.ru/base/dev/malloc.txt.html

Вот именно, что прибивают. Это означает, что ты не получишь внятной ошибки, а получишь сегфолт.

Проверка на NULL не спасает. Адрес ведь возвращает не-NULL. А сегфолт получишь, когда своп при очередном a[i] = x закончится.

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

По-всякому бывает. Тексты Аристотеля на древнегреческом были ужасны. Но идеи в этих текстах создали основу физики.

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

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

Начать можно с принципа наименьшей неожиданности

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

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

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

Про Столярова как преподавателя ничего сказать не могу. Комментирую только текст его книги.

И что ты этим хочешь сказать, что это как-то оправдывает скотское поведение столярова?

Что это нормальная (в статистическом смысле) реакция на замену чего-то привычного старого на непривычное новое. Особенно, если человек не сталкивался с теми практическими задачами, для которого новое сделали.

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

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

Ладно переформулирую. Разве современные ОС не всегда выделяют память?

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

Проверка на NULL не спасает. Адрес ведь возвращает не-NULL.

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

По-всякому бывает. Тексты Аристотеля на древнегреческом были ужасны. Но идеи в этих текстах создали основу физики.

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

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

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

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

С учётом того, что там только программирование на Паскале и Си, прикладное значение очень преувеличено.

Что и требовалось доказать.

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

Про Столярова как преподавателя ничего сказать не могу. Комментирую только текст его книги.

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

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

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

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

Так сами по себе они не плохи. Побочный эффект в printf это хорошо.

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

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

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

В общем, я не вижу примера для переносимой программы, когда проверка на NULL имела бы смысл. Если пишешь для конкретной ОС, в которой malloc резервирует память, тогда имеет.

В си и плюсах разыменование NULL является UB, со всеми вытекающими последствиями. Например, компилятор может соптимизировать твой код как угодно, в результате чего ты разыменуешь не NULL, а NULL с каким-нибудь оффсетом. Огромное количество CVE, связанных с NULL pointer dereference, не дадут соврать. Вот зачем нужно всё это проверять.

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

Логично a[10] = x, если a == NULL, превратится в (int*)(10) = x. И если очень не повезёт, может попасть на разрешённый блок памяти.

Убедил.

А современные ОС разве возвращают NULL?

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

Кстати, когда Столярову указали на то, что существует ulimit, он сказал что-то вроде «ну да, я забыл про это, но в такой ситуации всё равно продолжать работу не имеет смысла, нужно упасть. А вас я забыл в игнор кинуть — старость не радость, да».

А разыменование NULL всё равно успешно завершает программу безо всяких проверок.

Нет, это UB. Произойти может всё, что угодно. А если ты root, то можно замаппить нулевую страницу в своём процессе.

ad hominem?
Мы обсуждаем моральный облик автора или его книгу и утверждения в книге?

Это связанные вещи. Если человек продаёт на базаре «лекарство от всех болезней», а кто-то подходит и говорит, что этот человек уже был судим за мошенничество и обращение фальсифицированных лекарственных средств — это ad hominem? «Мы обсужаем моральный облик торговца или его лекарство и утверждения о лекарстве?»

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

Кем? Вашим «любимцем» - Столяровым? ;P ;)))) Не знаю. Кем-то другим? Наверняка. И что??..

Побочный эффект в sin в виде вывода возвращаемого результата на стандартный вывод - плохо

А побочный эффект в виде установки errno в EDOM или кидания floating-point exception — плохо? В стандартной библиотеке sin делает одну из этих вещей, если передать ∞.

Число возвращает? Возвращает. Значит функция.

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

Так «•функциями•» являются все четыре сущности (поскольку они возвращают число), или же только те, к которым можно применить атрибут pure (первые две)? Вы уж определитесь.

Кстати, «возвращает число» — это значит гарантированно завершается после конечного числа операций? Или просто тип возвращаемого значения? Если первое, можно написать сущность, которая будет функцией тогда и только тогда, когда ZFC is non-sound.

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

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

А побочный эффект в виде установки errno в EDOM или кидания floating-point exception — плохо?

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

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

Так «•функциями•» являются все четыре сущности (поскольку они возвращают число), или же только те, к которым можно применить атрибут pure (первые две)? Вы уж определитесь.

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

Кстати, «возвращает число» — это значит гарантированно завершается после конечного числа операций? Или просто тип возвращаемого значения?

Тип значения.

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

Кем-то другим? Наверняка. И что??..

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

В смысле, функцию, которая всегда завершима только тогда, когда ZFC is non-sound? Это какая?

В смысле, функцию, которая всегда завершима только тогда, когда ZFC is non-sound?

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

Нет. Ничего на нем уже не пишут, кроме дремучего легаси.

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

Мы не всегда даже помним какие были проблемы в освоении программирования. Новичкам даже концепция массива и его индекса не сразу заходит, а им сразу Python, где и массивы и списки и туплы и словари, да ещё и массив может быть array, а может быть numpy'-евским и ещё в нескольких вариантах. И по синтаксису обращения не всегда ясно что есть, что, например, a[0] - это 1-й элемент массива или тупла? Понятно, не всё сразу давать надо, но всё же Паскаль тут мне кажется педагогически проще и Python и Си, притом Python далёк от железа и есть риск, что может не совсем правильное понимание работы вообще сформировать.

С теми же массивами, питоновский цикл for x in a: не даёт новичку нормально понять, что такое индекс массива. И чем вообще массив от списка (питоновского) отличается. Зачем для массива надо писать import array? Де-факто вместо массива новичок будет иметь дело со списком. Конечно, объяснить всё-равно можно, индекс (и для списка и для массива) можно использовать отдельно от цикла, сделать цикл с явным инкрементом индекса в теле или enumerate() и тд., но Паскаль тут педагогичнее, по-моему, а с Python новичок рискует оказаться с кашей в голове в понимании массивов и списков.

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

#include <stdio.h>
#include <stddef.h>

typedef struct Node {
    struct Node *prev;
    struct Node *next;
    unsigned char x;
} Node;

static const char *ip; // instruction pointer
static Node *dp; // data pointer

static void jump_to_matching_bracket(int direction)
{
    size_t balance = 0;
    for (;;) {
        switch (*ip) {
        case '[': ++balance; break;
        case ']': --balance; break;
        }
        if (balance == 0) {
            break;
        }
        ip += direction;
    }
}

static inline void interp(void)
{
#define RECUR(delta) (ip += (delta), interp())

    Node N;

    switch (*ip) {
    case '+':
        ++dp->x; RECUR(1); break;
    case '-':
        --dp->x; RECUR(1); break;
    case '.':
        putchar(dp->x); RECUR(1); break;
    case ',':
        dp->x = getchar(); RECUR(1); break;
    case '<':
        dp = dp->prev; RECUR(1); break;
    case '>':
        if (dp->next) {
            dp = dp->next;
        } else {
            N = (Node) {.prev = dp, .next = NULL, .x = '\0'};
            dp->next = &N;
            dp = &N;
        }
        RECUR(1);
        break;

    case '[':
        if (!dp->x) {
            jump_to_matching_bracket(1);
        }
        RECUR(1);
        break;

    case ']':
        jump_to_matching_bracket(-1);
        RECUR(0);
        break;

    case '\0':
        break;

    default:
        1 / 0;
    }
}

int main()
{
    ip = ">++++++++[<+++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>++++++++++[<---------->-]<-.";

    Node N = {.prev = NULL, .next = NULL, .x = '\0'};
    dp = &N;

    interp();
}

Впрочем, в busy beaver не будет ввода-вывода (точнее, он будет эмулироваться) — и оно будет «чистой функцией» (?).

С теми же массивами, питоновский цикл for x in a: не даёт новичку нормально понять, что такое индекс массива. И чем вообще массив от списка (питоновского) отличается. Зачем для массива надо писать import array? Де-факто вместо массива новичок будет иметь дело со списком.

Ничем. Питоновский list это плюcовый vector<variant>. А array в питоне это типизированный массив (оптимизация для скорости).

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

но Паскаль тут педагогичнее, по-моему, а с Python новичок рискует оказаться с кашей в голове в понимании массивов и списков.

В Паскале списков вообще нет, только вручную писать. В питоне хоть есть from llist import sllist.

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

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

А ещё он не считает нужным проверять результат malloc(), calloc() и прочее, на NULL.

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

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

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

Те кто пишут systemd и wayland может и не идиоты, но это всё равно хрень. И очень плохо что становится всё труднее работать без неё. Вон в GTK4 собираются иксы дропнуть.

А надо? Попытка разыменовать NULL приводит к падению процесса.

Выше же писали.

a = malloc(n);
a[i] = x; 

при a == 0 превратится в *i = x. Может не упасть, а что-то испортить.

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

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

Подмножество Си это почти полностью включает в себя ANSI C.

И есть ещё третий том, где рассматривается понятие парадигмы программирования и языки C++ и Tcl, а так же функциональные и логические.

a[i] = x; при a == 0 превратится в *i = x. Может не упасть, а что-то испортить.

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

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

Мир не ограничен x86-64/Linux. И нулевая страница может быть и разрешена админу на запись (а там ядро ОС).

А ещё он не считает нужным проверять результат malloc(), calloc() и прочее, на NULL.

А современные ОС разве возвращают NULL?

Сколько можно то?

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

Это само собой, но питоновский for удобен конечно, для тех, кто понимает, что он делает, но не уверен, что для новичка годится.

В Паскале списков вообще нет, только вручную писать. В питоне хоть есть from llist import sllist.

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

если реально «правильно учить программированию а не языку» и первым языком использовать Python то структуру данных с которой стоит начинать это dict - как нечто позволяющее ключ отображать в значение затем пояснить за «ассоциативные массивы» и перейти уже к описанию памяти как последовательности ячеек с натуральными адресами

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

Нет, я считаю, что первый язык должен быть не абстрактным в вакууме, а инструментом для решения практических задач студента. Чтобы он мог взять свежеизученный язык и использовать его, скажем, для подготовки лаб по физике, проведя массу однотипных рассчетов. Или подготовить какие-нибудь данные к пеачати. Или гуй налабать для чего-нибудь. Проблема нашей системы образования в том, что предметы катастрофически оторваны друг от друга. А если бы на одном предмете ты изучал что-то, а потом видел, как это что-то можно применить в другом предмете - изучение обоих шло бы гораздо лучше. Когда я учился в универе, мои однокурсники, изучив на программировании какой-то язык, на той же физике продолжали мучительно считать вручную 40 строк для таблицы по формуле стьюдента. Это полный и бесповоротный абсурд.

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

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

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

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

Подмножество Си это почти полностью включает в себя ANSI C.

Сейчас какой год? Это уже полный абсурд.

И есть ещё третий том, где рассматривается понятие парадигмы программирования и языки C++ и Tcl, а так же функциональные и логические.

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

Сказать тебе, как я изучал питон? Прочитал первые 50 страниц какой-то книжки в 2006 году. Всё. Остальное доделала практика.

Это само собой, но питоновский for удобен конечно, для тех, кто понимает, что он делает, но не уверен, что для новичка годится.

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

Это вроде не уязвимость

Это UB, с которым есть херова гора CVE, я об этом выше писал.

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

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

Тут как бы стоит разделять…

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

Таки с этим все согласны. Вот только ещё НЕ умеющий программировать студен НЕ сможет взять и изучить полезный живой язык. Просто потому что для него фразы «в Си есть три оператора цикла» пустой звук.

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

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

С этим справиться даже bc, который после любого ЯП осваивается за 2 часа. Если же надо с извлечением данных из файла и записью результатов в файл, то bc внутри шелл-скрипта, что будет быстрее и понятнее для начинающего.

Или гуй налабать для чего-нибудь.

Это перпендикулярная к любому ЯП задача, поскольку гуй сейчас лабается применением внешней к ЯП библиотеки, т.о. знать надо эту библиотеку (Tk, GTK, Qt), которую можно применить с любым ЯП.

Таки с этим все согласны.

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

необходимы самоучители

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

С этим справиться даже bc

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

Это перпендикулярная к любому ЯП задача

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

Хватит тратить время студента на бесполезную ерунду.

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

Для этих целей паскаль в виде FreePascal годен и для лаб по физике и для GUI (Lazarus). Я сам в начале 90-х лабы делал на турбо-паскале (на фортране тоже делал), принципиально лабы с тех пор не изменились. Python может даже более годен для лаб, но для этого студенту нужно не просто Python немного изучить, а освоить Pandas, Numpy, Mathplotlib и т.д. Впрочем, аналоги, позволяющие работать с табличными данными и библиотеки численных алгоритмов есть и для паскаля (FreePascal).

Тебе не нужно лезть в дебри numpy и array, достаточно использовать базовые структуры языка, на которых объяснять алгоритмику. Сущность списка гораздо более интуитивно-понятна, чем массив, особенно если ты хочешь положить в массив строки.

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

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

Ну какие там ограничения-то? Не предлагается же на ISO Pascal всё делать, а уже с 90-х годов Delphi и FreePascal не имеют дурацких ограничений оригинала.

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

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

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

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

Для этих целей паскаль в виде FreePascal годен и для лаб по физике и для GUI (Lazarus).

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

Python может даже более годен для лаб, но для этого студенту нужно не просто Python немного изучить, а освоить Pandas, Numpy, Mathplotlib и т.д.

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

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

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

Ну какие там ограничения-то?

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

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

Курс MIT по программированию начинается с питона.

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

А мы и не знаем, добивался ли он какого-то успеха, или просто грел стул, как 99% преподов, работающих по двадцать-тридцать лет на кафедрах. Я думаю, что в универе его могли облизывать по остаточному принципу, потому что он выпускает какую-то литературу и типа-знаменитость. О качестве его образования можно косвенно судить по его протеже, который писал статью rust-must-die, где навалил кучу безграмотных утверждений, буквально пересказывая утверждения столярова один к одному. Ее еще на хабре разбирали, если помнишь.

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

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

И чем вообще массив от списка (питоновского) отличается.

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

Хотя мне проще рекурсией делать и в FPC есть tailcall elimination с каким-то -O так что стек она не забивает.

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

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

Кто мешает по формуле Стьюдента считать на паскале? Норм язык для практических задач. А уже освоив его можно переходить на другие языки, когда в нём становится тесно.

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

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

Сказать тебе, как я изучал питон? Прочитал первые 50 страниц какой-то книжки в 2006 году. Всё. Остальное доделала практика.

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

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

У Столярова есть предварительные сведения — дискретная математика, комбинаторика, использование юникс-подобных ОС. А в «аналогичной» книге про питон наверняка пишут, как поставить какую-то неведомую хрень под Windows и использовать IDE, не так ли?

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

Ты книгу Столярова вообще не читал что ли? Он там явно пишет, причём в предисловии, что классический паскаль не нужен и объясняет, что кроме паскаля вообще ничего толкового нет в качестве первого языка и почему. При этом он берёт минимальное полезное подмножество паскаля и не рассматривает всякие with и set.

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