Поворот не туда (про ООП, Форт и языки)

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

Как глоток свежего воздуха было знакомство с парадигмой в языке Эрланг.
В сущности много от Лиспа и Форта. Вместо плотных упаковок - модульность.
Я считаю, что Форт просто не доделан как язык.Но доделывать его в стиле ООП - это тупик.
Надо добавить больше контроля за корректностью сложения кубиков и удобные соединения.
И чтобы это не превратилось в многословную каку вроде javascript.
RPL попытался и не справился - язык не читабелен, конструкции не слишком удобны.
Думаю надо избавляться от обратной нотации, но сохранить саму идею цепочки операций над общим стеком.Может быть развернуть в префиксную???

Видел я попытки вввести в Форт структуры и всякие генерации префиксов get/set - пользоваться неудобно, выглядит как приделанное сбоку. Надо чтобы иерархические структуру сразу были частью языка как в Си. А какие уродские строки в Форте, этим же невозможно пользоваться. В Лиспе парсер не сильно сложнее, а строки нормальные и ещё куча плюшек вроде макросов ридера.

В общем в калькуляторном плане важно чтобы можно было программу набирать нажатиями клавиш, а символьный ввод был бы опциональным, должны быть нормальные структуры и строки. Эти вопросы почти решил RPL, совсем немного не хватило до счастья.

Forums: 

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

На входном языке МК-161 (ЯМК) невозможно было даже ввести своё имя с клавиатуры. Сейчас появились такие мощные слова, как ." и TYPE, KEY и ACCEPT.

Мы даже перескочили этап меток — и от адресов на МК-52/МК-161 перешли сразу к структурным IF и циклам прямо «на борту» калькулятора. Вместо номеров регистров теперь имена переменных, вместо адресов подпрограмм — имена слов. Метки, правда, в системе кросс-программирования МК-161 с компьютера появились.

Всё это удалось сделать при сохранении относительной совместимости с советскими ПМК. Конечно, от ограничения стека на 4 элемента пришлось избавиться — прямо по классику:

— Ну и колымага! — отсмеявшись, сказал Коршунов. — Но зачем все эти дурацкие ограничители? На ускорения, на расход, на время маневра? Учтите — я все это выброшу.

Также появилась вторая относительная совместимость, с Фортом — и первая фортовская программа (редактор EDIT) уже работает на МК-161.

Сейчас основной тормоз — то, что Каллисто работает поверх интерпретируемого входного языка. Перенос её в камень, особенно без документации от разработчика по периферии — серьёзный труд. Но уже есть референсная реализация, к чему стремиться. Одновременно с этим попробуем улучшить ситуацию с обработкой строк. В стандарте Форт-2012 есть некоторые интересные предложения. Но работы и без того много.

Главный же плюс в гибкости Форта. На Каллисто каждый может подстраивать язык под себя. Можно экспериментировать хоть со строками, хоть с префиксной записью. Есть возможность начать разработку библиотек — графических, музыкальных, связь и т.п. Нужен хороший редактор, заточенный под особенности калькулятора — взамен общефортовскому EDIT. Наиболее интересные и популярные предложения попробуем включить в Каллисто-2.

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

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

В ООП действительно есть проблемы. Никлаус Вирт во время своих лекций в России агрессивно атаковал ООП и конкретно C++, как антинаучный и шарлатанский подход.

Профессор учит, что в программировании есть модульность (которую он развил в Модуле-2), есть функции-члены и иерархия типов (которые он добавил в Обероне). «Полиморфизм, инкапсуляция и наследование» это безграмотная попытка соединить принципиально разные подходы (как для примера кирпич, интеграл и фрикадельки — AtH), вредная для проектирования сложных систем и годная разве что для вышибания денег из необразованных спонсоров.

К слову, учёный агрессивно относится к «открытым исходникам». По науке у каждого модуля должна быть открытая часть (интерфейс) и закрытая часть (реализация). Если для работы требуется залезать в исходники чужого модуля, значит его интерфейс погано спроектирован. По хорошему модули с одинаковым интерфейсом должны быть взаимозаменяемы — общий проект не должен зависеть, какая у какого модуля реализация.

То, что закрытая часть модуля содержит свои собственные объявления (недоступные из других модулей) никак не связано с разработкой системы типов. Другими словами, «инкапсуляция» это попытка использовать модульность в неверном месте, вызванная непониманием модульного программирования — которое является логичным развитием структурного программирования.

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

Университетское образование должно уделять внимание научным, то есть передаваемым знанием (что реально выучить за семестр), а C++ это нечто вроде шаманства и печального набора костылей для поддержки кода, которого слишком дорого писать заново.

Вообще в языках типа С++ так много всяких конструкций и их особенностей, что становится почти невозможным автоматический анализ кода и его преобразования. Я сейчас портирую код с C# на C++, но желания анализировать код и генерировать костыли автоматически как то не появляется. В других более "однородных" языках вроде Лиспа и того же Форта возможно поручить такое портирование самому исходному языку.

За это я не люблю С++, костылей не просто много, они ещё торчат ощетинившись во все стороны :-( Для калькулятора подобные языки, куда входит и Питон, строго противопоказаны, ибо новичку написать по быстрому может быть будет легче (и то за компьютером), но вписать это в эко систему калькулятора - вряд ли! Все механизмы сцепления и взаимодействия между частями программ в "больших языках" какие то слишком специальные, не однородные как в RPL калькуляторах. Например сравните потоки Unix и COM/ActiveX. В калькуляторах не нужен монстр COM/ActiveX, там хватает и стека в качества интерфейса. Возможно чтобы снизить бардак и произвол нужна какая то дисциплина (механизмы модульности и изоляции реализации), но не такие монстры уж точно.

Не знаю, примеры HP Prime и TI NSpire не кажутся правильными. В то же время RPL кривоват как язык, например в нём ужасное представлены локальные переменные, очень плохо с функциональным подходом, нет из коробки фильтров последовательностей в функциональном стиле, которые очень удобно решают типовые задачи. Нужны конструкции для перечислений типа сопрограмм в Lua и т.п. Думается в этой области до совершенства ещё ОЧЕНЬ далеко.

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

Не совсем так, Вирт плохо относится к Си++, т.к. этот язык проектировался "снизу-вверх" и в итоге требует высокий порог для квалификации программиста и внутреннюю стандартизацию для эффективного и безопасного использования в коллективных проектах.

Про ООП, как парадигму, высказывания Вирта мне неизвестны, т.к. этот подход был реализован еще в 1960-х годах (см. Симула-67), когда еще не было ни Паскаля, ни Си, не говоря уже о Си++.

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

В Обероне-2 есть элементы ООП, однако они недоделаны. Например, конструктор не выделен явно, как элемент языка, что исключает динамическое создание объектов по ссылкам на его тип.

Причина критики C++ немного другая. Для программирования на C++ приходится изучать много мусора, который потребовался лишь из-за «стихийного», плохо продуманного проектирования языка. Непродуктивный расход времени.

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

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

Вирт приводил аналогию с единой нотной записью, которой пользуются музыканты разных стран, говорящие на разных языках.

Оберон-2 не мог не проектироваться без учета ООП. Об этом в частности говорят работы его создателей: H.Mössenböck. Object-Oriented Programming in Oberon-2

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

Просто невозможно поблагодарить всех тех, кто так или иначе подпитывал своими идеями то, что теперь называется Oberon. Большинство идей пришло от использования и изучения существующих языков, таких как Modula-2, Ada, Smalltalk и Cedar, которые часто предостерегали нас от того, как не надо делать.

Никлаус Вирт

Ученики Вирта не так фанатичны, как сам профессор, и идут на компромиссы — чтобы их понимали окружающие, воспитанные в мире, где есть ООП. :-)

Например, коммерчески успешен Компонентный Паскаль — так был назван диалект Оберона, именно из коммерческих соображений. Паскаля в нём не больше, чем ООП в Оберон.

Сам Вирт учит, что ООП это путь в никуда. Неудачная попытка осмыслить опыт SmallTalk. Которая помогла «освоить» большие денежные средства, но привела к огромной бесполезной растрате рабочего времени программистов, поясняя происходящее на примере «распухших» языков C++ и Java.

В приведённой книге раскрывается, как популярная маркетинговая чепуха (ООП) может быть реализована при научном подходе к программированию (Оберон). Чтобы выжить, программистам приходится учитывать рыночную ситуацию — а учителям преподавать то, на что нынче спрос.

Вирт же может позволить себе говорить прямо о своём отношении к ООП, призывая инертное человечество к уму-разуму. Некоторые даже прислушиваются. Особенно те, у кого нет огромных запасов библиотечного кода на Си, который надо поддерживать даже в XXI веке — ради такой задачи можно смириться даже с убожеством C++.

Цитата оттуда же, ясно показывающая реализацию ООП в Обероне.

...Описание расширенных записей, проба типа и охранник типа - это единственные дополнительные средства, введенные в данном контексте. Более всестороннее обсуждение данного вопроса можно найти в работе [Wir88a]. Концепция эта весьма схожа с понятием класса, используемым в языках Simula-67 [Bir73], Smalltalk [GoR83], Object Pascal [Tes85], C++ [Str86] и других, где говорят, что свойства базового класса наследуются производными классами. Механизм классов предусматривает, что все процедуры, применимые к объектам класса, будут определены вместе с описанием данных.

и там же в продолжении

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

Это не догма, реализация partial class в Сишарпе или менее безопасные class helper в Object/Free Pascal реализуют вышеуказанное.

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

Как агрессивно! Святое задели, сжечь еретика. Ж-) Не впадайте в «синдром утёнка».

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

«Религия церкви имени Вирта» это европейская научная школа, не связанная с теми агрессивными коммерсантами, кто выдвинул убогую концепцию ООП и пытается натянуть её на всё, что было до них и развивается независимо, без их участия.

Не хотите, не обсуждайте, конечно. Сохраняйте верность C++ и Java, там крутятся большие деньги. :-) Оберон предлагает другой путь, в том числе для того же самого расширения типов, которое вам стало известно через лагерь сторонников ООП.

P.S. C# появился значительно позже Оберона и даже того текста проф. Вирта (1990 год), который вы пытаетесь опровергнуть. Оберон это 1989 год, а ваш C# опубликован в 2002 году, FreePascal в 1997 году. Создатели ООП языков, например Java (1995 год), изучали работы Вирта и воплотили, что поняли.

Речь о том, что ООП это винегрет или даже помойка, куда навалено всё, до чего «владеющие темой на практике» смогли дотянуться. «Церковь имени Вирта» рекомендует тщательно отобранный, лаконичный набор инструментов — достаточный для практики, вплоть до реализации операционных систем и компиляторов.

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

Недостатки ООП известны, их никто не отрицает. Одно несоответствие реляционной и объектной моделей (impedance mismatch) многого стоит. Однако то, что вы упоминаете не является никаким решением, оно лишь возвращает обратно в 1960-70-е с надеждой найти там что-нибудь забытое. Идеальные области для ООП по-прежнему - имитационное моделирование и графические интерфейсы, откуда оно и выросло. Для остального будут допущения. Судя по нынешнему охвату технологией, эти допущения вполне приемлемы для всех.

Ниша функциональных языков небольшая. Про декларативные подходы я уже писал ниже.

Модель ООП динамических событий в системе заменили на статическое связывание в C++ не в этом ли суть последующих "глобальных" костылей ООП?
Хотя и с динамической моделью событие->реакция есть свой гемморой.

P.S. Сам принцип ООП мне не нравится большим числом "писанины" (даже в моделях ООП от Форт) для несложных вещей. И да иерархия ООП это почти "железобетон" В SPF 2.5 под ДОС был написан Черезовым мультиоконный редактор FEDN в Smalltalk парадигме. Некоторое время (по молодости более 20ти лет назад :) пытался улучшить этот код (и даже получил свой работоспособный вариант), но сам нетривиальный процесс отладки кода и преследующие утечки памяти поставили "крест" на этих экспериментах. Да и вместо ДОС появилась Виндовс. Хотя этот опыт был интересен и даже где то сохранились исходники всего этого безобразия (микрооконной системы)

Крис Касперски "Языки, которые мы потеряли"
https://www.evilfingers.com/publications/research_RU/oldnewlang.pdf
Вроде в этой статье и Форт упоминался, но здесь этого упоминания не нашёл.

Не надо отождествлять Си++ с ООП, хотя и там динамики хватает (позднее связывание, интерфейсы). В современных реализациях динамики навалом, начиная от reflection в первых версиях C# до динамических вызовов в 4-й версии платформы.

Выбор между статикой и динамикой опять таки не имеет прямого отношения к ООП, это выбор проектировщика, компромисс между гибкостью и строгостью. Этот выбор есть даже в SQL.

Все программисты думают что C++ поддерживает ООП, кроме автора ООП
https://habrahabr.ru/post/307354/

Автоцитата из рецензии на книжку по Симуле-67, которая была задолго до "автора ООП".

Хотел бы порекомендовать всем считающими себя программистами хотя бы бегло ознакомится с текстом книги, чтобы понимать, откуда растут все современные языки ООП. Чтобы отличать базовые концепты в чистом виде от "карго-культов", от выпестованной в религиозных войнах шелухи и от "синтаксического сахара", которым они обильно посыпаны, но который не привносит новизны по сравнению с объектно-ориентированным программированием образца 1967 года.

Вы правы, что в плане калькуляторных языков я предлагаю вернуться немного в прошлое, не тащить на карманное устройство эти уродские питоны и прочие ООП ужасы бездумно. Что же касается "чистого" ООП, увы - это оно как раз монстр из прошлого, а функциональное программирование настолько обогнало время, что только сейчас самые передовые из используемых в индустрии языков начали оттуда тащить всё что плохо лежит. Чистая функциональщина конечно не имеет широкой ниши, а вот общие моменты просочились уже везде. Я бы предложил заимствовать оттуда как можно больше, ибо хуже не получится, получается всегда лучше. И боже упаси ориентироваться на типовую обезьяну, такие ПМК уже есть, пускай обезьяны на них пишут свои HelloWorld. Они ведь не задумываются, почему на языке HP Prime нельзя написать нормальную систему компьютерной алгебры, а на RPL можно. Однако неоднократно говорил, что чистый Forth и RPL слишком неудобны и не являются идеалом ибо там не продуманы даже простейшие вещи (ни модульности нормальной и типов нормальных) и пользоваться неудобно.

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

Предлагаю не опираться на опыт миллиардов мух, так можно и г...на наесться :-)
Бейсик - убожество чуть менее чем полностью, мы же говорим не о калькуляторе для хомяков и чтобы пипл хавал, а о правильном православном труЪ ПМК, который мы можем сделать без оглядки на стоны умственно покалеченных бейсиком школьников. Собственно как Питон убожество во всех планах, так и его предок Бейсик (хотя для TI-89 неплохой диалект). Такой хоккей нам не нужен. Кроме того у нас может не быть мощности для вклячивания даже Бейсика, речь о низкопотребляющей серии.

Забавно, если любителям удастся произвести какой то свой калькулятор с Оберонами, Фортами и прочими Лиспами, чувствую попадём под такой же шквал критики как незабвенный СЕМИКО :-) Хотя у нас будет оправдание, мол для себя производили, кому не нравится, доделывайте (заметьте программирование железяки будут открытым в отличие от МК-161) или сделайте свою версию.

Я не поддерживаю использование Форта, Лиспа или тем более скриптового варианта Оберона в качестве языка для ПМК, хотя и не препятствую разгулу творчества. По этому поводу я уже высказывался, наиболее интересный вариант - Рапира, отечественное развитие Pop-2.

Оберон хотелось бы. Но у него тот же недостаток, что у Рапиры или Питона — он хорош для десктопов, а для маленького экранчика и ПМКшных клавиатур не идеален. Хотя, конечно, это язык следующего поколения по сравнению с Рапирой и Бейсиком.

Если под скриптом понимать интерпретируемость, то чистый Оберон будет сложно таким сделать. Он всё же под компиляцию заточен. Здесь лучшее решение это компилировать программы с диска в п-код, который будет исполняться прошивкой. Возможно, даже эмулировать RISC'процессоры Вирта.

Если обходиться без компиляции, во входной язык возможно внести какие-нибудь элементы Оберона. Но это будет не больше Оберон, чем RPL — Лисп.

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

RPL вообще не Лисп. Очень многое не от Лиспа. А жаль. Я тут много размышлял. RPL стал бы куда лучше, если перевести его в ПРЕфиксную форму для начала, арифметические формулы придумать как позволить сделать инфиксными, иерархические ссылки через инфиксные знаки,индексаторы через скобки, так реально удобнее. Но дальше заходить крайне не желательно, надо обеспечить всему синтаксическому сахару развернутое каноническое представление, как в Лиспе 'x означает (quote x), иначе пропадут все плюшки "программируемого языка программмирования".

Пример такого облагораживания http://naivedesign.com/ND1/ND1_Reference__RPL+.html, но не нравится, что это adhoc конструкции наплены как в Perl. А изменения как видно значительно повысили читаемость.

Хотя меня мало интересует синтаксис, пока он позволяет делать необходимое. А необходимо чтобы язык мог наращиваться и позволял создавать механизмы, а не только новые программные объекты.Пускай юзер лопоухий пишет высокоуровневые программы обработки данных и т.п., а разработчик сможет например добавлять команды системы компьютерной алгебры или встроенный язык запросов близкий к Прологу. Или нарисует себе Оберон мечты.

Проект уже довольно долго развмвается
http://factorcode.org/
Построен на идеях Forth и Лисп.
http://dropmefiles.com/zWKan 8th c синтаксическим сахаром и мультиплатформенный
(в платной версии может создавать автономные приложения)

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

Форт на Луркморье
http://lurkmore.to/Forth

грамматика языка в БНФ описывается одной строчкой ;

Выше я приводил грамматику Форта в РБНФ. Там далеко не одна строчка. Например, определение слова и операторы управления заслуживают по отдельному предложению (Р)БНФ.

Впрочем, исчерпывающую грамматику не получить. Она меняется в процессе программирования.

Одна из них
https://github.com/larsbrinkhoff/forth-metacompiler
а также кросс средства для F18 chip https://bitbucket.org/rohinmshah/forth-interpreter
http://zwizwa.be/staapl/staapl.html для PIC18

https://rosetta.alhur.es/

P.S. Но похоже не все языки добавлены из списка проекта RosettaCode, но Форт язык присутствует (вероятно GForth)

Характерный пример, выше я писал, что единственный отличительный момент ООП (где П=программирование, о П-проектировании говорить в это теме оказалось вообще бессмысленно) - наследование реализации, остальное есть и в других парадигмах. Дискуссия плавно переводится "оппонентом" на "в Обероне инкапсуляция реализована правильным образом" (а "правильным" - это как в Обероне, разумеется, самодоказыващееся утверждение). То что в Обероне по недосмотру или другому недоброму умыслу нет конструкторов, и потому объекты нельзя создать по динамической ссылке на тип - игнорируется. Типичная секта.

Уважаемый Сергей. Вы хотите вывести дискуссию на трюкачество — в сторону критериев, по которым языки ООП «побеждают» однозначно. Понятно, что в языках, стихийно складывающихся на производстве, разнообразия этих идущих от практики трюков больше. Точно также с помощью КБП или вычисляемого GOTO можно больше трюков наворотить, чем со структурными циклами Форта и Алгола.

Преимущества Оберона именно в его тщательно разработанных ограничениях (которые вам так хочется поставить ему в вину), позволяющих полностью описать универсальный язык на 30 страницах. Авторское описание Оберона редакции 2016 года занимает всего 17 страниц (англ., pdf).

Исходный текст первого компилятора Оберона занимал меньше 4000 строк — для сравнения, в Каллисто сейчас 4183 строки. А требовалось памяти ему менее 50 Кбайт. Компилятор Оберона для ARM 2007 года (англ., pdf) занимает 3120 строк, а последнее достижение это Оберон 2013 года для RISC-процессора на FPGA, 2900 строк и само-компиляция за 3 секунды (англ., pdf). Полный синтаксис Оберона-2 умещается на одной странице (33 предложения РБНФ). Сейчас держу в руках виртовский учебник по Оберону (англ., pdf) — в нём 320 страниц, включая упражнения, формальное описание языка, библиотеки и индекс.

Это и есть «правильным образом». «Секта Вирта» даёт объективные, проверяемые научные критерии превосходства языка, а «самодоказывающееся утверждение» как раз у сторонников ООП. Сколько строк занимает исходный код компилятора C++ ? Сколько предложений РБНФ займёт полный синтаксис C++, да и возможно ли вообще его формальное описание? Сколько сотен (уже тысяч!) страниц требуется для того, чтобы описать C++, обучить ему?

Не знаю, имеет ли смысл продолжение дискуссии. Здесь конфликт между разными критериями оценки. Мне важно, что Вирт тщательно отобрал небольшое работающее подмножество из всего мыслимого — и этих ограниченных средств хватает для построения коротких программ, эффективно решающих сложные задачи. Конструкторы, например, не включены в Оберон осознанно — если кому они потребуются, конструктор можно написать как обычную функцию-член и вызывать явно: NEW(p); p.Init(начальное_значение);

Вам же важно «создать объект по динамической ссылке на тип». Не пересматривать свои привычки и привыкать к новой дисциплине, а максимальная свобода в средствах. Ваше мнение уже сложилось и научный подход вам не интересен. Даже знать о нём не хочется.

Это как споры между владельцами айфонов и андроидов. Ты им говоришь — в моей экосистеме всё совместимо и работает из коробки. Они — а вот посмотри, сколько у меня настроек, сколько у меня гигагерц! Никто не спорит, что в Фортране можно запрограммировать хитрющее спагетти, с помощью его GOTO. Потребовались научные разработки, чтобы убедиться, что процедур, циклов и условного оператора Алгола для любых практических нужд достаточно и потребности в «спагетти» нет — к хорошему коду приводит отсутствие вредных привычек.

Завидное упорство в отождествлении ООП с Си++ и вера в то, что на виртовских языках нельзя наваять "лапши" (имею несколько сот тысяч строк кода такой "лапши" в депо под боком). Респект, не сем и остановимся.

Плохо программировать можно даже на хороших инструментах. «Настоящий программист напишет фортрановскую программу на любом языке.» © антипаскалевский манифест

Но всё же Оберон минимизирует инструментарий и этим дисциплинирует, а C++ развращает обилием предоставляемых средств — и требует само-дисциплины, которую компилятор проверить не в состоянии.

Имхо С++ построен на парадигме ООП, как же не отождествлять. То что там можно ещё дополнительные ужасы на шаблонах сделать и прочие гадости на уровне структурного программирования - это же баловство, которое в реальном коде либо сделает поддержку невозможной, либо будет слишком сложным (все эти выкрутасы Александреску и прочие степановы). По сути С++ делает сложным даже простейшие обобщения (хотя он в этом мощнее чем C#,Java,Python). Однажды я целый час объяснял фанату С++, что список типов в Лиспе,
это просто список символов-имён типов. Такой же список, как и все остальные. Он то привык к шаблонному мазохизму.

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

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

Во-первых, язык Си по популярности уверенно держится на вершине "топ-10" вместе с Явой уже лет 10 и тренд сохраняется. Во-вторых, на чистом Си несложно программировать в ООП-стиле, достаточно правильно оформлять имена функций и передавать им первым аргументом ссылку на структуру соответствующего типа. Второй пункт касается также любых процедурных языков третьего поколения, того же Паскаля. Самый известный пример - ОС Windows, весь её API - объектно-ориентированный, но реализован на Си.

То что вы называете ООП в Лиспе или Форте - это аналог программирования на Си в ООП-стиле, не более. В частности на Форте любые попытки такого рода будут эквивалентны использованию препроцессора Си для надстройки языка. На уровне самого языка ни в Лиспе, ни в Форте ОО-подход не поддерживается, поэтому и выкидывать там нечего.

что Страуструп сделал С++ при помощи препроцессора Си, поэтому писать в ОО парадигме, можно хоть на ассемблере, только что не удобоваримо выглядит. Таблица VMT в принципе достаточно легко реализуюется указателем на функцию, но вот перегрузка операторов, конечно, не реализуема в прямую только препроцессором.

Писать на си в стиле ООП можно, но большая часть плюшек, которые даёт C++ будут недоступны, это пародия на ООП. То что вы называете ООП в Лиспе вы совершенно не знаете, за Форт не скажу, я не фортер, когда в вашем любимом ООП языке появится хотя бы близкий к CLOS функционал, тогда можно заикаться про то, что в Лиспе ООП не очень. К тому же препроцессор ни разу не эквивалентен макрам Лиспа и Форта, вас жестоко обманули.
Попробуйте на досуге препроцессором Си сделать макрос преобразующий аргумент строку в массив кодов её символов, наступит горькое прозрение.

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

В препроцессоре Си, насколько я помню, преобразование строк в массив не реализовано (за ненужностью), но в уже упомянутом макропроцессоре M4 такие операции возможны (используются циклы), как и многое другое из области метапрограммирования.

"чепуху говорите и возмутительнее всего то, что говорите ее безапелляционно и уверенно!"(с) Булгаков.

Всё наоборот - это в С++ не всё есть объекты, примитивные типы объектами там не являются !!! А в Лиспе, как раз ВСЁ является объектами. Про CLOS вы ничего не знаете, предлагаю вам сначала ознакомиться, прежде чем говорить откровенную чупуху про "как бы ООП". Если что, CLOS ещё является частью языка Common Lisp записанной в его стандарт, это вам не "как бы ООП". Даже галимый Лисп без CLOS куда более соответствует этой вашей "стандартной модели ООП", чем С++.

В препроцессоре Си, насколько я помню, преобразование строк в массив не реализовано

Ого! Уже заднюю скорость включаете ? Кто там говорил, что ООП в Лиспе и Форте равноценен препроцессору в Си ? Уже M4 понадобился, а в М4 уже реализован CLOS и всё что есть в Форте и Лиспе ? Нет ? Ну когда реализуете, приходите спорить. Внешний препроцессор никогда не приблизится к тому, чего можно достичь из самого языка средствами этого же языка.

Ну, наконец-то и до вас дошло, что Си++ - язык, объединяющий несколько подходов, в отличие от Смоллтока или Симулы. И про M4 со второго раза, но услышали. Пожелаю удачи в дальнейшем вдумчивом чтении уже написанного выше.

Согласитесь, что С++ объединяет груду костылей и не реализует нормально ни один из подходов, и без ООП вообще не может работать. М4 в нормальных метаязыках не нужен. Не стоит брать всякие M4, чтобы реализовать забагованную половину Common Lisp и тем самым "доказать", что всё то же самое якобы можно сделать препроцессором. :-)

Возвращаясь к нашим ПМК там вообще чистый ООП вреден, но и галимый Форт - ни о чём. Посмотрел разные Форты - этим невозможно пользоваться на более менее прикладном уровне, тянет на уровень ассемблера. Но он расширяется. Если приделать плюшки от Лиспа, вроде ридера (что то подобное есть в amForth) то получим нормальные строки и всякий синтаксический сахар в удобной упаковке. Видимо без сборщика мусора не обойтись.

Честно говоря, я на данный момент не знаю где надо ответвиться от низкоуровневого Форта чтобы не попасть в Basic и прочие Питоны, сохранить гибкость и возможности расширения. Но верю, что такое возможно, ибо тот же RPL уже был относительно неплох.

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

P.S. Препроцессор в Си это совсем не тоже самое что вся мощь Форт языка
для "изменения" своей же внутренней структуры.
Wn32Forth, кстати, активно использует некоторую модель ООП для построения программ.

Модель ООП в Форте построить возможно. Но она оказалась невостребованной. Благодаря гибкости языка удаётся программировать и без неё.

Более того — Чак Мур вообще убрал словари из colorForth. Не в последнюю очередь из-за того, что с их помощью кое-кем была построена система ООП-программирования. :-) «Объекты» Форта возникли до ООП и содержат ровно один метод, который не наследуется. Иногда 2-3 метода, как в VALUE , DEFER и QUAN

ООП — зло. Попытка хвоста управлять собакой. Способ больших корпораций порабощать программистов, забивая их мозги собственнической дрянью. Но расширение типов (а также процедурные переменные и абстрактные типы данных), на котором оно зиждется — полезный и научно-обоснованный инструмент. Проф. Вирт в книге «Programming in Oberon. Steps beyond Pascal and Modula.» (pdf, англ стр. 238) приводит словарик с buzzwords объектно-ориентированных на человеческий, научный язык.

С ООП на человеческий.

Object -> Variable of that type
С каких пор переменная (ящик для ссылки на объект) стала самим объектом ? :-)
А в целом согласен. Идеологии посылки сообщений придают слишком много важности, а по факту результаты достаточно плачевные, числом взяли по сути. Я не призываю отказаться от ООП, но утверждаю, что он лишь одна из примочек, но никак не способ программирования, особенно на малых устройствах вроде ЭКВМ, ПМК и т.п. ООП гораздо лучше реализован в каких нибудь Haskell, Ocaml (F#), Erlang, чем в С++, где он выглядит как гигантский костыль.

Переменная «стала объектом» с тех пор, как разработкой языков занялись маркетоиды.

«Классы, объекты» это всего лишь коммерчески-обусловленные бессмысленные упаковки для старых и хорошо изученных терминов — тип и переменная (type, variable). Когда вводится научный термин «расширение типа» и допускаются процедуры в качестве полей записи, возникает стройная и мощная теория, породившая коммерческую вакханалию под названием ООП с последующей делёжкой программистов по лояльности той или иной корпорации.

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

Научный же термин «объект» был введён проф. Гуткнехтом в языке Active Oberon для куда более крупной и принципиально новой сущности «параллельного программирования», которая может иметь собственный поток управления или даже исполняться на отдельном процессорном ядре.

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

Так изучите тему самостоятельно, раз учителя вызывают такую агрессию. :-) Ссылку на учебник по Оберону я давал. Посмотрите, что такое type extension для записей (11.1) и ссылок (11.2.1). Тогда не будете свою ООПшную ересь нести про subclassing и subtyping.

Чтобы увидеть логику, надо иметь и знания, и мозги. Интересоваться не только заработком (C++ и Джава прокормят, тут не поспорить), но и наукой. Проще всего, когда встречаетесь с новым, переводить разговор на собеседника и начинать обвинения, судья вы наш.

Сравнивать Оберон, научную разработку, с «Жигулями» — трудом инженеров, причём совершенно не из области софтостроения — может только человек «с допуском», которому уж очень требуется подыграть господину Степанищеву «с допуском». Все уже привыкли к тому откровенному вранью, которым покрывают некомпетентные работники ФСБ всё и вся вокруг себя.

Маркетройды с их баззвордами это конечно зло, но какая те терминология всё равно нужна. И переменная не может быть объектом или типом, потому что типы и объекты это нечто другое. Например в Лиспе переменная может быть связана со значениями разных типов. В то же время одна переменная может быть связана в разное время с разными объектами, таким образом очевидно, что "переменная" - это МЕСТО указывающее на ЗНАЧЕНИЕ/ОБЪЕКТ какого то ТИПА, как бы не реализовывались никогда переменная не тождественна объекту. Типы и классы тоже не эквивалентны, если это не классы типов :-)
Зачем объекту собственный поток управления и процессорное ядро, так ресурсов не напасёшься. В общем эти профессора ещё хуже фирмачей, напридумывают ноу-хау, туши свет :-)

В Форте, например, переменная это только текущее её понимание (как она введена в программу) т.к. она тоже подпадает под абстракцию СЛОВА и если понадобится изменить её семантику на какое то действие (при изменении контекста задачи), то так и будет при сохранении интерфейса входных/выходных соглашений (в данном случае употребления переменной)

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

Какие бы механизмы там ни были, переменная сохраняет свой смысл, она не может быть объектом, потому что объект это нечто другое. В Лиспе переменные можно создавать многими способами, не обязательно в лнксическом замыкании. Есть еще динамические переменные, которые ведут себя как глобальные, но в замкнутой области. Есть глобальные. В Лиспе переменная - это именно слово-символ, а к ней что то привязано. В Лиспе-1 привязано либо значение, либо функция как значение. В Лисп-2 на один символ можно привязать и значение и функцию.
Тип хранится в самом значении, если не брать расширения где есть вывод типов, то переменная вообще не знает что к ней привязано.

Переменная состоит из трёх частей — идентификатор, тип и значение.

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

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

В Обероне переменная — это переменная. Они определяются в разделе VAR, а динамические создаются словом NEW. У кого мозги забиты ООП, те могут обзывать некоторые переменные «объектами». Но это не проблемы самого языка, скорее профессиональный жаргон.

В Лиспе будет правильней сказать: тип не "хранится вместе со значением", а значение имеет какой то тип. К переменной (если не выведено в момент компиляции и явно не объявлено) тип не имеет никакого отношения, переменной может и не быть, а значение с типом всё равно существует.

"Объе́кт в программировании — некоторая сущность в компьютерном пространстве, обладающая определённым состоянием и поведением, имеющая заданные значения свойств (атрибутов) и операций над ними (методов)." - ИМХО отличное определение, не подкопаешься. В плане ООП надо добавить, про наследование, сокрытие реализации и всякие там мультиметоды. Ни с чем не спутаешь.

Повторяю, только безграмотный человек назовёт переменную объектом или значением, потому что переменная и значение, которое она представляет (указывается на, ссылается на, связана с) в какой то момент времени - будь оно хоть зелёным сыром - ЭТО РАЗНЫЕ ВЕЩИ !!!

Если задача торговать своим трудом и хорошо зарабатывать, то «фирмачи» лучше учёных. Но если речь о терминах, то в строгом смысле их вводят именно учёные.

Профессор Вирт много сил вложил, чтобы сделать программирование наукой и сейчас computer science получила признание. В университетах ещё с конца прошлого века открываются кафедры и факультеты «компьютерных наук». Конечно, каждый язык волен вводить собственные представления — переопределяя под себя слова вроде «переменная», «объект». Можно состряпать самые извращённые языки вроде Brainfuck, воплощающие самые искажённые представления о программировании. Если цель программировать только на Лиспе или Джаве — да, имеет смысл использовать жаргон, принятый в вашем языке.

Но научные термины это не просто слова. У терминов должны быть точные определения. Большие требования предъявляются к завершённости, корректности связанной с ними научной теории. Если нужен научный подход, а не подработка у «фирмачей», стоит обратить внимание именно на «этих профессоров».

Оберон разрабатывался в рамках компьютерных наук, как научная теория с чёткими терминами, определениями, теоремами, доказательствами и выводами. Это научная альтернатива «ООП» ремесленников — такая же строгая, как например, теория поля или общая теория относительности. Project Oberon (операционная система и компилятор) это не «Жигули» (как здесь некоторые считают), а научный эксперимент, проверка теории проф. Вирта на практике.

Его развитие Active Oberon (сообщение о языке) вводит термин object — который далеко не то, что «объект» в Лиспе или ООП. Это, повторюсь, более крупная сущность, чем переменная. Где-то на уровне модуля. Связанная с объектом нить исполнения запускается при создании объекта. Когда она завершается, объект перестаёт быть «активным» и (при отсутствии ссылок на него) может быть убран из памяти сборщиком мусора.

Объекты создаются явно ключевым словом OBJECT. Просто определяя переменную x типа INTEGER никакого нового треда не создаёшь, так что с ресурсами всё нормально.

Ну а то, что маркетоиды ради финансовой выгоды обозвали «объектом» в C++ — с точки зрения науки (Оберона) разновидность переменной. «Класс» — просто разновидность типа «запись». Выше я приводил табличку, как выглядит вся эта напыщенная болтология ООП с точки зрения науки.

Натырил отовсюду механизмов и придал наукообразный вид.Чем ему Mozart Oz не угодил или Clean. Видно фатальный недостаток не устраивал - они написаны не им :-)

Натырить отовсюду концепций, это больше про C++. В коммерции и важен «фатальный недостаток» — если опубликовано не корпорацией AT&T, то бабло и мозги утекут в руки других корпораций.

Наука устроена немного по-другому. В Обероне меньше 60 зарезервированных слов (включая арифметические операторы, циклы и т.п.) и 61 синтаксическое правило. Полное описание языка (англ. pdf) занимает 17 страниц, из которых формальный синтаксис изложен на двух страницах в РБНФ.

Поэтому C++ это распухшее чудовище с «понатыренными отовсюду механизмами», оставляющее слишком много вещей «на плечах разработчика». А Оберон — стройная и последовательная научная теория, из которой убрано всё лишнее. Экономит время того, кто изучает язык. Проще программировать, находить ошибки.

Конечно же, Вирт изучил всё созданное до него и тщательно взвесил, что брать в свой «чемоданчик» и связать со своей научной репутацией, а что выкинуть. В Обероне было выкинуто многое из того, что Вирт позволял себе в Паскале и Модуле-2.

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

С++ конечно груда натыренных или надуманных костылей. Только сомневаюсь, что в Обероне всякие эти механизмы языка высосаны не из того же пальца, ведь они приделаны туда всё так же по произволу Вирта, а уже потом обоснованы научно. Может быть это замечательный язык, но что то не видно желающих на нём писать, вы единственный кого я встретил с такой тягой к Оберону.
Кроме того по описанию Оберон смахивает на очередной дубовый язык без возможностей метапрограммирования (как тот же Паскаль).

Вы можете заставить меня написать

VAR
  VarName : PROCEDURE {REALTIME, C} ( VAR low, high: LONGINT ): BOOLEAN;

только под дулом пистолета :-)

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

Во-вторых, язык для изучения различных методов программирования. Которые потом студент сможет использовать на работе в любой корпорации — неважно, заставят его там программировать на C++, C#, Swift, Java, Питоне или чём-нибудь ещё.

На практике же получилось, что за успехами профессора Вирта в 1986-90 годах внимательно следили корпорации. После чего его (и не только его) научные разработки были использованы при создании современных собственнических языков и операционных систем. Единой нотации «для всех» на производстве не получилось. Но, возможно, получится в мире науке и образования. Такова цель, например, отечественного проекта «Информатика-21» — открепиться от зарубежных корпораций и преподавать науку.

То есть «Оберон», научные достижения, были внедрены в производство. Но не таким прямым образом, как хотелось бы. Корпорациям оказалось выгодней поддерживать собственные карманные языки (единая формальная нотация «для себя»), не полностью совместимые ни с Обероном, ни друг с другом.

Языки типа Си/Си++/Сишарп, на которые существуют отраслевые стандарты не только на сам язык, но и на стандартные библиотеки и множество реализаций от разных поставщиков, включая свободные с открытым кодом - это "карманные". При этом Обероны, созданные для конкретных целей разработки встроенных систем, на которых специализируется Вирт, не имеющие таких стандартов - это, типа, свобода.

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

Попытка же из Оберона сделать ЯП общего назначения (то есть не под конкретный проект) неизбежно его раздувает. В оригинальном ЯП Оберон описание 16 страниц, в Оберон-2 (а это уже первые шаги к народному ЯП) уже 26 + 50 страниц из Oakwood Guidelines (там уже и стандартная библиотека какая-то появляется + уточнения семантики и синтаксиса языка). Насколько я понимаю, Компонентный Паскаль и Активный Оберон (со всеми расширениями) еще сложнее и больше.

Оберон — научная разработка, где даже операционка делалась «как надо». Компонентный Паскаль — основанная на Обероне система для разработки под Windows и Linux, где своё тяжёлое наследие. Понятно, что в КП пуризм Оберона разбавлен практическими нуждами. Но конечный результат по толщине документации не сравнится с теми «отраслевыми стандартами» Си/C++/C#, на которые вы ссылаетесь.

«Встроенные системы» это вас обманули. Опять на «компетентных» опираетесь? Вирт занимался разработкой рабочих станций, ещё со времён Лилит(1977-1981) и не прекращал это делать до ухода на пенсию. Рабочая станция это компьютер от центрального процессора (в последних моделях проф. Вирт разрабатывал его на FPGA), операционной системы и компилятора до текстового редактора, графредактора и почтовой программы.

К слову сказать, рабочие станции проф. Вирта выпускались небольшими тиражами, были полностью разработаны в Европе (как «Электроника МК-161» сделана в России) и находили своих покупателей. Обеспечивая европейцам, в том числе, максимальную независимость от американских корпораций.

Другое дело, что Оберон также смог занять твёрдую нишу на коммерческом рынке программирования микроконтроллеров ARM (англ.). Как и в некоторых других рынках «реального мира софтверной индустрии». Видимо, кураторы вашей неспровоцированной агрессии в мой адрес знакомы только с этой стороной обсуждаемой темы.

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

То что язык МК подходит для записи алгоритмов из диссертаций, это УЖЕ сомнительно, т.к. тот же Паскаль подходит НАМНОГО лучше, ибо язык МК нечитабелен чуть менее чем полностью. Хотя лично я из уважения к прошлому желаю ему жить вечно и создавая какую то вычислительную среду для самодельных ПМК непременно попробую сделать режим выполнения программ для МК и их расширения. А если случится страшное и на планете кончится цивилизация, то у нас останутся замечательные справочники Дьяконова и неубиваемые машинки с возможностью программировать по ним всякую математику. Я уже поднимал этот вопрос в теме ~"Калькуляторы на случай фаллаута".

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

Сейчас не принято сгущать краски, мол когда гикнется, тогда и думать будем. Лично мой стратегический парк калькуляторов ждёт своего часа (осталось спрятать в железный ящик от ЭМИ) ! Есть даже бумажный справочник дьяконова и несколько книг по вычислительным алгоритмам, одна из них на Паскале. Так что я готов открыть малый постапокалиптический вычислительный центр :-)

А где эта тема "Калькуляторы на случай фаллаута"? Что-то не нашел.
Если не думать о том, что в случае фоллаута будет не до калькуляторов, а цениться будут, в первую очередь, патроны, то тема интересная. В идеале фоллаут-вычислитель должен уметь работать от солнечных батарей, а такого, кроме инженерных калькуляторов, к сожалению, не наблюдается.

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Тема кажется была на форуме Фролова, но он выбрал путь боли - забанил всю жизнь на форуме и форум сейчас тихо умирает. Видимо хорошие отношения с СЕМИКО зачем то нужны :-)

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

Ох не зря я кручу тему с e-Ink экранчиками :-) По идее программируемые калькуляторы могут не только вычислять, но и служить всяческими базами данных и электронными таблицами, заменяя ноутбуки, которые мне кажется в услових фаллаута быстро придут в негодность. Неплохо бы ещё иметь запас SD карточек, чтобы на них хранить БД и кстати КНИГИ !!!

Постапокалипс Программируемый Калькулятор.
Интересная тема! Калькулятор, который может работать от батареи месяцами, с еИнк дисплеем высокого разрешения, в формфакторе "металл и резина", и пачка самых надежных SD карточек с запасом необходимых знаний цивилизации, помещенная в герметичный металлический контейнер.

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Я медленно, но верно иду к реализации. Сегодня пришли микросхемы с CoolRunner-II, так что восстанавливающаяся цивилизация рискует получить ещё Реконфигурируемые Постапокалиптические Программируемые Калькуляторы :-) Кстати реально напечатать корпус в стиле PipBoy-3000, я даже подозреваю, что в таком формате на них был бы больший спрос, чем виде классического карманного ПМК :-) Представляете, вокруг фаллаут, и вы распределяете тушёнку со склада, ни карандашей ни бумаги нет, а у вас на руке верный РППК с e-Ink экраном и процессором с низким потреблением, в нём БД на всех людей и кто сколько чего получил, и вы знаете, что он вам прослужит ещё как минимум год, а потом снова надо будет где то искать батарейку CR-2032 :-)

Уважаемый Ватник, Вы просто зрите в корень! :)

Представляете, вокруг фаллаут, и вы распределяете тушёнку со склада, ни карандашей ни бумаги нет, а у вас на руке верный РППК с e-Ink экраном и процессором с низким потреблением, в нём БД на всех людей и кто сколько чего получил, и вы знаете, что он вам прослужит ещё как минимум год, а потом снова надо будет где то искать батарейку CR-2032 :-)

А также в РППК хранятся "верификационные хеш-ключи" на всех людей, вычисляемые из того, что у людей есть: документов, IDкарточек и биометрии, что помогает уменьшить мошенничество при получении нескольких банок тушонки в одни руки.

З.Ы. Я более чем уверен, что спрос на такой ПипБой превысил бы спросы на карманные ПМК.

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

В принципе на этом экранчике реально даже отображать фотографии людей, соответствующих хэшам. Жаль китайцы зажали самый большой двухцветный экранчик, он никак не может пройти китайскую почту, но я верю, что он успеет прийти до апокалипсиса ! Тот достаточно большой, чтобы быть экраном классического ПипБоя3000. Может успеем наклепать достаточно экземпляров пока цивилизация не гикнулась :-)

В качестве предустановленного софта - аналог Андроид приложения Offline Survival Manual.

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Можно в топике "Самодельные калькуляторы". У меня кстати книжка есть на русском по выживанию, правда написана чуваком из британского спецназа, местами доставляет, типа "ждите помощи", в западном мире это нормально конечно, а у нас как правило это будет вредным советом :-) Если передрать общие пункты и картинки в монохром, то это уже не будет плагиатом.

Работа с двумя SD картами одновременно (такой SD RAID массив), четыре SD карты хранятся тут же в корпусе, в защищенном контейнере (металл, герметично).

Мануал по выживанию может быть для начала полностью в текстовом виде.

З.Ы. А вот некоторые рабочие складов пользуются Пипбоем каждый день.

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Зачем рэйд из карт ? Ведь это всё будет жрать энергию

Ватник wrote: Зачем рэйд из карт ? Ведь это всё будет жрать энергию

Проект народного компьютера OLPC помните? (в Биосе, кстати, тоже Форт на базисе OpenBios:)
Ну или биологические источники химо-электрических реакций.

Нужна надежная SPI флеш память, а SD карту втыкать лишь для бакапа и обмена файлами

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

На академических версиях Оберона программировать действительно трудно. Хотя Active Oberon можно запускать в виде программы (лично не пробовал) — обычно авторские Обероны работают в собственных «манямирках», где всё хорошо продумано, но труд в которых никто не оплачивает.

Этими системами воспользовался не широкий слой программистов, а, например, корпорация Sun. Которая заплатила за «рельсы», заготовленные учёными для внедрения Оберона на рынок, и внезапно использовала их для внедрения собственного языка Java. Языка, беспорядочно набравшего из Оберона и других источников всё, что фирма Sun захотела/решилась себе взять. Об этом интересно рассказано в статье «Судьба Оберона» (pdf, стр. 4-5).

Для разработки востребованного софта сейчас используются инструменты вроде упомянутого BlackBox (Windows и Линукс), Astrobe (для ARM) и Zonnon (для .NET). Этим летом был опубликован Free Oberon — как простая замена Free Pascal для небольших задач. Кстати, это уже почти по теме форума, ведь FreePascal используется для разработки эмулятора «Электроники МК-161».

Например был Actor Prolog (аналог Active Oberon для мира Пролога), вся эта акторная штука мне как поклоннику забивания всех гвоздей алгоритмами A* очень нравится :-) В общем я не противник, если будет альтернатива, думаю надо пилить минимальный рантайм низкого уровня фортообразный (не обязательно прямо Форт).Он будет играть роль платформы и можно даже реализовать обмен между разными языками. А поверх него рисовать разные языки, в том числе ваш Оберон в лучшем виде, в конце концов в HP Prime язык очень похож на эти ваши Обероны. Отличная получилась бы машинка для обучения программированию. Захотел включил режим MIX или MMIX и почесал по книжке Кнута ! Включил Оберон, начал обучать виртовским вещам. Включил Scheme - расчехлил SICP :-) А возможности графики и всякой работы с периферией будут доступны в равной мере всем языкам. Кстати для детей мож и правда стоит подумать о программируемом браслете в стиле PipBoy ????

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

Есть что-то общее в том, как:

  • Вирт делает европейские рабочие станции (Лилит, Церера, Хамелеон и т.п.), придя к проектированию не просто операционки и языка, но даже собственного RISC-процессора на FPGA
  • Чак Мур проектирует на обновлённом Форте GA144 — мультипроцессорную Форт-систему, начинающуюся с транзисторов
  • Apple, которая выпускает «разработанные в Калифорнии» айфоны (собственный софт и оборудование), а также два корпоративных языка (Objective C и Swift), придя к собственным SoC-процессорам A10X
  • Новосибирск, разработавший МК-161 со своим «железом» (теоретически могущим производиться в РФ/РБ) и прошивкой, которую засекретили-зашифровали

Конечно, у проектов разные бюджеты и наукоёмкость, но есть общее, отличающееся от «открытой архитектуры» IBM PC/Wintel. Это общее можно объяснять разными «а если завтра война», параноиками «а вдруг враг поменяет цифры синуса», «Fallout'ом», выживальщиками с «бункером и схронами», угрозой санкций или патриотизмом.

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

Вирт да тут все правильно, только вроде про Lilith забыли.
Чак Мур - не понял пассажа про транзисторы, GA это его творение, однако при чем тут транзисторы? Ну и если уж отдавать дань такому замечательному человеку то надо сказать что он давно в теме "харда" с момента основания им Novix и появления первого Форт процессора NC-4000.
Ну с Апле почему то у всех проблемы, начнем с того что Апле со времен Стива Джобса в альянсе с Acorn, разрабатывающим ARM. Это кстати еще тот ARM первых кровей так сказать :) Однако не забываем что в альянс с Acorn вошел еще и DEC, так что я склонен видеть в ARM больше DEC-а чем кого либо еще :) Так что A10X такая же разработка Apple, как и все остальное - маленько доработанный напильником цельно тянутый "хард".

P.S. Говоря про Вирта почему то всегда забывают где он "черпанул" новых идей после Паскаля, не забывайте Алана Кея, хорошо?

Чак Мур разработал colorForth, на котором переписал систему проектирования микросхем OKAD — и использовал её для разработки современных форт-процессоров. Получается Форт-компьютер, созданный от транзисторов VLSI до интерфейса пользователя если не одним человеком, то по крайней мере коллективом под его руководством.

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

«только вроде про Lilith забыли» — кто именно забыл? Я написал Лилит первым же пунктом в скобках. Ещё выше в ответе Сергею указал годы её разработки и дал ссылку на первоисточник.

Конечно же, Вирт создавал computer science не в одиночку. Упрёки в заимствовании идей могут ещё как-то смотреться в бизнесе. Там решается вопрос, кто кому деньги отчисляет. Но в науке любой учёный развивает идеи своих предшественников и это норма. В случае профессора Вирта он формулировал фундаментальные научные идеи Оберона одним из первых, на основе наблюдения за R&D отделами производства. Xerox PARC упоминается как на сайте проф. Вирта, так и на первой же странице предисловия к «Programming in Oberon». Это нормально для компьютерных наук, которые разрабатываются для помощи в упорядочении и совершенствовании технологий. Например, астрономы наблюдают звёзды и разрабатывают теории об их строении и эволюции.

Так что грех Вам пенять на личностные отношения.
Вот убей меня не пойму с какого тут перепугу транзисторы, VLSI и Чак Мур. Вы, что, так на ручной дизайн его чипов "намекиваете"? Так такого думаю не было.

Тон задали Ваши пиетет к Apple. Возражения против Апле главным образом потому как честно говоря задолбался слышать от Вас (а особенно от Вас) и от других эту мантру про Апле, Апле то Апле се. Там кроме Возняка работников не было! Апле после Возняка бесконечно перекупали почти завершенные технологии и продукты, уж Джобс в этом очень сильно поднаторел. Так сильно что из под его гениального носа ушла в его же компании разработанный BeBOX и BeOS. так что завязывайте с конгениальностью Апле, Арви, не подавайте дурных примеров молодому поколению. Нашли тоже пример для подражания, или вы так пытаетесь за Трендами не гнаться а встроиться в них как Гргеф велит?

Вот при чем тут не в "одиночку Вирт", когда речь идет совсем о другом что все ОО- технологии начинались в Xerox PARC и Аланом Кеем, про которого Вы так и умудряетесь дальше молчать. И Паскаль и Модула не чуть не меньшая, а наверное даже большая и наверное по настоящему своя заслуга Вирта. Ну вот как то так.

P.S. Жалко что не услышал например про проект "Кронос" наших замечательных Новосибирцев практически основанный на идеях Вирта. Про Апле вот услышал а про Кронос нет - "абидна понимаш"!

Какой смысл всё это обсуждать, когда на сегодняшний день мы у разбитого корыта, вроде и ресурсы есть, а народного ПМК и языка программирования к нему не создано. Что бы там муры и вирты не мудрили в прошлом, сейчас это не так важно !

Как это не создано? «Электроника МК-161» выпущена и продаётся.

Есть сложности с внедрением, информационной поддержкой и распространением по прилавкам магазинов. Есть информационная война против МК-161. Но это не «разбитое корыто». Просто над своим надо работать и улучшать его, тогда всё будет.

Если вместо поливки своего огорода и сбора урожая семья начнёт бить друг другу рожи прямо над грядками (с особым рвением нападая на тех, кто смеет не отвлекаться на грядки соседей и фантазии про «Нью Васюки», а заботиться о своём урожае), тоже будет «разбитое корыто».

Это у нас с Арви вечная полемика, внимания не обращайте.

А на самом то деле МК-61 и его входной язык я как то давным давно рассматривал в сравнении с другими платформами, и пришел к выводу что он самодостаточен. И писать под платформу на которой он нативен очень даже можно.
http://digitalinvitro.blogspot.ru/2009/06/61.html
http://digitalinvitro.blogspot.ru/2009/06/61_26.html

На мой взгляд проблема тут одна очень важная которую крайне не легко решить - пакет BCD арифметики для числе с 8 р-р мантисой и 2 р-р порядком. Это решит все.

Технологии мне интересны. А вот ваши обидки с переходами на личности — нет. Вне зависимости от того, давно это у вас или нет.

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

вы мне свои болячки не приписывайте Арви

Говорил об Обероне и colorForth — вы пришли потявкать на говорящего. К вам в темы поругаться, вроде, не ходил.

Так что это у вас что-то в мозгу против меня натренировано, а не наоборот. Я до вчерашнего дня 16:25 вообще не знал, что у вас со мной какая-то «вечная полемика». Казались мне нормальным человеком.

Не холивара ради, а спокойного обсуждения для.
Но что это за "любой декларативный подход". ИМХО решение на Prolog по гибкости скорее всего в любой день уделает любое решение на C++, как не проектируй, вопрос в том что, идеоматическая Prolog программа не может работать с такой скоростью. Также решения на Erlang фактически получаются проще и гораздо более гибкими, чем на монструозных Явах и сопровождает всё это один человек и строк надо на порядок меньше. Кроме того я заметил, что "правильное проектирование" - это не более чем красивые слова, нет никакой чёткой теории правильного проектирования, по сути правильные проектировщики получаются ТОЛЬКО в бою. Общие принципы есть, но не чёткие инструкции - бесполезное дело, похоже срабатывает теорема Гёделя о неполноте, сколько не строй формальные структуры, они идеально красивыми стать не смогут, обязательно будут дыры. Вообще проблема ООП ИМХО в том, что ООП в первую очередь героически борется со своими же ограничениями и так называемые паттерны проектирования как правило являются рецептами "как с помощью ООП сделать хоть что то полезное", а насчёт повторной используемости кода и отсутствия необходимости делать "рефакторинг" на каждый чих - в ООП всё очень плохо. Конкретно в моей работе всегда оказывается, что внутренняя структура уже готовых классов не подходит для нового дела и надо пересочинять код каждый раз. Однако у руководства (кто заказывает музыку в индустрии) стойко держится убеждение, что ООП даёт какую то предсказуемость результата и заменяемость исполнителей.

Речь не о "правильности" проектирования, а его сложности. В ООП все возложено на плечи разработчика, технология позволяет закодировать всего один "волшебный" класс, который делает все, и потом удивляться, почему он не подходит под другие задачи или почему его трудно изменять под новые требования. Эта тема также есть в книжке, раздел "Думать головой".

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

«В ООП все возложено на плечи разработчика,»

Языки отражают дисциплину программирования — которая предназначена разгрузить эти плечи.

Ситуация с ООП повторяет тот прецедент с GOTO. Когда спагетти условных/безусловных переходов (Фортран) потребовало введения дисциплины структурного программирования (Алгол). Именно поэтому я и назвал беседу в честь знаменитого «GOTO Considered Harmful» — анархия в расширяемости типов также не доводит до добра, как анархия в вопросах передачи управления.

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

Нехорошо перевирать, цитируя. В исходном тексте явно было сказано о проектировании. Как я понимаю, опыта проектирования систем со средними и большими объемами (сотни классов, сотни тысяч строк кода на ЯВУ с ООП) у присутствующих нет, поэтому нет смысла писать глупости про GOTO.

Нехорошо перевирать, цитируя — ответ именно про проектирование.

Опыт проектирования больших систем есть у Никлауса Вирта, идеи которого и воплощены в Обероне. Он называет это «программирование в большом». Данные из статьи «Оберон как эсперанто программирования» (pdf) о размере, занимаемом соответствующей системой программирования на диске после ее установки:

  • 1983. Turbo Pascal 1.0 — 130 Кбайт.
  • 1991. Ядро Оберона (включая редактор и компилятор) — около 200 Кбайт.
  • 2001. Система XDS-x86 (Modula-2/Oberon-2) — 23 Мбайт.
  • 2003. Система BlackBox (Component Pascal) — 34 Мбайт.
  • 2005. Visual C++ (из комплекта Visual Studio 2005 Beta) — 1,5 Гбайт.

Это системы, предназначенные для решения одной и той же задачи (компилирование системных и прикладных программ) — но разные подходы к проектированию, продуманный научный и производственный тяп-ляп. Плюс разный инструментарий использован — Оберон пишется на Обероне (тщательно спроектированном, чтобы облегчить «программирование в большом»), а ООПшники пишут на ООПшной помойке из технологий.

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

Спасибо, я понял. Проблема GOTO чисто проектировочная, ведь проектируя классы нельзя не принимать в расчет, есть ли в ЯП этот оператор или нет. Также надо принимать в расчет размер дистрибутива инструментальной среды программиста.

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

Что-то не то вы поняли. Оба пункта не подтверждаю.

Размеры дистрибутивов были приведены, т.к. они пропорциональны размеру исходного кода этих систем. Где-то было прямое сравнение по числу исходных строк ОС Windows и ОС Оберон, компиляторов C++ и Оберона — показывающее выгоду правильного проектирования. Но так быстро не нашёл.

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

С таким умением "понимать" (включать дурку?), боюсь, вам и сам Вирт не поможет. :-)

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

Синхронность/асинхроность вызовов как правило, поддерживаются средой/платформой. Например в .NET это есть, соответственно, в семействе языков (C#, VB, F#...) есть спецификатор "async". В Smalltalk тоже все на уровне среды, насколько я помню. Проблема распараллеливания не в наличии такой опции, хотя она несколько облегчит жизнь, а в выделении реализуемой логики, которую можно обрабатывать параллельно, и синхронизации этих процессов.

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

Не вижу ничего естественного в ручном распределении людей по кассам :-)

Вроде бы про ручное распределение не говорили.

автоматическое распараллеливание алгоритмов ?

Но если уж так хотите то да - автоматическое распараллеливание возможно, например умножение чисел BCD (как впрочем и любых), можно делать вполне себе по разрядно и не зависимо. А уж распределение очередей давно автоматизированы.

Я не писал про автоматическое распараллеливание частных задач, а о распараллеливании любых алгоритмов. Такого и близко нет, особенно если писать на императивном г с указателями и прочими дубовыми штуками вроде С++.

Распараллеливание на нижнем уровне это вызов fork(). Автоматизировать это в языке можно примерно также, как структурное программирование автоматизировало GOTO — продумать удобные и математически предсказуемые высокоуровневые концепции, которые бы сами вызывали fork() в нужных местах.

Этой научной задачей занялся Active Oberon. Распределяешь задачи по объектам. В нужное время создаёшь эти объекты — задачи решаются, fork() вызывается автоматом и вручную его ставить надо не чаще, чем GOTO в Паскале.

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

Хмм не совсем то что я хотел услышать. Я бы хотел услышать сравнение вызов (call) с передачей управление какому либо коду немедленно с асинхронной, планируемой передачей сообщения (скажем посредством DMA). Такой реализации насколько я понимаю нет ни у кого кроме самого Алана Кея.

Вы смотрели язык Active Oberon и операционную систему Bluebottle? Там всё вертится вокруг процессов, обменивающихся сообщениями. Разработка протоколов входит в синтаксис языка.

Об этом есть, например статья A2 в Википедии.

Такая операционная система уже есть почти на каждом столе, она называется Windows. Все объекты системы обмениваются синхронными или асинхронными сообщениями через очереди.

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

ООП - это концепт, реализован он программно или аппаратно - неважно.

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

Отличие BlueBottle в том, что она написана на языке Active Oberon — в котором, повторюсь, обмен сообщениями и разработка протоколов такого обмена происходит на уровне языка, а не библиотечных вызовов. Это язык программирования, созданный специально для разработки параллельных процессов.

Нет софтверная реализация мне не интересна, что бы асинхронная очередь жила своей жизнью без блокировки она ни с кем не обязана делиться временем исполнения.

BlackBox немного другое, там ещё нет параллелизма.

Active Oberon это следующее поколение языка, где процессы могут выполняться на разных ядрах. Это не так важно, софтверно или хардверно. Главное, что сам язык программирования подразумевает параллельное исполнение кода в разных объектах и обмен сообщениями между ними.

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

Красивейший язык для параллельных вычислений — созданный не лично Виртом, но в его научной школе на основе Оберона-2.

EDIT Есть и компромисс с грешной ООП-индустрией, вариант этого языка под .NET — Zonnon. В его разработке принимал участие наш соотечественник Евгений Зуев (МГУ). В Нижнем Новгороде даже выпустили университетский учебник (pdf, 62 с.) — но самого интересного (активные объекты, сообщения, протоколы) я в нём не нашёл, надо читать английские доки (pdf, англ.).

Тогда я не совсем понял вопрос. Асинхронные вызовы есть на уровне платформы и языков. В большинстве ООП-языков вызов метода и есть передача сообщения, их очередь управляется средой. Дальше уже про концепт, как получить ответ: то ли ждать в соседнем потоке, то ли передавать делегата (подход ООП) или просто callback.

Идея Алана Кея на момент инкарнации Смалталк использовала асинхронную очередь и объекты связанные с ней механизмом приема-доставки сообщений. Но поскольку крутилось все это на одном процессоре, это фактически была виртуальная среда в которой определенный квант времени проживали сами объекты, а другой квант времени очередь доставки сообщения. Эффективность в этом смысле совершенно нулевая, прямой вызов (call address) в этом случае даст максимальное быстродействие. Но в современных платформах кол-во ядер стремится почти что уже к сотне (утрирую). И механизм прерываний - это огромная потеря тактов на сохранение/восстановление контекста, а архитектура smalltalk изначально софтовая весьма не плохо масштабируется на такого рода системы. При этом мы добиваемся максимальной инкапсуляции объекта в ядро. В этом случае механизм прерываний - это анахронизм, и одновременно элемент синхронизма между объектами.

"Нас не подкосить очередями" - в магазинах IKEA был такой слоган :)

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

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

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

Все верно - именно так.

Как считаете в этом случае Транспьютер бы был более приемлем чем любая другая многоядерная архитектура? Конечно связь между ядрами в этом случае должна быть по принципу каждый к каждому. Либо кольцевая шина.

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

Топ 10 языков по уровню зарплаты. Индустрия, это дело такое

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Похоже, что корпорации используют научные разработки (тот же Оберон) вовсе не для популяризации науки — а чтобы вызвать зависимость программистов от своих фирменных поделок вроде C++, Джавы и C# (AT&T, Oracle и Microsoft).

При этом языки, разработанные не корпорациями (такие, как Форт) особо не финансируются.

Вспомнил, что пару лет назад возвращался к теме. Не вдохновило совершенно. Язык Лисп и его реализации

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

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