Smalltalk - изучаем вместе

исчо пример: в Dolphin SmallTalk компоненты реализованы как MVC. при этом есть подобная Delphi палитра компонентов, из которых эти MVC компоненты можно выбрать и набросать. но здесь не из GUI строятся компоненты набросав мышкой на форму – наоборот, 1) набросав ресурсы на форму 2)написав код мы получим полноценный самодостаточный компонент в духе MVC, а не unit-ов в Delphi.

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

Ты можешь скачать исходники форточек NT 4 и 2000, и убедиться, что, несмотря не наличие крестов в сорцах, кресты на нижних уровнях нигде не используются - только голый Си. Потому что сложное состояние, которое никак не вписывается в объекты. Много чего не вписывыается в объекты, просто это - одна из таких вещей.

это слишком голословное утверждение, чтобы быть правдой. во-первых, хотя и «голый си», но написано в объектном стиле. на си, да. те же тегированные структуры в WinAPI где сначала размер потом структура (привет, паскалевские строки). и API в духе функции с 8 параметрами, 3-4 из которых используются только при особой комбинации флагов первых двух. это и есть объекты, только «анемичной модели данных», какие-то недоделанные.

во-вторых, хендлы. многие функции API возвращают хендлы на какие-то свои внутренние «объекты системы».

в-третьих, NT Object. файловая система в NT есть подмножество этой объектной системы. корень ФС по умолчанию это поддерево объектной системы. в которой есть ещё и пайпы, mmap файлы, каналы, мейлбоксы и прочее. на всё это тоже выдаются хендлы (конструктор) и убиваются по хендлам (деструктор)

в-четвертых, забудем про исходники ядра, посмотрим на юзерспейс. и компонентную модель COM и средства её реализации на С++ библиотеками ATL, WTL, MFC. что же мы видим?

бросается в глаза шаблоны на шаблонах через шаблоны, ибо С++. шаблоны здесь исполняют функцию template mixin в D, или скорее trait. в MFC множественное наследование от контейнеров контейнеров используется для того, чтобы заменить наследование как самый ж0сткий тип связи на агрегацию или композицию, дабы сократить цепочку в иерархии наследования от некого абстрактного базового пращура Object.

COM модель по сути со всеми её недостатками (например, нельзя наследовать компоненты в отличие от SOM, где реализованы метаклассы из смоллтока) – реализована чтобы заменить наследование аггрегацией, через трейты логически (физически реализованные как шаблоны, или скорее уже шаблоны шаблонов). множественное наследование агрегатов чтобы объединить трейты. при этом немного уменьшается важность проблемы хрупкости базового класса, существенной для С++ с его кривой объектной моделью. но не устраняется полностью.

WTL это MFC реализованный как ATL, шаблонами шаблонов поверх шаблонов.

ATL это C++ обёртки вокруг COM. здесь почему именно С++ ? потому что COM компонентная модель по сути является хаком, битхаком и байтодрочерством с бинарной раскладкой ABI представления класса с++ в памяти вокруг VMT – Virtual Method Table, VTABLE, VPTR.

байтодрочерство есть в MFC, когда макросами события и привязки событий задаются таблицами диспетчеризации (которые потом алиасят в VTABLE).

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

ATL, и косвенно – С++ является стандартной инфаструктурой для реализации COM объектов.

в итоге программисты под винду настолько обленились писать низкоуровневый код на С для COM-автоматизации, реализации COM-серверов (хотя технически это возможно, что на си, что на ассемблере; просто в ATL, и косвенно, в С++ это удобнее и API реализовано полнее, есть книжки с примерами и т.п.), что уже надрессирован условный рефлекс «говорим COM – подразумеваем С++. говорим винда (например, DirectX) – подразумеваем С++. не будет никакого ТВ, театра, блябляотек – только один сплошной С++ во все поля», что С++ схвал мозги виндопрограммеров, и они искренне считают что по другому и невозможно.

что далеко не так. можно хоть на лиспе, хоть на Dylan (на реализации COM доступа к объектам из Dylan основан код DOORS от лавсана, например).

хоть на Аде с модулой какой-нибудь.

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

это не те ~дроиды~ объекты, которых вы ищете. проходите мимо.

такая хитрая джедайская техника. говорим ООП, подразумеваем С++. а не нормальные расширяемые модели вроде CLOS с мультиметодами и метаобъектным протоколом для рефлексии либо смоллтока с метаклассами и MVC в Dolphin SmallTalk аналогично реализации unit из *.BPL в Delphi, только круче либо компонентной модели Morphic из Pharo, Squeak (которой сто лет в обед, из смоллтока под макинтош классический).

попытка коммерциализации была, кстати: Dylan от Harlequn/Functional Objects/ LispWorks и MLWorks от него же. сейчас можно скачать исходники, как исторические и новые. собрать их, запустить это IDE, в нём поковырять примеры: крестики-нолики под винду на ML, самодостаточный графический хелловорд на ML, библиотека DUIM под Dylan являющаяся форком CLIM под CL. запустить пример, остановить его в REPL и переопределить GUI с командами, моделью-видом-контроллером. инкрементально откомпилировать изменения, и продолжить выполнение с той же точки.

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

это были реальные коммерческие продукты из 90-х, которые тогда продавали, а сейчас можно найти открытые исходники. примеры из среды разработки и сейчас годные. разве что среда разработки в том же Dylan довольно хрупкая, ибо С++ и С частично с Dylan, data race, глючит и падает иногда ибо С++. консольный компилятор на самом Dylan – он просто работает. сейчас в open source версии вроде переписали уже на LLVM, со стабильностью стало получше.

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

а кто-то ждёт хайпа, и вот тогда уж и он верит что смогёт.

ждуны ждут. адепты адаптируют. неосиляторы продолжают ниасиливать, несмотря на.

Куда же кобылу впрягать?

Когда ФП полезен?

Кому и кобыла – невеста.

Стереть грань можно только одним способом - отказаться от привычных приложений вообще, и на архитектурном уровне закрепить первые два пункта философии Unix (программы должны делать что-то одно, а также - программы должны работать совместно). То есть, весь системно-прикладной комплекс должен состоять из массы взаимодействующих друг с другом программных компонентов, каждый из которых может выполнять только одну или небольшое число смежных функций. Также на архитектурном уровне нужно закрепить обязательное наличие документации, описывающей структуру и работу каждого компонента, а также наличие исходного кода для каждого компонента. Суть проста: если компонент не имеет документации и текста с исходниками - он неработоспособен, и система его «не видит».

Теодор Холм Нельсон, автор и изобретатель гипертекстовой системы Xanadu (и самого термина «гипертекст», под которым тогда подразумевалась не навязанная иерахичная онтология вроде DOM, XML, XHTML что сейчас, а нечто более полезное – параллельные тексты и связи между ними, с уникальной адресацией отдельных структурных единиц; любые тексты, где медиа – тоже текст; гипертекст это тоже текст, то есть возможен «гипертекст высшего порядка», гипертекст гипертекстов ) однажды изобрёл applitudes.

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

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

например, организовывая измерения такие какие ему удобно.

пусть у нас есть программный компонент почта. но пускай мы отсылаем не только лишь текст, но и гипертекст. и возможен гипертекст гипертекстов, и гипертексты хранятся все в настраиваемой многомерной ZigZag Database, в произвольных объектах и связях между ними – а не в их линейном упрощённом и уплощённом представлении, файлах как неструктуированном сплошном потоке байт (блоб это проекция, объект это многомерность).

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

эксель превращается в редактор сводных таблиц в OLAP кубы.

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

данные это объекты, структурированные как угодно пользователю, а не приложениям.

приложения отменяюцца. остаются «приложеньица» applitudes которые устроены просто (вроде почты), но работают не с файлами и текстом, но с zzStructures (настраиваемыми пользователем измерениями модели данных) и гипертекстом гипертекстов, гипертекстом высшего порядка (объектами в ZigZag Database).

сейчас: приложения сложные, данные простые.

applitudes: приложения простые, данные сложные. более компонентные, модульные, повторно используемые.

потом брюки превращаются в … превращаются брюки…

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

это также достаточно просто реализовать: нужно совместить принципы Literate Programming Дональда Эрвина Кнута с zzStructures, ZigZag DataBASE, enfilades и паралельными гипертекстами высшего порядка, с типизированными ссылками в Xanadu Теодора Холма Нельсона.

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

но «блоки данных» должны быть сложнее чем в org-mode. например, это должно быть представление объектов из MVC (в духе компонентов из Dolphin SmallTalk или Morphic).

модель = «блоки данных», в каком-то простом редактируемом представлении (например, JSON, YAML, ну или полноценный STEP EXPRESS с параметризацией и вычисляемыми аттрибутами, с валидацией моделей).

осталось состыковать контроллеры таких моделей, и обновлять (или автоматически кодогенерировать composable) view таких моделей. например в каком-то условном графическом метапроге.

либо например, в некоторой среде Literate Programming. поверх Morphic объектов.

всё является объектом (даже классы и метаклассы, модели и их представления), и всё является гипертекстом. гипертекстом высшего порядка, с типизированными связями и контролем ссылочной целостности.

файлы отменяются. остаются объекты. или их многомерное zzStructures либо MUMPS представление.

чем-то типа FUSE можно и legacy интерфейс к одному из измерений, срезу или проекции объекта (то есть файлу) организовать. дабы редактировать в емаксе православном, M-x org-babel-tangle богоугодном.

векторный гипертекстовый фидонет Xanadu воссияет повсюду – невозбранно достигнув желаемого.

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

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

к примеру, Тед Нельсон изобрёл свою терминологию. все эти fanfics, enfilades, нумерацию на трансфинитных числах, прочие applitudes и zzstructures. в итоге его почти никто не понял. хоть, справедливости ради – ещё в книге Computer LIB/Dream Machines он достаточно популярным языком объяснил, зачем нужны компьютеры. в книге из середины 75 годов он написал, что приложения это не про вычисления. приложения – это презентации, это шоубизнес, это режиссирование твоих программных акторов, %username%. в середине 80х появились электронные таблицы Lotus и ёксель, которые стали хитом. именно потому, что этот шоубизнес с презентациями стали доступны широким немытым народным массам, без хитрого программирования и теории вычислений (монада есть моноид в категории эндофункторов; комонада +контекст применяется для формализации коэффектов, контекстов побочных изменений; коконус имеет связи с аспектами и аспектым программированием; рефакторинг с натуральным преобразованием; реактор и реактивные вычисления с правильным гипертекстом, моделью «что-если», компонентной MVC моделью, метаобъектным протоколом и т.п.)

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

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

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

это весьма увлекательно читать, когда что-то знаешь и про CALS (и STEP EXPRESS), и про 1С и прочую бухгалтерию и ERP, и про тот же ISO 9001, и LitProg, и про компонентные архитектурные модели приложений. и про векторный гипертекстовый фидонет, конечно же.

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

такое ощущение, что этот автор внезапно открыл, что все разговаривают прозой (совсем как герой Мольера).

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

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

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

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

такое ощущение, что охотятся на снарка и щупают слона за хобот в тёмной комнате. а потом 10 мудрецов-аналитиков каждый выдаёт своё особо «экспертное» (лол), заключение, что за зверя нащупали.

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

иначе получится как с Синьити Мочидзуки – товарищ математик изобрёл умную вещь, которую мало кто способен осмыслить, осознать и верифицировать. поскольку написана она на его собственном метаязыке, и доказана в предыдущих публикациях автора (в монографиях по 10500 страниц зубодробительного текста).

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

посмотри в сторону акторов, акторной модели, языка Self (тоже смоллток, с прототипной ООП моделью как в Io и JS).

там что-то было.

ещё в районе языка Pony про акторы и мультиагентские системы, и/или Open Cobalt, Terf и т.п. что-то было. про то, как они успешно совместили акторы, машинное обучение с многослойной нейросейтью, движок какой-то MMO игры переписали и оптимизировали таким образом. или это не MMO а что-то VR подобное было, уже не помню.

современные сетевые приложения так яростно используют ioctl для работы с сетью

но зачем? вот в Plan 9 нету никакого ioctl, ибо не нужно. вместо BSD сокетов есть в libc вызов dial, который через /dev/net/ctl контрольный файл делает тоже самое, что ioctl, только с унифицированным языком команд. потом получает хендл нового сокета (тоже файл), использует его. всё прозрачно на уровне API/shell/система, прозрачно по сети и нейтрально от языка программирования. общаться по сети можно хоть на шелле.

ещё там есть например «устройство» /dev/draw которое позволяет рисовать GUI посылкой команд. которые реализуют «композабельный» интерфейс и API. которые вполне себе можно скриптовать, похожи на какой-нибудь язычок graph или pic из troff и скриптуются аналогично. которые осталось завернуть например в Literate Programming.

вот что-то похожее можно и допилить до кондиции. а ты говоришь, графен-графоний.

Вот, к примеру, человек решил что-то поменять в мире IT https://www.cantorsys.com/p/about.html

интересный проект. но:

•Формирование нового направления в ИТ — функционального системного программирования.

не ново. например, проект unikernel MirageOS на OCaml. там и ОС, и компонентная модель, и DSLи, и системное программирование. на Ocaml, да. реально есть и работает.

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

но впечатляет целеустремлённость автора.

а что ему ещё остаётся? посмотрим, когда будет нечто законченное.

так-то one man show вполне себе явление. SkyOS, SerenityOS – это проекты «театра одного актёра».

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

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

в общем, всё идёт по плану…

почему идеи автора языка Кантор нельзя реализовать на той же Аде, например? зачем новый язык?

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

вот тебе ещё одна красивая идея: коэффекты . коэффекты выражаются через комонады да. могут быть composable и расширяемыми.

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

всё это красиво распараллеливается ибо та самая красивая идея и теория.

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

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

примерно так реально и происходит в реально существующих ОС и решениях: Amiga OS + скриптование GUI на ARexx; BeOS, Haiku + скриптование GUI.

всё это было уже году так в 1995 для BeOS, году в 1985 для Amiga и ARexx. у приложений есть порты, в которые можно слать сообщения. GUI, реализованный в ООП стиле (BOOPSI) с одной стороны согласно CUA выглядит и ведёт себя унифицированно; с другой, есть стандартные библиотеки и их API; с третьей, можно скриптовать на Amiga Rexx (ARexx), посылая сообщения объектам пользовательского интерфейса.

причём могут быть как низкоуровневые (на уровне кнопок и объектной модели библиотеки, например MUI/Zune в AROS) так и выскокоуровневые (на уровне API самой программы) сообщения.

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

ну разве что какой-то ООБД не хватает, а так почти полный комплект. так что осталось прикрутить какой-то MUMPS либо LambdaMOO.

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

например: Amiga OS + ARexx, BeOS/Haiku, Inferno OS + графический sh с tk + Limbo/tk.

в первой: свой шелл и язык, однако расширяемый Rexx-ом. Rexx позволяет подгрузить С dll и дёргать функции напрямую. но ещё это «командный язык» который позволяет добавлять свои команды в приложение (то есть, быть как вызываемой скриптухой, так и встраиваемой в приложение скриптухой). есть стандартная функция «послать сообщение программе в такой-то порт ARexx», программы когда запускаются регистрируют порты и их обработчики, отрабатывая use case, диаграмму прецедентов с акторами пользователями и функциями программы(командами). получается высокоуровневое скриптование если автор программы озаботился. но есть и низкоуровневое – автор библиотеки GUI (например, MUI, Zune) озаботился предоставить стандартные команды, методы для скриптования GUI объектов. в итоге аналогичное AutoIt, AutoHotKey уже встроено в приложение, написанное на стандартных библиотеках. и скриптовать можно не только на уровне (курсор в позицию x y нажать кнопку мыши, но и «нажать мышкой кнопку ‘применить фильтр’», «обработать письмо в голдеде» и т.п.

в Inferno: sh реализован на Limbo, модульный, подгружает другие модули (почти как Arexx и библиотеки). Limbo/tk интерфейс к tcl/tk (без tcl, только limbo), аналогичный tkinter. всё, что можно сделать в GUI можно сделать и в командной строке.

плюс к тому, что в шелле есть тип списки, а не просто строки. например PATH это список, а не строка. в итоге ибо монада это моноид в категории эндофункторов, а список (как и строка) тоже моноид – его можно программно разбирать и строить ad hoc GUI. плюс ещё в Plan9 был plumber, который делал диспетчеризацию по типу скопированного в клипборд в нужное приложение.

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

Опять же (если я правильно понял написанное), здесь всё упирается в разделение списка функций (алгоритмов) на примитивные и на составные функции.

а также на способ композиции составимых. и являются ли базовые компоненты, объекты, моноиды достаточно composable.

Скажи еще, что у Brainfuck есть исследовательские цели.

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

Объектная база данных в памяти/STM

а почему только в памяти? есть например тот же GOODS Константина Книжника. ООСУБД на С++, с хранимыми персистентными объектами. его диссер на тему её написания включает хороший обзор сравнения существующих на тот момент ООСУБД, и их подходов к реализации. и GemStone там тоже есть, среди прочих.

Опять же план девять это же тоже шаг от классического юникса в эту сторону, правда, очень небольшой шаг

маленький шаг для человека – большой шаг для человечества :))

файл coeffects-dundee2014.pdf, страница 10 слайда:

Coeffect annonations are vectors of natural numbers

ну как тут не вспомнить tumblers, адресацию в Xanadu на основе трансфинитных чисел.

векторный гипертекстовый фидонет таки будет достроен – невозбранно достигнув желаемого.

http://tomasp.net/

Data-driven storytelling и язык the gamma
реактивный ёксель в 100 строчек

В большинстве случаев алгоритмы не делятся на независимые объекты. Даже достаточно сложный классический (современный) GUI уже не делится на объекты, а представляет собой тесно связанные механизмы. По этой причине Smalltalk не подходит для реализации большинства сложных задач, поскольку его средства ориентированы на углубление развязанности компонентов. Последняя концепция больше подходит именно для ОС, а не для пользовательского софта. В том числе этот софт можно в среде Smalltalk запускать, но сам софт будет не на Smalltalk.

опять голословные утверждения. просто посмотри на компонентную структуру вокруг взаимодействующих объектов в Dophin SmallTalk, где в обучающем видео нарисовано примерно тоже самое как в Дельфи делают свой компонент. только компоненты здесь полноценный MVC.

или тот же самый Morphic в Pharo, Squeak.

ещё есть такой смоллток Spry. на Nim. AST смоллтоковый транслируется в Nim и далее в Си, написан интерпретатор такого AST. некоторые конструкции реализованы как intrinsinc на Nim либо Си, а не на смоллтоке. то есть может эффективно компилировать в эти базовые примитивы. состав примитивов расширяемый, можно писать свои (на Nim и/или, на Си).

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

ещё пример – это своя велосипедная система контроля версий, версионирование этой ООБД при экспорте.

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

то есть, таки соответствует и описанию «тесно связанных механизмов» тоже. которые не обязаны быть такими тесно связанными, а могут быть и развязанными.

и это есть зело хорошо весьма.

опять же, если кому интересно причём тут смоллток и функциональщина. может потыкать newspeak как функциональный смолток. и почитать публикации про mirrors, active worlds оттуда.

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

о двух крупных проектах, которые использовали Smalltalk (FLProg и OpenCobalt).

у OpenCobalt есть коммерческая реализация, Terf. где переписали узкие места на Nim (бывший Nimrod). и получили ускорение на порядки.

Я не думал про ФРП в тот момент, но это тоже пример архитектуры, которая плохо влазит в ООП.

да нормально влазит, паттерн реактор. просто получается не функционально-реактивное а объектно-реактивное.

другие упрощать не стали, и в этом направлении алгол 68, PL/I, та же Ада (хотя ада наверное чуть проще PL/I будет)

Ты пишешь «другие», будто другие - это не Си и не Smalltalk. Алгол 68, PL/I, та же Ада - это всё высеры коммитетов, бездарных кабинетных крыс и эффективных менеджеров. Паскаль, Си, Smalltalk - это языки, созданные программистами; да, у них были проблемы, но эти проблемы меркнут на фоне творений людей, понятия не имеющих о программировании.

Представь себе автомобиль, у которого есть руль, педали, но вдобавок к этому конструкторы решили, что водителю может понадобиться рычаги регулирования смещения фаз двигателя, глубины открытия клапана, давления в ГУР и тормозах, а также индикация тепературы абсолютно всех жидкостей, шин, воздуха за бортом, и седушек всех пассажиров - это идеальная конструкция автомобиля в видении коммитета. Почему? Ну потому что кому-то пригодится, параметры-то важные, после создание автомобиля переделывать уже будет намного сложнее. В итоге коммитет из автомобиля с себестоимостью 5'000$ сделал автомобиль себестоимостью 50'000$, и примерно то же произошло с сложностью и стоимостью обслуживания.

просто у тебя объекты неправильные. недостаточно гибкая архитектура с убогим пониманием ООП в духе С++

Нет, я пишу именно про объекты в понимании адепта C++. Если мы расширяем определение, то убогими они быть перстают.

что такое «развязанность»? приведи примеры. пока что я вот по книге классической Design Patterns банды четырёх, где паттерны параллельно приводились на С++ и смоллтоке вижу – понимание алгоритма затрудняет именно С++ из-за многословной развязанности мысью по древу. алгоритмы на смоллтоке же самодостаточны, и вполне компактны, что понимание облегчает

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

и таки в чём здесь проблема? в plan9 например есть rfork, где можно задавать какие ресурсы шарить, какие делать copy on write. в BSD тоже есть нечто похожее

Форк - абсолютное зло и не имеет места быть в современных ОС, так что здесь я не разделяю позицию создателей Plan 9. Дело в том, что форк беспорядочно копирует огромное кол-во страниц памяти и объектов ядра без контроля за их состоянием. Да, в rfork они попытались реализовать хоть какой-то вариант контроля, но это лишь малая доля от того, что по-хорошему требуется. Форк не был проблемой в однозадачной системе, где во время форка не может выполняться ни один программный или апаратный алгоритм. Но сейчас у нас есть потоки, которые могут менять память во время форка, у нас есть драйвера сети и видеокарт, которые могут менять память даже при полной остановке всех потоков пользовательского режима. В итоге весь софт приходится дорабатывать на совместимость с форком, потому что кому-то когда-то может понадобится этот форк сделать.

Единственное решение проблемы - это отказ от форка как штатного средства ОС. Именно это сделали в оффтопе. К слову, в нем копирование дескрипторов файлов возможно через CreateProcess - это вполне годная фича. Но бесконтрольно копировать всю память процесса - извиняйте, это только для специальных целей, вроде отладочного снимка процесса (RtlCreateProcessReflection).

здесь оно реализовано правильно, как и должно быть – через nt native kernel API. если в SUA ранее это была отдельная подсистема для запуска POSIX приложений которые .exe с другим типом системы, то тут можно просто обычные exe запускать, или запилить свой лоадер эльф файлов под винду, с нормальной подсистемой (куда оно и движется в десяточке)

В NT вседа была поддержка позиксов, Win API точно так же был неродным для NT. Просто совместимость с позиксом была слабая и ее переделывали.

кстати, вектор движения намеченный ещё в Plan9 и Inferno (дешевые зелёные нити вместо форка, асинхронность, lock-free) в современных языках программирования уже просто общее место

Не знаю, что там про lock-free, а вот асинхронность и зеленые потоки нужны потому, что современные ОС до сих пор не обрели продвинутых механизмов многопоточности. Дело в том, что механизмы переключения контекстов и планировщики в них слепые и тупые, потому безобидные на первый взгляд операции, вроде вызова функции из другого потока, приводят к катастрофическому падению производительности работы системы (порядка х10-х50). В гугле ребята когда-то пытались пропихнуть в ядро функции для прямой передачи управления от одного потока другому, но так ничего толком не добились, мол, «никому не нужно». Чтобы не ждать, пока создатели ОС прочухаются и решат эти проблемы - их просто решают здесь и сейчас, прямо в пользовательском режиме, без переключения контекстов, без выделения объектов ядра. Отсюда event-driven сервера nginx и apache, отсюда зеленые потоки в Go, Erlang, Haskell, JS, C#, Python.

то есть, угадали 25 лет назад, всё-таки

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

это слишком голословное утверждение, чтобы быть правдой. во-первых, хотя и «голый си», но написано в объектном стиле. на си, да. те же тегированные структуры в WinAPI где сначала размер потом структура (привет, паскалевские строки). и API в духе функции с 8 параметрами, 3-4 из которых используются только при особой комбинации флагов первых двух. это и есть объекты, только «анемичной модели данных», какие-то недоделанные

Ты сейчас рискуешь прийти к тому, что ассемблер - это объектно-ориентированный язык.

во-вторых, хендлы. многие функции API возвращают хендлы на какие-то свои внутренние «объекты системы»

А что им еще возвращать? Там нет взаимоотношения 1 к 1, разные дескрипторы могут ссылаться на один объект, а единственный дескриптор - на сложноструктурированные данные.

корень ФС по умолчанию это поддерево объектной системы. в которой есть ещё и пайпы, mmap файлы, каналы, мейлбоксы и прочее. на всё это тоже выдаются хендлы (конструктор) и убиваются по хендлам (деструктор)

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

в-четвертых, забудем про исходники ядра, посмотрим на юзерспейс. и компонентную модель COM и средства её реализации на С++ библиотеками ATL, WTL, MFC. что же мы видим?

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

ATL это C++ обёртки вокруг COM. здесь почему именно С++ ? потому что COM компонентная модель по сути является хаком, битхаком и байтодрочерством с бинарной раскладкой ABI

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

«говорим COM – подразумеваем С++. говорим винда (например, DirectX) – подразумеваем С++. не будет никакого ТВ, театра, блябляотек – только один сплошной С++ во все поля», что С++ схвал мозги виндопрограммеров, и они искренне считают что по другому и невозможно

Еще был Васик. Что поддерживается - тем и пользуемся. А пототом стал C#. Это не результат какого-то выбора, решения, просто что дали - то и жрём.

а почему только в памяти? есть например тот же GOODS Константина Книжника. ООСУБД на С++, с хранимыми персистентными объектами. его диссер на тему её написания включает хороший обзор сравнения существующих на тот момент ООСУБД, и их подходов к реализации. и GemStone там тоже есть, среди прочих

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

А COM в итоге загнулась, несмотря на поддержку крупнейшим производителем ПО того времени.

С чего бы это?
Все продукты Microsoft использую COM.
Да и API - COM-ские интерфейсы.
Wine COM хорошо поддерживает.

Посмотрите реестр Microsoft в нем COM на COM-е и COM-ом погоняет.

Владимир

Давненько разработал API для работы ресурсами /диалоговые формы, DFM, …/ и пожалуй разработаю API для работы с TypeLib.

PS: «TypeLib - жизнь» /шутка/.

Владимир

самое смешное, что метапрог на каком-нибудь Morphic, лениво почитывая Pharo by example запилить – обычное дело.

Ну так запили, что мешает?

Узнал мелодию

https://www.youtube.com/watch?v=o0D32RWdQro

Сказал «пластинка заела» потому, что 99% - критика Метапрог и metaprog.

Скорее не создание графического языка программирования, а технологии разработки, 
предоставляющей и возможность графической /если это целесообразно/ представления алгоритмов:
 - он должен обеспечивать разрабоику текстовых и графических алгоритмов;  
 - предоставлять возможность "из коробки" работу с объектами:  
    - деревья, списки, матрицы, 2D, 3D, ..., ..., ...
    - уметь использовать dll, elf, ...;
    - xml, json, jpeg, mp3, mov, ...
    - ...

К сожалению вы уперлись в LabView как «баран в новые ворота» и ничего вне LabView не хотите знать, да еще вдобавок отвергаете.

Владимир

Скорее не создание графического языка программирования, а технологии разработки

Да собственно этим и занимаюсь.
Предоставление возможности графической записи алгоритмов далеко не первоочередная задача.

Владимир

переписали его под виртуальную hosted os систему, в виде Inferno и Limbo/Dis VM.

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

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

Facepalm.jpg

Хотелбы я посмотреть, как ты будешь мышкой писать код в VW. Бгг.

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

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

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

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

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

Ну, как минимум часть из них будут обеспокоены вопросом, как снова усложнить жизнь и себе и пользователям :)

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

Именно так.

PS: Бизнесу правда все это - «НЕ НУЖНО».
Впрочем и мне до этих «дядей» ни какого дела нет.

Владимир

Шутка

Эшо хочу сказать всем ЛОР-увнякам критикующих Метапрог.

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

Владимир

Бизнесу правда все это - «НЕ НУЖНО».

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

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

https://cyberleninka.ru/article/n/svobodnoe-programmnoe-obespechenie-kak-sistemoobrazuyuschiy-faktor-informatsionnoy-sredy-nauki-i-obschestva-sostoyanie-i-perspektivy/viewer

PS: «Вода, вода, кругом вода».

Владимир

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

Ого, спасибо за наводку на эту инфу. Скачал zzStarterKit, покрутил туда-сюда ячейки с демо-базой, пока правда толком ничего не понял, и получил «взрыв мозга» от всей этой многомерности, но чую есть смысл копнуть в этом направлении глубже.

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

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

примерно так реально и происходит в реально существующих ОС и решениях: Amiga OS + скриптование GUI на ARexx; BeOS, Haiku + скриптование GUI.

Приму к сведению, спасибо.