Информация об изменениях

Сообщение Re[8]: Почему программисты прошлого были умнее от 27.06.2025 13:00

Изменено 27.06.2025 13:10 vdimas

Re[8]: Почему программисты прошлого были умнее
Здравствуйте, Sinclair, Вы писали:

V>>Никто не говорил о том, что сейчас в IT стало меньше грамотных людей.

S>Если под "никто" понимается ТС, то он именно что это и говорил.

Меньшая их доля и это медицинский факт.
Т.е. в любом коллективе их сейчас меньше, чем раньше, хотя самих айтишных коллективов в разы больше.


S>Более того — если брать средний уровень программирования среди "всего населения", то он ещё и поднялся.


Да. В Индии, Китае и РФ необычно высокий интерес к IT.
В США и Европе меньше, хотя там больше айтишников, но это за счёт чудовищного наплыва приезжих айтишников, а вот местное население не ринулось в так резко IT.

И причины этому банальные — в перечисленных бедных странах IT даёт заметный доход индивидууму.
А если водитель-дальнобойщик в Германии зарабатывает примерно как middle-программер (а это 4-6 лет учёбы + 3-5 лет работы), то IT не выглядит настолько уж привлекательным.

И да, у программера ЗП, допустим 5-8 тыс евро, зато у языкатого продажника в той же конторе ЗП 20-30 тыс евро в месяц аж бегом!
Вот и учатся они на менеджмент и продажников.

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


V>>Разговоры про "планку входа" у нас шли вовсю шли уже в первой половине нулевых.

S>Разговоры про планку входа идут столько, сколько лет самому программированию.

Их не было еще до середины нулевых.
Их даже не было еще в 1996-1997 гг.
А уже в 1998-м массово пошли курсы PHP для домохозяек и прочее....
До краха доткомов оставалось 3 года...


V>>Я не могу себе представить эти разговоры в твоём 93-м, потому что за пределами требуемой на тот момент "планки входа" этих людей просто не было в профессии — они получали "корочку", но занимались другой деятельностью.

S>Я эту фразу не понимаю. Что за планка, кого именно не было в профессии?

Которая "планка входа".
Выпускник по IT-специальности принципиально не мог так рассуждать, ему вообще было пофик на чём программировать, бо в процессе обучения он программировал на многих ЯП разной философии.
А "языки сценариев" вообще за языки не считались в той среде. ))


S>В наших краях, к примеру, "корочек" по программированию не было примерно ни у кого.


Что странно для Новосиба, потому что со второй половины 70-х и в 80-е была разработана очень мощная программа по IT в СССР, существенно доработаны 19-е и 34-е ГОСТ-ы.
И оно всё родилось не на ровном месте, конечно, а как обобщение передового тогдашнего опыта.
Ведь в СССР было свободное курсирование знаний и наработок, в отличие от кап.мира. ))

Такого системного и всеобъемлющего, но при этом массового образования в IT, как было в СССР в 80-е и начала 90-х, не было нигде на тот момент.
"Весь мир"tm подтянулся вот только к середине 90-х и позже, и позже, и позже.
А у нас, наоборот, это были года развала...

Наши распечатки часов, курсовые+дипомы обычного специалитета СССР легко и со свистом получали "M.A. in Computer Science", сравнимое с ведущими их жутко дорогими в обучении ВУЗ-ами США.


S>В профессии были кто угодно, кроме программистов — математики, физики, химики, экономисты, связисты.


Это какая-то ваша специфика в Новосибе или ты банально не в курсе, ХЗ.

А у нас тут сразу два радиозавода + военка, т.е. радиоаппаратура, радиомодули и ПО для спутников, "умные" противокорабельные ракеты (умеющие действовать "волчей стаей") и прочее — айтишников было как грязи.

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

Ну еще совсем-совсем малый процент занимались формальными грамматиками и прочим таким, бо DSL были "всегда", намного больше, чем сейчас, бо сейчас (a) средний уровень вшивого программера не позволяет разрабатывать свои DSL, и (b) средняя высокая ЗП программеров не позволяет бизнесу выделять на это ресурсы. Тут уже банальному devops-у уже стали платить как боевым программерам, какие в опу DSL? ))

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

И да, ну разумеется, все эти все PHP, Bash, Perl и прочие Питоны с JS рассматривались примерно как XML и прочие языки конфигурирования.
Это ж не "спесь плюсовиков", как тут часто пытаются подменить понятия.
Плюсы тут вообще не при чём, бо использовались различные инструменты, чаще голый Си, асм и тот же Паскаль или Фортран для рассчётов, именно у нас еще был популярен Forth, хотя, был непопулярен в западном IT...

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

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

Тогда уж проще в С++ запретить некие унаследованные от голого Си вещи и обогатить новыми safe-конструкциями, типа pure, unique и valid, с доп. гарантиями.

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

Поэтому, ТС всё верно говорит.
Да и не он один — это уже давным давно не разовые замеченные флуктуации, а натурально система.

От этой беды нас спасёт только AI, конечно. ))


S>В основном — потому, что "профильного образования" как такового не существовало до нулевых.


Мда...
Иногда лучше жевать, чем говорить.


V>>Ты ж учился не на IT, откуда у тебя статистика по однокурсникам, учившимся на IT?

S>У меня статистика по однокурсникам, учившимся на ФФ. Из них многие стали программистами.

Потому что наука тогда погибла.
Я ж тоже оставался в ВУЗ-е в аспирантуре по направлению цифровой обработки сигналов, но понял, что помру с голоду. ))


V>>Ну и прокачать некоторые навыки, например, внимательность и объективность.

S>

Объективность — страшное оружие. ))
Помогает принимать правильные решения на любом уровне разработки.


S>>>У меня инсайд из НИИ Автоматизированных Систем — типичное учреждение промышленного программирования.

S>>>Уверяю вас: никакого "любопытства", никаких "исследователей". Совершенно простые смертные. Тётеньки, которые писали унылые программы на фортране.
V>>И они получают свои 5-10 тыс $$ в месяц, поэтому сидят там? ))
S>Какие 5-10 тыс $$ в 1980х? Очнитесь. 135р в месяц — вот их зарплата. 200 — у ведущих специалистов.

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


V>>А тут нагло ходят на собеседования.

S>Это показывает не уровень образования, а тупо желание попасть на работу.

Одного желания мало. ))
Это еще уверенность, что хоть где-то, но возьмут.

Просто ходят такие уникумы, которые ну никак не могли бы исполнять даже работу тех унылых тёток из 80-х, потому что тётки нифига не унылые.
Я с парочкой таких тоже был оч неплохо знаком, одна даже на асме писала аки электровеник.
Редкий тип женщин... Огонь просто!
Жаль, что они обычно не очень красивые... Блин, даже не знаю, ставить ли тут смайлик и какой... Се ля ви, однако.


V>>Я не могу представить себе подобное в других областях, где требуются определённые непростые навыки.

V>>Например, придти устраиваться танцором в балет, но растяжки нет, классика хромает, прыгучесть нулевая...
S>Как только в балете начнут платить по 5-10 $$$ в месяц, туда будут идти примерно все.

Именно!
Об этом и шла речь.


V>>Решат, что чел просто прикалывается. ))

S>Ну, так и вы решайте. Делов-то. Но вообще, это означает, что ваш HR просто отлынивал от первичной фильтрации.

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


S>К нам и в 2002, и в 2005, и в 2010, и в 2015, и в 2020 приходили очень и очень вменяемые люди.


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


V>>А сейчас аналогичные ребята уверены, что хоть где-то их возьмут, бо дефицит и всё в этом роде.

S>Ну, раз они уверены, то никакой проблемы нет.

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


S>Охтыж боже мой. Ну да, на С++ по-другому никак, т.к. паттерн матчинг не завезли.

S>А в нормальных языках с современной системой типов мы имеем
S>
S>a = dictionary.FindKey("foo"); // Maybe<int>

S>avalue = a ?? 0; 
S>/* sugar for: 
S>avalue = switch(a)
S>{
S>   Some(d): d;
S>   None(): 0;
S>} */
S>


Такая же точно диспетчеризация.
Собсно, в ФП это видно явно и не скрывается, а выросшие из процедурного подхода программеры, смотрю, считают ПМ за какую-то магию. ))

Это ровно то же, что было показано мною в dispatch() на плюсах и в специализациях ф-ии для Хаскель, происходящее идентично.

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


S>Никакого IoC тут нет, как нет и никаких функций для вызова.


Ну вот в Хаскель и плюсах IoC, и ты показал ровно то же самое, во что превратится аналогичный код на плюсах из моего примера:
auto result = a.dispatch([]{ return s.value(); }, []{return 0;});

Та даже согласно стандартов языка С++, код методов в декларации классов рассматривается как инлайный, т.е. получим такой же точно код еще до всякой оптимизации.

(Оптимизация, к примеру, может исключить лишнюю проверку на hasValue(), если эта проверка уже была произведена где-то выше по контексту или компилятор "видит" жизненный цикл значения, в этом случае ненужные ветки под if просто исчезнут)


V>>В Хаскеле возможен только IoC вариант, т.е. рантайм-диспетчеризация как в последней строчке:

V>>
V>>data Optional t = Default | Specific t;

V>>func :: Optional SomeType -> Void
V>>func (Specific ptr) = someFunc ptr
V>>func Default        = reportEmpty
V>>


V>>Да, до некоторого предела вложенности компилятор при оптимизации производит распространение констант, поэтому часто рантайм-диспетчеризация заменяется на прямо вызов, но в современных С++ эта оптимизация куда глубже/качественней, так шта мой С++ вариант будет соптимизирован лучше.

S>

Ты в 2024-м ты пару раз демонстрировал, что изучал бинарный код, который порождают современные компиляторы С++ после оптимизации (когда про UB обсуждали).
Ну ты хоть убедился, наконец, что Хаскель в этом деле отстаёт примерно на 25-30 лет?
И только теперь смайлик!

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


V>>На IT-специальностях так не было, разумеется.

S>Как по мне, так это вообще на всех специальностях. Значительная доля народу идёт в ВУЗ чтобы пересидеть армию или выйти замуж. Ещё сколько-то — потому что "мама заставила" или "подруга посоветовала".
S>Из нашей не-IT специальности программистов вышло больше, чем физиков.

Кушать хотелось.
И это трагедия того времени, несомненно.


V>>Та не мог твой ВУЗ быть совсем отсталым, даже в пик развала в 93-м.

V>>Просто у тебя выборка по непрофильной специальности.
S>Распределение IQ примерно одинаковое, от специальности не зависит. Распределение уровня мотивации примерно одинаковое, от специальности не зависит.
S>Распределение произведения этих двух параметров даёт неплохую оценку результирующей эффективности.

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

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

Давай называть вещи своими именами — на такие специальности шли люди с IQ выше среднего.
А сейчас на IT прут с произвольным IQ.


V>>В Lisp и Algol абсолютно идентичные nil, никакого NULL в Algol нет, RTFM!

S>Продолжаете жечь?
S>https://www.algol60.org/docsW/algolw.pdf, раздел 4.5 References.
S>В Lisp nil — это не "невалидная ссылка", а пустой список.

Это просто нулевой указатель.
И разные диалекты Лиспа по разному его отображают — некоторые как [], есть такое.


S>(sigh).


Отож...
Ты ж не баловался Лиспом достаточно, а нам пришлось одно время, потому что по программе, и потому что некоторые вещи на ём делались проще, чем на голых сях.



V>>Защита от nil всегда через проверки, что в Lisp, что в Algol, безальтернативно.

S>(sigh).

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

Я спрягал когда-то и Лисп с нейтивом и даже Пролог.
И замечательно всё может вылететь на твоём "пустом списке", потому что это тупо null. ))


V>>Как думаешь, какой чертой пользовался сам Хоар приличную часть своей карьеры еще до всяких Windows? ))

S>Думаю, что прямой. Вряд ли Хоар много работал в DOS.

Я ж написал — это наследние CP/M.
Unix тогда не было еще.
В Маке использовали ':' в качестве разделителя, в больших машинах часто использовали точку в качестве разделителя (расширений у фуйлов не было, угу, это более позднее изобретение).
SymbianOS (она же EPOC в 80-е) использовала тоже обратную косую черту, потому что файлы именовались с расширениями.

Но старику захотелось поругать конкретно Windows, которая была не при чём.
А ты и повёлся, чем показал низкую эрудицию.
К тому же, в Winbdows тоже используется прямая черта в пути к файлу в некоторых случаях — RTFM доку по cmd.exe ))


V>>Сам термин IoC из объектно-ориентированной среды, я его использовал сугубо удобства ради.

S>Скорее, ради красного словца.

Чтобы было понятно, о чём речь — необходимо подавать два независимых куска кода в некий алгоритм, где этот алгоритм выбирает и вызывает один из кусов кода.
Именно поэтому твой пример с ПМ или мой с Хаскель или плюсами идентичные.


V>>Я тебе заранее на это уже отвечал — смотри как это обыгрывается в функциональных языках или в том же Kotlin, т.е. в языках, где присутствуют исключения.

S>И опять смешение мух и котлет. Исключения и ФЯ ортогональны друг другу.

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


S>В ФЯ описанная проблема решается при помощи системы типов, точка.


Решается при помощи ПМ, где ты должен покрыть все ветки.
Даже когда ПМ не расписан явно, вот тут происходит "автоматический ПМ" в рантайм:
data Optional t = Default | Specific t;

func :: Optional SomeType -> Void
func (Specific ptr) = someFunc ptr
func Default        = reportEmpty

Кароч, сплошная динамика и тормоза...

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


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

S>Да что тут прикидывать? Всё известно от зари времён. В том-то и дело, что Хоар это понял, хоть и задним числом. А вы не понимаете по-прежнему.

Ничего он не понял, он просто забыл из-за возраста.
А понимал он раньше и принимал правильные решения.

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

А вот на Алголе и его наследниках, типа Паскаля и прочих, было написано овердофига тогдашнего промышленного ПО вплоть до эпохи начала активного распространения среди системщиков языка Си. И сам язык Си (включая всех его наследников, т.е. Джаву, JS, C# и прочих) был рождён именно под влиянием алголоподобных языков, взяв у них минимально-необходимое, доказавшее свою полезность. В сях всего-то заменили begin/end на более короткие {}, заменили присваивание := на более короткое =, отказались от встроенных в язык set-ов и прочих высокоуровневых вещей, переложив это всё на библиотечный уровень. Ну и битовые поля, конечно!

Увы и ах, в первых Си по-прежнему надо было сначала давать список аргументов ф-ий, а потом перечислять их типы.
И сначала надо было описывать переменные в начале ф-ии, а потом их использовать, как в Алголе или Фортране.
Ну зато С++ отшлифовал и это, совместив объявление с присваиванием — но это уже наработка из ФП. ))


V>>Далее.

V>>Если в языке есть возможность описывать пользовательские типы, выбрасывать и перехватывать исключения, переопределять операторы и вводить алиасы типов (как typedef в С/С++), то проблема упрощается.
S>Ну, это просто длинный способ сделать "примерно то же самое", хоть и не совсем.

Наоборот, это короткий способ — однократная библиотечная реальзация.
А вот допиливать до бесконечности язык под каждый прикладной кейз — такое себе. ))

В этом смысле С++ дал инструмент для построения DSL прямо в языке.
(Кстате, это одна из причин, почему сейас DSL стали более редки, но это лишь небольшая часть всех причин, основные я указал выше)


S>В языках с нормальной системой типов приведение Null к NotNull является ошибкой времени компиляции, а не рантайм-исключением.


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

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


V>>А теперь давай про интероперабельность nullable и non-nullable типов.

V>>Вот проверь статически Optional<T*> без IoC или исключений. ))
S>Охтыж боже мой. Ну да, на С++ по-другому никак, т.к. паттерн матчинг не завезли.

ПМ — это и есть IoC
Re[8]: Почему программисты прошлого были умнее
Здравствуйте, Sinclair, Вы писали:

V>>Никто не говорил о том, что сейчас в IT стало меньше грамотных людей.

S>Если под "никто" понимается ТС, то он именно что это и говорил.

Меньшая их доля и это медицинский факт.
Т.е. в любом коллективе их сейчас меньше, чем раньше, хотя самих айтишных коллективов в разы больше.


S>Более того — если брать средний уровень программирования среди "всего населения", то он ещё и поднялся.


Да. В Индии, Китае и РФ необычно высокий интерес к IT.
В США и Европе меньше, хотя там больше айтишников, но это за счёт чудовищного наплыва приезжих айтишников, а вот местное население не ринулось в так резко IT.

И причины этому банальные — в перечисленных бедных странах IT даёт заметный доход индивидууму.
А если водитель-дальнобойщик в Германии зарабатывает примерно как middle-программер (а это 4-6 лет учёбы + 3-5 лет работы), то IT не выглядит настолько уж привлекательным.

И да, у программера ЗП, допустим 5-8 тыс евро, зато у языкатого продажника в той же конторе ЗП 20-30 тыс евро в месяц аж бегом!
Вот и учатся они на менеджмент и продажников.

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


V>>Разговоры про "планку входа" у нас шли вовсю шли уже в первой половине нулевых.

S>Разговоры про планку входа идут столько, сколько лет самому программированию.

Их не было еще до середины нулевых.
Их даже не было еще в 1996-1997 гг.
А уже в 1998-м массово пошли курсы PHP для домохозяек и прочее....
До краха доткомов оставалось 3 года...


V>>Я не могу себе представить эти разговоры в твоём 93-м, потому что за пределами требуемой на тот момент "планки входа" этих людей просто не было в профессии — они получали "корочку", но занимались другой деятельностью.

S>Я эту фразу не понимаю. Что за планка, кого именно не было в профессии?

Которая "планка входа".
Выпускник по IT-специальности принципиально не мог так рассуждать, ему вообще было пофик на чём программировать, бо в процессе обучения он программировал на многих ЯП разной философии.
А "языки сценариев" вообще за языки не считались в той среде. ))


S>В наших краях, к примеру, "корочек" по программированию не было примерно ни у кого.


Что странно для Новосиба, потому что со второй половины 70-х и в 80-е была разработана очень мощная программа по IT в СССР, существенно доработаны 19-е и 34-е ГОСТ-ы.
И оно всё родилось не на ровном месте, конечно, а как обобщение передового тогдашнего опыта.
Ведь в СССР было свободное курсирование знаний и наработок, в отличие от кап.мира. ))

Такого системного и всеобъемлющего, но при этом массового образования в IT, как было в СССР в 80-е и начала 90-х, не было нигде на тот момент.
"Весь мир"tm подтянулся вот только к середине 90-х и позже, и позже, и позже.
А у нас, наоборот, это были года развала...

Наши распечатки часов, курсовые+дипомы обычного специалитета СССР легко и со свистом получали "M.A. in Computer Science", сравнимое с ведущими их жутко дорогими в обучении ВУЗ-ами США.


S>В профессии были кто угодно, кроме программистов — математики, физики, химики, экономисты, связисты.


Это какая-то ваша специфика в Новосибе или ты банально не в курсе, ХЗ.

А у нас тут сразу два радиозавода + военка, т.е. радиоаппаратура, радиомодули и ПО для спутников, "умные" противокорабельные ракеты (умеющие действовать "волчей стаей") и прочее — айтишников было как грязи.

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

Ну еще совсем-совсем малый процент занимались формальными грамматиками и прочим таким, бо DSL были "всегда", намного больше, чем сейчас, бо сейчас (a) средний уровень вшивого программера не позволяет разрабатывать свои DSL, и (b) средняя высокая ЗП программеров не позволяет бизнесу выделять на это ресурсы. Тут уже банальному devops-у уже стали платить как боевым программерам, какие в опу DSL? ))

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

И да, ну разумеется, все эти все PHP, Bash, Perl и прочие Питоны с JS рассматривались примерно как XML и прочие языки конфигурирования.
Это ж не "спесь плюсовиков", как тут часто пытаются подменить понятия.
Плюсы тут вообще не при чём, бо использовались различные инструменты, чаще голый Си, асм и тот же Паскаль или Фортран для рассчётов, именно у нас еще был популярен Forth, хотя, был непопулярен в западном IT...

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

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

Тогда уж проще в С++ запретить некие унаследованные от голого Си вещи и обогатить новыми safe-конструкциями, типа pure, unique и valid, с доп. гарантиями.

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

Поэтому, ТС всё верно говорит.
Да и не он один — это уже давным давно не разовые замеченные флуктуации, а натурально система.

От этой беды нас спасёт только AI, конечно. ))


S>В основном — потому, что "профильного образования" как такового не существовало до нулевых.


Мда...
Иногда лучше жевать, чем говорить.


V>>Ты ж учился не на IT, откуда у тебя статистика по однокурсникам, учившимся на IT?

S>У меня статистика по однокурсникам, учившимся на ФФ. Из них многие стали программистами.

Потому что наука тогда погибла.
Я ж тоже оставался в ВУЗ-е в аспирантуре по направлению цифровой обработки сигналов, но понял, что помру с голоду. ))


V>>Ну и прокачать некоторые навыки, например, внимательность и объективность.

S>

Объективность — страшное оружие. ))
Помогает принимать правильные решения на любом уровне разработки.


S>>>У меня инсайд из НИИ Автоматизированных Систем — типичное учреждение промышленного программирования.

S>>>Уверяю вас: никакого "любопытства", никаких "исследователей". Совершенно простые смертные. Тётеньки, которые писали унылые программы на фортране.
V>>И они получают свои 5-10 тыс $$ в месяц, поэтому сидят там? ))
S>Какие 5-10 тыс $$ в 1980х? Очнитесь. 135р в месяц — вот их зарплата. 200 — у ведущих специалистов.

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


V>>А тут нагло ходят на собеседования.

S>Это показывает не уровень образования, а тупо желание попасть на работу.

Одного желания мало. ))
Это еще уверенность, что хоть где-то, но возьмут.

Просто ходят такие уникумы, которые ну никак не могли бы исполнять даже работу тех унылых тёток из 80-х, потому что тётки нифига не унылые.
Я с парочкой таких тоже был оч неплохо знаком, одна даже на асме писала аки электровеник.
Редкий тип женщин... Огонь просто!
Жаль, что они обычно не очень красивые... Блин, даже не знаю, ставить ли тут смайлик и какой... Се ля ви, однако.


V>>Я не могу представить себе подобное в других областях, где требуются определённые непростые навыки.

V>>Например, придти устраиваться танцором в балет, но растяжки нет, классика хромает, прыгучесть нулевая...
S>Как только в балете начнут платить по 5-10 $$$ в месяц, туда будут идти примерно все.

Именно!
Об этом и шла речь.


V>>Решат, что чел просто прикалывается. ))

S>Ну, так и вы решайте. Делов-то. Но вообще, это означает, что ваш HR просто отлынивал от первичной фильтрации.

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


S>К нам и в 2002, и в 2005, и в 2010, и в 2015, и в 2020 приходили очень и очень вменяемые люди.


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


V>>А сейчас аналогичные ребята уверены, что хоть где-то их возьмут, бо дефицит и всё в этом роде.

S>Ну, раз они уверены, то никакой проблемы нет.

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


S>Охтыж боже мой. Ну да, на С++ по-другому никак, т.к. паттерн матчинг не завезли.

S>А в нормальных языках с современной системой типов мы имеем
S>
S>a = dictionary.FindKey("foo"); // Maybe<int>

S>avalue = a ?? 0; 
S>/* sugar for: 
S>avalue = switch(a)
S>{
S>   Some(d): d;
S>   None(): 0;
S>} */
S>


Такая же точно диспетчеризация.
Собсно, в ФП это видно явно и не скрывается, а выросшие из процедурного подхода программеры, смотрю, считают ПМ за какую-то магию. ))

Это ровно то же, что было показано мною в dispatch() на плюсах и в специализациях ф-ии для Хаскель, происходящее идентично.

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


S>Никакого IoC тут нет, как нет и никаких функций для вызова.


Ну вот в Хаскель и плюсах IoC, и ты показал ровно то же самое, во что превратится аналогичный код на плюсах из моего примера:
auto result = a.dispatch([]{ return s.value(); }, []{return 0;});

Та даже согласно стандартов языка С++, код методов в декларации классов рассматривается как инлайный, т.е. получим такой же точно код еще до всякой оптимизации.

(Оптимизация, к примеру, может исключить лишнюю проверку на hasValue(), если эта проверка уже была произведена где-то выше по контексту или компилятор "видит" жизненный цикл значения, в этом случае ненужные ветки под if просто исчезнут)


V>>В Хаскеле возможен только IoC вариант, т.е. рантайм-диспетчеризация как в последней строчке:

V>>
V>>data Optional t = Default | Specific t;

V>>func :: Optional SomeType -> Void
V>>func (Specific ptr) = someFunc ptr
V>>func Default        = reportEmpty
V>>


V>>Да, до некоторого предела вложенности компилятор при оптимизации производит распространение констант, поэтому часто рантайм-диспетчеризация заменяется на прямо вызов, но в современных С++ эта оптимизация куда глубже/качественней, так шта мой С++ вариант будет соптимизирован лучше.

S>

Ты в 2024-м ты пару раз демонстрировал, что изучал бинарный код, который порождают современные компиляторы С++ после оптимизации (когда про UB обсуждали).
Ну ты хоть убедился, наконец, что Хаскель в этом деле отстаёт примерно на 25-30 лет?
И только теперь смайлик!

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


V>>На IT-специальностях так не было, разумеется.

S>Как по мне, так это вообще на всех специальностях. Значительная доля народу идёт в ВУЗ чтобы пересидеть армию или выйти замуж. Ещё сколько-то — потому что "мама заставила" или "подруга посоветовала".
S>Из нашей не-IT специальности программистов вышло больше, чем физиков.

Кушать хотелось.
И это трагедия того времени, несомненно.


V>>Та не мог твой ВУЗ быть совсем отсталым, даже в пик развала в 93-м.

V>>Просто у тебя выборка по непрофильной специальности.
S>Распределение IQ примерно одинаковое, от специальности не зависит. Распределение уровня мотивации примерно одинаковое, от специальности не зависит.
S>Распределение произведения этих двух параметров даёт неплохую оценку результирующей эффективности.

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

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

Давай называть вещи своими именами — на такие специальности шли люди с IQ выше среднего.
А сейчас на IT прут с произвольным IQ.


V>>В Lisp и Algol абсолютно идентичные nil, никакого NULL в Algol нет, RTFM!

S>Продолжаете жечь?
S>https://www.algol60.org/docsW/algolw.pdf, раздел 4.5 References.
S>В Lisp nil — это не "невалидная ссылка", а пустой список.

Это просто нулевой указатель.
И разные диалекты Лиспа по разному его отображают — некоторые как [], есть такое.


S>(sigh).


Отож...
Ты ж не баловался Лиспом достаточно, а нам пришлось одно время, потому что по программе, и потому что некоторые вещи на ём делались проще, чем на голых сях.



V>>Защита от nil всегда через проверки, что в Lisp, что в Algol, безальтернативно.

S>(sigh).

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

Я спрягал когда-то и Лисп с нейтивом и даже Пролог.
И замечательно всё может вылететь на твоём "пустом списке", потому что это тупо null. ))


V>>Как думаешь, какой чертой пользовался сам Хоар приличную часть своей карьеры еще до всяких Windows? ))

S>Думаю, что прямой. Вряд ли Хоар много работал в DOS.

Я ж написал — это наследние CP/M.
Unix тогда не было еще.
В Маке использовали ':' в качестве разделителя, в больших машинах часто использовали точку в качестве разделителя (расширений у фуйлов не было, угу, это более позднее изобретение).
SymbianOS (она же EPOC в 80-е) использовала тоже обратную косую черту, потому что файлы именовались с расширениями.

Но старику захотелось поругать конкретно Windows, которая была не при чём.
А ты и повёлся, чем показал низкую эрудицию.
К тому же, в Winbdows тоже используется прямая черта в пути к файлу в некоторых случаях — RTFM доку по cmd.exe ))


V>>Сам термин IoC из объектно-ориентированной среды, я его использовал сугубо удобства ради.

S>Скорее, ради красного словца.

Чтобы было понятно, о чём речь — необходимо подавать два независимых куска кода в некий алгоритм, где этот алгоритм выбирает и вызывает один из кусов кода.
Именно поэтому твой пример с ПМ или мой с Хаскель или плюсами идентичные.


V>>Я тебе заранее на это уже отвечал — смотри как это обыгрывается в функциональных языках или в том же Kotlin, т.е. в языках, где присутствуют исключения.

S>И опять смешение мух и котлет. Исключения и ФЯ ортогональны друг другу.

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


S>В ФЯ описанная проблема решается при помощи системы типов, точка.


Решается при помощи ПМ, где ты должен покрыть все ветки.
Даже когда ПМ не расписан явно, вот тут происходит "автоматический ПМ" в рантайм:
data Optional t = Default | Specific t;

func :: Optional SomeType -> Void
func (Specific ptr) = someFunc ptr
func Default        = reportEmpty

Кароч, сплошная динамика и тормоза...

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


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

S>Да что тут прикидывать? Всё известно от зари времён. В том-то и дело, что Хоар это понял, хоть и задним числом. А вы не понимаете по-прежнему.

Ничего он не понял, он просто забыл из-за возраста.
А понимал он раньше и принимал правильные решения.

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

А вот на Алголе и его наследниках, типа Паскаля и прочих, было написано овердофига тогдашнего промышленного ПО вплоть до эпохи начала активного распространения среди системщиков языка Си. И сам язык Си (включая всех его наследников, т.е. Джаву, JS, C# и прочих) был рождён именно под влиянием алголоподобных языков, взяв у них минимально-необходимое, доказавшее свою полезность. В сях всего-то заменили begin/end на более короткие {}, заменили присваивание := на более короткое =, отказались от встроенных в язык set-ов и прочих высокоуровневых вещей, переложив это всё на библиотечный уровень. Ну и битовые поля, конечно!

Увы и ах, в первых Си по-прежнему надо было сначала давать список аргументов ф-ий, а потом перечислять их типы.
И сначала надо было описывать переменные в начале ф-ии, а потом их использовать, как в Алголе или Фортране.
Ну зато С++ отшлифовал и это, совместив объявление с присваиванием — но это уже наработка из ФП. ))


V>>Далее.

V>>Если в языке есть возможность описывать пользовательские типы, выбрасывать и перехватывать исключения, переопределять операторы и вводить алиасы типов (как typedef в С/С++), то проблема упрощается.
S>Ну, это просто длинный способ сделать "примерно то же самое", хоть и не совсем.

Наоборот, это короткий способ — однократная библиотечная реальзация.
А вот допиливать до бесконечности язык под каждый прикладной кейз — такое себе. ))

В этом смысле С++ дал инструмент для построения DSL прямо в языке.
(Кстате, это одна из причин, почему сейас DSL стали более редки, но это лишь небольшая часть всех причин, основные я указал выше)


S>В языках с нормальной системой типов приведение Null к NotNull является ошибкой времени компиляции, а не рантайм-исключением.


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

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


V>>А теперь давай про интероперабельность nullable и non-nullable типов.

V>>Вот проверь статически Optional<T*> без IoC или исключений. ))
S>Охтыж боже мой. Ну да, на С++ по-другому никак, т.к. паттерн матчинг не завезли.

ПМ — это и есть IoC