Здравствуйте, Sinclair, Вы писали:
S>Nullable types там не было, но системы типов было достаточно для реализации вот такой идеи:
discriminating unions в системе типов — это тоже "технология будущего" для практического языка из 1965. Блин, их 25 лет в С# добавить не могут, все ждем.
ИМХО Тони вероятно понимал некошерность и попытался что-то придумать, но "мыши не становились ежики" и он пошел на компромисс, нужно было делать R&D еще много лет.
Здравствуйте, netch80, Вы писали:
N>Я не вижу, чем тут динамика или статика — при прочих равных — влияла бы. Меняется только оформление формата этого самого Maybe.
My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler.
В динамике вопрос безопасных систем типов не стоит.
N>Понимание самого понятия, извините за каламбур — было. N>Не было понимания важности. Не было оценки последствий, пусть даже таких фантастических, как "миллиард долларов".
+1. Понимания важности не было. Однако желание решить вроде было, но не было понимания как.
Здравствуйте, novitk, Вы писали:
N>discriminating unions в системе типов — это тоже "технология будущего" для практического языка из 1965.
И тем не менее, они там были. http://oberon2005.oberoncore.ru/paper/nw_algw.pdf, 5.1.1/5.1.2
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, velkin, Вы писали:
V>В этой статье я попытаюсь ответить на вопрос, почему программисты прошлого были умнее, а качество образования с каждым годом только падало.
Какие именно программисты? И что значит умнее?
Если что, именно ум — это близко к врожденному. Ум сразу или есть, или нет. Под умом я подразумеваю быстрое схватывание на лету сложных концепций, способность что то глубоко понять, способность держать в памяти до черта всего и эффективно этим пользоваться. Среднего человека можно надрессировать на выполнение чего то и даже разжевать какие то сложные концепции, но именно умный осилит это без дрессировки и разжевывания, он сможет понять сам, с нуля.
В прошлом, как и сейчас, были работы на переднем крае. И была лютейшая рутина. На переднем крае, те, кто двигали отрасль вперед — как были умные, так и остались. А насчет рутины — для рутины как не требовалось особого ума, так и не требуется. Вот только ранее рутина была практически необходима, и рутину не брали на себя среды разработки и до хрена всего делалось вручную, иногда велосипедами, то сейчас низкоквалифицированная рутина нафиг не нужна.
Соответственно раньше нужно было немного умных и до фига тех, кто занимается тупейшей рутиной. И в среднем будет уровень крайне невысокий, ибо упор на рутину. Сейчас тоже нужно немного умных, но меньшее количество рутины, рутину перебросили на другие профессии вроде тестировщиков, и даже труд верстальщика в значительной степени автоматизирован. Соответственно средний уровень даже оказывается повыше. Плюс сейчас упор делается на скорость разработки, time to market оказывается весьма небольшое.
Здравствуйте, novitk, Вы писали:
N>My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. N>В динамике вопрос безопасных систем типов не стоит.
Вообще-то стоит.
В Лиспе не зря принято проверять аргументы в апишных ф-иях перед подачей аргументов "куда-то дальше", потому что иначе получаем по классике проявление ошибки не там, где она породилась, т.е. получаем невозможность найти источник ошибки и всё равно получаем ошибку исполнения, как ни крути. Другое дело, что нет прохода по памяти...
N>+1. Понимания важности не было. Однако желание решить вроде было, но не было понимания как.
Дык, и сейчас хорошего понимания нет.
Повторюсь, в идеале требуется обеспечить валидность любой ссылки, а не только notnull, и твоё процитированное оставленное в первой строчке повторяет эту мысль.
(Твой монадический maybe тут полезен лишь в узком классе структур данных, где null является частью семантики, например, в связанных списках).
Здравствуйте, Sinclair, Вы писали:
S>Пришлось бы для каких-то случаев реализовывать паттерн null objeсt
На практике этот паттерн хорошо работает лишь в случае отсутствия полей у объекта, т.е. когда есть только виртуальные ф-ии и им можно приписать некое "нулевое" поведение либо выбрасывание исключений (одно время широко использовали этот паттерн в реальных разработках, потом отказались).
Потому что на практике в программе, допустим, будет связанный список объектов некоего типа, и если использовать как конец списка ссылку на "нулевой" объект, то при непроверке на null (в чём суть ошибки, которую пытаемся лечить) будет обращение к полям этого null-объекта с чтением фигни, т.е. ошибка маскируется и себя никак не проявляет. Или проявляет себя намного позже, вдали от места и времени возникновения — это самый неприятный случай.
В общем, такие костыли обычно ведут к еще худшим ошибкам, т.е. требующим гораздо больше усилий на обнаружение самого факта ошибки и затем на её локализацию.
Здравствуйте, vdimas, Вы писали:
V>На практике этот паттерн хорошо работает лишь в случае отсутствия полей у объекта, т.е. когда есть только виртуальные ф-ии и им можно приписать некое "нулевое" поведение либо выбрасывание исключений (одно время широко использовали этот паттерн в реальных разработках, потом отказались). V>Потому что на практике в программе, допустим, будет связанный список объектов некоего типа, и если использовать как конец списка ссылку на "нулевой" объект, то при непроверке на null (в чём суть ошибки, которую пытаемся лечить) будет обращение к полям этого null-объекта с чтением фигни, т.е. ошибка маскируется и себя никак не проявляет. Или проявляет себя намного позже, вдали от места и времени возникновения — это самый неприятный случай.
V>В общем, такие костыли обычно ведут к еще худшим ошибкам, т.е. требующим гораздо больше усилий на обнаружение самого факта ошибки и затем на её локализацию.
record IntegerList(integer Value; reference(IntegerList, Null) Next);
record Null();
Чтобы делать current := Next(current) нужно, чтобы а) current имел тип reference(IntegerList, Null), и б) чтобы была выполнена проверка if(current is IntegerList).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>чтобы была выполнена проверка if(current is IntegerList).
Еще и динамическая типизация...
Как и с размеченным объединением, вариант с динамической типизацией ужасен.
Это ведь тоже две серьёзные инженерные ошибки, стоившие индустрии овердохера миллиардов...
И оно в любом случае не спасет, если объект был удалён, а ссылка на него еще есть — я ж сразу обращал внимание, что проблема валидной ссылки намного шире, и не ограничивается только null.
Требуются совершенно другие техники. А полноценный GC на тот момент тупо не взлетел бы, бо ему требуется метаинформация над полями, это ж не Лисп с его парой {CAR, CDR}.
Да и сама потребность в GC резко сужает область применения любого языка.
Еще можно как в Rust, но тогда язык был бы непригоден для массового использования в те годы, бо требовался язык, на котором могли бы сразу писать большое кол-во инженеров без программистского образования, бо его тогда ни у кого не было, и даже без программистского опыта, бо его тоже тогда ни у кого не было.
Более того, удовлетворительно оно решается только в зависимых типах (сказал сразу же еще 3 года назад в этой ветке, наивно надеясь, что спор сдуется сам с собой из-за очевидного аргумента), но даже на сейчас нет ни одного человеческого языка с этой системой типов, а на дворе уже 2026-й, на минуточку.
Т.е. мы даже сегодня не имеем удовлетворительного решения...
Но зато горазды рассуждать о том, что это можно было сделать еще в 60-е.
=====
И да, novitk там лишнее говорит, мол, в Лиспе ж динамика, т.к. сразу же тогда и сказал, что имею приличный опыт сопрягания Лиспа с нейтивом, где на границе такого сопрягания если не проверишь — получишь все эти же светошумовые эффекты. Т.е. другое дело, что в самой программе на Лисп всегда идёт проверка на конец списка и вываливание с ошибкой вместо неверной реинтерпретации...
Но всё равно от самой этой ошибки страховки нет! И можно эту ошибку передать "куда-то дальше" и она проявит себя намного позже.
т.е., если рассуждать не о последствиях ошибки (вылет системы vs "format c:"), а о самой возможности совершать ошибки, связанные с null, то в Лиспе всё аналогично. Ну просто будет постоянный вылет и всё, вместо непонятного исполнения мусора. Но с развитием защищённого исполнения, теперь всегда вылет, если идёт обращение по null, т.е. получили эффекты в точности как в Лисп, разве что не через ручную проверку на каждой операции разыменования, а через прерывания проца...
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>чтобы была выполнена проверка if(current is IntegerList).
V>Еще и динамическая типизация... V>Как и с размеченным объединением, вариант с динамической типизацией ужасен. V>Это ведь тоже две серьёзные инженерные ошибки, стоившие индустрии овердохера миллиардов...
Крайне спорное утверждение. Впрочем, если вам удастся его доказать, то вы опровергнете заглавную тему топика, т.к. эти "ошибки" как раз и были сделаны программистами прошлого, которые якобы были умнее
V>И оно в любом случае не спасет, если объект был удалён, а ссылка на него еще есть — я ж сразу обращал внимание, что проблема валидной ссылки намного шире, и не ограничивается только null.
В Algol W это невозможно. Там нет способа "удалить объект".
V>Требуются совершенно другие техники. А полноценный GC на тот момент тупо не взлетел бы, бо ему требуется метаинформация над полями, это ж не Лисп с его парой {CAR, CDR}.
И тем не менее, в Algol W сборка мусора была.
Выводы, сделанные на основе неверных предположений, поскипаны.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Как и с размеченным объединением, вариант с динамической типизацией ужасен. V>>Это ведь тоже две серьёзные инженерные ошибки, стоившие индустрии овердохера миллиардов... S>Крайне спорное утверждение.
В смысле "спорное утверждение"?
А как же принцип подстановки Лисков?
(крутая женщина)
Это сразу на пересдачу...
S>Впрочем, если вам удастся его доказать, то вы опровергнете заглавную тему топика, т.к. эти "ошибки" как раз и были сделаны программистами прошлого, которые якобы были умнее
Дык, программисты прошлого придумали концепцию абстрактного итератора, чтобы не нарушался принцип подстановки.
Причём, в некоторых языках эта абстракция не имеет пенальти за абстракцию. ))
Начало 70-х годов, язык CLU:
list: int_list := int_list$create()
for item: int in int_list$elements(list) do
putl(stream_output, "Элемент: ", int$unparse(item))
end
замени $ на точку и получишь код, близкий к любому мейнстримовому современному языку.
А точно ли программисты прошлого было глупее? ))
Или это говорит невежество некоторых современных <даже не знаю как назвать>.
V>>И оно в любом случае не спасет, если объект был удалён, а ссылка на него еще есть — я ж сразу обращал внимание, что проблема валидной ссылки намного шире, и не ограничивается только null. S>В Algol W это невозможно. Там нет способа "удалить объект".
Ага, точно!
Зато в наследнике-Паскале уже можно удалить.
Ну так ошибку на хреналлион денег совершил Вирт, а не Хоар, получается?
На самом деле никто из них, конечно же.
Решение это было очевидным и очень давним, задолго до них, ведь ЯП тех лет традиционно оформлялись как потребность ухода от ассемблера, но без потери эффективности или с минимальной такой потерей. В этом смысле Лиспы и прочие Прологи были сугубо прикладными языками, а вот Алголы и Ады — языками достаточно низкого (системного!) уровня, с соответствующими требованиями к ним.
V>>Требуются совершенно другие техники. А полноценный GC на тот момент тупо не взлетел бы, бо ему требуется метаинформация над полями, это ж не Лисп с его парой {CAR, CDR}. S>И тем не менее, в Algol W сборка мусора была.
Разве?
В Algol W отсутствует встроенная сборка мусора.
Все источники единодушны в этом. При этом несколько документов подчёркивают, что это было осознанное архитектурное решение — для простоты реализации и эффективности на машинах 1960-х годов.
Прям почти моими словами, вау...
S>Выводы, сделанные на основе неверных предположений, поскипаны.
Пока что неверные предположения оказались у тебя.
Попробуй еще раз...
Здравствуйте, vdimas, Вы писали:
V>В смысле "спорное утверждение"?
В прямом. И про то, что это — ошибки, и про овердохера миллиардов.
V>А как же принцип подстановки Лисков?
Прекрасно. А что с ним не так? V>Это сразу на пересдачу...
Ну так приходите на пересдачу, если завалили. Пока я вижу, что вы не понимаете терминов, которыми пользуетесь.
Например, у вас есть какие-то заблуждения о совместимости алгебраических типов с LSP.
S>>Впрочем, если вам удастся его доказать, то вы опровергнете заглавную тему топика, т.к. эти "ошибки" как раз и были сделаны программистами прошлого, которые якобы были умнее
V>Дык, программисты прошлого придумали концепцию абстрактного итератора, чтобы не нарушался принцип подстановки.
Да, точно. Смысла слов вы не понимаете, продолжаете фонтанировать чушью. V>Ага, точно!
Ну, вот видите. V>Ну так ошибку на хреналлион денег совершил Вирт, а не Хоар, получается?
Нет, т.к. null-refernce был в Algol W до Паскаля.
V>Разве? V>
V>В Algol W отсутствует встроенная сборка мусора.
V>Все источники единодушны в этом. При этом несколько документов подчёркивают, что это было осознанное архитектурное решение — для простоты реализации и эффективности на машинах 1960-х годов.
V>Прям почти моими словами, вау...
Пробили очередное дно. К собственному бреду добавляете галлюцинации ИИ. Вы что, так и не научились требовать от него ссылки на "источники"?
Можно компенсировать отсутствие эрудиции логикой: как должна была работать программа на языке, где нет операций освобождения памяти?
Можно компенсировать отсутствие логики тщательностью поиска: пойти да почитать, как были устроены реализации Algol W.
Вы зачем-то компенсируете отсутствие всего этого безудержным фантазированием. Это, как бы вам сказать, прямо красный флажок для разработчика при устройстве на работу.
Здравствуйте, Sinclair, Вы писали:
V>>В смысле "спорное утверждение"? S>В прямом. И про то, что это — ошибки, и про овердохера миллиардов.
Сказал же — нарушение LSP.
V>>А как же принцип подстановки Лисков? S>Прекрасно. А что с ним не так?
Ты его нарушаешь через явный if.
С этим сразу на пересдачу, почему нельзя так делать. ))
V>>Это сразу на пересдачу... S>Ну так приходите на пересдачу, если завалили. Пока я вижу, что вы не понимаете терминов, которыми пользуетесь.
Это всё вода на киселе ни о чём.
Ты давай конкретней, плиз, а то сии эмоции "я очень-очень считаю, что вы очень-очень неправы" — позиция безумца.
Где аргументы? Выкладки? Конкретика?
S>Например, у вас есть какие-то заблуждения о совместимости алгебраических типов с LSP.
Фуф... Ты на моей памяти делал эту ошибку уже много раз, и продолжаешь совершать одну и ту же ошибку — у тебя тут НЕТ чистой алгебраической системы типов, коль ссылочные типы данных отделяются явным образом от нессылочных из-за мутабельности данных и отсутствия GC.
Сосредоточься, плиз: в иммутабельной алгебраической системе типов с GC ссылочная семантика неотличима от семантики значений! А раз нет ссылочной семантики, то неоткуда взяться null!
А в обсуждаемой системе типов имеем хренвам — отсутствуют любые гарантии и "хорошие практики" относительно алгебраических типов.
Плюс система типов открыта, т.е. даже полноту диспетчеризации ПМ в общем случае гарантировать невозможно.
В итоге, привет костыли, выполненные в механике IoC — в прошлые годы я тебе показывал единственный валидный способ работы с такими типами в указанных ограничениях, но ты и там плохо понимал, почему именно IoC является единственно корректным способом работы в этих ограничениях: http://www.rsdn.org/forum/philosophy/8956284.1
Ругался на эту элементарщину зачем-то, чем сильно удивил.
Так и не разобрался до сих пор?
Ну так спроси коллегу novitk, он такие вещи понимает очень хорошо и у него на таких как ты больше терпения.
В общем, в этих ограничениях ты можешь полагаться только на абстракции ссылочных данных в сочетании с абстрагированием ф-ий через те или иные разновидности диспетчеризации ф-й: явные указатели на них, объекты-функторы, встроенные таблицы виртуальных ф-ий в языках со встроенным ООП и т.д. — все перечисленные (или аналогичные) подходы пригодны для реализации IoC механики над этими недоалгебраическими типами, где по ссылке я показал корректный способ работы с такими типами. И там ведь хорошо видно, что это банально неудобно, блин!
V>>Дык, программисты прошлого придумали концепцию абстрактного итератора, чтобы не нарушался принцип подстановки. S>Да, точно. Смысла слов вы не понимаете, продолжаете фонтанировать чушью.
Т.е. опять не в состоянии пояснить своё несогласие?
Мне так понимать эту несдержанность? ))
LSP ведь очень прост, и как раз абстрактный итератор — один из наилучших примеров следования этому принципу.
Причём, это отличный пример как в оригинальной реализации типов/подтипов, так и в соседней на лямбда-кубе системе типов с параметризуемыми термами (генериками/шаблонами).
V>>Ага, точно! S>Ну, вот видите. V>>Ну так ошибку на хреналлион денег совершил Вирт, а не Хоар, получается? S>Нет, т.к. null-refernce был в Algol W до Паскаля.
Не-не-не, проги глючат даже в защищённой памяти вовсе не из-за null (бо по null честный вылет), а из-за обращения к мусорным адресам — к удалённым объектам или за пределы массивов, в т.ч. "условных" массивов, т.е. динамически выделенных "просто участков памяти".
А по null уже лет 30 никуда обратиться невозможно.
Но ошибки на хреналлиарды продолжают происходить!
Именно поэтому я сразу обозвал "проблему null" преувеличением и перетягиванием одеяла постаревшего Хоара на себя. ))
S>Можно компенсировать отсутствие эрудиции логикой: как должна была работать программа на языке, где нет операций освобождения памяти?
Ты никогда не писал на Фортране или Бейсике?
Ил просто на Паскале без динамического выделения памяти? ))
Программы тех лет не работали 24x7 в сервисах/облаках, они запускались, читали input, обрабатывали его и давали output.
В этом сценарии освобождение памяти весьма опционально, да и пулы объектов никто не отменял.
S>Можно компенсировать отсутствие логики тщательностью поиска: пойти да почитать, как были устроены реализации Algol W. S>Вы зачем-то компенсируете отсутствие всего этого безудержным фантазированием. Это, как бы вам сказать, прямо красный флажок для разработчика при устройстве на работу. S>http://i.stanford.edu/pub/cstr/reports/cs/tr/68/98/CS-TR-68-98.pdf
Фуф... Не читать то, что сам приводишь в кач-ве аргументов — вот красный флажок
По ссылке у тебя некая альтернативная реализация Algol W, где прямо указаны отличия от спецификаций Хоара и Вирта.
Ну и как ты собрался что-либо "доказывать" при таких вводных?
Это ж натуральное безумие...
V>>Попробуй еще раз... S>Смешно.
Местами смешно, конечно.
Но когда упоротость переходит границы здравого смысла, то уже досадно за потраченное время.
Ну пусть тогда будет просто порка сугубо как напоминание остальным, что надо быть (а) тщательнее и (б) уметь вовремя остановиться, если вдруг пошёл не туда. ))
Здравствуйте, vdimas, Вы писали:
V>Сказал же — нарушение LSP.
Ну так его там нет.
V>Ты его нарушаешь через явный if.
Нет. V>С этим сразу на пересдачу, почему нельзя так делать. ))
Кто вам такое сказал?
V>Ты давай конкретней, плиз, а то сии эмоции "я очень-очень считаю, что вы очень-очень неправы" — позиция безумца.
Конкретно: в примере нет нарушения LSP. Вы его видите — докажите, что оно есть.
V>Фуф... Ты на моей памяти делал эту ошибку уже много раз, и продолжаешь совершать одну и ту же ошибку — у тебя тут НЕТ чистой алгебраической системы типов, коль ссылочные типы данных отделяются явным образом от нессылочных из-за мутабельности данных и отсутствия GC.
Это совершенно неважно. Ссылочный тип в Algole W позволяет перечислять варианты того, на что ссылается — это и есть алгебраический тип. V>Сосредоточься, плиз: в иммутабельной алгебраической системе типов с GC ссылочная семантика неотличима от семантики значений! А раз нет ссылочной семантики, то неоткуда взяться null!
Это совершенно нерелевантное рассуждение, т.к. в Algol W не было иммутабельной алгебраической системы типов.
V>Плюс система типов открыта, т.е. даже полноту диспетчеризации ПМ в общем случае гарантировать невозможно.
Да где ж она открыта-то? Вы спецификацию читали?
V>LSP ведь очень прост, и как раз абстрактный итератор — один из наилучших примеров следования этому принципу.
V>Не-не-не, проги глючат даже в защищённой памяти вовсе не из-за null (бо по null честный вылет), а из-за обращения к мусорным адресам — к удалённым объектам или за пределы массивов, в т.ч. "условных" массивов, т.е. динамически выделенных "просто участков памяти".
Существование другой ошибки не означает, что первой нет. В Algol W к мусорным данным обратиться было невозможно.
V>А по null уже лет 30 никуда обратиться невозможно. V>Но ошибки на хреналлиарды продолжают происходить!
Вот именно, т.к. проблема не в том, что мы "прочитаем из null что-то неверное", а в том, что программа упадёт в рантайме. И это будет нам стоить денег.
V>Ты никогда не писал на Фортране или Бейсике? V>Ил просто на Паскале без динамического выделения памяти? ))
Ну так в Algol-то было динамическое выделение памяти.
S>>http://i.stanford.edu/pub/cstr/reports/cs/tr/68/98/CS-TR-68-98.pdf
V>По ссылке у тебя некая альтернативная реализация Algol W, где прямо указаны отличия от спецификаций Хоара и Вирта.
Да? Процитируйте же эти отличия.
И заодно можете показать техническое описание оригинальной реализации Вирта, в которой осознанно отказались от сборки мусора.
V>Но только зачем ты столько бегал, если чуть более поздний Algol 68 уже требовал сборку мусора прямо по своей спецификации?
Потому, что Хоар ссылался именно на Algol W.
V>Зато Algol W в своей спецификации сборку мусора не требовал. V>Есть же вики: V>https://en.wikipedia.org/wiki/ALGOL_W V>Есть другие ресурсы: V>https://grokipedia.com/page/ALGOL_W V>Ну и как ты собрался что-либо "доказывать" при таких вводных?
Да я-то легко — приводя, к примеру, ссылки на спецификации. V>Это ж натуральное безумие... S>>Смешно. V>Местами смешно, конечно. V>Но когда упоротость переходит границы здравого смысла, то уже досадно за потраченное время. V>Ну пусть тогда будет просто порка сугубо как напоминание остальным, что надо быть (а) тщательнее и (б) уметь вовремя остановиться, если вдруг пошёл не туда. ))
Совершенно с вами согласен. Вот вам всё уже принесли и объяснили на пальцах — нет, вы упорствуете. Аргументируете одно заблуждение другим — и по нарастанию бредовости.
Вместо того, чтобы написать "да, я опростоволосился, в Algol W была сборка мусора и способ отличить запись-заглушку от настоящей записи", вы продолжаете выдумывать альтернативную реальность.
Вас уже ткнули носом в спеку исходной реализации Алгола — но нет, не в коня корм. Вы всё ещё думаете, что можно рассуждать на темы, в которых ничего не понимаете, путём беглого чтения одностраничных статеек из википедии.
Удачи. Отвечать вам далее не буду, т.к. у меня есть более интересные занятия, чем спорить с идиотами, да ещё и об очевидном.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
V>>>В этой статье я попытаюсь ответить на вопрос, почему программисты прошлого были умнее, а качество образования с каждым годом только падало. 0>>Для начала было бы неплохо доказать, что это факт имеет место быть.
V>Кому надо тот пусть и доказывает
Собственно этой фразой можно и ограничиться, она отлично показывает насколько программисты прошлого были умнее и как упало качество образования с тех пор.
