OberonCore

Ну вообще-то разрядность компьютеров всё время растёт. Они никогда не были двоичными, но сейчас на рабочих столах они обычно 64-разрядные, хотя мой первый компьютер был 8-ми разрядным. Соответственно, если мы отвлечёмся от человеческого языка и перейдём к компьютерному, то размер слова и ёмкость смыслов, которые оно может передать, драматически выросло. А уж если возьмём ёмкость пространства всех возможных URL-ов, то тут прямо астрономическое увеличение масштаба.

Вот эта идея мне нравится - чтобы компьютер особо не задавался и тоже ничего не знал более, чем о 60 людях, или о 60 компьютерах. Я всецело за ограничения компьютеров с учётом многосторонней угрозы, которую они несут людям. Но люди почему-то этого не хотят. Им интересно, когда компьютер помнит все улицы Москвы и прокладывает маршрут, интересно, что гугл всё знает (хотя сегодня уже половину забыл, пожалуй), интересно иметь возможность купить какую-нибудь хрень в любом магазине. А уж властям предержащим как интересно заглянуть в каждую замочную скважину... В общем, человек остаётся человеком с 33 буквами и 60 контактами, а компьютер растёт и растёт, как джинн из бутылки.

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

Мне понравился аргумент про 33 буквы алфавита. Явно маловато, надо больше.

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

Этого я никогда не понимал, и видимо, никогда и не пойму. Есть image-based системы, такие, как базы данных SQL, где исходные тексты хранятся в самой СУБД и никакие файлы не нужны. Но это явно не про Оберон.А поскольку я это не понимаю и не пойму, то не стоит над этим и думать или это обсуждать. Одна из первых вещей, которую я сделал, когда отделил ЯОС от A2 - это привязал, насколько мог, модуль к файлу. Отлаживать программы и переходить к определению стало гораздо проще. Привязка пока хорошо работает только в одну сторону. В другую сложнее, но ничего, ещё не вечер.

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

Но надо признать, после того, как тема отлежалась, что Сергей Дурманов разбил всю мою рекламу про качества Оберона по сравнению с Си/Си++ и теперь мне будет сложнее с пропагандой, зато будет меньше иллюзий и вранья, а это уже плюс.

P.S. а не пойму я, когда отделяют язык от библиотек, реализации и среды разработки. Иметь дело приходится с системой из всех этих пунктов. Поэтому имеют смысл фразы "этот язык плохой, потому что у него не может быть хорошей среды разработки". Например, почему в Си/Си++ проблемы с поиском определения? А потому, что там есть препроцессор. Но при определённых ограничениях на систему сборки (проекты MSVS, CMake, или хотя бы уж bear) и при определённых других ограничениях (рассматриваем одну конфигурацию сборки) это решаемо. В A2 тоже есть препроцессор, есть та же самая проблема и она точно так же решаем - сужаем до одной конфигурации и поиск определения становится при этом однозначным (но в нём начинают появляться щели).

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

Ещё одна проблема, по ней ББ ни на ι не лучше C++. Вот написано в коде a.b(). Где определён b()? А вообще говоря, неизвестно. Потому что наследование. Имея полный образ программы, можно перебрать все методы b() по всей иерархии и предложить список. Но в системе с динамически подгружаемыми модулями это сделать уже нельзя. Особенно плохая ситуация, если методы являются перекрываемыми по умолчанию и этого нельзя отменить (ведь в ББ же именно так, или я ошибаюсь?). Если по умолчанию метод не перекрывается или есть слово final хотя бы, то во многих случаях найти определение b() легко. Т.е. вот, проблема вроде бы в среде разработки, но корни её лежат в самом языке.

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

Чувствую, я тут уже на костёр инквизиции наговорил. Прошу не обращать внимания на это бурчание - это всё от лени и желания откосить от работы.

Еще вот из рассылки прилетело
"C Is Not a Low-level Language"
https://queue.acm.org/detail.cfm?id=3212479

Да-да. И не переносимый ассемблер

Непереносимый ))

А каждый разряд (хоть у 64-разрядного или хоть у 8-разрядного), он сколько состояний имеет?


"Бряхняяя"... с ARM32 на MSP430 "ассм" влёгкую... (но, правда, исходники мои собственные были)

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

Расскажите это тем программерам, которые уже скоро 60 лет, как на одном и том же ассемблере в IBM для мэйнфреймов пишут прикладное ПО...

К чему бы это?
Но надо отметить, что одни понимают теорию и видят возможности, другие не понимают и не видят. Из недавних примеров - в компании Apple понимают.

А вот кстати - да (в смысле "не ассемблер"), из собственного опыта: готовые исходники на це (проект CMSIS-DAP адаптер) для "чуть более жирного" проца не помогают в переносе на чуть "менее жирный", но полностью достаточный по ресурсам проц (ядро то же самое, производитель тот же, а семейство по-проще и организация портов в/в вообще другая).

А что надо сделать, чтобы работать в Обероне в стиле Erlang?
из статьи:

Ну естественно, по проводам иначе как двоичным способом передать нельзя. Но количество битиков для одного и того же сообщения может варьировать в зависимости от сжатия информации. Речь шла именно об этом. Например, 33 буквы алфавита продолжили использовать и после появления двоичного алфавита. Пишем по старинке "абвг", а не "0 1 10 11". Т.е. в общем-то за пределами проводов никто двоичным алфавитом и не пользуется. Там, где двоичный алфавит возник, дампы пишут в 16-ричном алфавите, а не в двоичном, потому что это в 4 раза компактнее на экране. Так что я могу согласиться, что подвижек не видно. Но не видно их не потому, что их нет, а потому, что они уже давно произошли ввиду их очевидной полезности, и с тех пор не видно самого двоичного алфавита - он где-то в проводах только остался.

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

Но факт налицо, что ту мысль, которую я пытался передать, опять передать не удалось. Причём по той причине, что её на принимающей стороне просто отказались принять к рассмотрению. Это не ново, но удивлять не перестаёт.

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

Вы все сравниваете с С++ ))) Для многоядерных архитектур он отстой.

А способности Erlang полезно повторить в Обероне как раз для многоядерных архитектур, хотя бы чтобы проверить - вдруг раскроются новые возможности ...

"Особенность потоков эрланг в том, что они легковесные. Это значит, что они:

быстро стартуют и завершаются;
быстро переключаются;
потребляют мало памяти.
Новый поток создается и стартует за 3-5 микросекунд. На старте он получает 2,5Кб памяти (стек, куча и служебная информация о потоке).

Виртуальная машина имеет лимит на число потоков, по умолчанию это 262,144 (218). Лимит можно увеличить до 134,217,727 (227"


https://search.proquest.com/results/E89 ... ntid=30386

Можете "на пальцах" и "в двух словах", применительно к архитектуре х86 проиллюстрировать, откуда такое счастие образовалось?
Или-таки потоки в Эрланге - "не совсем" именно потоки (в рамках привычных представлений использования аппаратных средств х86 для многозадачности?