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

С 90-х годов изменения в технология программирования ничтожны.

Я спросил у ботяры OpenAI: - Как дела у byko3y? А он мне

 byko3y как был узколобым, так и остался.

И классику предложил читать.

Как насчет наследования в системе типов?

Ну чисто технически, препроцессор полон по Тьюрингу, так что им можно реализовать все что угодно, в т.ч. и наследование типов. В каком-то смысле препроцессор открывает дверь в динамическую типизацию… Но код будет, конечно, адским.

Даже в кубейсике goto уже не приветствовалось, нам в школе сразу нормальные циклы и проч объясняли.

Как можно за goto «держаться», мне непонятно. Это откровенно неудобная хрень, которая ничего не упрощает.

Да, я считаю, что JavaScript и C++ были грамотно спроектированы для своего времени.

Не скажу за JS, но C++ спроектирован ужасно. Это, знаешь, была такая незатейливая избушка, без особых наворотов, но крепкая, тёплая и геометрически правильная. Потом решили к этой избушке пристроить баньку, с другой стороны курятник, поверх чердака второй этаж, не ломая совместимости с чердаком, у соседей подсмотрели идею гаража, но собрали его из палок и соломы, короче, лет через 30 получился муравейник размером с небоскрёб, в котором несколько архитекторов заблудились и пропали без вести, а ещё несколько в ужасе выбрались и приступили к строительству более продуманных избушек. Короче, вы прочитали краткое содержание книги «Дизайн и эволюция С++» Б. Страуструпа.

Ты пробовал использовать gtk?

Я вот пробовал, у меня даже цикл статей на Хабре есть по GObject. Суть в том, что GTK изначально (ну, по крайней мере, со времён GTK+2) проектировался с расчётом на то, что к нему будет очень просто писать биндинги. Никто бы не заморачивался с такой геморройной системой ООП просто так. В итоге биндинги к GTK есть примерно к каждому первому языку, от PHP до Haskell, в то время как к правильно спроектированному плюсовому Qt разве что биндинги к Питону вспоминаются из живых и развивающихся. Ну не считая их собственного QML. Так что GTK не просто так выжившие из ума хакеры делали.

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

Ну вот массово сейчас ГУЙ пишут на Электроне или декларативщине, потому что С или С++ программисты дорогие.

… получился муравейник размером с небоскрёб

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

Так что GTK не просто так выжившие из ума хакеры делали.

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

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

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

from collections.abc import Callable

def feeder(get_next_item: Callable[[], str]) -> None:
    # Body

def async_query(on_success: Callable[[int], None],
                on_error: Callable[[int, Exception], None]) -> None:
    # Body

async def on_update(value: str) -> None:
    # Body
callback: Callable[[str], Awaitable[None]] = on_update

у вот массово сейчас ГУЙ пишут на Электроне или декларативщине, потому что С или С++ программисты дорогие.

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

Не давно, но да, добавили, стало сильно удобнее и понятней. Но проблема скриптовых языков в том, что это, по-сути, обработка строк, что приводит к тому, что можно реализовать любые конструкции с километрами плохо отлаженного неявного исполнения. Мне вот, например, синтаксис Pandas кажется ОЧЕНЬ неестественным для написания алгоритмов, т.е. для программирования.

Ну попробуй написать какую-нибудь фигню с кнопками, скажем крестики нолики 3х3, на gtk, а потом на qt, и сравни потраченные усилия. Или попроси начинающего программиста это сделать и посмотри что получится.

Сильно мимо. Разница в трудозатратах +- 10%. Я понимаю ещё, если бы надо было бы наследоваться от базовых виджетов, там да, на Си куча бойлерплейт-кода. Но кнопки-то лепить вообще практически одинаково.

Но проблема скриптовых языков в том, что это, по-сути, обработка строк

Но мы же говорим про Python а не Tcl, что там за обработка строк такая?

Мне вот, например, синтаксис Pandas кажется ОЧЕНЬ неестественным для написания алгоритмов, т.е. для программирования.

Хорошее замечание, можно узнать какая у Pascal есть альтернатива Pandas?

Сильно мимо. Разница в трудозатратах +- 10%. Я понимаю ещё, если бы надо было бы наследоваться от базовых виджетов, там да, на Си куча бойлерплейт-кода. Но кнопки-то лепить вообще практически одинаково.

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

Так то понятно, что с опытом и квалификацией эта разница становится несущественной.

Ты хочешь мне сказать, что Python, JavaScript, C++ были грамотно спроектированными языками для своего времени?

У оригинального паскаля по сути нету строк, смешно же.

Но мы же говорим про Python а не Tcl, что там за обработка строк такая?

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

Хорошее замечание, можно узнать какая у Pascal есть альтернатива Pandas?

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

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

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

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

Ну Qt вполне привычен для знающих С-подобные ООП языки, а GTK всё-таки экзотика.

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

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

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

Не читал, ну это не важно паскаль или не паскаль, pandas существует для питона, а для C или Pascal его нету, поэтому они не могут иметь преимущества из за какой либо ужасности пандаса?

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

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

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

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

Да да, именно. Главное, это понимать, когда учишь.

Некоторые почему-то свято уверены, что все люди одинаковые — одинаково мыслят, одинаково думают, одинаково поступают.

Бесят такие.

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

Вы точно оригинальный паскаль с C не путаете?

Конечно, проблема описана в «Why Pascal is Not My Favorite Programming Language». В С строки всегда были.

В C/C++ вместо строк массивы. Плюс какая разница какими языки были в 1970-х и начале 1980-х, если с тех пор они уже давно не такие?

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

Сколько там сейчас в школах учителя информатики зарабатывают? Вот и ответ)

я пробовал объяснять циклы на питоне. ну, врагу конечно пожелаю, но сам не хотел бы. ты ведь понимаешь что надо объяснить человеку что такое range и почему он этот ренж использует.. там где на паскале просто цикл, тут надо объяснять целую дополнительную дребедень и дети всё время забывают эти детали. это не учитывая что нужно сначала понятие переменной усвоить , что (по моему) гораздо проще делать если переменная типизирована (т.е. можно класть числа, можно строки и всё, а не как в питоне.. на практике очень удобно бывает, но объяснять это новичку.. ну его нафиг, лучше паскаль). что до си, то ++i/i++ и запятые в синтаксисе цикла тоже смущают. а в паскале довольно просто.

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

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

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

Дышать воздухом тоже попса?

Нененене, девидблейн. ЯП не являются необходимостью как воздух. И не являются организмами, эта аналогия не работает. Это искуственно созданные инструменты. Молоток не должен изменяться в руке. Если молоток изменяется в руке — это обычно «внезапно сломанный» молоток.

А на распространенность технологий чаще влияет наличие «сильного игрока» на рыночке, который в них денюжки закачивает. За сишкой стоял телекоммуникационный монополист :) за адой — министерство обороны США. За коболом и алголом межделмаш. За джавой сначала санки, теперь оракл. За паскалем был борланд. Борланд заигрался в биржевое казино и слился — паскаль стагнировал. Шарп появился потому что майкрософт не смог наложить лапы на джаву и расширить ее своими фичами, а вот из борланда чувака который создал дельфи сманить получилось. За обероном сильного игрока нет — нет вливаний бабла, пеара из всех утюгов, нет популярности «минималистичного языка». Т.к. некому нанять кодерков написать стандартную библиотеку подпорок под велосипеды потребителей.

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

Ничего подобного. Функция-то не меняется. Просто срок службы клеток конечен, т.к. организм открытая система и на вход поступают не только полезняшки. Это даже не патчи :) это тоже функция которая уже есть. Внезапный «апдейт» функции ноги — это перелом. Внезапный «апдейт ДНК» — это сбой синтеза белка, большинство мутаций вообще не полезны. В природе апдейты индивидуальных организмов в зачот не идут. Только популяционные закрепления в потомстве. Т.е. апдейты функций не происходят пока нет давления среды — через естественный отбор. Сроки там геологического масштаба времени. Современные люди например существуют слишком недолго чтоб эти изменения стали заметны.

там где на паскале просто цикл, тут надо объяснять целую дополнительную дребедень

Зато там, где на Си

for(i=0,j=100; i<=9; i++,j++) {
...

а на нормальных языках

loop
  for i from 0 to 9
  for j from 100
  do
  ...

На Паскале приходится объяснять

j := 100;
for i := 0 to 9 do
  j := j + 1;
  ...

Кстати, нашёл тут пару локальных вакансий на Делфи (RAD studio). Не особенно денежных, но тем не менее.

RAD (Builder C++) как-то ставил себе напосмотреть, но любви после Borland Builder C++ 6.0 между нами не произошло.

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

ЗЫ.

j := j + 1;

inc(j);

Единственное, что мне нравилось в винде - это RAD'ы. Delphi, C++ Builder и Visual Basic. Visual C++ не осилил, а те осилил.

Из этого списка то, что ты назвал «нормальными языками» - самое неочевидное. По понятности Си и Паскаль намного лучше (одинаковые), по лаконичности лучше Си.

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

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

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

Что, хуже оригинального Turbo Pascal 7.x?

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

Паскаль это как игра в куличики в песочнице. Лишней не будет, но при обучении на инженера-строителя вполне можно пропустить этот этап.

Весьма сомнительно. Почему вы считаете, что можно пропустить? Откуда такие выводы?

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

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

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

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

Учи лучше Модулу-2, на ней софт для спутников пишут

От паскаля отличается довольно мало. Вообще, я пытался её изучать, но остановило то, что нормального компилятора для неё вообще нет. Его только обещают добавить в gcc-13, но это ещё когда будет. А fpc ставь и пользуйся.

Ещё мне не понравилось, что ключевые слова только капсом.

Алсо потом можешь посмотреть в сторону Ada, но там уже надо отраслевые стандарты знать и уметь

А это уже устаревшая фигня которая только для легаси, сейчас вместо неё применяют что-то вроде Coq.

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

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

Так всё современное программное проектирование — это выбор между костылями (которыми прикручиваем к готовому решению) и велосипедами (которыми заменяем готовое решение). Причём строгого критерия выбора костыля или велосипеда нет

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

А если к структуре данных нужен доступ из нескольких потоков, то давайте ничего не использовать

Блокировка диапазона на массив нормально прикручивается

К библиотечному quicksort/mergesort?

Да, я считаю, что JavaScript и C++ были грамотно спроектированы для своего времени. Они позволили быстро решать задачи, которые было необходимо решать тогда.

Про JavaScript: нет. Об этом многократно говорил даже сам создатель языка. Его взяли на работу, чтобы вкрячить в браузер Scheme. Но т.к. Netscape загибалась, и нужны были деньги, они вошли в какое-то партнерство с Sun, а Sun, если кто помнит, тогда настолько агрессивно продвигала Java, что наверное на этом и надорвалась, но не суть.

В общем, для того, чтобы Sun поддержала на плаву Netscape, надо было сделать какой-то реверанс в их сторону, и вместо вкрячивания Scheme ему пришлось делать новый язык, который не Java (поскольку жаба всегда была монструозной, я помню эти апплеты, которые заставляли комп повиснуть на несколько минут при каждой загрузке, и этой монструозности точно было не место в браузере), но имеет что-то общее с Java (хотя, что он имеет общего, кроме названия, я не помнимаю).

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

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

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

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

Ну так а что вообще принципиально нового тогда со времён фон Неймана было создано? Так, новые абстракции городили поверх машинных кодов и устройства ввода-вывода полировали

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

У оригинального паскаля по сути нету строк, смешно же

Лолшто? Указателей на массив символов нету? Даже в оригинальном паскале было new/release.

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

К библиотечному quicksort/mergesort?

lock(begin, n, sizeof(int));
qsort(begin, n, sizeof(int), compare);
unlock(begin, n, sizeof(int));

Если сортируешь диапазон, в процессе сортировки всё равно вмешиваться нельзя.

Нет. i и j обе переменные цикла.

Можно ещё так:

for(i=0,j=100; i<=9 && f(j); i++,j++) {
...

loop
  for i from 0 to 9
  for j from 100
  while (f j)
  do

На Паскале эквивалент сходу не напишу.

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

Visual C++ не зашёл тоже.

В Builder есть сильная вещь - библиотека компонентов VCL.