Обсуждение

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

Аббревиатура подходящая, LOL. Потому что у них http://xkcd.com/927/ Но, судя по уровню материалов, даже не попадая в competing. :) Концепты в мире и так хорошо идентифицированы. И замыкания/closures (правильно писать именно через s, а Clojure это название лиспоподобного языка под JVM), и классы, и указатели, и все прочие. Но в каждом языке своя специфика. Т.е. какой-нибудь класс в Python, C++, Java и Smalltalk это разные вещи, с разными правилами перегрузки, method resolution order и всего прочего. И чтобы их транслировать (хотя бы сигнатуры, даже не код методов) для каждого языка будут применяться совершенно различные алгоритмы. Различия этих классов не только в нотациях (парсинге), а ещё и в семантике. Нельзя совместить противоречивое, можно только выбрать один из вариантов, а затем "наши классы самые лучшие, пользуйтесь нашими классами". И если люди говорят об унификации, то они кого-то обманывают. Возможно самих себя. LOL. :) Сила, она не в абстрактной унификации неунифицируемого, а в хороших работающих компонентах. Вот у нас есть билдер в 15926-2 и 15926-7, а также writer результата в RDFXML. И применение соответствующее. Однако, я могу реиспользовать их же для любых RDF-датасетов. Так и в language workbench, если есть хороший writer для C-бэкенда или сразу ассемблера/байткода, то он может быть использован при трансляции разных языков.

Ой, я и впрямь clojure написал (вместо "замыкания" :-) Это я перед скоростным выбегом такое (эти строчки пишу в Нижнем). Что там классы! В Scratch предупреждается, что семантика циклов существенно отличается от многих и многих языков :-) Ну, есть разные мнения про "универсальность": -- универсальности вообще не бывает -- универсальность в нашем проекте, про другие не знаем -- универсальность только в данных -- универсальность только в коде -- универсальность в .... Конечно, универсальности нет. Мы сейчас с Виктором где-то час обсуждали разные мысли про .15926 как language workbench (ибо свет в конце этого низкоуровневого туннеля начинает уже мерцать), так именно так и обсуждали -- хороший бэкенд, универсальный (для наших целей, конечно) проективный фронтенд (желательно и с рендером -- "мастером отчётов"). И наше знание целевой предметной области, без которой никакое программирование вообще не нужно...

Странный какой-то этот LoL. Пережёвывает идеи MPS, которая не вчера появилась, не говоря уже о том, что существенная часть этих идей была в Лиспе, которому вообще сто лет в обед. Если говорить о language workbench на смолтолке, то в этом плане LoL не так впечатляет, как Helvetia (http://scg.unibe.ch/research/helvetia). Helvetia обладает большими возможностями, чем LoL, и не страдает при этом избытком болтовни про "Concepts", "Models" и "LOP".

Как я понимаю, вопрос в целях, а не реализации (хотя хорошая реализация часто удовлетворяет многим целям, но дальше вопрос патефона без пластинок: лучшие экспертные системы нам неизвестны, потому как с их помощью не было решено ни одной значимой прикладной задачи; лучшие языки нам неизвестны, потому как на них никто не написал ничего значительного -- и т.д.). Есть цели: -- поддержки создания произвольных DSL для новых предметных областей -- языковой интеграции (много разных языков в одном проекте) -- минимальной реализации, в которой "можно всё" -- но никто потом не разберется с результатом (тот же forth и STEPS) -- подставьте что-то своё Так что пока я не пойму, на какой предмет вы сравниваете LoL, заброшенную Helvetia и весь зоопарк многочисленных Java-бенчей, разговор будет не клеиться. Обратите внимание: я писал про выявляемое в LoL небольшое множество языковых концепций, отражающее максимальное множество разнообразных любимых белковыми сущностями по разным причинам имеющихся уже языков -- каковому небольшому множеству концептов можно было бы учить деток вместо обучения десяткам разных языков для разных целей. Это и есть для меня результат проекта -- но меня не волновала реализация как таковая. Это же множество концепций затем можно реализовывать хоть на Машине Тьюринга. Или брать идеи по выявлению этого множества концепций, и применять хоть к самим базовым языкам типа языка машины тьюринга, форта, смоллтока, лиспа и джавы -- не к ночи они все будь помянуты.

Да, я именно по этому поводу Есть цели: -- поддержки создания произвольных DSL для новых предметных областей -- языковой интеграции (много разных языков в одном проекте) и эти цели достигнуты на более-менее приличном уровне в MPS, Helvetia, Racket, чего про LoL не скажешь. Helvetia заброшена, да, но это не приговор, т.к. проект open-source, более того, изначальный автор не окончательно потерял интерес к нему. я писал про выявляемое в LoL небольшое множество языковых концепций, отражающее Ммм, они это множество нашли или, так сказать, цель поставили? Я попытался в их публикациях найти список выявленных концепций, и не нашёл. каковому небольшому множеству концептов можно было бы учить деток вместо обучения десяткам разных языков для разных целей Дилемма не вполне очевидная. Прошу прощения, если всё было разжёвано в прошлых записях :) О какого возраста детках идёт речь? Если о школьниках, то не достаточно ли будет их учить паре-тройке простых непохожих друг на друга языков, из нынешних? Ну например, Pharo+Racket+C. Вроде бы не "десятки" языков, а основные концепты охвачены.

Я тоже не нашел в LoL списка найденных концептов :-) но мне понравилось, что они именно эту задачу четко ставили, и пытались сделать для нее инструментарий (дальше вопрос: еще не решили, или инструмент неподходящий, или отвлеклись и бросили, или уже никогда не решат, или задача неразрешимая -- и т.д.). Да, я писал про обучение деток и языки несколько раз. Повторю кусочек: когда-то давным-давно (примерно в 1985-1987г.г.) была поставлена задача научения советских деток алгоритмике (которую обозвали информатикой, а компьютеров тогда не только в школах никто ни разу не видел, и IBM PC появился только в 1980 году, это нужно учитывать). Но тогда было уже много разных языков, ООП в моду уже не вошел, но от процедурных Фортрана и Паскаля уже сделали шаг к пакетным Модуле-с-номерами и Аде. И языков этих было пруд пруди, и нужно было отобрать небольшой набор концептов, и создать русскоязычный школьный алгоритмический язык. Этот язык был создан (Ершол), под него были придумана исполняющая среда ("нуль-компилятор" -- тогдашнее чудо программистской техники, еще такие компиляторы до кучи были созданы и для Фортрана и еще для чего-то, что уже не помню). Протестировано на многочисленных группах детей, что они получают переносимые на другие предметы и языки навыки программирования. Аналогичные идеи протестированы на вузовском (мехмат МГУ) курсе программирования. Сейчас делаются эксперименты по обучению начальных школьников цепочкой языков -- по мере нарастания мощности (например, ПиктоМир(близок к тайловым, и даже проще)+КуМир(уже текстовый)+НастоящийПитон). Но эти эксперименты только начинаются, я в них участвую. Задача стоит так: какого возраста дитенка можно научить настоящему программированию, и в каком объеме? Вот у меня третьеклассник сейчас мучается с типом данных "логическое" (а:=b=c) и передачей разнотипных параметров в процедуру и из нее -- уже в КуМире. Концепты же (разные виды циклов, разные виды операторов условия, переменная, параметр и т.д. -- если говорить о процедурных языках, исполнитель и его обстановки и команды, если говорить о пакетных языках, а для ООП всё не так уже очевидно с основными концептами) важны тем, что для овладения каждым из них нужно составить набор задач. А поскольку тренируем мозги, а не воспитываем прикладного программиста, то использование "промышленных языков" тут не являются критерием -- для этих задач можно сделать специальный DSL (где domain = образование).

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

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