OberonCore

Хлеба насущного ради стал я учить Голанг. И обнаружил много общего с Обероном. Более того, мои планы по реформе Оберона были во многом выполнены авторами голанга. Были вещи, о которых я помалкивал. Например, врождённая сериализация в текст. В лиспе она есть. В обероне её нет. Я хотел её добавить без лишнего шума, чтобы не спёрли. Оказалось - в голанге сериализация есть, не знаю насчёт десериализации обратно из текста. Многие другие вещи как раз прямо являются воплощением моих планов и завершением моих экспериментов.

Чтобы не тратить время на копирование, вот тема на моём форуме.

http://вече.программирование-по-русски.рф/viewtopic.php?f=2&t=104&p=409#p409

Половина того, что я предлагал сделать для Оберона, сделано авторами голанга. Но вы можете продолжать упорствовать в своей ортодоксии.

Смотрите динамику: https://www.linux.org.ru/forum/development/12767812 . В 2016 году было сначала две вакансии в России по Голангу, потом 5. Сейчас их 121. В том числе с зарплатами за 300 руб. Это интересно, и я иду туда.

А сколько было по оберону вакансий в 2016? Ноль. А сколько сейчас? Ноль.

Притом потенциально Оберон лучше голанга (об этом я тоже написал на своём форуме).

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

Вы не решили ни одной серьёзной задачи.
Поэтому цена такой истерике -- грош.

КМК, раздел "Технологии компиляции" не самое подходящее место для тем типа "критика xxx" .

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

Вы перепутали. В этой теме предлагается критиковать не БудДена, а Голанг. Судя по всему, про Голанг сказать нечего, поэтому было решено сосредоточиться на более доступном для критики объекте С Вами, Пётр, я тоже всё понял. Ровно тогда, когда Вы назвали лисп декларативным языком. На этом я заканчиваю перепалку и жду, пока кто-нибудь напишет что-то по существу предложенной темы. Или можно совершить Поступок и объявить тему не представляющей научного интереса.

Вы, Денис, тоже не горячитесь. Здесь высказывались не о Вас, а о Ваших высказываниях.

Информации по существу в плане критики Golang Вами, Денис, не представлено.

В части лично Вас - не сочтите за бесцеремонность дать Вам совет:
Занимайтесь тем, что любите. И любите то, чем занимаетесь.

Если Вам не нравится Оберон, просто тихо переключитесь на что-нибудь полезное. Лисп, Golang или выпиливание лобзиком. Будете любить свое дело, и у Вас обязательно получится. Только не рассчитывайте, что толпы благодарных последователей побегут за Вами.

И еще. Разные многословные посты мало кому интересны, когда содержат мало информации по существу. Это напоминает "Страдания юного Вертера" в гораздо менее талантливом изложении.

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

ЛИСП и есть декларативный язык, а ты есть неграмотный человек, если отрицаешь.

Учтите, что исключения есть в дизайне Go, но из-за другого названия и другого способа записи многие считают, что нет, не видя разницы между термином и понятием. Отчасти, поэтому, а, отчасти, и из-за других средств неструктурного потока исполнения оказывается нужен defer. Если нет необходимости скакать туда сюда на разных разновидностях GOTO, то и нет нужды в defer, который не бесплатен во всех смыслах.

Это разновидность автоматической обёртки в ANYREC, похожий механизм есть в Java. Опять-таки, вещь не бесплатная во всех смыслах и там и там. В частности, есть некоторые особенности с nil.

Нужен не больше, чем Оберону. Если при программировании на Golang обойтись без связывания с библиотеками на Си, то это сильно упрощает межплатформенную сборку.

Comdiv, спасибо за содержательное обсуждение. Похоже, да, что паника - это исключения, т.к. она обрабатывает defer (которые есть блоки finally), т.е. есть раскрутка стека. Хотя я не в курсе, почему исключения в С++ считаются дорогими и страдает ли голанг от этой проблемы. Впрочем, идея Оберона, как я её понял, состоит в том, что мы не ставим быстродействие во главу угла. Мы ставим во главу угла простоту и надёжность. Если исключения позволяют упростить работу и сделать программы более надёжными, то их можно использовать, даже если они медленные. Но defer может быть использовать и отдельно от паники, и отдельно от исключений. В этом случае он служит для реализации RAII и в этом виде полезен (хоть и многословен). RAII сама по себе с исключениями не связана, она становится актуальной при наличии более чем одной точки выхода из функции. Да и просто удобно: открыл файл, в этом же месте (а не 20 строчками ниже) позаботился о том, чтобы файл закрылся, и забыл об этом вопросе. С исключениями это опять же не связано.

Осталось выяснить, нет ли исключений в Обероне, ведь в ББЦБ и BlueBottle нём есть локализация ошибки в активности или в обработчике события. Там есть и trap cleaner. Впрочем, лично мне сейчас это неважно. У меня в вопросе исключений каких-то убеждений. Мне кажется, что хорошего подхода к обработке ошибок пока не придумано.

> Если при программировании на Golang обойтись без связывания с библиотеками на Си, то это сильно упрощает межплатформенную сборку.
Тогда вопрос такой: есть ли на голанге что-то, подобное BlueBottle, т.е. немножко ассемблера и дальше один голанг, без всякого Си?

Это потому, что то и это - операционные системы, хотя и в разной степени. Также, как в современных ОС АВОСТ в программе не приводит к выключению компьютера, так и аварийное завершение команды в ББ не приводит к падению всей программы.

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

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

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

Например, для того, чтобы получить привычную развёртку стека после АВОСТ в текущем проекте на Java, мне сначала пришлось долго настраивать IDE и пришлось бы настраивать заново для другого кода, а затем, вообще, понадобилось менять архитектуру приложения. В обычном режиме приложение зажёвывает исключения и продолжает выполнение, включая случаи некорректного состояния и предоставляя испорченный конечный результат. Типичной проблемой исключений является сложность отделения ошибок в программе от ошибок входных данных, и это пример такого смешения.

«не читал, но осуждаю». Там речь идёт исключительно о скорости выполнения, и я тоже имел в виду именно это. Первоисточник: http://www.flounder.com/exceptions.htm

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

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

Ну, тут ещё надо разобраться, страдают ли исключения в голенге от тех же проблем, ведь они сделаны существенно по-другому. Плюс рекомендации по стилю, например, не выпускать панику из библиотек. Касаемо defer - я вижу в них сплошные плюсы. Единственное, что в них плохо - это возможность возникновения каскадной ошибки. Например, если закончилась память, а defer пытается что-то записать в журнал и для этого нужна ещё память. Но это - достаточно малая доля возможных проблем, и я всё равно считаю, что defer скорее выгодны, чем вредны. Впрочем, это можно счесть вкусовщиной. Дальше вроде пока нечего обсуждать.

В Go, несомненно, сделано лучше, так как в нём исключения задвинуты в дальний угол для того, чтобы меньше злоупотреблять этим механизмом. Поскольку Go зарится и на область скриптового применения (написал-запустил-выкинул), то в нём исключения и другие неструктурные переходы и смотрятся более-менее уместно. Тут же и defer - это не может быть положительным свойством из общих рассуждений, это вопрос области применимости.

В современных реализациях runtime-стоимость минимизируется (особенно для happy path):
Нет ничего проще, чем вызвать функцию, я сам это делал неоднократно
Что же там такого тяжелого в обработке исключений C++?
С++ exception handling под капотом или как же работают исключения в C++