Сколько зарабатывает Pascal программист?

Мои глубочайшие соболезнования всем сопричастным:-(

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

так жить нельзя…

Лол ок, ваше мнение очень важно для нас, спасибо за звонок. А как ты себе представляешь работу мидла-топа в крупном продакшене (производстве, не ит)? Сидеть на яхте тереть за жизнь и нихрена не делать?

тереть за жизнь и нихрена не делать

Примерно такой же выхлоп, как и от «работы» в экселе.

Мои глубочайшие соболезнования всем сопричастным

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

Вот уж лучше скрипты хоть на чем-то чем руки стереть в пыль

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

Ну так на мои аргументы о простоте кода, вы ответили догмой, что нужен паттерн модель, нужно, чтобы переменные не менялись в функции. А потом сказали, что вообще все в main нужно засунуть, но magic-numbers нужно объявить отдельно. Как-то это все странно.

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

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

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

Там кроме забытого + одна биомасса лишняя как минимум. Это не хим.реакция второго порядка, там линейное ОДУ.

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

В сишке и сейчас делают: GTK живее всех живых.

А про JS шутка:

- На каком языке никто не пишет, но все транслируют код
в него?
- Ассемблер?
- Нет. JavaScript.

А я еще видел, как вручную таблицы на 10000 строк и 200 столбцов правят, типа разбивают записи на два поля или наоборот сливают в одно… Требования бюрократии в составлении отчетов и документов порой принимают очень извращенные формы.

Примерно такой выхлоп, как и от «работы» в экселе.

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

Со списком, с моей точки зрения, это ошибка разработки питона.

Ну так я про это и говорю, и такого довольно много в питоне.

Я пользуюсь кстати паскале-поделием - Double Commander. Из за этого на ряде платформ эта программа будет недоступна, увы

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

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

Со списком, с моей точки зрения, это ошибка разработки питона

Почему ошибка? У тебя абсолютно все включая примитивы передаётся только по ссылке, а дальше включается правило mutable/immutable. Это просто осознанный выбор, а не ошибка

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

От преподавателя зависит. В целом с группой 30 человек еще возможно. Где-то треть будут копировать чужой код, и они не будут хорошо учиться, так, получат начальные навыки и все, поэтому индивидуально работать придется по факту только с 20-ю, из них человек 8-10 будут прям вот стараться, самостоятельно что-то осваивать, их нужно будет направлять и подсказывать, соотв. индивидуальной работы тоже по времени будет не особо много. В итоге время будут сжирать 10 середнячков, ну так на это времени хватит. Но конечно, все сильно зависит о контингента.

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

Ну не проверил, ну ошибся в цифре, ну просрал пару лямов и пару десятков тонн добра

Да, для этого эксель как ничто иное подходит.

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

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

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

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

Зато есть ссылочные параметры и передача массива или записи (структуры) по значению приводит к копированию массива или записи. Хотя считать ли это плюсом, если в Python, Iota, Java, Ruby, JavaScript, Scheme, Ocaml, AppleScript, … всё не так и придётся переучиваться. А в Си++ переучиваться в другую сторону.

В целом с группой 30 человек еще возможно

С одной группой да. В общей школе у препода по информатике групп мягко говоря больше одной. В моё время у нас было два препода на все 11 классов. Ни о каком индивидуальном подходе даже речь не шла. Только по личному и очень сильному желанию ученика. Да и в универе на нашего препода было групп 5 кажется. Это уже на старших курсах 1-2 группы, и то не факт.

В Финляндии помню преподам легче было, там где-то 2-3 группы всегда, больше редко, но там свои тараканы были, по сути каждый курс готовься что у тебя 2/3 группы «нулевые» (не было последовательности прохождения курсов).

Я про то, что a += b меняет значение объекта внутри a, если этот объект изменяемый. В то время как почти всюду написано, что A += B ≡ A = A + B.

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

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

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

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

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

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

В то время как почти всюду написано, что A += B ≡ A = A + B.

Ох блин, вот это один из моих любимых примеров почему питон не надо давать первым языком. Потом ещё можно сразу довеском вопрос что быстрее, a = a + b или a += b.

Ну подготовка кадров в РФ мертва, тут особо говорить нечего. Я вот больше математику уже не преподаю, хотя 14 лет ее рассказывал, потому что стало уже невозможно. Щас вот оставил себе один день в неделю (основы программирования и что-то про ИИ) в пешей доступности от дома и все. Но если там будут требовать кучу фигни, то как бы и там прекращу преподавать.

Ну подготовка кадров в РФ мертва, тут особо говорить нечего

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

Поэтому я считаю, что если речь идет об обучении будущих системщиков и работающих с железом, то нужно начинать с С и С++

Вот для системщиков я бы давал Паскаль. Есть машинные типы, есть указатели, есть структуры, есть передача по ссылке и значению. При этом нет вопросов «почему массив является указателем», «почему символ является числом», «почему работа со строками через ж… сложные функции».

Кроме того нормальное деление на процедуры и функции. Нормальное деление на интерфейс и реализацию.

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

Для ребят, которым понимание как устроено железо не нужно, я бы давал питон

Здесь я полностью согласен.

Но не про все это рассказывать

Достаточно рассказывать про питон без ООП. Рассказать про структуры управления и про типы (списки, словари, кортежи).

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

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

Потом ещё можно сразу довеском вопрос что быстрее, a = a + b или a += b.

Для встроенных типов должно быть одинаково. Для невстроенных может быть как угодно, так как add и iadd могут делать вообще разное, для списков += быстрее, так как не происходит копирования существующих элементов списка.

Вот для системщиков я бы давал Паскаль.

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

Достаточно рассказывать про питон без ООП. Рассказать про структуры управления и про типы (списки, словари, кортежи).

Согласен.

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

Согласен.

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

Для встроенных типов должно быть одинаково. Для невстроенных может быть как угодно, так как add и iadd могут делать вообще разное, для списков += быстрее, так как не происходит копирования существующих элементов списка.

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

Но тут не могу не отметить, некую нелогичность в разнице «a=a+b» и «a+=b» для списков, результат то один и тот же с т.з. содержимого переменной.

Но тут не могу не отметить, некую нелогичность в разнице «a=a+b» и «a+=b» для списков, результат то один и тот же с т.з. содержимого переменной.

y = [1, 2, 3]
x = y
x += [4] # здесь меняется и y
x = x + [4] # а здесь только x

Да, точно.

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

Я питон не преподавал, соотв. ничего не могу про это сказать. Но я бы скорее всего говорил, что «=» создает новый объект, соотв. чтобы вы были уверены что результат операции не влияет на что-то в другом месте, то используйте «=», а «+=» меняет объект и могут быть последствия (как твой пример выше), соотв. избегайте этого, если нет причин это делать (оптимизацией занимайтесь, тогда когда она вам реально нужна, вначале чтобы работало, потом чтобы код был написан правильно, а потом уже оптимизация, если не надоело с кодом возиться).

Ну так на мои аргументы о простоте кода, вы ответили догмой, что нужен паттерн модель, нужно, чтобы переменные не менялись в функции. А потом сказали, что вообще все в main нужно засунуть, но magic-numbers нужно объявить отдельно. Как-то это все странно.

Ещё раз:

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

2. как только Вы попытаетесь это сделать, Вы тут же поймете что функции лишние (по делу они там не нужны, комментить/патчить можно и в main).

3. если Вы таки захотите оставить функции, то Вы упретесь в передачу параметров. Глобальные переменные это общеизвестный антипаттерн.

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

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

Нет конечно. Бактерии размножаются как dx/dt = ax при безлимитных ресурсах. В этом случае бактерии не взаимодействуют друг с другом, тупо делятся раз в сколько то минут, откуда там квадрат?!

Некоторые хим.реакции протекают как dx/dt=ax^2 (т.н. реакции второго порядка), но это другое.

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

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

если Вы таки захотите оставить функции, то Вы упреиесь в передачу параметров. Глобальные переменные это общеизвкстеый антипаттерн.

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

таким образом мы неизбежно приходим либо к одной функции (максимально пррстое решение),

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

либо к классу (правильно решение на вырост)

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

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

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

Нет конечно. Бактерии размножаются как dx/dt = ax при безлимитных ресурсах. В этом случае бактерии не взаимодействуют друг с другом, тупо делятся раз в сколько то минут, откуда там квадрат?!

А, ну да. Переклинило что-то, от времени квадрат.

PS: поймите меня правильно, я не спорю, что паттерн модель это хорошо, что классы это хорошо, что неизменяемые параметры это хорошо. Я говорю о том, что простые вещи нужно делать просто и не нужно использовать сложные методы для простых задач, усложняя код. Кроме того, не все их знают, нельзя несколько лекций подряд рассказывать сложные вещи, а потом чтобы их реализовывали. Все должно быть постепенно. Каждый подход к написанию кода имеет свой лимит по сложности решаемой задачи и свой порог входа, и про это нельзя забывать. Приведенный пример это второе задание при обучении программированию (первое это запустить hello world из IDE), а вы сразу паттерны и классы хотите. Много из тех, кто используют код вообще ни паттернов, и даже ООП могут и не знать. Если быть чуть более корректным, то мое второе задание это моделирование актива, т.е. что выгодней взять ипотеку или копить в банке, соотв. там я предупреждаю, что будут разные события, типа кризиса и потери работы и нужно промоделировать разные варианты… Это хорошая задача, которая и интересна с практической т.з. и требует усложнения кода, т.е. довольно быстро приходится создавать структуры, но не прям сразу.

PSS: «ак только эта схема написания кода перестает отвечать сложности задачи, и это все студенты прочувствуют, видя как код превращается в хаос, я рассказывают про то, какие средства есть чтобы сделать код простым для этой новой сложности.» – с таким подходом то вы согласны?

Хоть кто-то прочитал код.

Вы сейчас про квадрат? Я в модель даже не пытался вникнуть…

Вы сейчас про квадрат? Я в модель даже не пытался вникнуть…

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

программа становится большой

Всё относительно. Когда начинаешь ворочать MLOC правила игры существенно меняются. Я даже не уверен что в вузах можно к этому подготовить…

Всё относительно. Когда начинаешь ворочать MLOC правила игры существенно меняются. Я даже не уверен что в вузах можно к этому подготовить…

Угу. Ну вузы сегодня мало что могут сделать, если только это не целенаправленная подготовка программистов. Тем, кому я преподаю, у них всего один раз в неделю, по две пары, в течении третьего курса. Так что тут можно успеть только привить несколько подходов к написанию кода разной сложности (паттерны уже никак) и заставить их написать тысяч 10, может 20 строчек за все время. Ну так, знакомство с программированием.

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

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

Мой пример, был демонстрирующий подход путем разбиения на функции по уровням абстракции, бизнес-логика это ядро, она соотв. в функции simulation, все остальное – детали, вынесены в отдельные функции. Это демонстрация подхода, который еще позволяет довольно сильно усложнить решаемую задачу, т.е. можно вносить другие события, можно делать более сложными отдельные функции, и пр. При этом, конечно, нужно будет начинать улучшать текущую заготовку, т.е. избавляться от magic-numbers, объединять данные в структуры, вынести вывод в консоль в отдельную функцию и т.п. Но сам подход, разделение на функции и сокрытие сложности путем выноса реализации очень хорош.

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

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

Потом паттерны…

Потом виртуальные машины…

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

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

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

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

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

И наоборот, как ты можешь пояснить устройство списоков-кортежей в CPython? Которые сплошной сишный массив. То есть, абсолютно любая операция, кроме «изменить ячейку» либо дорогая, как append, либо очень дорогая, как prepend или insert.

Ты включал комп, набирал команду - и она мгновенно работала! А теперь? Включи, загрузи ОС, запусти IDE, набери код, скомпилируй, запусти, дождись

Ура, я думал, что я один такой поехавший, который считает, что в 2022 для пользовательского устройства (софт+хард) недопустимо запускаться дольше пары секунд. Черт подери, даже автомобиль нынче не нужно по 10 секунд заводить. Особенно крестовики живут в каком-то своем мире, где у них быстрее компиляции крестов ничего не бывает, при том, что весь остальной мир понимает, что если изменения к программе применяются медленнее, чем я отпускаю кнопку Enter после нажатия — то это всё уже градации между «медленно» и «чертовски медленно».

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

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

Жаба это чистый ооп. А ооп без классов это, кхм, занятно б было

Посмотри на клон жавы — C#. Он отображается почти один в один на модель CLR, а в эту же модель отображается F#, который функциональщина. И под JVM есть функциональные языки, которые отображаются в классы. Другое дело, что на самом деле классы — это бесполезная промежуточная сущность, без них написание программ и разработка компилятора были бы намного проще.

классы — это бесполезная промежуточная сущность

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

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

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

Альтернативами на тот момент были Фортран и ПЛ/1 с одной стороны. Которые тоже были предназначены для написания быстрых программ, но скорость программы зависела не от программиста, а от компилятора. И Лисп с другой стороны, где было всё для написания надёжных программ: сборка мусора, отсутствие неопределённого поведения, невозможность средствами языка влезть в неинициализированную память, но медленный.

С момента, когда ассемблерные структуры перестали адекватно соответствовать примитивам Си (MMX?), развитие Си пошло по пути Фортрана. Только вместо нормальных высокоуровневых инструкций компилятор начал распознавать идиоматический код на Си.

Которые сплошной сишный массив. То есть, абсолютно любая операция, кроме «изменить ячейку» либо дорогая, как append, либо очень дорогая, как prepend или insert.

Так в Си и Си++ массивы тоже активно используются. Чем Питон хуже? Разве что не понятно, зачем они массивы назвали списками.

Тем, кому я преподаю

Где-то можно глянуть на программку/методичку? И если не секрет - где преподаёте?

Если знать что «программа — это индуктивная гипотеза» и уметь в доказуху, весь этот абстракционизм на паттернах и даже ООП не нужен (Степанов ООП именно поэтому выстебал, создав STL :)) они изобретены как подпорка для погромистов не в теме, которые якобы увидят знакомые кубики и разберутся, но... нет, не разберутся, если предметная область предполагает знания какой-нибудь ядерной физики, передвигать кровати бесполезно и слона по частям нанятый с рыночка за еду, никто не съест, не в коня корм. Из буков О, П, А, Ж они «щастье» не сложат, и софт на фортране красиво на модный молодежный и танцевальный стек не перепишут :)

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

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

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

Их просто не учат чувству меры и границам применимости методологий :)

Где-то можно глянуть на программку/методичку? И если не секрет - где преподаёте?

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

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

По содержанию занятия устроены так.

1. Первое занятие это установка IDE, настройка toolchain, использование cmake (если не IDE это не visual studio), регистрация в github, написание (запуск) «Hello World». Разумеется, вначале я рассказываю что это такое и зачем нужно, но не долго и без подробностей. А потом мы это ставим, это выносит им мозг, т.к. очень много чего нового, непонятных слов, еще и настройка/установка не особо простая (а ребята сидят на винде, кроме 1-3 человек), и соответственно, вдобавок ко всему огребают проблемы от кириллического имени пользователя. Но тут надо перетерпеть, тут очень важно продавить их, чтобы к концу занятия у всех была среда в которой можно писать и запускать программы.

2. Следующее занятие это уже написание кода на С. Лекция очень короткая: объявление переменных (int, double), функция main(), циклы for(){} и while(){}, свои фукнции int my_function(){}, функция printf().

Задание: есть Alice и Bob, у них такая-то зарплата, Alice берет ипотеку под столько то процентов, Bob копит в банке под такой-то процент. Чья стратегия более успешна? Тут я сразу говорю, что задача поставлена не полностью и нужно самому додумать детали, т.е. все как в жизни.

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

Второй момент это организация кода. Они пишут все в main и очень быстро он превращается в хаос, они перестают видеть свой код, особенно, в этом помогает printf. Я еще добавляю, что надо учесть, что через 4 года Bob потеряет работу и будет тратить сбережения, а не копить. На этом этапе я рассказываю про процедурный подход, что можно разбивать все на функции и выносить детали реализации в них. В первую очередь, нужно вынести вывод результата, т.е. блок printf.

Периодически студенты показывают мне код и я ненавязчиво говорю им, как его можно улучшить. Предлагаю хорошие названия для переменных и функций, показываю мелкие приемы, типа (int deposit = 1000000; => int deposit = 10 * 1000 * 100; // копейки).

Потом недолго в форме лекции рассказываю о том, что есть соглашения об оформлении кода. И с этого момента прошу их соблюдать, что глобальные константы большими буквами, что функции и переменные – маленькими (для C/C++ я выбрал этот стиль, т.к. он более читаемый) и т.д.

К этому времени задача усложнилась достаточно, и я рассказываю про структуры и предлагаю все их переменные объединить в них. Рассказываю про char[].

Потом я показываю как бы я написал этот код, т.е. открываю emacs (транслируется на экран) и набираю код комментирую что и почему я делаю. В стиле того примера. Отмечая, что при написании simulation можно отложить написание реализации вызываемых методов, и фактически simulation это ТЗ самому себе, короткое и понятное. И при таком подходе вы можете спокойно и ненапряжно написать достаточно сложные вещи все время держа в голове только маленький кусочек задания.

После этого (прошло примерно 3 занятия по 2 пары), это задание становится одним из заданий для получения зачета. Впрочем, к этом времени у половины оно уже фактически сделано, нужно только чуть-чуть поправить код.

3. Третий блок заданий это работа с памятью. Я прошу сделать структуру для матрицы и написать некоторые базовые функции для работы с ней – арифметику, детерминант, обращение, экспоненту. Учитывая, что они робототехники, я планирую потом это оформить в какое-нибудь более конкретное задание, типа решения уравнения Ляпунова, но пока не придумал какое. Ключевой момент этого задания это недопустить утечек памяти. Это сложно.

Рассказываю про указатели, прошу матрицу хранить в едином массиве, а не в массиве массивов, для удобства разрешаю, если хотят, иметь в структуре дополнительное поле – массив указателей на первые элементы строк.

По-прежнему, основное внимание уделяю стилистике кода. Чтобы он был понятным. Рассказываю о клише в именах, и о том, что они полезны, типа begin/end, first/last, set/get, что функции проверки лучше именовать is_***, и т.п. Рекомендую смотреть как называют аналогичные методы в других библиотеках и программных пакетах, чтобы все было ожидаемо.

Код становится сложным, на этом этапе я уже прошу чтобы функции не меняли параметры, а возвращали новое значение (если это разумно, конечно), что в функциях параметры полезно делать const.

Поскольку это работа с матрицами, то тут много вложенных циклов for, соотв. я прошу для индексов использовать понятные названия, например, col, row, а нt i, j, k. Они все равно используют, но ровно до того момента, как ошибаются, и не могут найти ошибку, я не говорю в чем ошибка, я прошу изменить названия индексов и после этого они ошибку видят и начинают писать нормальные имена для индексов.

Рассказываю про уровни вложенности и рекомендую, чтобы из было поменьше. Соответственно, рассказываю и показываю, что особые случаи, проверку данных лучше сделать вначале функции и завершить ее return.

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

Где-то по ходу дела немного рассказываю про препроцессор.

Это второе задание для зачета.

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

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

4. Четвертое задание. С++. Я прошу написать матрицы через классы. Немного рассказываю про классы: поля, методы, private, public, конструкторы (в т.ч. копий и переноса), деструкторы. Говорю, что выделение, очистку памяти надо делать в конструкторах и деструкторах, в других местах лучше не делать.

Потом рассказываю про перегрузку операторов, соотв. прошу перегрузить арифметические операторы и присваивание, и ==, !=.

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

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

Это четвертое задание для зачета: класс матрицы + исключения.

5. Уже конец семестра, и у многих подкопились долги. Немного рассказываю про шаблоны, что можно сделать так, что ваш код будет работать и для матриц с double и для матриц с float. Прошу изменить код чтобы типа данных элементов матрицы можно было задавать. Указываю, что учитывая код вычислений, на int заменить не получится, и соответственно, что шаблоны надо использовать ОЧЕНЬ аккуратно. Про сonstraints & concepts не рассказываю. На данном этапе нужно чтобы они немножно увидели template, чтобы лучше воспринять STL в следующем семестре.

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

Это последнее пятое задание.

Как-то так.

Снимаю шляпу. Я бы не выдержал. Имел дело исключительно с «выпускниками», и то - «тяжко мне было»…

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

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

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

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

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