OberonCore

Давайте, я просуммирую: как было высказано ранее, благодаря данному инструменту(RSA) можно устранить до 20% багов в автоматическом режиме. Следовательно, это баги, алгоритм внесения(и следовательно, выявления) которых уже известен. Возможно(с большой степенью вероятности), их основой являются вольности, которые позволяют высоко-низко-уровневые языки (они есть, и общеизвестны, и обсуждались тысячу и один раз), и которые неприсущи оберону по определению. Конечно, у оберона есть некие опасные моменты, типа SYSTEM(необязательного к использованию, заметьте), или Вашего примера с мегапроцедурами в одну строчку(честно: я такое увидел впервые, а ещё, процедуры кажется вычисляли тригонометрические функции, поэтому их значение в общем контексте проблемы явно преувеличено), как факт. Кто то может ещё что-то добавить, упрекуть меня или ещё что-то, если поставит себе такую цель. Я не считаю, что от этого мои аргументы, которые есть факт, становятся менее весомыми. В итоге: если считать "индусским" код, который содержит все возможные языковые "фокусы"(которые не опциональны, а предоставлены "как есть") то мы имеем налицо отсутствие этих "фокусов" в "индусском" оберон-коде. Замечу, что всё это - уровень языка. Не проектирования. Если индус в силу низкой квалификации не может разумом отследить все подводные камни языка, то в обероне эта задача не стоит как таковая, потому, что Вирт подумал за индуса . Получаем: на обероне индусский код с большой вероятностью невозможен(замечу ещё раз: на уровне языка).
Обоснуйте! Не менее необоснованное, чем ваше заявление о панацее в виде ФП. Не передёргивайте, пожалуйста. Вы формалист, а это наглядный пример вашего формализма.

Раз пошёл такой разговор...

Я высказался в том плане, что ЯП задаёт некую реальность. Сознание программиста работает в этой реальности. Чем фантастичнее возможности в такой реальности, тем легче такому сознанию делать "ненормальные" вещи (планка легальности действий занижена до плинтуса). Потому что эта ненормальность задаётся самой реальностью. В такой реальности "индусский код" является совершенно нормальным. Хотя продвинутым гражданам кажется обратное.

Оберон же резко обрезает фантастичность реальности (число - это число и не более того), поэтому ненормальность кода должна сильно снижаться.

Естественно, это некая условная культурологическая интерпретация, не больше. Чтобы всерьёз и ответственно разговаривать о таких вещах, необходима обоснованная метрология языковой реальности. Нужна мерялка, с помощью которой можно будет адекватно сказать: этот язык (к примеру) имеет "коэффициент условной фантастичности" 1, а этот - 2.

Вот о чём я говорил.

Потом, Geniepro, приходите Вы и начинаете говорить про необоснованность заявлений Вы, вообще, о чём?

Очень просто: в ФП/ДП эта операция является нелегальной.


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

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

Предположим, есть задача -- иметь некий способ производить логически одинаковое действие над совершенно разными сущностями, будь то число, булево значение, символ, строка, массив, список, запись, таблица база данных, объект, расписание поездов, траектория полёта космического корабля по просторам Большого Театра, всё что угодно, в-общем.

Лично я знаю несколько способов, как делать эти действия. Перечислю их:

1) Путь ООП: создаём иерархию типов, в которой корневой тип (класс Object, например) имеет метод ToString() (в данном конкретном обсуждении).
Этот подход является сейчас очень распространённым в мэйнстриме (.NET, Java). Тем не менее, это довольно старый подход, известный ещё во времена Смоллтока, а может быть даже и Симулы-67 (не имею точной информации, но там это было бы вполне возможно).
Здесь всё является объектом -- и космический корабль, и простой байт.
x.ToString() -- образец перегрузочного полиморфизма в стиле ООП.

2) Путь современного ФП: создаём класс типов Show с методом show (упрощённо можно это назвать интерфейсом как в Яве, С# или там в Дельфях, так что это вполне может показаться допустимым способом и для ООП).
Для каждого нужного типа создаём экземпляр этого класса Show (а вот тут уже появляется различие между классами типов и интерфейсами. Экземпляры классов типов не привязаны к объявлению самих этих типов, в отличии от интерфейсов, т.е. в новые классы типов можно включать старые типы без их переписывания и вапще даже без доступа к их исходникам).
show x -- образец перегрузочного полиморфизма в стиле ФП.

3) Путь Ады и С++: создаём перегруженные функции/процедуры, которые не имеют никакой систематизации и внутренней логики и объединены лишь общим именем, но могут иметь совершенно разные параметры, в том числе и разное количество параметров...
Довольно гибкий способ, но, на мой взгляд, не самый безопасный и удобный в долговременной перспективе, о которой так пекутся оберонщики...
С одной стороны, он позволяет больше свободы, по сравнению с классами типов или иерархией типов, с другой стороны, как-то ощущается потеря контроля над этими функциями, не хватает некоторой дисциплины... :о(

(На самом деле, в том же C# объединены и первый, и третий способы.)

4) Ну, и наконец, путь таких языков, как Си, Паскаль, Модула-2...
Создаём зиллион разных функций для всех нужных нам типов, все они имеют разные имена вроде intToString, longToString, byteToString, ulongToString, boolToString, charToString, record1ToString, record2ToString, typeXXXToString, и т.д. и т.п.

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

Позволю себе некоторые выводы.

Для меня лично нет особой разницы при использовании первого или второго способа, в общем-то, между x.ToString() и show x разница лишь синтаксическая, но вот при создании этих перегруженных функций мне больше нравится второй способ (хотя у него есть и свои достоинства, и свои недостатки по сравнению с первым).
Общее достоинство первых двух способов -- экономия понятий, которыми придётся оперировать пользователям этих функций -- для одного и того же действия одно и то же название.

Третий способ мне не нравится -- как-то не очень надёжным мне он кажется...

Четвёртый способ, особенно в исполнении оберонов, мне кажется абсолютно неприемлемым.

Оберонщики скажут -- нужно типа знать меру, диалектику природы уважать и всё такое, но по-моему, это просто лукавство.
Будьте последовательными, чёрт возьми! Что за такая вечная двойная логика, двойные стандарты? Не верю я вам!!! :-х

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

Опять же, см. выше - исключаем из языка все легальные возможности, не оставляя программисту ничего. Путь ФП

Сложить два числа и сложить два расписания поездов, или две траектории ракеты - это семантически одинаковое действие? Это действия лежат в рамках одной логики? Или у них только обозначение "+" совпадает? Сложить два скаляра и сложить два вектора - это одно и то же? Потрясающе.

P.S. Думаю, будет нелишним напомнить, что тема касается ЯП как средства развития культуры программирования. Оберон здесь приведён в качестве примера замечательного средства, предположительно позволяющего не тратиться на инструменты типа IBM'овского RSA. Рассуждения про двойные стандарты "оберонщегов" тут вообще не в струю, типичный троллинг.

"Кажется", "не нравится" и т.д. Не очень убедительно, имхо.
Вы, по инерции, подходы к проектированию из первых 3-х примеров, переносите, не думая, на оберон. типа "один метод чтобы сделать всё возможное преобразование ОБЪЕКТ=>СТРОКА". Я лично выбрал бы другой подход. Использовать готовые методы перевода "базовых" типов в строку, которые я бы скомпоновал(собрал из компонентов) в нужном мне порядке(в зиллионах раличных комбинаций, для зиллионов различных ОБЪЕКТОВ). Чем плох этот подход? О нём вы умолчали.

P.S. При таком подходе разделение сущностей на "базовые" и "составные" разумно и оправдано.

Нельзя ли с этого места поподробнее? Сразу возникает несколько вопросов.

1. Что такое "эргономичный язык программирования"?
2. Какие проблемы решает "эргономичность ЯП", и как?
3. Почему методы работы с сущностями должны быть единообразными, ведь семантика сущностей (а значит, и работа с ними) может значительно различаться?
4. Как единообразие влияет на эргономичность, и влияет ли вообще?

Мне кажется, эти вопросы лежат близко к теме той самой "мерялки", с помощью которой можно измерять связку "человек+ЯП".

Эта мысль была понятна ещё до того, как здесь наскучило Vlad-у. С байтом не обращаются как с объектом, потому что это не объект в смысле абстракций ООП. Однако, это не значит, что он не может быть объектом в других абстракциях, просто тогда нужно забыть и про ООП-шные методы : ).Объект Byte существовать-то может, но только есть проблемки. Вот представьте себе простор огромного поля гигабайтной оперативной памяти. Где-то в её недрах есть один маленький байт. Если Вы хотите, чтобы этот байт был объектом в смысле ООП и умел делать toString(), то добавьте к этому байту, скажем, ещё 70 байт (кода). После этого, объект сможет себя напечатать. Но этого недостаточно: если мы имеем дело с объектом, то неплохо бы использовать инкапсляцию, скрыв прямое обращение к данным. Чтение и запись значения - это ещё по 7 - 10 байт. Операция сравнения - ещё примерно 10 байт. А ведь, человек, выбирая байт, надеялся, что память экономит : ). "Ну так гигабайт памяти! Чего там экономить!?" Но её-то, оказывается уже и нет: числа не так уж и редко используются.Всё там последовательно. Если использовать объекты, то будет напряг с ресурсами. Поэтому, большинство ОО-языков не особо "чистые": позволяют обращаться к памяти напрямую (писать числа) и давать прямые указания процессору (вычислять операции). То есть, программа перестаёт быть просто структурой взаимодействующих объектов. Ещё и процессор появляется. Это увеличивает производительность, но лишает возможности использовать toString() и быть при этом последовательными. Да, неплохо бы забыть о процессоре, как и говорил Alexey_Donskoy, и при этом ничего (или почти ничего) не терять. Но для этого нужны другие идеи у трансляторописателей, а возможно, ещё и совсем другие идеи у проектировщиков процессоров (и остальных микросхем). Единообразие не помешает, но i.toString() ничего общего с object.toString() не имеет.

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

Эргономичный - значит эргономичный. К словарю, что ли, отсылать? Требующий минимума умственных и моторных усилий в процессе работы.

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

Я бы предложил такой пример.

Абстрактная постановка задачи:
Дано: две информационных сущности - А и Б.
Задача: выполнить операцию В над А в контексте Б.

Конкретизация постановки: А - число, Б - строка, В = "преобразовать А в Б".

Решение №1 (объектное):
- берём сущность А (другими словами, выбираем клиента и смотрим его интерфейс);
- задаём контекст Б (другими словами, выбираем сервер и смотрим его интерфейс);
- ищем пересечение интерфейсов и смотрим, насколько оно соответствует операции В;
- если не найдено, модифицируем интерфейс клиента А для поддержки операции В в контексте Б;
- выполняем операцию В.
Прошу обратить внимание - решение дословно соответствует постановке задачи!

Прошу обратить внимание - на 100% подходящих инструментов, в мэйнстриме или нет - я не знаю!
Ближе всего, вероятно Smalltalk, где всё, включая числа, есть объекты. Но увы, я с ним не знаком подробно, гарантировать не могу. Однако ж отнести Смоллток к "мэйнстриму" вряд ли у кого язык повернётся

Решение №2 (назовём его "НЕмэйнстримовое"):
если Б - атомарный тип то
если А - атомарный тип то
перелопачиваем гору документации в поисках (ведь даже простейшие inttostr во всех вариантах в голове держеть нереально и нецелесообразно)
если не найдено то
ищем подходящие функции в интернете...
...
иначе
ищем подходящий метод в интерфейсе А
если не найден то...
иначе
переходим к алгоритму Решения №1

Я ответил на Ваш вопрос об эргономике, семантике и иже с ними?

Ведь передёргиваете! Как любил говорить небезызвестный YK, "подмена тезиса!". Вместо абстракции информационного содержания задачи Вы всё тыкаете в конкретную кривую реализацию "мэйнстрима". Да кто бы спорил, что она кривая! Вот если б хотя бы относительно прямую (Смоллток) попробовали, тогда ещё было бы интересно. Но мы ж не об этом, а о сути задачи!

Я не Паронджанов, я не хочу писать многословно и вкрадчиво, хотите понимать - понимайте!
Обратите внимание, что на любом уровне инструмент должен давать Вам не какой-то реальный код, а представление (view) информационной сути задачи в контексте текущего уровня. Если для решения задачи мне удобно рассматривать байт как объект с интерфейсом, инструмент должен мне обеспечить такое представление! Но из этого вовсе не следует, что на других уровнях будет иметь место та же сущность и в той же ипостаси! Ниоткуда не следует, что в ОЗУ будут сидеть тучи виртуальных таблиц на каждый байт и легионы виртуальных функций будут содержаться в экзешнике и гоняться друг за другом во время исполнения!

Хотя, видимо, следует Из Вашего понимания софтостроения, каковое (понимание) представляет собой стереотипную схему нынешнего состояния "мэйнстрима".

То, что от этой схемы надо уходить, понятно всем. Но Вы путаете парадигму (ну пусть методологию) с конкретной реализацией, а это не есть гут!

Вот Вы и подтвердили мои слова о Вашем понимании...
Поймите же, что суть задачи - выполнить операцию В над сущностью А в контексте Б. Всё! Ваши i и object есть частные случаи, возможные представления сущности А, и между ними НЕТ РАЗНИЦЫ в контексте задачи!

Ваша ошибка в том, что, рассуждая о надёжности Оберона и аналогичных вопросах, Вы сводите всё многообразие многомерности задачи на один единственный уровень ЯП, что методически неверно!

При этом Вы, с одной стороны, теряете исполнителя (я ж приводил пример с вещественной арифметикой), а с другой стороны, ставите сами себе непреодолимые пределы в части высокоуровневых абстракций.

Ну то же самое - плоское стереотипное мышление, Вы уж меня извините...
Посмотрите внимательно на свой тезис. Всё правильно. Вы компонуете и т.п. ... Для чего? Для того, чтобы НА ВЕРХНЕМ УРОВНЕ пользователь Вашего продукта ВИДЕЛ ЕГО В КАЧЕСТВЕ АТОМАРНОГО! И ЧТОБЫ С НИМ БЫЛО ПРОСТО РАБОТАТЬ!

Теперь переверните свой тезис. Почему для Вас сущности А и Б являются атомарными? ПОТОМУ ЧТО КТО-ТО ДО ВАС ПОЗАБОТИЛСЯ ОБ ЭТОМ И ИНКАПСУЛИРОВАЛ все свои проблемы ВНУТРИ сущностей.

Когда Вы пишете "var x,y,z:real; x:=3.14; y:=x*z..." - почему Вы не хотите задуматься о куче реально вызываемого кода?

Потому что Вы ПУТАЕТЕ информационное ПРЕДСТАВЛЕНИЕ (View) сущности, с которым Вы работаете, с РЕАЛЬНОСТЬЮ!

А в реальности нет даже байтов, между прочим, не то что чисел! Есть транзисторы и токи... А если ещё на уровень глубже, то никаких там транзисторов, а структурированные кучи атомов с электронными облаками...

Поэтому тезис "инструмент должен обеспечивать адекватное представление на текущем уровне" отнюдь никак не пересекается с тезисами типа "я думаю, надо обеспечить компромисс между семантикой А и Б в реализации О".

Решая задачу - решайте задачу! Создавайте инструмент для её решения, а не спорьте о преимуществах и недостатках моделей (ООП vs ФП, ...) и их реализаций (С# vs Оберон и иже с ними).

Можно определить задачу перевода а в б как "превращение". Потому что а и б элементы разных пространств A и Б соответственно. В общем случае - непересекающихся. Поэтому перевод одной сущности в другую невозможен ни в А ни в Б. Поэтому логично, что должно сущестовать пространство преобразователя которое должно включать в себя пространства А и Б. Конкретизируя - базовые типы не могут сами себя переводить друг в друга. Для этого нужен "фокусник". Которого даёт среда разработки, или вы сами его создаёте.
Куда проще? Куда эргономичнее? Хотя конечно, это субъективно.


Позвольте Вам указать на то, что решение 1 - чисто абстрактное, а решение 2 - конкретизировано решением задачи в немейнстримном языке программирования. Абстрактное решение я привёл выше. Жертвование логичностью(она не может быть субъективной, не надо спрашивать "для кого?") в угоду эргономике я считаю неприемлемым. Хотите эргономичности - перейдите на следующий уровень, следующий слой сущностей. Пишите инструменты для этого.

Вы подозреваете меня в незнании всего этого?
Зачем, зачем мне думать про токи? Про кучу кода? Про перфокарты с дЫрками? Кажется, чтобы не думать обо всём этом, были созданы ЯП. ЯП Оберон(как и другие) изолирует меня от всего этого, не заставляет об этом думать. Это то, что вы называете слоем представления. НО! Атомарные типы в этом языке обеспечивают полную базу для создания сколь угодно сложных структур. Да ещё и соответствуют математическим представлениям. Где число - это число, а сложение - это сложение. Этим объясняется плоскость моего мышления? Мне дали базовый уровень, а я уже сам сделаю на его основе всё, что угодно. Я решаю. Споры для того, чтобы узнать, а правильно ли реализован инструмент, ведь его реализация определяет способы, и результат моего решения.

Рабяты, давайте договоримся об основах.

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

Особливо интересно также, что значит, что SQL - "полный по Тьюрингу язык за счет рекурсивных функций". Получается, он опять же - не декларативный?

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


Опять же - что такое "психологическая напряжённость"? Так ли необходимо её уменьшение, ведь, например, когда человек пишет "на подъёме", то ему пишется легко - а напряжённость ведь при этом есть. В чём измеряется производительность труда, в строчках кода? Ну и так далее.

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


Я понял Ваш пример.
В решении №1, все операции, доступные для объекта, подтаскиваются к самому объекту. Получается единообразный способ поиска контекстов и операций, т.к. исходной точкой поиска является сам объект. Во втором случае, операции лежат отдельно, и откуда начинать искать - непонятно.
Когда я начинал осваивать BlackBox, то по второму пункту у меня была масса критики Теперь критики нет. Я пытался понять, что произошло, и пришёл к такому выводу. Т.к. разработчики BB максимально упростили среду, то многие вещи достигаются т.н. соглашениями. Например, документация лежит в каталоге с определённым именем, названия модулей имеют определённую структуру и т.п. Когда я "въехал", что тут меньше автоматизации, а больше соглашений; увидел все эти самые соглашения, то перестал испытывать проблемы. Прошу заметить, я не утверждаю, что такой способ лучше. Он просто другой, и апеллирует к здравому смыслу разработчика гораздо больше, чем другие инструменты.
Что же касается первого решения, то оно нормально выводится на уровень соглашений. Например, модуль работы со строками имеет название Strings. Конечно, приходится придерживаться корпоративных правил разработки.

И оно должно таким оставаться! То есть конкретизация на должна проходить через дебри новых, лишних, сущностей, вносимых неадекватностью инструмента (например, ЯП).

Однозначно. "Логичность" (точнее, когнитивная "прозрачность") модели - одна из важнейших составляющих эргономики! Однако Вы жертвуете этой логичностью (вводите лишние сущности) - для чего? В угоду имеющемуся инструменту?

Безусловно. Только есть такой тонкий момент:
- когда мы пишем "a:=b+c", мы работаем в "математическом" контексте; а когда пишем "s:=IntToStr(i)", мы находимся в другом контексте (строковых операций);
- с одной стороны, ниоткуда не следует, что все сущности в этих контекстах должны выглядеть одинаково; поэтому мы воспринимаем без напряжения замену абстрактной модели "b c + a !" (не удержался, ввернул Форт ) на "математическую";
- контекст строковых операций выглядит хуже, он сильно разнится в разных инструментах;
- с другой стороны, единообразие действий с сущностями модели удобно (не допустимых операций с точки зрения ЯП, а именно алгоритм решения информационных задач человеком).

Вот такие противоречивые требования. Большинство тут же плюнет, скажет "нет серебряных пуль" и пойдёт решать (неэффективно) свои задачи (криво сформулированные) на своём инструменте (кривом по определению).

Вы только не обижайтесь, но у нас несколько разные задачи С моей точки зрения ваши споры похожи на:
- а моя песочница лучше!
- нет, это у тебя совок кривой!
- ой, на нас мэйнстрим на тракторе едет!
- ничего, сейчас мы его закопаем!

А вообще-то на этом месте сад должен расти...

Сильно ли я Вас огорчу, если признаюсь, что не знаю ответа на эти вопросы? Если б знал, не тусовался бы в форумах, а написал бы кучу умных книг, где предложил новую супермодель, итерационно приближенную к "серебряным пулям"

Давайте рассуждать. Будем смотреть в корень. Что тут есть основное? Задача и её решение.
Что есть код? Инструмент для решения задачи.
Что есть программирование? Методология решения задачи с применением инструмента "код".

Поэтому меня много лет назад привлекла идея Паронджанова про абстрагирование от кода. Однако, уходя от Сциллы, мы попадаем на Харибду, абстрагируясь от исполнителя. Конечно, атомарные (базовые) типы в контексте данного обсуждения есть вполне разумная уступка на пути поиска компромисса.

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

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

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

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

У Вас нарушение в логике. Вы сравниваете абстрактное решение(1) и решение на ЯП(2). Почему бы не сравнить два абстрактных решения, и только потом переходить на уровень ЯП?
А как вы определили что они лишние? Я ведь не сферического коня в вакууме обсуждаю. Нужно же на каком то этапе перейти к конкретике. Вы призываете всё рассматривать, как объекты, с единообразным поведением. Вот это клиент, вот это сервер, вот это активность клиента в контексте сервера. А что за клиент, какая у него специфика, это не учитывается вашей моделью. Физического смысла нет.Инструмент предоставляет минимальный базис, основу для всего. А целое с методом, это уже не базис. Кто-то подумал за меня и определил, что так лучше? Увольте. А зачем контекст? А число есть в строковом контексте? Или наоборот? собственно, перевод числа в строку может считаться строковой операцией(аналогично конкатенации, например)?Форт - это зря, имхо. Я вот с усилием разобрал что означает запись. А кто-то вообще не поймёт. Это важно в контексте беседы? А математическую модель вроде все умеют распознавать и обрабатывать.Хочется процЫтировать: "Мерялки то нет". Абстрактно "криво" или относительно чего-то? Я стараюсь по мере возможности говорить не опираясь на конкретику реализации языка, а только приводя её как пример.

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

Давайте сравним два абстрактных решения, если это возможно (я второго абстрактного решения не видел, кроме "компоновки" - но это ведь не того уровня абстракция)! Итак, Ваш ход.

Когда я пишу "x:=3.14", есть тут физический смысл или же нет? По-моему, так нет! Есть смысл логический (информационный, в контексте модели "плавающая арифметика"). А как оно ложится на физический уровень, мы с Вами и знать не должны!

Позвольте также напомнить, что в теме "Что такое алгоритм" никто не захотел опускаться до "физического" уровня - уровня исполнителя. Я не понимаю, чего Вы (здешнее Оберон-сообщество) хотите тогда на самом деле?

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

Можно ещё смотреть с другой стороны: код - это текст, а программирование - создание текста. Программист-"писатель" в тексте "шифрует" решение задачи. И есть ещё "читатель", тот - кто должен прочесть текст. Отсюда, чем яснее\понятнее текст, тем лучше. А как он может быть ясным? Только если использует общеупотребительные понятия и внятные правила, по которым он составлен.
Исходя из этого, "показатели эргономичности" оберона должны быть очень высокими.

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


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