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

Стереть грань можно только одним способом - отказаться от привычных приложений вообще

А что вместо них? Как разделить программы, чтобы выполнить «программы должны делать что-то одно»?

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

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

А что вместо них? Как разделить программы, чтобы выполнить «программы должны делать что-то одно»?

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

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

Суть всего этого вот в чём:

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

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

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

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

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

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

Функции «сложить» и «умножить»: любая из них выполняется при помощи другой. В первый список не попадёт ни одна?

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

Инструкция SUBLEQ?

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

Вторая проблема — производительность. Можно считать, что cat нужен, так как grep . делает то же самое, если не смотреть на скорость. А если учитывать производительность, то выясниться, что парсеров XML необходимо по крайней мере дюжина для разных случаев. И почти столько же библиотек работы со строками, матрицами и графами.

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

Если под «графическим интерфейсом» не подразумевается окно терминала с командной строкой, то как в графическом интерфейсе нарисовать что-то вроде: find | grep \\.java | wc

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

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

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

Так в кложе или racket тоже можно императивно писать и норм.

это относится к clojure - в последней есть как жавовые типы, так и изменяемая ячейка-атом.

Все верно, но не из-за джавовских типов. А просто just as planned. В кложе есть и мутабельные операции и побочные эффекты.

ФП нужно, чтобы оттягивать на себя поехавших математики, чтобы те не убивали прогрессивные разработки в IT,

Ну это ты явно про хаскель и подобное? У этих языков тоже есть свои цели - в первую очередь исследовательские.

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

На «чистым» фп ты имеешь ввиду? Так его чистого нигде и нет практически. Даже в хаскеле.

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

Ну тоже неплохо.

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

Это часто оправдано. А кое-где (clojure) есть persistent data structures и копировать ниче не надо.

Но неизменяемые структуры - это далеко не панцея, потому есть мало желающих резко переходить на них.

Основная как раз проблема с неизменяемыми структурами обычно на уровне компилятора находится, если в не реализованы persistent data structures, что приводит к оверхеду по памяти и производительности. В языках, где реализовано, таких проблем нет.

Я вот сейчас пишу свою либу на Си

А почему на Си, а не на плюсах, расте, D, кстати? Что за либа, что делает?

Истину вам говорю: алгол 60 и паскаль намного опередили свое время, до сих пор мало языков в IT до них доросло.

Да ладно :) ruby, python, smalltalk, tcl итд что не доросли что ли?

Большинство программ написано в смешанном стиле, даже на Clojure и Haskell. Вопрос тут скорее в соотношениях.

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

В Си есть примитив «получить n-й символ строки». В Rust есть примитив «получить следующий символ строки». Они легко реализуются друг через друга. Какой из них считать примитивней.

Тот, что более общий. И в идеале (одновременно) более низкоуровневый.

Вторая проблема — производительность. Можно считать, что cat нужен, так как grep . делает то же самое, если не смотреть на скорость. А если учитывать производительность, то выясниться, что парсеров XML необходимо по крайней мере дюжина для разных случаев.

Наверное, это должны быть один расширяемый стандарт / интерфейс. А какой алгоритм использовать, выбираешь опционально.

grep . мог бы быть просто чуточку умнее и реализовать cat. Без потери производительности.

Если под «графическим интерфейсом» не подразумевается окно терминала с командной строкой, то как в графическом интерфейсе нарисовать что-то вроде: find | grep \.java | wc

А что здесь может быть графическим кроме таблички? Стрелочек добавить, каких-нибудь связей (опять стрелочки), объемное представление 3d? Интерфейс взаимодействия мышкой, анимацию? гыгы :)

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

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

Это часто оправдано. А кое-где (clojure) есть persistent data structures и копировать ниче не надо.

А как проблема с массивами решается? Кстати и со строками тоже. Как в clojure будет реализовано без копирования (str a-string «1»)?

grep . мог бы быть просто чуточку умнее и реализовать cat. Без потери производительности.

То есть предлагаешь в каждой функции сделать кучу особых случаев?

А что здесь может быть графическим кроме таблички?

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

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

То есть вместо qstring_add(qstr1, qstr2) будет выполняться string_to_qstring(string_add(qstring_to_string(qstr1), qstring_to_string(qstr2)))? Тормозить будет адски. Поэтому каждый алгоритм придётся продублировать для каждого формата.

А как проблема с массивами решается?

Если тебе нужно миллиард инплейс изменений в массивах, то или надо брать не кложу, или использовать специальные библиотеки, заточенные под перформанс (в том числе на gpu) типа https://neanderthal.uncomplicate.org/.

https://dragan.rocks/articles/17/Clojure-Numerics-1-Use-Matrices-Efficiently

Кстати и со строками тоже. Как в clojure будет реализовано без копирования (str a-string «1»)?

Ты об этом спрашиваешь? https://practicalli.github.io/clojure-webapps/persistent-data-structures/ - ну так и реализовано.

Или я не понял вопрос и тебе надо потом что-то где-то менять инплейс после конкатенации?

grep . мог бы быть просто чуточку умнее и реализовать cat. Без потери производительности. То есть предлагаешь в каждой функции сделать кучу особых случаев?

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

А что здесь может быть графическим кроме таблички? Ты пишешь «командная строка и графический интерфейс должны быть равноценными в такой системе».

Вроде я так не писал. Я ответил на твой камент другому челу. Типа мимокрокодил просто.

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

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

Вот и пытаюсь понять, как это хотя бы теоретически возможно.

Мы че-то о разном по-моему совсем говорим. Если что я не отстаиваю (и даже почти не читал) точку зрения твоего собеседника.

То есть вместо qstring_add(qstr1, qstr2) будет выполняться string_to_qstring(string_add(qstring_to_string(qstr1), qstring_to_string(qstr2)))? Тормозить будет адски. Поэтому каждый алгоритм придётся продублировать для каждого формата.

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

А как проблема с массивами решается? Кстати и со строками тоже. Как в clojure будет реализовано без копирования (str a-string «1»)?

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

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

Функции «сложить» и «умножить»: любая из них выполняется при помощи другой. В первый список не попадёт ни одна?

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

Инструкция SUBLEQ?

Не, ну до крайностей доходить нет смысла

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

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

В Си есть примитив «получить n-й символ строки». В Rust есть примитив «получить следующий символ строки». Они легко реализуются друг через друга. Какой из них считать примитивней.

Это похоже на самый первый пример про «сложить» и «умножить». А раз так, значит оба будут в примитивах.

Если под «графическим интерфейсом» не подразумевается окно терминала с командной строкой, то как в графическом интерфейсе нарисовать что-то вроде: find | grep \.java | wc

Без разницы как - кнопками, блок-схемами, прыгающими объектами в трёхмерном пространстве, или как-то ещё. Это неважно. Тут важна эквивалентность команды терминала действию в графическом интерфейсе. У каждой текстовой команды (с параметрами или без), у каждого названия скрипта (также с параметрами или без оных) должен быть аналог в GUI. И наоборот, любой элемент GUI должен прежде всего генерировать текстовые команды. Такая двусторонняя эквивалентность - не прихоть, а целесообразное требование для возможности:

1. Быстрого прототипирования интерфейсов с последующим подключением прототипов к исполнителной логике (то бишь к примитивам)
2. Повторения любого действия или последовательности действий пользователя (как в GUI, так и в командной строке). А это нужно как минимум для записи макросов, которым потом можно назначить новый элемент интерфейса или передать другому пользователю по сети, или передать в общий репозиторий макросов.
3. При соответствии текстовых команд действиям в GUI решается также задача самодокументирования системы - когда запуск скрипта помимо воздействия на исполнительную логику, или даже без такого воздействия, указывает графическому интерфейсу какие кнопки нажимать, какие меню открывать, какие текстовые подсказки при этом писать, и т.д. Таким образом, запустив такой «обратный» скрипт, пользователь просто сидит и смотрит своеобразный интерактивный «видеоурок», реализованный силами самой системы.

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

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

Все верно, но не из-за джавовских типов. А просто just as planned. В кложе есть и мутабельные операции и побочные эффекты

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

Ну это ты явно про хаскель и подобное? У этих языков тоже есть свои цели - в первую очередь исследовательские.

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

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

Это часто оправдано. А кое-где (clojure) есть persistent data structures и копировать ниче не надо

Напомню, о чем был разговор:

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

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

Основная как раз проблема с неизменяемыми структурами обычно на уровне компилятора находится, если в не реализованы persistent data structures, что приводит к оверхеду по памяти и производительности. В языках, где реализовано, таких проблем нет

Это где реализовано? Песни про лисп-машины были уже давно, да только где эти машины теперь?

А почему на Си, а не на плюсах, расте, D, кстати? Что за либа, что делает?

Объектная база данных в памяти/STM.
На крестах я не пишу. D когда-то осваивал поверхностно, но у них стандартная библиотека до сих пор не умеет работать без сборки мусора - а я пишу расширение для питона. Раст я знаю поверхностно, но уже достаточно для того, чтобы догадываться, какие проблемы он может мне создать с областями видимости. Методом исключения остается Си, и еще паскаль (через Python4Pascal). Можно считать, что я решил не проверять, насколько легко писать на паскале расширения, а сфокусировался на написании самого расширения по кратчайшему пути.

Истину вам говорю: алгол 60 и паскаль намного опередили свое время, до сих пор мало языков в IT до них доросло.

Да ладно :) ruby, python, smalltalk, tcl итд что не доросли что ли?

Питон/руби - нет. Это оба языка с отвратительным подходом «спецификация определена через реализацию». Smalltalk - это не язык, а ОС. Как язык он за пределами своей ниши бесполезен. Tcl мне сложно оценить.

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

Эм-м-м... а тебя не смущает, что эта «нормальная конкурентность / многопоточность» написана на жаве? Например, vector - это минимальный интерфейс к src/jvm/clojure/lang/LazilyPersistentVector -> src/jvm/clojure/lang/PersistentVector.

Haskell - это такой же Brainfuck, только в облегченной версии: он делает написание простых программ сложным, а сложных - невозможным. За исключением написания компиляторов.

Только если по религиозным соображениям не использовать монаду IO. Практически любую программу на Си можно переписать на Haskell подстрочником.

А отдельные классы подпрограмм (функции, результатом которых является преобразование аргумента) на Haskell пишутся намного проще.

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

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

А ещё есть такая текстовая команда, как perl. Ей тоже «perl в картинках» обяжем придумать?

Если нужен другой формат, то и алгоритм, вероятно, будет использоваться другой.

Алгоритм сложения строк всегда один и тот же: получить длину результата, получить память под результат, скопировать первую строку, скопировать после неё вторую строку.

А вот формат строк может быть крайне разным: ASCIIZ, питоновские, пара указателей, массив юникодных графем, массив юникодных кодов символов, массив UTF-16, …

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

Алгоритм сложения строк всегда один и тот же Сложение строк надо будет либо писать под каждый тип данных

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

А вот формат строк может быть крайне разным

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

Сложение строк надо будет либо писать под каждый тип данных (тогда будет много «велосипедов»)

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

либо преобразовывать в некую стандартную «строку»,

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

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

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

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

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

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

А ещё есть такая текстовая команда, как perl. Ей тоже «perl в картинках» обяжем придумать?

Текстовые поля (выбор по списку, вставка своего текста, и пр.) в GUI никто не отменял. Поэтому для особых случаев они и будут использоваться. Как пример, в текстовом редакторе Notepad++ (или в его линуксовом аналоге Notepadqq) регулярные выражения при поиске и замене ведь можно вписывать обычным образом, то есть в текстовую строку.

То есть получаем те же приложения, но под другими названиями

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

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

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

Практически любую программу на Си можно переписать на Haskell подстрочником

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

А отдельные классы подпрограмм (функции, результатом которых является преобразование аргумента) на Haskell пишутся намного проще

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

sqrall :: [Int] -> [Int]
sqrall x = map (^2) x

IntArray *
sqrall(IntArray *x) {
   IntArray *rslt = malloc(sizeof(IntArray) * x.length);
   for (int i = 0; i < x->length; ++i) {
       rslt->data[i] = x->data[i] * x->data[i];
   }
}

IntArray *b = int_array_map(a, {
    y = x * x;
})

На самом деле предлагается ОС как система программирования. Как это сделано в имаксе, в блюботтл и прчих оберон системах, да и том же Паро смалтолк. Тоесть у нас пользовательская сторона ос не набор программ и какой-то клей для них в виде скриптов или механизмов ос для дёрганья разделяемых библиотек, а набор сущностей (не обязательно объектов в смысле ооп подхода) среды программирования + визуальные красоты для работы с ними. Пользователь может или работать с этими сущностями, как с чем-то изолированмым и тогда это аналог команднострочных утилит, может на языке этой системы программирвоания что-то комбинировать из них для своих нужд, может полностью заменить их сохранив только интерфейс низменным. Помню меня восхитила в ОС Блюботтл на обероне возможность в командной строке написать что-то вроде ОбъектЯдроОС.ПлучитьСписокЗапущеныхПроцессов() и получить список процессов, который можно дальше использовать или в программах или просто напечатать. Жаль, что такой подход к построению вычислительных систем не получил развития и мы вынуждены жить в мире костылей и подпорок.

Помню меня восхитила в ОС Блюботтл на обероне возможность в командной строке написать что-то вроде ОбъектЯдроОС.ПлучитьСписокЗапущеныхПроцессов() и получить список процессов, который можно дальше использовать или в программах или просто напечатать. Жаль, что такой подход к построению вычислительных систем не получил развития и мы вынуждены жить в мире костылей и подпорок

WMI, PowerShell:

Get-WmiObject -Computer 10.216.25.157 -Credential ocdomain\dawnr -Namespace "root/cimv2" -Query "select * from Win32_ComputerSystem"

Я уже давно пишу, что юникс устарел - даже оффтоп уже заметно опередил никсовую консоль по мощи языка.

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

На самом деле предлагается ОС как система программирования. Как это сделано в имаксе, в блюботтл и прчих оберон системах, да и том же Паро смалтолк.

Да, мы все скучаем по lisp-os :(

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

В чем принципиальное отличие?

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

А сейчас оно не так?

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

«низменные интерфейсы» звучит интересной концепцией :) Вы могли бы расписать ее поподробнее?

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

Каким образом и почему сейчас так нельзя, через дополнительную прослойку?

Потомучто я нигде за пределами повершелла это использовать не могу

WMI работает везде.

Каким образом и почему сейчас так нельзя, через дополнительную прослойку?

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

А сейчас оно не так?

Сейчас у нас программы, данные и сама ос сильно отдельные сущности. А в системах, которые описывал выше всё есть объект этой системы программирования, апи которого легко дёргается откуда угодно. Тоесть ос у нас как бы иде для работы с объектами самой себя.

Clojure здесь выполняет роль порта лиспа на платформу JVM.

Удивительное рядом.

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

Я бы еще обучающие цели добавил.

Haskell - это такой же Brainfuck, только в облегченной версии:

Согласен, машина тьюринга это более сложная концепция, чем лямбда-исчисление.

он делает написание простых программ сложным, а сложных - невозможным.

А невозможных подымает в сферу непознаваемого. А ты говоришь, язык не нужен.

За исключением написания компиляторов. Можно сойтись на том, что Haskell - это DSL для написания компиляторов.

Haskell можно считать экспериментальной веткой OCaml для увлеченных.

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

С постоянным копированием тормоза не заставят себя ждать. Даже без бигдаты.

Основная как раз проблема с неизменяемыми структурами обычно на уровне компилятора находится, если в не реализованы persistent data structures, что приводит к оверхеду по памяти и производительности. В языках, где реализовано, таких проблем нет

Это где реализовано?

clojure?

Песни про лисп-машины были уже давно, да только где эти машины теперь?

Лалалла, лисп-машина, лалала the land of lisp, машин нет, но песни-то песни остались!!11 https://www.youtube.com/watch?v=HM1Zb3xmvMc

И есть даже в этом треде парой постов выше.

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

Какие там проблемы с областями видимости? Адепты вроде как радуются-ненарадуются модульной системе раста по сравнению с С/С++.

Истину вам говорю: алгол 60 и паскаль намного опередили свое время, до сих пор мало языков в IT до них доросло.

Да ладно :) ruby, python, smalltalk, tcl итд что не доросли что ли?

Питон/руби - нет. Это оба языка с отвратительным подходом «спецификация определена через реализацию».

Странный критерий для утверждения «не доросли».

Smalltalk - это не язык, а ОС. Как язык он за пределами своей ниши бесполезен. Tcl мне сложно оценить.

Какая ниша у смолтолка? Программирование в образе это тоже ос, а не методология разработки?

Tcl мне сложно оценить.

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

Эм-м-м... а тебя не смущает, что эта «нормальная конкурентность / многопоточность» написана на жаве?

Нет. Точно так же, как не смущает, что большинство компиляторов написано на С и С++.

Например, vector - это минимальный интерфейс к src/jvm/clojure/lang/LazilyPersistentVector -> src/jvm/clojure/lang/PersistentVector.

Как страшно жить.

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

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

Haskell можно считать экспериментальной веткой OCaml для увлеченных

Наследование такое: ML -> Miranda -> Haskell. А Brainfuck можно считать экспериментальной веткой C.

С постоянным копированием тормоза не заставят себя ждать. Даже без бигдаты.

Мой компьютер килобайтный массив копирует примерно за 250-300 циклов. Стоимость операции изменения общей памяти из общего кэша - порядка 30 циклов умножить на кол-во потоков.

Основная как раз проблема с неизменяемыми структурами обычно на уровне компилятора находится, если в не реализованы persistent data structures, что приводит к оверхеду по памяти и производительности. В языках, где реализовано, таких проблем нет

Это где реализовано?

clojure?

Это реализовано в коде на Java. Но компилятор Java не поддерживает то, что ты говоришь. Не знаю что конкретно, но точно не поддерживает.

Адепты вроде как радуются-ненарадуются модульной системе раста по сравнению с С/С++

Модули - это очень хорошо, но удобство языка складывается из множества факторов. На расте можно тоже писать код в духе «ехал unsafe через unsafe», но будет длинно и нечитаемо.

Странный критерий для утверждения «не доросли»

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

Какая ниша у смолтолка? Программирование в образе это тоже ос, а не методология разработки?

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

Такая же скриптота как питоноруби, только с гомоиконностью и специфическим понятием базового объекта манипуляции

У Tcl нет гомоиконности, потому что язык не предоставляет инструментов для изменения кода. И нет, изменение кода через регулярные выражения не прокатывает, потому что регулярки внезапно становятся другим языком, снова ломая гомоиконность.

Точно так же, как не смущает, что большинство компиляторов написано на С и С++.

Только src/jvm/clojure/lang/PersistentVector - это не компилятор, если чо. Это примерно как список в питоне или ввод-вывод в Си - тесно интегрированные с языком функции библиотеки. И никому в голову не придет сказать, что библиотека питона, включая базовые типы, написаны на питоне - они таки написаны на Си. Как и типы clojure не написаны на clojure - они написаны на жаве. Это не код, который компилируется в жаву - это изначально жава.

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

«Не читал, но осуждаю». Какие, к маше, отзывы работавших ? VisualWorks - это класическая, а не «визуальная» IDE.

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

Я где-то упомянул «rapid development» или ты сам додумал ? VW - это типа Netbeans\Eclipse только со SmallTalk’ом вместо Жабы, и намного удобнее.

Мой компьютер килобайтный массив копирует примерно за 250-300 циклов. Стоимость операции изменения общей памяти из общего кэша - порядка 30 циклов умножить на кол-во потоков.

Попробуй поработать хотя бы с 10-гигабайтными массивами (это не бигдата) потом расскажешь.

Это реализовано в коде на Java.

Какая разница, что под капотом? В python или CL тоже потроха на С написаны, и чо?

Но компилятор Java не поддерживает то, что ты говоришь.

Это реализовано на уровне библиотеки.

Не знаю что конкретно, но точно не поддерживает.

:)

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

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

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

И ненужно.

просто херак-херак - и в продакшн

Быстрое прототипирование это здорово, я с тобой согласен ;)

В большинстве случаев алгоритмы не делятся на независимые объекты

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

Даже достаточно сложный классический (современный) GUI уже не делится на объекты, а представляет собой тесно связанные механизмы.

Ты про FRP и автоматное программирование? Да, это клевенько.

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

А какие средства по-твоему лучше реализуют данных подход? Или набор средств (в контексте связанности-развязанности).

У Tcl нет гомоиконности

You’re wrong

потому что язык не предоставляет инструментов для изменения кода

Гомоиконность - позволяет проще модифицировать сам язык, но не обязывает поддерживать какую-то макросистему. Метапрограммирование возможно и в системах без полноценных макросов, и вообще без макросов. И даже без гомоиконности (внезапно). Просто это будет выглядеть менее задорно.

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

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

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

Гомоиконность это не писаная торба. Макросы, например, которые вводят новый синтакис в некоторой степени «ломают» не только синтаксис, но и семантику. Но оно именно вот так и надо, иногда внутри гомоиконного языка (eDSL), а иногда и вместо (DSL) - отдельным модулем, либой, языком.

Только src/jvm/clojure/lang/PersistentVector - это не компилятор, если чо.

Да, это библиотека.

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

А я нигде и не говорил, что кложа написана только на себе самой. Другие высокопроизводительные компиляторы, например CL, SBCL написаный в значительной мере на С. Это не мешает лиспу быть крутым рантаймом и оставаться лиспом, а не просто «скриптухой» над С.

Как и типы clojure не написаны на clojure - они написаны на жаве

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

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

Не все языки подходят для написания низкоуровневых примитивов. Но clojure, я уверен, тоже будут максимально бутстрапить со временем. И условной «джавы» останется ровно столько, сколько нужно. Точно так же, как это происходит с другими компайлерами лиспа.

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

Владимир

«Не читал, но осуждаю». Какие, к маше, отзывы работавших ? VisualWorks - это класическая, а не «визуальная» IDE

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

Я где-то упомянул «rapid development» или ты сам додумал ? VW - это типа Netbeans\Eclipse только со SmallTalk’ом вместо Жабы, и намного удобнее

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

Попробуй поработать хотя бы с 10-гигабайтными массивами (это не бигдата) потом расскажешь

Для начала придумай мне практическую задачу (не «вот у нас в институте однажды нужно было»), для решения которой понадобится массив размером хотя бы 100 Мегабайт.

Какая разница, что под капотом? В python или CL тоже потроха на С написаны, и чо?

А то, что нет никакой разницы в том, на каком языке будут написаны запускалки к этим библиотекам. Реализация библиотеки CPython - это заслуга языка Си, который привнес свои ограничения и особенности реализации. Реализация питона на собственном компиляторе, RPython, дала совершенно иную среду, с JIT компиляцией, насквозь оптимизирующей код сквозь стандартную библиотеку - Си такого не позволял делать.
В случае Clojure особенности реализации типов определяются языком Java, поскольку именно на нем они написаны. Посмотри на ClojureScript - это ведь совершенно другой язык, который лишился жавы, а вместе с этим лишился хваленой многопоточности. Их потому разными именами и назвали, но и общее слово в именах есть.

Это реализовано на уровне библиотеки

Вот и я о том же. Есть аналогичные библиотеки для жавы, я уже давал ссылку на библиотеку для C++ - и там нет никакой clojure.

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

Не помню такого. Это точно я был?

Ф-ция как объект первого класса это тоже «объект».

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

Даже достаточно сложный классический (современный) GUI уже не делится на объекты, а представляет собой тесно связанные механизмы.

Ты про FRP и автоматное программирование? Да, это клевенько.

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

А какие средства по-твоему лучше реализуют данных подход? Или набор средств (в контексте связанности-развязанности)

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

Гомоиконность - позволяет проще модифицировать сам язык, но не обязывает поддерживать какую-то макросистему. Метапрограммирование возможно и в системах без полноценных макросов, и вообще без макросов. И даже без гомоиконности (внезапно). Просто это будет выглядеть менее задорно.

Опять несостыковка определений:
«A language is homoiconic if a program written in it can be manipulated as data using the language, and thus the program's internal representation can be inferred just by reading the program itself»
Код нельзя изменять как структуру данных самим языком? Нельзя - значит, язык не гомоиконен.

Но clojure, я уверен, тоже будут максимально бутстрапить со временем. И условной «джавы» останется ровно столько, сколько нужно. Точно так же, как это происходит с другими компайлерами лиспа

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

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

Хоть один человек понял «что такое Си и для чего он» /это радует/.

Владимир

У этих языков тоже есть свои цели - в первую очередь исследовательские.

У этих языков одна цель — давать меньше возможностей скомпилировать потенциально ненадёжный код.

У этих языков тоже есть свои цели - в первую очередь исследовательские.

У этих языков одна цель — давать меньше возможностей скомпилировать потенциально ненадёжный код.

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

У этих языков одна цель — давать меньше возможностей скомпилировать потенциально ненадёжный код

Мертвый негр не идет играть в баскетбол.

Обязательно сообщу своим неграм на поле, что они мертвы.

shpinog

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

Bagrov

Я бы, например, мог помочь с формальным описанием языка. 

Ну так открывайте тред и формируйте сообщество.

PS: Пластинка Метапрог уже давно заела.

https://www.youtube.com/watch?v=h7r9qwY879I
https://www.youtube.com/watch?v=3aVt9Rrz2A8

Владимир

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

просто Вирт ещё тогда начал упрощать, выдав Algol-W. в алголе 60 несмотря на сложности в реализации были и преимущества, например та же семантика call-by-name. вообще конструкции мощнее потому что блоки. потом, альтернативный синтаксис в духе лисп-выражений (или это уже в алголе 68?)

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

Это очень весёлое чтиво

да стебётся он там.

любопытно что «почему я не использую паскаль» Кернигана совершенно иррелевантно относительно Ады, а ведь это стандарт 83 года, работы начиная с 1978 года, ну то есть, и кроме турбо паскаля что-то было, нормальный же паскаль эта Ада, только широким народным массам типа Кернигана толком не известный. опять же, в 5 языков прототипов выбранных для Ады Вирт вроде тоже каким-то образом просочился.

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

как будто что-то плохое. тогда это было модно, тот же Ноам Хомский со своими грамматиками, например. или «структуральнейший лингвист» у Стругацких. или метакомпилятор META by Henry Barker, ЕМНИП, ещё курс по нему есть, технология как раз из конца 60-х.

или Xanadu это наше всё AUGMENT, NLS by Doug Engelbart, который ещё мышку изобрёл. там тоже были tree grammars настраиваемые по правилам, по которым можно было команды и действия, триггеры запускать. кто сказал machine learning? не, просто обычный интеллект аугментированный (не искусственный идиот) – человеко-машинное взаимодействие, где тулзы машинные человека не ограничивают тыкалкой в браузер в бесконечных свитках уеб-страниц, а наоборот, развиваются вместе с ним и развивать помогают. в духе наноаугментированных из Deus Ex, лол.

Типа «сделай свой язык сам» и «у вас не получается пользоваться нашим языком? Вы просто не умеете его готовить». Таким образом коммитет снял с себя ответственность и выдал совершенно бесполезный язык.

а потом бесполезный Д. Кнут выдал бесполезный WEB и литературное программирование, лол. где сам язык WEB можно рассматривать как метаязык (ну или M4 из configure это тоже мета), в духе теории кибернетической эволюции как развития метасистем и метасистемный переход В. Ф. Турчина.

где в этом метаязыке есть чанки, без параметров. то есть, метапроцедуры (макросы) и метапеременные (которых нет). которые раскрываются в call-by-name семантике, в удобном порядке перечисленном логикой «литературного» повествования (а не навязанном языком программирования, например неудобным паскалем).

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

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

время было такое – структуральнейшим казалось что нашли свой золотой молоток.

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

вообще в современном формате блогозаписей блогозапись это и есть метауровень человекопонятного простого текста, на его естественном метаязыке. а «блок кода» или чанки – уровень кода на ЯП, а «алгоритмы+структуры данных=программа» -> структуры и модели данных – уровень онтологий и метамоделей данных на ЯД, языке описания данных, ещё один метауровень.

и совместная коэволюция бутстрап систем – в духе метасистемного перехода.

ну да, совершенно бесполезный язык. конечно же. ога-ога.

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

в 60-е с «аугментированным интеллектом» (not artifical intelligence, but augmented intellect) в этом направлении было много экспериментов.

суть которых можно свести к тому же условному Xanadu – многомерной текстовой (и даже, гипертекстовой, лол) виртуальной реальности, настраиваемой пользователем под себя и свои потребности, и вместе с собой и этими потребностями развивающейся, типа метапрог изнутри «сам на себе» (ну или емакс с org-mode)

а потом пришли упрощенцы и «женщину вынули, робота засунули. а ему чатлы нужны». с браузерами и яваскриптом.

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

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

свою виртуальную гипертекстовую реальность.

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

но это текстовое программирование же, лол. даже не гипертекстовое.

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

В том числе MS Excel. Стала жирнее оперативка - расширили строки. В том числе в MS Excel

там, ЕМНИП, Joel Spolsky кажется вспоминает, как дело было. где-то в экселе есть P-code и вирутальная машина паскаля. потому что какой-то код в ёксель 1985 года ещё был написан, и когда виндоофисы вышли, виртуальную машину спортировали, и тот же самый код сразу заработал, под все платформы сразу (дос/вин3.1/мак классический).

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

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

тот же метаобъектный протокол CLOS из CL, мультиметоды в CL или в Julia или метаклассы смоллтока – это более расширяемая архитектура. Eclipse в начале 2000 это переписанный на Java Visual Age смоллток от IBM, сохраняя в основной сути его архитектуру из 90х.

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

Много чего не вписывыается в объекты, просто это НЕ одна из таких вещей.

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

кто все эти люди, и что практически они на нём написали? если бы они хотя бы скачали ту же Pharo by example, проработали её по шагам – уже бы что-то поняли про этот язык. но они этого не делают, ибо думают что «уже знают этот язык», хотя знают по чьему-то мнению а не реальному опыту. ценность такого опыта 0 или даже отрицательная.

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

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

о том, что смолтолк скорее претендует на роль операционной системы, нежели просто языка. Я имею в виду образы как аналоги файлов в виртуальной машине, и взаимодействие акторов-объектов как аналогов процессов. Именно потому, что это операционная система и он пытается заменить собой функции операционной системы, он будет невостребованным - в IT мода на ОС крайне инертна, новых никто не разрабатывает - в лучшем случае переписывают старые. Возьмите тот же линукс - у него корни тянутся с однозадачной ОС 60-х годов. Это я сейчас имею в виду в том числе фундаментально однопоточный fork, который устарел лет так 30 назад и теперь сильно затрудняет любую системную разработку необходимостью постоянно оглядываться на поддержку fork-а. Да, как ОС Smalltalk смотрится заметно продвинутее никсов - и чо?

ну исследования в области системного ПО нерелевантны.

можно сколько угодно воздыхать на эту тему, но делу это не поможет. когда авторы Plan 9 поняли, что Unix движется куда-то не туда, и «товариси, мы осибалися. вся эта программная ко революция операционных бутстрап-систем уже превратилась в контрреволюцию. так что революция отменяецца, а теперь – дискотека!».

POSIX уже был симптомом, что Unix превратился в зоопарк несовместимых с друг другом реализаций, и автолулзный ./configure.sh пророк его!

в такой ситуации ничего изменить не возможно, Unix уже good enough, а лучшее – враг хорошего, поэтому никто менять и не будет (как и заметил Эрик Реймонд в Art Of Unix Programming).

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

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

когда авторы Unix, поэкспериментировав с System 7, System 8, STREAMS поняли что «классический юникс» движется не туда – они не штурмовали броневичок, а написали свой ответ Чемберлену. типа, я ж тебя породил, я же и переделаю как бог черепаху.

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

и в rio когда стало ясно что реформировать X11 дальше невозможно ибо он совсем уж FUBAR (fucked up beyond any repair) – они придумали свой дизайн non-blocking lock-free window system.

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

потом когда стало ясно что сам по себе Plan 9 никому особо не нужен, ибо Linux is good enough – переписали его под виртуальную hosted os систему, в виде Inferno и Limbo/Dis VM.

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

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

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

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

нужно пилить midipix, а не этот не доделанный MINGW. в котором от зависимости от msvcrt.dll никогда не избавяться.

ну и/или, допилить до ума POSIX слой в ReactOS и бекпортировать туда и оттуда.

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

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

собственно как и с акторами в смоллтоке и каком-нибудь ЯП Pony (среда типа сишечка, типа LLVM, а по сути всё то же самое).

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

как ОС и SmallTalk, и Active Oberon, и Limbo/Inferno заметно продвинутее никсов. да тот же эрланг.

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