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

В целом забей кто тут что говорит, 99% негативных комменаторов не запускали смолтолк ниразу.

Да это везде так, в метапрог-тредах хейтеры тоже ничего не знают о метапроге, такой лол.

сообществу смолтолка удалось не расколоться на десяток несовместимых стандартов/имплементаций как сообществу лиспа

В лиспе весь «раскол» по сути между двумя языками - CL и Racket, которые изначально «расколоты» были, и при создании преследовали различные цели. Код между реализациями CL, как и между реализациями схемы - 100% переносим, если придерживается стандартов и не использует специфические для реализации модули / фичи (их придется переписать).

CL в свое время (более 20+ лет назад) как раз таки объединил разрозненные лиспы в единый стандарт, который существует до сих пор, но имеет десятки *реализаций". Что очевидно, огромный плюс. У Racket - одна реализация. Есть еще несколько диалектов Scheme (как и Racket), которые придерживаются схемовских стандартов, каждая реализация имеет свои практические цели.

Есть clojure, но конкурентом ее вряд ли можно считать, скорее это замануха программистов из сурового ынтерпрайза в мир лиспа, а также тех, кто давно хотел попробовать, но не знал как. Следовательно, ее наличие не раскалывает сообщество, а расширяет и привносит много интересных идей, которые можно (будет) применять в других лиспах, обычный эволюционный процесс и обкатка, например, чистого фп подхода на лиспе для продакшна. Вообще, считай bleeding edge. До этого такие попытки были у F#, Scala, Ocaml. Но это все не пуре-фп, а все же симбиотические яп. Haskell в проде для широкого круга задач использовать никто не будет, слишком много матана и ограничений самого языка, вот только clojure и борется за фп во всем мире :) У нее тоже несколько реализаций для разных таргет-платформ (java, js, clr). Короче, лисп как всегад рулит.

За инфу по смолтолку спасибо, давно хотел глянуть в свободное время.

Скажу за VisualWorks: самая удобная IDE из всех с которыми приходилось работать, библиотека OpenTalk позволяет дёргать объекты между образами по сети написав всего десяток строк кода, объектная БД GemStone/S 64 в основном привязана как раз к VW, удобная система контроля версий Store отлично интегрированная в среду (точнее она на ней и написана) - на ней же и живёт VW Public Repository - репозиторий общедоступных проектов

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

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

Вот я прямо сейчас пишу код на Vue. Я долго искал в инете ответ на вопрос о сравнении Vue и React (с реактом не знаком), пока сам, наконец, не понял: Vue проще изучать, но React проще устроен. В итоге сложные сценарии на Vue сложнее реализовывать, чем на React, потому что нужно оглядываться на дополнительные вещи, которые изначально были призваны упростить работу.

обычный эволюционный процесс и обкатка, например, чистого фп подхода на лиспе для продакшна. Вообще, считай bleeding edge. До этого такие попытки были у F#, Scala, Ocaml. Но это все не пуре-фп, а все же симбиотические яп. Haskell в проде для широкого круга задач использовать никто не будет, слишком много матана и ограничений самого языка, вот только clojure и борется за фп во всем мире

Чистое ФП никому не нужно. F#, Scala, OCaml не вносили чистое ФП в коммерческое программирование - они просто предоставляли удобные инструменты для написания императивных программ. Индустрия уже лет 30 находится в глубоком заблуждении по поводу того, что ООП помогает писать код. Выкинь ООП мусор, оформь соотношение данных и функций таким, каким оно напрашивается быть естественным образом, без архитектурного планирования и шаблонов программирования - и ты получишь программу в типичном стиле F#, Scala, OCaml, Clojure, CL. У всех них богатые инструменты работы с состоянием, они просто не запрещают тебе писать на чистом ФП. Но с таким же успехом можно писать чистое ФП на Си, однако же, вы не будете утверждать, что Си - это ФП язык?

Если автор захотел смолтолк - путь берет смолтолк, тебе что обидно что не твое пхп выбрали?

Золотые слова!

Еще могу назвать такую штуку как GemStone. Это платная хайлоад-среда киллер-фича которой это транзакционные объекты. То есть в такой системе нет внешней базы данных а все хранится тут же в смолтолке. Когда ты делаешь например status := «active» это сохраняется перманентно. И это массово скейлится, ты подключаешь новый клиент этого GemStone к системе и в нем прозрачно доступны все классы и объекты кластера. Аналога этой штуки я пока еще не видел нигде. На прошлогоднем ESUG выступали челики которые использует это в конторе которая делает 20% мирового контейнер-шипинга и говорили что у них аптайм чуть ли не 100%.

Благодарю за эти сведения, и сведения из других ваших комментариев в этой теме.

F#, Scala, OCaml не вносили чистое ФП в коммерческое программирование

Я об этом и написал.

получишь программу в типичном стиле F#, Scala, OCaml, Clojure, CL

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

У всех них богатые инструменты работы с состоянием

На хаскеле и в кложе не очень удобно / идиоматично работать с состоянием, в первом это еще и выглядит уродливо.

Но с таким же успехом можно писать чистое ФП на Си

Писать в фп-стиле на С на столько же сложно, на сколько и не нужно.

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

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

Хм, про лисп почти то же самое пишут.

Злые языки говорят, что какие-то очень популярные терминалы (Kiwi, что ли) были на смолтолке реализованы, правда потом его выпилили и заменили на что-то иное.

Касаемо лиспа, мож у кого работка есть? :)

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

Ориентация на неизменяемые структуры данных не делает его «более ФП». Тем более, что неизменяемость эта скорее внутренняя, а программа видит вполне себе изменяемые данные.

На хаскеле и в кложе не очень удобно / идиоматично работать с состоянием, в первом это еще и выглядит уродливо

А хаскеле - да, неидеоматично, но Clojure может работать с контейнерами Java примерно так же, как обычный жава код:
https://clojure.org/reference/java_interop#_arrays
По этой причине она может заменить собой жаву с минимальными швами.

Писать в фп-стиле на С на столько же сложно, на сколько и не нужно

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

Касаемо лиспа, мож у кого работка есть?

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

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

Первая попытка: Smalltalk как ОС в Xerox PARC в 1970-х годах.
Вторая попытка: SqueakNOS ©, но тоже не взлетела.

P.S. «Плох тот язык, который не претендует стать ОС.»

Есть третий вариант: я опираюсь в своих суждениях на людей, которые знают этот язык. И да, мою оценку смолтолка можно не воспринимать серьезно - я вам дал сомнение, пользуйтесь им.

В данном случае опирайтесь только на свои знания, а не на чужие. К тому же, зачем мне ваше сомнение? Своих сомнений мне вполне достаточно.

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

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

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

Как я понял, что-то подобное давно уже планирует сотворить Дмитрий Завалишин в своей PhantomOS. Но это когда ещё будет, и будет ли вообще, а Смолток вот он, рядом. Пусть даже в виде виртуальной машины, а не обычной ОС, вертящейся непосредственно на железе.

Именно потому, что это операционная система и он пытается заменить собой функции операционной системы, он будет невостребованным

Тем не менее, свои ниши он имеет, и там востребован.

в IT мода на ОС крайне инертна, новых никто не разрабатывает - в лучшем случае переписывают старые.

А смысл плодить новые операционки, если в итоге всё сводится к запуску в них уже существующих приложений? Новые ОС, на мой взгляд, нужны в случае, если планируется запускать что-то соверешенно не похожее на имеющийся прикладной софт (ни по внутренней архитектуре, ни по пользовательскому интерфейсу, ни по чему-то ещё). Непохожее и несовместимое. Но тогда и сама архитектура создаваемой ОС должна в корне отличаться от всех Unix- Windows- или BeOS-подобных систем. И для этого нужны веские причины, а не просто создание чего-то образно говоря «инопланетного» ради самой идеи, то есть непонятно ради чего. Для того же Фантома вроде Завалишин озвучивал веские на его взгляд причины (типа бесперебойной работы системы в сфере медицины, и т.д.). Но видимо этих причин недостаточно для того, чтобы его идею приняли на ура.

Да, как ОС Smalltalk смотрится заметно продвинутее никсов - и чо?

Вот и попытаюсь выудить пользу из этой продвинутости. Получится- хорошо, нет - ну и ладно.

Smalltalk как ОС в Xerox PARC в 1970-х годах

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

SqueakNOS ©, но тоже не взлетела.

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

mv ушел на сишке писать, или все-таки на лисп перекатился?

В данном случае опирайтесь только на свои знания, а не на чужие. К тому же, зачем мне ваше сомнение? Своих сомнений мне вполне достаточно

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

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

Да. Современная коммерческая IT индустрия безнадежно увязла в болоте и совершенно не прогрессирует. Современным центральным процессорам и ОС примерно 50 лет, языки и видеокарты будут помоложе - примерно 25 лет, С++ - 35 лет. Настоящий прогресс не происходит в Intel или Google - там то же самое болото; настоящий прогресс идет в массах, среди аматоров, которые создают и реализовывают безумные идеи, часть из которых неспешно просачивается в мейнстрим.

Вот и попытаюсь выудить пользу из этой продвинутости. Получится - хорошо, нет - ну и ладно

Я бы делал акцент на том, что никсы сами по себе давно устарели. Какой смысл строить свой выбор между двух устаревших технологий?

mv ушел на сишке писать, или все-таки на лисп перекатился?

Питон жи. Или о чем речь?

Ну, во-первых, мне не кажется, что «современный» и «устаревший» — это 100% антонимы. Язык может быть не современным и не устаревшим, и это, ИМХО, как раз C (и, возможно, Python). Поэтому, кстати, «не современный» не означает «плохой».

Что касается определения — не возьмусь сформулировать его в стиле учебника, но, мне кажется, современный язык программирования должен использовать какие-либо крупные идеи, которые за некоторое — относительно небольшое — время до сегодняшнего дня не использовались, по крайней мере, за пределами узких, малоизвестных областей; либо, на крайняк, должен комбинировать ранее существовавшие идеи каким-то новым способом. Причём именно языковые идеи — вариант «а давайте реализуем Prolog на ZX Spectrum» не катят, даже если бы это не было уже сделано.

Я бы делал акцент на том, что никсы сами по себе давно устарели.

Раз говорите, что «устарели», то значит знаете как можно улучшить …

Причём именно языковые идеи — вариант «а давайте реализуем Prolog на ZX Spectrum» не катят, даже если бы это не было уже сделано.

Проблема в том, что «все все знают и ни чего не делают».
Это как на https://groups.google.com/forum/#!forum/harbour-users.
Там сейчас рыдания о том, что два основных основных разработчика перестали развивать проект /да и давно/, а новых разработчиков нет и не будет.
Почему?
Потому что разработка это не «щеки надувать в youtube и на конференциях».

Посмотрел некоторые из рекомендованных форумчанами видео.
Например https://www.youtube.com/watch?v=Opu8iKkS6lo Heavy Meta. Программирование, моделирование и предметно-ориентированные языки

ИМХНО «делящийся опытом» - НАЧИТАЛСЯ …

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

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

Не знаю, мне не кажется.

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

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

Я бы делал акцент на том, что никсы сами по себе давно устарели. Какой смысл строить свой выбор между двух устаревших технологий?

Вы предлагаете писать свою операционку с нуля, что-ли? :)

мне не кажется.

Нейроны — типично Smalltalk’овские объекты, доступные для модификации через саму нейросеть обменом сообщениями.

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

[user]mv[/user]

крупные идеи, которые за некоторое — относительно небольшое — время до сегодняшнего дня не использовались, по крайней мере, за пределами узких, малоизвестных областей

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

Идеальная парочка для нейросетей, блокчейна и прочего SAAS — это JS. Рассказать, почему?

Идеальная парочка для нейросетей, блокчейна и прочего SAAS — это JS. Рассказать, почему?

Конечно.

мне казалось, основной упор в них идёт на то, что все нейроны, по сути, одинаковы?

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

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

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

Используется там, где не нужно.

И хайпа ради.

Pharo это очень мощная среда которая в то же время подана в максимально простом для освоения виде

Python R.I.P.? Когда хороним? ^_^

Идеальная парочка для нейросетей… это JS.

Одно другому не противоречит. Семантически Smalltalk и JS — одного поля ягоды, но с разным вкусом :)

Ориентация на неизменяемые структуры данных не делает его «более ФП».

Конечно делает более, также как persistent data structures, STM, акторность / параллеллизм кругом -> подталкивает к написанию именно в фп-стиле. А зачем еще нужен фп, кроме гарантии однозначного соответствия между входными и выходными параметрами и более простого подхода к написанию многопоточных и асинхронных приложений? Ну там композиция ф-ций красиво все такое, но красиво только если ф-ции без побочных эффектов, иначе лишено смысла.

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

Че?

А хаскеле - да, неидеоматично, но Clojure может работать с контейнерами Java примерно так же, как обычный жава код

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

По этой причине она может заменить собой жаву с минимальными швами.

Ну как бы и отлично, о чем речь? (не везде, конечно, но все равно гуд)

Писать в фп-стиле на С на столько же сложно, на сколько и не нужно Да кучу функций библиотек в таком стиле написано

Еще больше написано не в таком :)

нет внешнего состояния, вывод и ввод не смешиваются - это хороший стиль письма на Си

Улыбнуло.

Язык может быть не современным и не устаревшим, и это, ИМХО, как раз C (и, возможно, Python)

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

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

По этим причинам устаревшими можно назвать: Cobol, Fortran, C, C++, Java, Python, PHP, Perl, Ruby - какие-то из них не позволяют использовать потоки, какие-то из них не позволяют писать за вменяемое время современные сложные алгоритмы. В этом списке я хотел бы подчеркнуть Java, как язык, а не как JVM, который вполне современный по моим критериям, поскольку требовательность к ресурсам нынче отходит на второй план, а простота кодописания обеспечивается отказом от Java в пользу человекочитаемых языков.

Раз говорите, что «устарели», то значит знаете как можно улучшить

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

Или вот, например: ограничение в 128 КБ на длину аргументов программы ничем не оправдано. На самом деле, проблема более фундаментальна, и вызвана опорой на строки, как наборы байтов, и строки, как линии на экране. Без решения этого вопроса никсы никуда не дальше не пойдут - они и не собираются, в общем-то: Firefox, Chromium, и прочий софт, который практически невозможно реализовать в юникс-стиле, будет с нами еще долго.

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

Далее: сеть. SSH и X11 - это мало, очень мало. Костылестроение не стоит на месте, решения для исправления слабой поддержки сети в никсах становятся всё лучше и лучше, что не отменяет фундаментальной проблемы - сеть в никсах хреновая. По этой причине современные сетевые приложения так яростно используют ioctl для работы с сетью, хотя, казалось бы, в POSIX сеть детально стандартизирована.

Там сейчас рыдания о том, что два основных основных разработчика перестали развивать проект /да и давно/, а новых разработчиков нет и не будет.
Почему?
Потому что разработка это не «щеки надувать в youtube и на конференциях»

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

Вы предлагаете писать свою операционку с нуля, что-ли?

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

[user]mv[/user]

Не знаю такого.

Да, знаю. Кое-что уже написал: нужно выкинуть форк и перестать требовать от ОС и системного софта его поддержку. …

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

Вот, к примеру, человек решил что-то поменять в мире IT https://www.cantorsys.com/p/about.html И взялся осуществлять свои идеи. Не скажу, что я полностью понял смысл самой задумки (хотя суть там - объектно-ориентированная ОС), и даже без разницы правильная ли там концепция выбрана, но впечатляет целеустремлённость автора.

STM

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

акторность / параллеллизм кругом -> подталкивает к написанию именно в фп-стиле

Не вижу взаимосвязи.

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

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

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

Че?

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

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

Кто предпочитает? Ты? За себя тогда явно и говори. Разраб Clojure прекрасно знает, что львиная доля реализации сделана на жаве, и нет никакого толку пытаться притворяться отдельным языком - это исключительно придаток для JVM и ее стандартной библиотеки классов.

Писать в фп-стиле на С на столько же сложно, на сколько и не нужно Да кучу функций библиотек в таком стиле написано

Еще больше написано не в таком

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

Может быть. Ну мы же говорим про передовые технологии, правильно?

То есть у вас есть готовый список по настоящему веских причин, чтобы пилить передовую ОС, не похожую ни на что имеющееся и несовместимую ни с чем существующим (в том числе и в плане прикладного ПО)?

Возникает вопрос - а какова конечная цель таких рассуждений?

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

Ведь ясно, что никто (абсолютно никто), прочитав подобного рода посты, не побежит менять существующие технологии

Никто ничего не пойдет делать, даже если я составлю детальный и безупречный план действий. Чтобы приманить современный планктон, нужна халява: акция, только сегодня, без смс и регистрации, скачать и установить. Сколько Торвальдс халявы выдал, сколько автор Clojure пахал над своим языком, даже богомерский питон - и тот был бесплатно дарован от Гвидо, и 20 лет после этого никто не мог выдать языка лучше, хотя предпосылки для улучшения реализации были - CPython уже на момент выхода был посредственным языком с большим кол-вом проблем.

Тем не менее слова «Да, знаю» в данном контексте подразумевают намерение предложить миру что-то своё, причём не на словах, а на деле

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

Вот, к примеру, человек решил что-то поменять в мире IT https://www.cantorsys.com/p/about.html И взялся осуществлять свои идеи. Не скажу, что я полностью понял смысл самой задумки (хотя суть там - объектно-ориентированная ОС), и даже без разницы правильная ли там концепция выбрана, но впечатляет целеустремлённость автора.

Меня больше удивляет то, что автор почти ничего не написал. Как в плане кода, так и в плане описания подробностей идей. Вот этот бред я не считаю продуктивной деятельностью:
https://www.cantorsys.com/p/halva.html

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

То есть у вас есть готовый список по настоящему веских причин, чтобы пилить передовую ОС, не похожую ни на что имеющееся и несовместимую ни с чем существующим (в том числе и в плане прикладного ПО)?

Да, есть:

• это круто;
• это очень круто.

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

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

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

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