Здравствуйте, Sinclair, Вы писали:
V>>Первые СУБД только появились в начале 80-х и были с нынешней колокольни убоги. S>Вижу, домашнюю работу вы так и не выполнили.
V>В этой статье я попытаюсь ответить на вопрос, почему программисты прошлого были умнее, а качество образования с каждым годом только падало.
V>
Поколения программистов
V>Для начала разделю программистов по поколениям на основе источников доступной информации, а так же способам программирования, они же парадигмы программирования.
V>
Здравствуйте, Sinclair, Вы писали:
V>>Например? S>Из самого известного — "ошибка на миллиард долларов" Тони Хоара. (К квалификации Тони вопросы есть?)
Квалификации — нет, а вот её оценке — есть.
Я считаю, что на момент принятия того самого решения — иметь null как вариант значения указателя — оно было правильно, потому что практически реализуемо. Альтернатива была просто неподъёмна с тогдашними средствами.
Главный вопрос — когда же это стало не просто подъёмно, но и необходимо. А вот это, я думаю, уже около 2000.
Пусть Хоар критикует себя тогдашнего сколько угодно, он прав в идеале, но неправ на практике. Конечно, лучше такая самокритичность, чем мания непогрешимости, но трезвый подход — ещё лучше.
V>>Концептуально нового? )) V>>Например? S>Ну, например, я не ожидал, что в 21 веке смогут придумать какой-то новый вид скалярных индексов для СУБД. Казалось бы — после B-trees, hash, и bitmap индексов в этой области уже ничего нового не придумать.
LSM tree забыл. Это уже ~2000, граница века.
S>Ан нет — апрель 2020, PGM-index.
Где алгоритмы обычных операций с индексами — добавление, удаление ключа? Как управлять эффективностью хранения? Или это индекс из тех, что строятся один раз для постоянного набора?
Как у него с конкурентностью? Для B-деревьев есть давно разработки с одновременным доступом из нескольких участников с адекватной синхронизацией, а тут?
S>Был ли возможен такой индекс в 1963? Да, конечно. Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек. S>Математика в основе лежит общеизвестная, сложность алгоритмов — не выше, чем у B-tree. Просто — не додумались.
Здравствуйте, netch80, Вы писали: N>Квалификации — нет, а вот её оценке — есть. N>Я считаю, что на момент принятия того самого решения — иметь null как вариант значения указателя — оно было правильно, потому что практически реализуемо. Альтернатива была просто неподъёмна с тогдашними средствами.
Интересная гипотеза. В LISP, к примеру, обошлись без null, и ничего, тогдашними средствами всё поднялось.
N>Главный вопрос — когда же это стало не просто подъёмно, но и необходимо. А вот это, я думаю, уже около 2000.
Как видим, языки без нулевых указателей были подъёмны в 1960. N>Пусть Хоар критикует себя тогдашнего сколько угодно, он прав в идеале, но неправ на практике.
Хороший ход. Ещё можно сказать, что он имел в виду совсем другое. N>Конечно, лучше такая самокритичность, чем мания непогрешимости, но трезвый подход — ещё лучше.
Я уверен, что у Тони вполне трезвый подход.
N>LSM tree забыл. Это уже ~2000, граница века.
Да, тоже верно.
N>Где алгоритмы обычных операций с индексами — добавление, удаление ключа? Как управлять эффективностью хранения? Или это индекс из тех, что строятся один раз для постоянного набора? N>Как у него с конкурентностью? Для B-деревьев есть давно разработки с одновременным доступом из нескольких участников с адекватной синхронизацией, а тут?
Настолько детально я не разбирался. С модификациями там всё не вполне очевидно. А вот с конкурентностью всё хорошо известно — все древовидные структуры обрабатываются одинаково. N>Или не был такой нужен. Эту гипотезу коллега vdimas уже высказывал. Контраргументы те же — вопросы компресии индексов интересовали разработчиков ещё в ранних 1980х. Это хорошо видно по публикациям статей.
Так что возможность уменьшить размер индекса в пару тысяч раз конечно же была востребована.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
N>>Квалификации — нет, а вот её оценке — есть. N>>Я считаю, что на момент принятия того самого решения — иметь null как вариант значения указателя — оно было правильно, потому что практически реализуемо. Альтернатива была просто неподъёмна с тогдашними средствами. S>Интересная гипотеза. В LISP, к примеру, обошлись без null, и ничего, тогдашними средствами всё поднялось.
В LISP не обошлись без null. В LISP он есть в виде NIL. Только не надо повторять ещё и ко мне ту чушь, что, мол, NIL это "пустой список", а не пустой указатель.
Нет, как раз пустой список реализован в LISP в виде пустого указателя, и тут он ничем не отличается от какой-нибудь C-подобной реализации где struct node с struct node *next, а NULL значит, что список пуст (длины 0).
Чтобы понять это глубже, посмотри, как в LISP работает хак (A.B) для неспискового B, где его используют и почему он нежелателен для общего применения.
N>>Главный вопрос — когда же это стало не просто подъёмно, но и необходимо. А вот это, я думаю, уже около 2000. S>Как видим, языки без нулевых указателей были подъёмны в 1960.
Как видим, твой пример не проходит. Но даже если бы это было так, то специфично функциональный язык надо рассматривать иначе, нежели процедурный.
N>>Пусть Хоар критикует себя тогдашнего сколько угодно, он прав в идеале, но неправ на практике. S>Хороший ход. Ещё можно сказать, что он имел в виду совсем другое.
Ну с тем, кто так скажет, и дискутируй. Мне-то зачм твои ветряные мельницы?
N>>Где алгоритмы обычных операций с индексами — добавление, удаление ключа? Как управлять эффективностью хранения? Или это индекс из тех, что строятся один раз для постоянного набора? N>>Как у него с конкурентностью? Для B-деревьев есть давно разработки с одновременным доступом из нескольких участников с адекватной синхронизацией, а тут? S>Настолько детально я не разбирался. С модификациями там всё не вполне очевидно. А вот с конкурентностью всё хорошо известно — все древовидные структуры обрабатываются одинаково.
Точно все?
N>>Или не был такой нужен. S> Эту гипотезу коллега vdimas уже высказывал. Контраргументы те же — вопросы компресии индексов интересовали разработчиков ещё в ранних 1980х. Это хорошо видно по публикациям статей. S>Так что возможность уменьшить размер индекса в пару тысяч раз конечно же была востребована.
Теоретическая. Практически же тут есть непреодолимая пропасть — даже две — между 1) реализуемым в теории, 2) реализуемым на практике для константных деревьев и 3) реализуемым на практике для активно изменяемых деревьев. И что "реализуемо на практике" зависит от 100500 факторов.
То же LSM tree тоже ничто не мешало изобрести, например, в 1972 (возьмём за базу публикацию B-деревьев), он в разы проще тех же B-деревьев, но мешали аж три вещи:
1) недостаток места (чтобы индекс занимал место в 2-4 раза больше — не могли себе позволить);
2) отсутствие потребности в алгоритме для потоковой записи крупными порциями вместо одного блока;
3) проблема с организацией фоновых сжатий индекса (сейчас решается, например, через фоновые нити — а тогда надо было делать машину состояний и мириться с замираниями на сбор крупных порций).
Возможно, его тогда и изобретали кучу раз. А потом думали "и зачем эта фигня?" и забывали.
А вот ближе к 2000 начали давить тормоза позиционирования HDD, добило — появление SSD с записями порциями типа 128KB. А дисковое место на индексы стало доступно.
Вот то же самое и с потребностями при разработке языков.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, netch80, Вы писали: N>>Квалификации — нет, а вот её оценке — есть. N>>Я считаю, что на момент принятия того самого решения — иметь null как вариант значения указателя — оно было правильно, потому что практически реализуемо. Альтернатива была просто неподъёмна с тогдашними средствами. S>Интересная гипотеза. В LISP, к примеру, обошлись без null, и ничего, тогдашними средствами всё поднялось.
А что имеется в виду под неподъемностью без null в ЯП того времени? Доп. анализ от компилятора?
Здравствуйте, Sharov, Вы писали:
S>А что имеется в виду под неподъемностью без null в ЯП того времени? Доп. анализ от компилятора?
Это не ко мне вопрос, а к netch80.
Хоар считает, что уже в ALGOL W можно было обойтись без константы NULL. Пришлось бы для каких-то случаев реализовывать паттерн null objeсt, но уже при системе типов ALGOL W это означало возможность описания non-nullable types, контролируемых компилятором.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ботаныч, Вы писали:
V>>Поколения программистов V>>Для начала разделю программистов по поколениям на основе источников доступной информации, а так же способам программирования, они же парадигмы программирования. V>>1. Поколение программистов математиков (1940-1960) Б> а вы это годы рождения имели в виду ?
Годы активного обучения и начала работы. Кто-то может стартовать раньше, кто-то позже. Это время вхождения в профессию. При этом если люди будут следовать текущим тенденциям, то получаем перечисленные поколения. А не следовать им тяжело, так как внешнее окружение определяет сознание. Но в итоге путь пройденный предыдущими поколениями оказывается не пройден текущими, что образует огромную дыру в образовании.
Здравствуйте, 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>
Такая же точно диспетчеризация.
Собсно, в ФП это видно явно и не скрывается, а выросшие из процедурного подхода программеры, смотрю, считают ПМ за какую-то магию. ))
Это ровно то же, что было показано мною в dispatch() на плюсах и в специализациях ф-ии для Хаскель, происходящее идентично.
Разве что в Хаскель невозможно нарисовать неполную диспетчеризацию, для этого язык и писали. ))
S>Никакого IoC тут нет, как нет и никаких функций для вызова.
Ну вот в Хаскель и плюсах IoC, и ты показал ровно то же самое, во что превратится аналогичный код на плюсах из моего примера:
auto result = a.dispatch([]{ return s.value(); }, []{return 0;});
Та даже согласно стандартов языка С++, код методов в декларации классов рассматривается как инлайный, т.е. получим такой же точно код еще до всякой оптимизации.
(Оптимизация, к примеру, может исключить лишнюю проверку на hasValue(), если эта проверка уже была произведена где-то выше по контексту или компилятор "видит" жизненный цикл значения, в этом случае ненужные ветки под if просто исчезнут)
V>>В Хаскеле возможен только IoC вариант, т.е. рантайм-диспетчеризация как в последней строчке: 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>Охтыж боже мой. Ну да, на С++ по-другому никак, т.к. паттерн матчинг не завезли.
Здравствуйте, Sinclair, Вы писали:
S>В наших краях, к примеру, "корочек" по программированию не было примерно ни у кого. В профессии были кто угодно, кроме программистов — математики, физики, химики, экономисты, связисты. S>В основном — потому, что "профильного образования" как такового не существовало до нулевых.
В Ставропольском государственном университете, в котором учился я на Прикладной математике и получил корочку "математик, системный программист", подготовка велась задолго до нулевых:
Новое отделение возникло по инициативе Ученого Совета факультета в связи с введением в средние и высшие учебные заведения новой дисциплины «Информатика и вычислительная техника», что было предусмотрено реформой среднего и высшего образования 1984 г. Ректорат поддержал инициативу факультета. Лабораторию вычислительной техники (ауд.225) оснастили шестью персональными компьютерами отечественного производства ДВК-1 и ДВК-2 (диалоговые вычислительные комплексы). К лету 1986 г. отучился свои два семестра первый набор нового отделения, а после вступительных экзаменов к ним добавилось еще 100 человек. Была поставлена непростая задача информатизации учебного процесса. Все это послужило толчком для открытия специализированной кафедры.
В сентябре 1986 г. приказом ректора института проф. Смирнова Б.В. была образована новая кафедра, которую назвали кафедрой информатики и вычислительной техники. В состав кафедры вошло всего пять преподавателей: к.ф.-м. н., доц. Макоха А.Н., к.ф.-м. н., доц. Хлопонин С.С., к.т.н., с.н.с. Заплешко Н.Н., ст. преп. Брановский Ю.С. и ст. преп. Корнеев П.К. Заведующим кафедрой был назначен доц. Макоха А.Н., который заведовал ею до 1998 г.
То есть с 1984 года профильное образование уже существовало в нашей глубинке. И это был не самый передовой вуз, между нами говоря, не чета московским, ленинградским, новосибирским, томским и т.д. Если что, упомянутый в цитате Макоха А.Н., был моим преподавателем и дипломным руководителем, историю кафедры и специальности знаю из первых рук.
Здравствуйте, SkyDance, Вы писали:
SD>Падение среднего уровня подготовки программиста это не проблема, а результат многолетних трудов по снижению барьера входа. Чтобы профессия могла быть массовой, работники — дешевыми, количество сделанной работы — большим. А если бы программирование было столь же сложным, как 50 лет назад, фигу бы мы имели, а не work from home.
Ну почему. Разработка ядра СУБД — это как раз та сложная работа, где люди были на удалёнке более 15 лет назад.
Здравствуйте, netch80, Вы писали:
N>В LISP не обошлись без null. В LISP он есть в виде NIL. Только не надо повторять ещё и ко мне ту чушь, что, мол, NIL это "пустой список", а не пустой указатель.
LISP к ''ошибке Тони''(если под правильным решением мы понимаем Maybe) отношения не имеет, просто потому, что это динамика. vdimas его(lisp) совершенно не к месту как всегда привел, а Sinclair не к тому привязался.
Во времена Algol W безусловно не было правильного понимание nullable types (оно возникло имхо во времена ML), то есть подобную "ошибку" Тони просто не мог не совершить.
Хороший вопрос. Но саму статью увы не читал так как уверен, что знаю что там написанно
Если это вопрос, то ответ будет тут зависить от наличия смысла, от наличия необходимости ответа для тебя.
Если глубогоко смысла нет, то ответ прост — "Ну люди в среднем примерно одинаковы" и это ощибочное ощущение.
Если ты проблему видишь, и действительно считаешь что кругом какие-то не очень умные, то ответ — "Похоже ты просто слишком долго живешь", ну типа стал слишком умным, и все одногодки твои просто померли.
Да так бывает — да они дебилы, но возможно некоторые из них успеют стать умными.
Здравствуйте, Sinclair, Вы писали:
S>Хоар считает, что уже в ALGOL W можно было обойтись без константы NULL. Пришлось бы для каких-то случаев реализовывать паттерн null objeсt, но уже при системе типов ALGOL W это означало возможность описания non-nullable types, контролируемых компилятором.
Есть цитата? Для меня сомнительно. Первые реализации nullable types вроде появились в ML, то есть лет через 10 после W.
Здравствуйте, imh0, Вы писали:
I>Хороший вопрос. Но саму статью увы не читал так как уверен, что знаю что там написанно I>Если ты проблему видишь, и действительно считаешь что кругом какие-то не очень умные, то ответ — "Похоже ты просто слишком долго живешь", ну типа стал слишком умным, и все одногодки твои просто померли. I>Да так бывает — да они дебилы, но возможно некоторые из них успеют стать умными.
Если кратко, то ты не угадал о чём статья. Статья про то, что со временем менялись массовые источники информации и это не люди были умнее, они просто получили образование с прошлых источников информации, которые потом вышли из моды и многие перестали с ними знакомиться. Таким образом была потеряна связь знаний от прошлых до нынешних, то есть знания стали неполными.
Математик лучше в математике, аппаратчик лучше в аппаратуре, абстракционист лучше в программных абстракциях, а пользователь фреймворков лучше в использовании фреймворков. Но увы, когда нужно перейти на другой уровень знаний не имея чёткого представления о нём получаем тот самый эффект неумности.
А с эпохами это связано потому, что в эпоху математиков хоть тресни, но придётся учить математику, ведь знания об аппаратуре не существует. И так по цепочке, появилась аппаратура, на математику можно и забить, минус по настоящему умный человек. Появились абстракции, забиваем на математику и аппаратуру. Появились фреймворки, забиваем на математику, аппаратуру и абстракции.
С тех пор как я написал статью появились ещё большие языковые модели. Теперь можно "беседовать" с каким-то не обязательно достоверным пластом информации, а не учить математику, аппаратуру, абстракции и фреймворки. Получаем ещё одно поколение людей, которое будет воспитано на иных источниках знаний.
Здравствуйте, velkin, Вы писали:
V>Если кратко, то ты не угадал о чём статья. Статья про то, что ...
Понятно. Интересно.
Но в целом, все определяется оценками и формулировками.
Типа нет абсолюта. Абсолют это та самая точка опоры про которую Архимед переживал.
Но ИМХО ты не чуть понял, о чем я говорил.
Я только про то что ТЫ стал выше, и поэтому тебе кажеться что детские стульчики стали тебе казаться наивными.
Правда для тебя (пользы) в этом нет, как и нет смысла это изменить.
Здравствуйте, velkin, Вы писали:
V>Да, это так. Только проблема в том, что попытка снизить уровень входа так же сильно его повысила. Сильнее всего вход снижается, когда используются готовые библиотеки.
Вот на близком мне примере: никому не нужны люди, которые будут по новой писать растеризацию треугольника для 3д-игры. В лучшем случае они напишут ретро-инди-шутер для таких же долбанутых, ещё и с графическими артефактами. А вот специалист по UE5 с большей вероятностью пригодится при разработке игры, которая будет хорошо продаваться. Увы, такое время.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
N>Для меня сомнительно. Первые реализации nullable types вроде появились в ML, то есть лет через 10 после W.
Nullable types там не было, но системы типов было достаточно для реализации вот такой идеи:
record PERSON(string NAME; integer AGE);
record NULLPERSON();
procedure PrintPerson(reference(PERSON, NULLPERSON) person); // принимает NULLbegin
if person is PERSON
begin
print(NAME(person))
end
end
int procedure YearOfBirth(reference(PERSON) person); /// не принимает NULLbegin
2025-AGE(person);
end;
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, novitk, Вы писали:
N>>В LISP не обошлись без null. В LISP он есть в виде NIL. Только не надо повторять ещё и ко мне ту чушь, что, мол, NIL это "пустой список", а не пустой указатель. N>LISP к ''ошибке Тони''(если под правильным решением мы понимаем Maybe) отношения не имеет, просто потому, что это динамика.
Я не вижу, чем тут динамика или статика — при прочих равных — влияла бы. Меняется только оформление формата этого самого Maybe.
N> vdimas его(lisp) совершенно не к месту как всегда привел, а Sinclair не к тому привязался. N>Во времена Algol W безусловно не было правильного понимание nullable types (оно возникло имхо во времена ML), то есть подобную "ошибку" Тони просто не мог не совершить.
Понимание самого понятия, извините за каламбур — было.
Не было понимания важности. Не было оценки последствий, пусть даже таких фантастических, как "миллиард долларов".
Здравствуйте, Sinclair, Вы писали:
S>Угу. Я закончил школу в 1993 году.
Совсем молодой ещё.
S>Уверяю вас: никакого "любопытства", никаких "исследователей". Совершенно простые смертные. Тётеньки, которые писали унылые программы на фортране.
Точно, молодой.
В самом начале карьеры (конец 80-х) меня такие тётеньки учили реальной работе. И я должен сказать, что многим дяденькам до них было, как до Сатурна крабом. Если что-то у них не получалось с Фортраном (или PL/1), они переходили на ассемблер. А если было нужно, то они и с передней панели находили с машиной общий язык. Переднюю панель я не осилил. И знал я только двух дяденек, освоивших ЕС ЭВМ на уровне тех тётенек. Да, я у этих тётенек кое-чему научился. И всю жизнь буду им благодарен за ту науку.
За всю жизнь я видел только одну унылую тётеньку, которая что-то программировала на Васике на "Искре-226". По сей день я не знаю, чем она занималась.
А на Фортране я успел пару строк черкнуть. И скажу: это кровавый энтерпрайз унылый. Я сейчас им занимаюсь. А в НИИ, где я в 90-е работал, на Фортране весьма серьёзные вещи делались. Там не до уныния было.
Эту гипотезу коллега vdimas уже высказывал. Контраргументы те же — вопросы компресии индексов интересовали разработчиков ещё в ранних 1980х. Это хорошо видно по публикациям статей. 
