OberonCore

> вставить логирование, перекомпилировать и запустить не медленней, чем поставить брэйкпоинт и потом руками нужные переменные напечатать

Вообще-то медленнее. Перекомпиляция может быть быстрой, а вот возникать ошибка может не сразу, а в ходе какого-то долгого вычисления. Например, перекомпиляция ЯОС у меня занимает 2 минуты и да, проблемы были. В пошаговом отладчике шаг занимает пару секунд, а тут пару минут. Сразу в 60 раз. А кратковременная память человека 2 минуты не держит своё содержимое. Т.е. мало что медленнее, так и мощь ума снижается при таких паузах. Особенно плохо, если ошибка является результатом действий в ГПИ, которые на автоматизированы. Но в общем я не уговариваю, просто раз уж обменялись мнениями, то я тоже своё высказал.

> а gdb вообще произведение внеземного разума, предназначеное для того, чтобы человеков сошли с ума

Однако без gdb я бы не смог:

* разобраться, как загружается A2 на ARM
* починить баг в QEMU, мешавший ей это делать в QEMU
* запустить эмуляцию ЯОС для Zynq (были проблемы с эмуляцией SD карты)
* починить загрузку A2 под x86 с CD
* починить кооп. версию ядра A2 на ARM (ядро загрузилась, а дальше там ничего нет).
Ибо при загрузке ОС до какого-то момента нет никаких логов. А вот возможность запустить эмуляцию в QEMU и пройти по шагам - есть.

а я в Doom люблю играть. только не в тот, который из 90-х, а который с полновесным 3д-рендером, динамическим освещением с тенями, и воксельными объектами вместо спрайтов. примерно на этом месте A2 становится очень грустно, потому что в GPU она не умеет. да и нет под неё нужного сурспорта. ну и что мне, гонять A2 под виртуалкой и делать вид, что я реально её использую как ОС? да ну его.

конечно, то, что A2 не умеет в GPU — это не вина A2 самой по себе, а вина производителей GPU, которые сидят на своих спеках как приклееные. но мне-то от этого не легче, моя невидия там всё равно бесполезна.

не спорю: я ней искренне восхищаюсь. но увы: она бесполезна «для дома, для семьи». это может показаться странным — с моей-то любовью к велосипедам ;-),— но мне нужна система чтобы решать практические задачи. я, к сожалению, не могу написать с нуля абсолютно всё; а даже если бы и мог — как заставить других бросить то, что уже есть, и начать использовать моё?

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

я вон BBCB забросил на кучу лет потому что у него не было порта под GNU/Linux. если бы меня жестоко не обманули обещанием, что 2.0 под линуксами нормально работает — я бы и сейчас не пришёл. ;-) хотя теперь не жалею.

кибербезопасность никого не волнует. вообще. а вот возможность набрать кодирав пучок за пятачок, а потом «херак-херак и в продакшон» — ещё как. кому нужен софт под A2-то, кому его продавать?

оно-то несложно, но кому-то надо это сделать. и ещё тестов написать, чтобы conformance check. а никто не любит писать тесты.

ну так оно, по сути, с остальной системой никак не интегрировано: живёт себе в своём отдельном юниверсуме. при таких раскладах и BBCB в A2 как таковой не нуждается: оттуда надо повыкидывать абсолютно всё кроме ядра, компилятора и драйверов. и получим странное создание, которое не понимает и не знает, чем же оно хочет быть: то ли ETHOS с зачем-то прилепленой сбоку бесполезной многозадачностью, то ли A2, у которой вырвали кишки и намотали на столбик.

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

А так же это удобно в режиме GUI Shell набора отладчиков, поддерживаемых IDA Pro, или в классическом отладчике x64dbg
( на всякий случай: это про отладку cm3 Modula-3 ).

Вообще я про крик читаю часто и всегда удивляюсь: с 90х, т.е. TopSpeed Modula-2 , Clarion , это, наоборот, было весьма практично. И эстетитчески привлекательно.

Я, наоборот, и в лабораторных работах на Turbo Pascal перешёл на такой стиль.

тоже вопрос привычки, я полагаю. а иногда просто людям капс не нравитсяю ну, бывает: меня вот люто, бешено нервируют идентификаторы на чём-то кроме английского, например. это намного хуже, потому что регистр, в конце концов, можно исправлять автоматически простым фильтром перед компилятором, а вот автоматически переводить имена переменных не выйдет. ;-)

но если серьёзно, то регистрозависимость вообще очень кривая идея. я, кстати, не помню, писал ли Вирт, почему от неё отказался. в смысле, были ли кроме чисто технических причин экономии восемнадцати (rough estimation for Z80 ;-) тактов ещё и идеологические. потому что для человека оно максимально неестественно: ни размер букв, ни начертание не меняют значения слов.

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

а. кажется, я понял, почему регистрозависимость. в обероне sym-файлы появились, и они важная часть системы. писать туда надо точно так, как в модуле объявлено, иначе нечитаемо будет. значит, нельзя нормализовывать идентификаторы, и каждый поиск замедляется. так себе причина, но на машине с 12 MHz, наверное, заметно было.

но всё равно это максимально недружелюбная система. хотя бы коммандеры научили бы на регистр плевать. (не, я в LC не стану, я тоже максимально недружелюбен к обычным пользователям. ;-)

А у меня наоборот, вот так выглядит код, который я пишу не на работе:

Или вот, на другом языке и из другого проекта:

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

На работе я проиграл борьбу за русскоязычные идентификаторы, но в последнем MR у меня молча приняли штук 5. Думаю, могу привести здесь немного видоизменённый кусочек кода, не раскрывающий секретов фирмы Вот, например:


Для справки: у нас собирались принять закон об уголовном преследовании за ограничения в использовании русского языка. Выглядит вполне логично на сегодняшний день. Не знаю, приняли ли уже или ещё пока не приняли.

Касаемо капса, ВЕРХНИЙ РЕГИСТР ОБЪЕКТИВНО МЕНЕЕ УДОБОЧИТАЕМ, потому что все буквы одинакового размера. У строчных букв то и дело торчат вверх и вниз различные хвостики, которые резко облегчают чтение. Особенно в латинице. Попадающиеся изредка среди строчных заглавные тоже дают глазу реперные точки для удобства чтения.

Другое дело, если есть небольшое число N заранее предопределённых ключевых слов, то тогда в принципе пофигу в каком они регистре. Третье дело, что в Обероне они всё ещё недостаточно сжаты. Сравнить го и питон, где слово PROCEDURE сокращено до 3-4 буковок и преимущество сразу ясно видно. Слово PROCEDURE просто тупо занимает место на экране, не неся никакой полезной нагрузки. Если оно при этом ещё и большими буквами - это особенно плохо. Отсутствие в Обероне слова BEGIN почти везде решает болячку Паскаля - многие люди осознают, что BEGIN - это просто мусор на экране, который мешет читать. Сравним с си и питоном, где это один знак - и преимущество очевидно. Поскольку программист на Паскале видит меньше кода за один раз, ему сложнее читать алгоритмы - значит, если мы исключим прочие факторы и начнём сравнивать программистов на этих языках только на основе удобства чтения синтаксиса, то программист на Паскале окажется самым тупым, оберонщик будет где-то в середине, а программисты на Го и Питоне окажутся самыми умными. Конечно, такой эксперимент сложно провести. Причём тупость будет проявлена не из-за того, что программист на Паскале реально тупее, а просто по той причине, что он потратит больше сил на то, чтобы пробраться через мусор, загромождающий экран, и скрывающий от него суть алгоритма (кстати, чем меньше экран - тем тоже тупее окажется программист).

Ну, если ещё подумать, то можно заметить, что для заглавных букв нужен больше междустрочный интервал, потому что строки налезают друг на друга. Наверное, это ещё одна причина, почему КАПС МЕНЕЕ УДОБОЧИТАЕМ. Если это так (а почему бы и нет), то тогда даже то, что слова предопределены, не полностью спасает от неудобств, вызванных тем, что ключевые слова в верхнем регистре.

P.S. опять же, то, что касается сокращения ключевых слов - верно лишь для профессионалов. Для тех, кто программирует от случая к случаю, и Оберон, и Паскаль могут иметь смысл, т.к. простые принципы и меньше условностей позволяют быстрее вспомнить, что тут к чему и перейти собственно к делу. К программе на Си вообще нельзя подходить, не выучив, к примеру, таблицу приоритетов. В Оберонах она всё же насколько-то проще и не сильно ушла от правил, которые учат в школе на алгебре (хотя тут Вирт не доработал, на мой взгляд). И тут действительно идея с заглавными в ключевых словах может быть очень продуктивна. Т.е. если мы вспомним изначальное целевое назначение Оберона, то всё сходится и Вирт всё сделал правильно.

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

ну да, есть VAR/DIV/MOD, сокращения. но это уже настолько общепринято, что пусть будет.

насчёт русского языка же — срач сейчас будет, давай просто сойдёмся на том, что у нас разные точки зрения на это. ;-)

p.s.: я, кстати, не из россии, поэтому мне русский в коде совершенно не нужен. справедливости ради — как и остальные национальные языки. но, кажется, я срач и провоцирую сейчас. ;-)

p.p.s.: у меня бы код бога был -666. так смешнее.

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

кстати, всегда любил паскаль и наследников за вложеные процедуры. очень удобно ведь, помогает лучше код структурировать. ну да, такие вот ad-hoc namespaces. но удобно. я и в GCC не чураюсь, там в сишечке это разрешили.

и кстати. с введением `VOID:xxx()` назрела проблема реюза временных локалов: компилятор плодит их по необходимости, но никогда не использует повторно. непорядок. научил фронтэнд запоминать уже созданые, и использовать ещё раз (и много, много раз), если возможно. все временные локалы после завершения разбора одного оператора (statement) возвращаются в список свободных, откуда их в следующий раз добудут. естественно, каждая процедура имеет свой список.

а то мне было очень некомфортно использовать `VOID:`. расточительство же! теперь комфортно.

> так что совершенно неважно, что PROCEDURE длинная

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

666 - это число зверя, не совсем ясно, что имеется в виду. Но это точно не число Бога. Зачем вводить в смысл неточности? Кстати, в этом пункте было замечание, поскольку изначально было что-то -100510, а это не вполне очевидно, что является "специальным" числом. Замечание было не по поводу названия константы, а по поводу её значения. Мне сказали "число Бога", я спросил у окружающих, и мне кроме 888 ничего не сказали.

это очередное место, где я категорически не согласен. потому что таким путём у нас получается опять сишечка, с её малочитабельным line noise.

как по мне, тут всё просто: если я читаю чей-то чужой алгоритм (или свой старый), то я никуда не спешу. даже наоборот: очень медленно поспешаю. поэтому ни длина идентификаторов, ни скачки глаз здесь совершенно неважны: я намного больше времени трачу на то, чтобы уложить в голове структуру. классический i/o stall получается. ;-)

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

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

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

кстати, про эстетику. английские слова в целом короче русских, поэтому там, где на английском вмещаются полные слова — на русском зачастую приходится сокращать, чтобы не получались имена длиной стопицот символов. и на русском получается отвратительная «ГосМосКрасШвея» какая-нибудь. коробит. плюс падеж и род ещё. это не основная претензия, конечно, но один из нюансов в копилочку моей нелюбви к русскоязычным идентификаторам.

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

* С - 0 букв
* Java - 0 букв
* Basic - 3 буквы (но это не точно)
* Python - 3 буквы
* Go - 4 буквы
* Lisp - 5 букв

А вот языки, где нет сокращений:
* JS - 8 букв
* Оберон - 9 букв

Мы видим, что в подавляющем большинстве языков слово "procedure" сокращено. То же касается и скобок. В Обероне тоже ведь сокращено BEGIN до 0 букв, если сравнить с Паскалем. Ну или почти.

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

Да, такой недостаток есть. В большинстве случаев у любого решения есть "за" и "против".

и наглядно про реюз временных локалов.


без реюза:

жуть и мрак.

с реюзом:

красота!

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

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

Ну если не обосновал, то всё равно, больше добавить по теме мне нечего. Кроме того, что если мы обратим внимание на человеческие языки, то увидим, что "I", "you", "and" и соответственно, "я", "ты", "и" - кратчайшие слова. Почему? Потому что они наиболее часто используются. Человеческий язык оптимизирован по частотам. Нет никакого смысла делать часто употребляемое длинным - нужно забрать короткие имена для часто употребляемых, тогда процесс общения будет более энергетически выгоден.

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

Если пытаться оптимизировать ЯП, то надо было бы деление писать словом, а значок "/" отобрать для определения процедуры, к примеру. Потому что процедуры определяются в среднем во много раз чаще, чем используется деление. Понятно, что так никто делать не будет, но я просто довожу ситуацию до логического завершения.