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

Там обычная алгебраическая запись, куда уж проще?

process context templateFile outFile =
readFile templateFile
>>= foldM (processLine processTemplate) context . lines
>>= writeFile outFile . unlines . reverse . result

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

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

Третий момент — если я захочу в этом коде сделать логирование, то мне придется либо дергать сишные функции, либо пробрасывать монаду через весь проект — это та самая катастрофа отсутствия унификации, которую хаскелисты нынче пытаются решать и рассказывают, как у них получается, но забывают, что этой проблемы просто нет нигде, кроме некоторых хаскель-подобных языков (даже не всех). В остальных языках нет необходимости в операторе «>>=» для 95% задач, но хаскель разворачивает всё верх ногами, и теперь для 95% задач «>>=» или do notation обязательна.

Неудавшийся Бейсик жалко?

Нет. Я опыта с ним не имел. А на фортран95 я получил удовольствие.

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

Сигнатуры требуются не больше, чем в конструкции «ls | grep … | sort | uniq». «aaa >>= bbb >>= ccc» делает то же самое для операций, а «ccc . bbb . aaa» для чистых функций. Принципы взаимодействия операций в любом языке знать надо. Логирование втыкается в любую операцию:

readFile templateFile
  >>= foldM (withLog $ processLine processTemplate) context . lines
  >>= writeFile outFile . unlines . reverse . result

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

Именно бесконтрольное оперирование указателем как числом является причиной всехз проблем Си — и потому этих проблем нет в Fortran и Ada.

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

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

Родили целый Си++. Не помогло. Пришлось рождать С# со сборщиком мусора. В нём проблем с UB нет.

Java

Modula-2, Oberon-2

Батареек нет.

Надо писать.

вакансии с Фортраном начинаются от 3000$/mo. И не то чтобы их сложно найти

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

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

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

Я не знаю, что это за withLog, так что конкретно его прокомментировать не смогу, но аргумент не меняется — либо пробрасывать монады по всему коду (как делает та же MTL, но я не уверен, что withLog из него), либо сишные функции, вроде trace.

Сигнатуры требуются не больше, чем в конструкции «ls | grep … | sort | uniq». «aaa >>= bbb >>= ccc» делает то же самое для операций, а «ccc . bbb . aaa» для чистых функций

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

Даже взять простое «aaa >>= bbb» — что же делает это «>>=»? Этого не ясно из кода, я должен знать типы aaa, bbb, и черт знате где находящегося типа возврата. Оно точно принимает аргументом bbb, а не результат его вызова? То есть, прочитав «строчку» кода на хаскеле невозможно понять, что она делает. Это называется «отсутствие модульности». Особенно в свете тесности связей вызываемой функции с вызывающей и со вложенными вызываемыми одновременно это превращает приложение на хаскеле в сплошной монолит из тесно переплетенных сущностей — типивой итог разработки, и основная причина, почему самый большой созданный на хаскеле проект — это сам компилятор хаскеля. В таком стиле не получится больше создать ни одной крупной софтины.

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

В Си++ адресной арифметикой практически не пользуются, а проблема с доступом к памяти, освобождённой из другого места, достаточно частая

Большая часть проблем решается счетчиками ссылок, но их горе-оптимизаторы порой не применяют, потому что «накладные расходы». А потом софтина почему-то падает. Но да, они не решают проблему до конца:
 — во-первых, потому что C++ сделан так забавно, что не позволяет реализовать достаточно zero-cost-овый shared_ptr — механизм intrusive container в целом плохо поддерживается;
 — во-вторых, один из величайших провалов Страуструпа — это совмещение деструкторов и высвобождения памяти, из-за чего взаимосвязанные объекты невозможно корректно уничтожить без костылей — второй уничтожаемый объект всегда оказывается владельцем некорректных указателей.

Если подумать, то обе проблемы являются минимально трансформированными Си, которые были усугублены переусложненностью C++. Например, в Си считается нормой держать указатель на некорректную область памяти — «ну я же не разыменовываю ево!». Вот и отхватывай UB по мере роста сложности, когда кода становится настолько много, что не удается запомнить, где там у меня был корректный указатель, а где — нет.

Родили целый Си++. Не помогло. Пришлось рождать С# со сборщиком мусора. В нём проблем с UB нет

Вообще-то у C++ нет никаких непреодолимых причин для того, чтобы не иметь сборщика мусора, кроме фактически полученного отсутствия единой архитектуры, полнейшего бардака и переусложенности в языке, из-за чего сборщик вообще не понятно, к чему и как лепить. А для сложносвязанных структур данных я, например, не знаю никаких методов организации контроля ссылок, кроме сбора мусора. Было бы интересно услышать про альтернативы. По факту в приложениях на C++ обычно применяются счетчики ссылок с ad-hoc детекторами циклов, что есть неуниверсальным, и, внезапно, не самым быстрым/эффективным способом реализации.

Большая часть проблем решается счетчиками ссылок, но их горе-оптимизаторы порой не применяют, потому что «накладные расходы». А потом софтина почему-то падает.

Потом в GNOME хватаются за голову: их гуйня жутко тормозит из-за каскадов деструкторов.

во-первых, потому что C++ сделан так забавно, что не позволяет реализовать достаточно zero-cost-овый shared_ptr — механизм intrusive container в целом плохо поддерживается;

Мужики и не знали.

во-вторых, один из величайших провалов Страуструпа — это совмещение деструкторов и высвобождения памяти

Бред. Деструкторы и высвобождение памяти связаны примерно никак. Деструктор объекта освобождает ресурс, которым тот владеет. Конкретно умные указатели из стандартной библиотеки С++ владеют памятью И объектом, поэтому удаляют и то, и другое. Никакой помехи разъединить это нет, например так делают в гугле.

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

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

полнейшего бардака и переусложенности в языке

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

Клиника.

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

Отвечаю на вопрос автора темы. Программист на Pascal-е получает 0 рублей, тугриков или пиастров, потому что ни на какой рвботе не нужен.

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

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

внезапно прямо сейчас приходится вспоминать (и слегка изучать) Pascal :-)

потребовалось написать инсталлятор нетленки в оффтопике, а там при всём богатстве выбора, единственно разумное это Inno Setup с Паскалем.

Потом в GNOME хватаются за голову: их гуйня жутко тормозит из-за каскадов деструкторов

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

во-первых, потому что C++ сделан так забавно, что не позволяет реализовать достаточно zero-cost-овый shared_ptr — механизм intrusive container в целом плохо поддерживается;

Мужики и не знали.

В STL строки до сих пор без счетчиков ссылок. Сколько уже крестовых библиотек заново реализовали строки только по этой причине?

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

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

Никакой помехи разъединить это нет, например так делают в гугле

Да, челы изобрели garbage collector, теперь с квадратными колесами. Я подчеркиваю, что челы из гугла банально борятся со врожденными недостатками C++, которых просто не должно было стать еще на этапе проектирования ЯП. И я бы не сказал, что их решение получилось простым (8000 измененных файлов, бг-г-г):
https://chromium-review.googlesource.com/c/chromium/src/ /3305132

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

Я уничтожил объект, он уничтожил все объекты, на которые ссылался — в чем тут проблема? Проблема в том, что ты мыслишь в той же патологической парадигме «вызов деструктора наделяет область хранения неопределенным значением». А с фига-ли она обязана быть неопределенной? Потому что так делали в Си, так продолжили делать в C++ — так и живем.

В принципе, с приседаниями эта проблема решаема:
https://250bpm.com/blog:4/ — Why should I have written ZeroMQ in C, not C++ (part I)
Проблема в том, что если ты пойдешь по пути автора статьи, то очень скоро выяснишь, что почти не используешь C++, а именно — не используешь деструкторы-конструкторы, исключения, перегрузку операторов, и почти всю STL как следствие, а также минимизируешь применение шаблонов.

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

.R

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

🤦‍♂️

В STL строки до сих пор без счетчиков ссылок. Сколько уже крестовых библиотек заново реализовали строки только по этой причине?

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

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

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

Да, челы изобрели garbage collector, теперь с квадратными колесами.

Это не garbage collector.

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

Нет. Челы из гугла озадачились проблемой UAF – и сделали для своего типа свое поведение. Твои рассказы про невозможность чего-то там оказались бредом.

(8000 измененных файлов, бг-г-г):

Rewrite most Foo* field_ pointer fields to raw_ptr<Foo> field_.

Сразу в лужу.

Я уничтожил объект, он уничтожил все объекты, на которые ссылался — в чем тут проблема?

Два объекта ссылаются друг на друга. Уничтожай.

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

Цитату, ссылку на сообщение.

В принципе, с приседаниями эта проблема решаема:

Такой же необучаемый пишет статьи. Код – просто пушка.

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

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

Здесь нужен иной «талант».
У меня его нет (и это к лучшему).

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

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

Я не знаю, что это за withLog, так что конкретно его прокомментировать не смогу

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

Еще раз аргумент из третьего абзаца моего прошлого сообщения: какой идентификатор с кем ассоциирован?

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

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

Нечитаемый код можно сделать на любом языке. На Си ещё проще, чем на Хаскеле.

что же делает это «>>=»? Этого не ясно из кода, я должен знать типы aaa, bbb

Нет. Для любых монадических aaa и bbb эта операция возьмёт результат aaa и передаст в bbb. Причём, неважно, эта монада будет IO или список или Maybe.

В Си++ намного хуже. «a >> b» может сделать арифметический сдвиг и вернуть результат, а может записать в файл на диск.

Это называется «отсутствие модульности».

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

f x = 1 + x * 2

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

Помнится, один фанат хаскеля назвал это «я слишком много думаю об архитектуре»

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

Вообще-то у C++ нет никаких непреодолимых причин для того, чтобы не иметь сборщика мусора

С++ со сборщиком мусора — это Java или C#. Всё хорошо, но скорость работы заметно ниже. Сборщик мусора не бесплатен.