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

Это хороший пример, и он учит хорошему стилю программирования.

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

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

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

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

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

Почему «б»? Существует же JS.

в питоне достаточно написать

def compose(f, g):
  def r(x):
    return f(g(x))
  return r

В Си++ несколько десятков строк нетривиального кода.

4 строчки как и на Python…

auto compose(auto f, auto g) {
    auto r = [=](auto x) { return f(g(x)); };
    return r;
}

Тогда, наверное и в три можно:

auto compose(auto f, auto g) {
    return [=](auto x) { return f(g(x)); };
}

Тогда Си++ уже тоже готов для функционального программирования.

Тогда, наверное и в три можно:

Да, так тоже можно.

https://gcc.godbolt.org/z/fKKxe8YWr

У нас был чувак-доцент. Вёл он не у нас, но я слушал его курс лекций. Ну, был интересен сам предмет.

Знаменит этот мужик был как участник экспозиции и обладатель медали ВДНХ. Когда-то это было синонимом нереальной крутизны.

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

На паскаль нанимают чтобы поддерживать дедовские экскременты мамонта, кнопка New Project в среде дельфи давно покрыта паутиной

Да что ты такое говоришь.

"VCL — лучшая библиотека для WinAPI, интеграции COM, WinRT и скоро Project Reunion.

Библиотека продолжает расширяться, на сегодняшний день включает в себя Windows API, COM и объекты оболочки, API платформы WinRT. И мы продолжаем добавлять новые компоненты и сопоставления с новыми API. VCL уже включает функции Microsoft Project Reunion, и в будущем будет еще больше." © (embarcadero.com)

Простые вещи надо делать просто. Не надо городить классы и пр, когда нужно промоделировать изменение одного параметра.

Чего тут отлаживать? Тут код линейный, все видно, переменная изменяется везде, т.к. единственный смысл функций это ее изменение.

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

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

Потому что я вижу в явном виде

Таки на call-site этого не видно, так что я соглашусь с Вашими оппонентами. Как вариант - передача параметра by-ptr была бы немножко нагляднее (и с тем же asm’ом, кстати), но в этом примере - приём и возврат double by-value самый чистый, и самый быстрый (точно никогда не медленней).

Я пробовал канпелять штук 20, ни одна не заработала с первого раза.

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

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

Таки на call-site этого не видно, так что я соглашусь с Вашими оппонентами. Как вариант - передача параметра by-ptr была бы немножко нагляднее (и с тем же asm’ом, кстати), но в этом примере - приём и возврат double by-value самый чистый, и самый быстрый (точно никогда не медленней).

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

А в питоне нужно понимать, что переменная может измениться в любой функции, т.к. всегда передача идет по ссылке. А еще нужно понимать, что var += 1 это забытие старой переменной «var» и создание новой переменной «var», а var[0] += 1 это работа с той же переменной-списком, но забытие старой переменной-первого-элемента и создание новой переменной-первого-элемента. Короче, нужно получать элементы концепции функционального программирования, т.е. неизменность «переменных», что само по себе звучит как оксюморон. В итоге получается, что простые переменные в питоне неизменны, а сложные вполне себе меняются, ведь список изменился после var[0] += 1, и var какой была, такой и осталась. Короче какая-то полуфункциональщина получилась. Это несколько смущает детские мозги, да и мои, если честно, тоже.

Вы хочете послушать за моделирование? Такое есть у меня.

1. хотите делать просто - делайте просто. В приведённом Вами примере функции, кроме main, нафик не нужны. Не надо городить функции там где они лишние.

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

Класс модели - это очень хороший паттерн.

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

+1
У меня была мысль, что он сознательно допустил в листингах программ ошибки, чтобы обладатели пытливых умов получили практику. Хотя не факт. Но если так, то своих целей #медалистВДНХ таки добился.

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

Да наоборот же. Переменная никогда не меняется.

а var[0] += 1 это работа с той же переменной-списком, но забытие старой переменной-первого-элемента и создание новой переменной-первого-элемента

Откуда переменная первого элемента взялась?

Вот тебе такой же пример на Си++:

void do_it(int var[10])
{
        var[0] += 2;
}

int main()
{
        int var[10];
        var[0] = 5;
        do_it(var);
        cout << var[0] << endl;
}

Выведет 7. Хотя передача по значению (нет &).

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

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

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

Да наоборот же. Переменная никогда не меняется.

Тут путаница с номенклатурой. Под переменной обычно подразумеваем ее имя, т.е. в «var = 1» переменная это «var», если мы потом сделаем «var += 1», то по имени «var» у нас будет не 1, а 2, вот и получается, что переменная изменилась. Простая логика.

А то, что под капотом это на самом деле не переменная, а указатель на неизменный объект, и изменился указатель, и теперь он указывает на другой неизменный объект – это все понимать гораздо сложнее, имя то тоже осталось!

А если переменная это список, то после «var[0] += 1» список стал другим, но указатель var остался тем же, это еще больше запутывает.

Вот тебе такой же пример на Си++:

ну потому что тут на самом деле «do_it(int* var);» или «do_it(int var[])», в С++ var[10] это не список, и он не позиционируется как список. Это указатель которому выделено 10 раз по size_of(). Тут сложно запутаться, т.к. тут в явном виде передан указатель.

VCL — лучшая библиотека для WinAPI

Иногда жалею, что забросил C++ Builder. VCL действительно хороша.

Под переменной обычно подразумеваем ее имя, т.е. в «var = 1» переменная это «var», если мы потом сделаем «var += 1», то по имени «var» у нас будет не 1, а 2, вот и получается, что переменная изменилась.

Ну. var += 1 === var = var + 1 как в Си. После этого в var новый объект.

А то, что под капотом это на самом деле не переменная, а указатель на неизменный объект, и изменился указатель, и теперь он указывает на другой неизменный объект – это все понимать гораздо сложнее, имя то тоже осталось!

Гораздо легче представить, что в var новое значение 2, чем то, что константа 1 изменилась и стала равняться двум.

А если переменная это список, то после «var[0] += 1» список стал другим, но указатель var остался тем же, это еще больше запутывает.

В Си(++) с массивами абсолютно также.

и он не позиционируется как список

Это список элементов. И если даже сделать список в виде struct List { int data; struct List* next }, то при передаче такого списка по значению и изменению в нём второго элемента, в переданном списке изменится второй элемент.

Гораздо легче представить, в var новое значение 2

т.е. то, что переменная var изменилась? А как же с неизменностью переменных?

В Си(++) с массивами абсолютно также.

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

А в питоне это все скрыто, вот вам переменная, и не думайте, но работает она вот так или вот так, а может еще и так. Почему? Не думайте, тут ссылок нет.

Трудно всерьез воспринимать не-кроссплатформенные библиотеки в 2020+ годах, будь они хоть трижды замечательные

т.е. то, что переменная var изменилась? А как же с неизменностью переменных?

Если ты пишешь var = ... или var += ..., то переменная меняется. Если ты пишешь f(var), то переменная не меняется.

А в питоне это все скрыто, вот вам переменная, и не думайте, но работает она вот так или вот так, а может еще и так.

Там также всё открыто. Любая переменная содержит (семантически) ссылку на объект. При выполнении любой функции всегда передаётся эта ссылка (но не переменная!). Если объект изменяемый, то при помощи этой ссылки можно изменить содержимое объекта, если неизменяемый, то нет. Всё единообразно. А не так, что если передаёшь значение строки или массива в старом стиле, то они изменяются, так как это указатели, а если в новом через STL, то не изменяются, так как будет копирование объекта. Причём даже если передашь старый тип, а в описании функции STL, то тоже будет копирование объекта. Вплоть до того, что при передаче по ссылке тоже может не меняться.

На чистом жс с прототипами никто не станет в здравом уме делать ооп. Для этого есть ts/cs.

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

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

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

У Lazarus'а кроссплатформенная библиотека.

Совершенно не обязательно объяснять начинающему все его фичи.

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

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

Если ты пишешь var = … или var += …, то переменная меняется. Если ты пишешь f(var), то переменная не меняется.

А если var это список, то и в f(var) значение списка может измениться. Короче, на мой взгляд логика для простого языка получилась слишком уж как спагетти.

Мне кажется, что логичней говорить, что «var += 2» означает, что будет новый объект доступный под старым именем. Это соответствует логике функционального программирования, если есть переопределение идентификатора.

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

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

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

они знают что под капотом этого вектора

Ну да ну да. Ты хорошего мнения о «ребятах».

А в питоне это все скрыто, вот вам переменная, и не думайте, но работает она вот так или вот так, а может еще и так. Почему? Не думайте, тут ссылок нет.

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

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

Уж лучше мы школьные познания паскаля откопаем.

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

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

А то потом суют этот иксель во фсе дыры, а остальным мучайся…

Ну да ну да. Ты хорошего мнения о «ребятах».

Так речь идет о тех, кто учится кодить, которые пару недель назад написали свой первый hello world.

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

На чистом жс с прототипами никто не станет в здравом уме делать ооп. Для этого есть ts/cs.

ООП таки делали. А ts появился только в 2012.

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

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

Не говорю уже о том, что у Вас в численной схеме грубая ошибка… бактерии не так размножаются:-(

и ваших оппонентов, любителей питона

Я на питоне как бы пишу, так что не оппонент.

Особенно порадовал VBA

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

Но все таки я за классическое образование с нормальными яп (можете считать мя снобом-ретроградом:-)).

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

Надо из икселя конвертить таблицу во что то нормальное, хоть в жсон, и дальше её тем же питоном курочить. У меня пандок только импортиться на порядки дольше чем сам скрипт обработки ворочается, так жить нельзя…

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

Пошла апелляция к стажу.

Не говорю уже о том, что у Вас в численной схеме грубая ошибка… бактерии не так размножаются:-(

Наконец-то, а я все думал, когда мне забытый + припомнят. Хоть кто-то прочитал код.

ООП таки делали

«Не станет делать», будущее время. Так-то и в сишке псевдо-ооп делали, и на фасме тоже извернуться можно. Но не нужно.

Пошла апелляция к стажу

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

Наконец-то, а я все думал, когда мне забытый + припомнят

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

А если var это список, то и в f(var) значение списка может измениться.

Но var то от этого не меняется. Также как в Си при передаче переменной, содержащей указатель, по значению.

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

Наоборот единообразная. И не приходится объяснять, почему a[10] передаётся всегда по ссылке, а struct { int a[10] } уже копирует массив при передаче.

что «var += 2» означает, что будет новый объект доступный под старым именем

Так именно это и есть.

Но со списком это уже не проходит, т.к. меняя содержимое списка мы не меняем объект-имя-списка…

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

При этом в тексте перепутать += 1 и += [1] сложнее, чем в << 2 заметить, что здесь не умножение на 4, а вывод двойки в файл.

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

в экселе

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

Ну дык надо их драть питоном с танцами вокруг дата сцайенс:-)

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

Надо из икселя конвертить таблицу во что то нормальное, хоть в жсон, и дальше её тем же питоном курочить

Там менеджеры, какой питон. Им доп софт нельзя ставить на комп самим. Дали эксель, дали морду сапа, дали outlook - всё, время фигачить. А запрос на установку чего-то нового в гигантской mnc это дело нескольких недель, если не дольше. При том для каждого следующего юзера этого кода.

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