Обсуждение

Я вот мучитально вспоминал сегодня: программировал ли я что-нибудь на каком-нибудь из прологов?

Лично про Вас -- не могу знать, но где-то возле Ринако, РТСБ и ФинансИста какое-то время делалась бухгалтерия (это было задолго до эпохи 1С), написанная на Прологе. Пролог был выбран за то, что это был единственный доступный язык, в котором не требовалось указывать длины текстовых полей в базе данных, всё было динамическим. Ну и да, сама база данных, встроенная в язык. А вот собственно логические фишки (бэктрекинг и унификация) только мешали. ;-)

... Асимметричный дуализм языкового знака ...

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

Может быть интересно. Сегодня послушал дядю из TIBCO про rule-based systems, complex event processing и т.д. Может бутет интересно: презентации http://www.tibco.com/solutions/bpm/iprocess-suite/default.jsp# блог http://tibcoblogs.com/cep/ А про семантику все сегодня говорили "У! Какая хорошая вещь. Только мы ещё не применяем: пользователи не готовы"

Не бухгалтерия, а реестр акционеров. Не Левенчук, а Акопянц. Но точно на РТСБ.

TIBCO является одним из главных участников OMG, ничего удивительного. Они драфтили существенную часть тамошних новых стандартов.

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

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

А бумажная документация от закупленного тогда фокса (/me скашивает глаза влево) вон она стоит. ;-)

... Правила давно знает, но иногда отвергает цели ...

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

Я в этих же тредах жаловался, что давно не слышал про "кремниевые компиляторы". Как же, вот они -- свеженькие поспели: http://techon.nikkeibp.co.jp/english/NEWS_EN/20090615/171747/. Компилятор из C прямо в кремний, C-to-silicon compiler. Вот еще три http://fpga.parallel.ru/lang.html

А лет через пять выяснится, что на C уже никто не пишет, кроме инженеров-электронщиков, которые на пишут чипы исключительно на нём :)

:) Я думаю кол-во инженеров-электронщиков пищущих на Си будет сравнимо с программерами пишущими на Си. В смысле что и тех и других будет мало в сравнении с программерами пишущими на ЯВУ, но они будут. Вот я к примеру иногда, хотя и крайне редко, пишу на Си, ибо Жабу надо интерфейсить с ДЛЛками. Т.е. Си часто является стандартным языком для организации межязыкового взаимодействия.

Кстати, сейчас часто софт очень близко ходит к компиляции в силикон. К примеру, я на выходных смотрел такую программу как Forge - это тулза для bounded model checking в частности программ для Жаба. Они соответственно берут Жаба программу, и разворачивают циклы ограничиваясь какой-то константой сверху, ну и размер памяти тоже ограничивают. Все это позволяет сконвертировать программу в булеву формулу (и по ней проверять выполнимость свойств). А булеву модель на силикон запихать - это уже давно отработанный механизм. Т.е. в принципе, поскольку "железно" заведомо ограниченно в количестве транзисторов помещающемся на кристалле, то можно писать проги на такой "ограниченной" Жабе и транслировать их в железо. Ну и разумеется такой подход годится для любого языка, ибо там ничего Жаба специфичного нет, стандартный компиляторно-анализаторский инструментарий. Собственно и сама тулза не джава-центричная, просто Жаба - первый язык, для которого есть трансляция во внутренний язык тулзы.

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

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

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

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

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

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

Это вряд ли. Если учитывать, что на C практически никто чипов сейчас не пишэт.

По этой причине я не верю в external DSL: общая задача создания нового языка так трудна, что инструментарием типа MPS ее не решить. Таким инструментарием можно упростить манипуляции с кодом, но это лишь верхушка айсберга. А проблему комплексирования разных формализмов такие тулзы не решают, и тому есть фундаментальные ограничения (вроде проблему NP-полных задач, но не только). Мне вот магистрально видится такой путь решения проблемы взаимодействие формализмов: 1. описание базовых формализмов на Higher Order Logic 2. создание тулзов которые умеют автоматически решать различные фрагменты HOL преимущественно фрагменты First Order Logic 3. создание тулзов автоматически извлекающих спецификации (работающих естественно не в 100% случаев) 4. ну и специальное образование + специальные юзерские интерфейсы, заточенные на интеграцию всего этого Условно - свести все к формальной логике и пытаться где можно решать задачу с помощью компьютера, в трудных случаях обращаясь за помощь к человеку. Такая комбинация уже сейчас может решать много проблем софтостроения полуавтоматически.