Обсуждение

Динамика может быть и контрреволюцией В программировании dynamic scope - зло. Да и динамическая типизация редко бывает полезна.

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

Любая революция поначалу объявляется контрреволюционной ;) Это известная вещь: пре-пост заблуждение (всё, что не текущий мейнстрим объявляется "прошлым", хотя часть объявленного на самом деле является будущим). Поглядим. Пока у этого виден только один серьезный недостаток: построить такие программирующие среды много сложней, нежели текущие. Хотя пользоваться может быть проще (но и это не факт: тем, кто привык понимать, к каким командам на ассемблере ведут их строчки на языке высокого уровня, тоже может быть не сладко).

Ролик про совсем другое. Насчет словесного поноса: для пятиклассника лекция по дифурам -- словесный понос, не так ли?

Да нет, почему же. Вы ведь в курсе про Лисп и эквивалентность времени компиляции времени выполнению в Лиспе? В ролике просто наглядно показано, как можно программировать параллельно с выполнением программы и одновременно её изменять. В упрощенном виде такоеинтерактивное программирование присутствует скажем в Unix Shell или в PREL (print-read-eval loop) современных и не очень языков программирования (tcl, ruby, scala и многих других). Или вы что-то другое понимаете под "интерактивным программированием"?

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

1. Вы вначале говорили про "эквивалентность времени компиляции времени выполнения, инкрементальность вычислений", а теперь упоминаете о некой "скомпилированной" программе. 2. Непонятно, о "шевелении" какого вида речь. Если программа скомпилирована из языка высокого уровня в машинный язык, то изменения синтаксиса языки и семантики этого самого языка высокого уровня на программу никак влиять не могут, так как компиляция уже произошла. Если вы подразумеваете, изменение синтаксиса и семантики машинного языка, скажем, изменение набора процессорных инструкций, то ваше высказывание возможно имеет смысл, но не понятно, при чём тут слово "интерактивность". А может быть, вы запутались в абстракциях и в аналогии с дифурами и пятиклассником выглядите как пятиклассник ;-( ЗЫ: Я честно по долгу службы пытаюсь разобраться в системной инженерии, MBSE, UML, SysML, AADL других странных шутках, но постоянно натыкаюсь на техническую отсталость и пренебрежение существенными деталями в материалах OMG, INCOSE, STEP и иже с ними.

1. Ну да, так и говорю: с точностью до того, что не любое преобразование (трансформацию) можно назвать "компиляцией" (так, суперкомпиляция формально компиляцией не является). Кроме того, меня не всегда интересует "программа" -- данные это или программа может быть выяснено когда-нибудь потом. Я ведь регулярно имею дело с какими-то САПР, и там необязательно в конечном итоге что-нибудь "выполняется" в привычном для программистов смысле слова. 2. На тех уровнях абстракции, о которых мы говорим, нельзя говорить о "машинном языке" (хотя можно перейти на язык "исполнителей" и "выполнителей" -- правда, с осторожностью. Ибо в оригинале эти термины были введены для императивных языков, а у нас совсем не факт, что что-то "выполняется". Может и "оцениваться", например). 3. Интерактивность тут важна. Представим, что у вас есть много-много гигабайт информации в большой-большой базе данных по модели какой-нибудь атомной подлодки (4млн. индивидуальных деталей, каждая из них описана с точностью, достаточной для изготовления + все имитационные модели с этим связанные). И вы потихоньку развиваете ту сотню языков, на которых написана эта вся общая и связанная модель. И вам важно, чтобы целостность этой модели не была потеряна в ходе развития ваших DSL -- ведь на прежних версиях DSL много-много уже было разработано! Тут можно работать в разных подходах: изменения модели данных без остановки базы данных (только тогда вылетает презентационная семантика, что может оказаться важным), "компиляции другой версией компилятора" -- но все в этой модели давным-давно откомпилировано "на лету" и т.д. Насчет того, что я запутался в абстракциях -- так наверняка. Я и пятиклассником соглашусь стать, нет у меня гордыни. Но нюх на новенькое у меня хорошо развит, и я (как показывает опыт) узнаю новенькое достаточно загодя. MBSE -- сейчас практически ничего нельзя сказать на эту тему, там пустое место, только базовое словосочетание. У меня 28 декабря 2009 в спецвыпуске INCOSE INSIHGT, посвященном MBSE как раз выходит статья, где я бодро предлагаю свое наполнение этого пока пустого термина (по-русски я пересказал основные мысли тут: http://ailev.livejournal.com/728605.html -- хотя в английском варианте было много уточнений). UML, SysML я считаю недоразумением, AADL развитием этого UML-недоразумения. STEP уже отстал навечно от ISO 15926. Про пренебрежение существенными деталями в материалах OMG и INCOSE мне можно не рассказывать, я с этим сталкиваюсь ежедневно. Так что ничего нового вы мне не открыли. Но я походил по базару, и более продвинутых и внятных тусовок не обнаружил (ISO 15926 при ближайшем рассмотрении ведь тоже оказывается местом, где "пренебрегают существенными деталями" -- но поставщики САПР говорят, что это первый стандарт, который позволил передать всю информацию между САПРами, а не только часть информации).

Спасибо, что не забанили, я объяснили. Пока что мы разговариваем на разных языках. Пошёл читать вашу статью про MBSE и материалы про ISO 15926. Ещё вернусь ;-)

Материалы по ISO 15926 отнюдь не все в открытом доступе (даже наоборот). Обращайтесь, ежели что. В открытом доступе по ISO 15926: Основная информация сейчас на https://www.posccaesar.org/wiki/ISO15926Primer Интересные ссылки есть и на https://www.posccaesar.org/wiki/ISO15926 Ссылки к онлайновому доступу ко всей надстройке (примерно 50 тыс. понятий): https://www.posccaesar.org/wiki/Rds

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

Обычно переход от статики к динамике во всех науках означал крутую революцию. Может, компьютерная революция как раз где-то в этом месте? Все как раз на это указывает, даже то, что эти "интерактивные подходы к программированию" сейчас являются вполне себе rocket science даже для хардкорных нердов. Я бы сказал что все больше набирает силы декларативный подход, который по не очень мне понятным причинам вдалеке от мейнстрима, но который гораздо более крутой. Хотя последнее обычно и называют причиной непопулярности - по принципу, worse is better.

На тех уровнях абстракции, о которых мы говорим, нельзя говорить о "машинном языке" (хотя можно перейти на язык "исполнителей" и "выполнителей" -- правда, с осторожностью. Ибо в оригинале эти термины были введены для императивных языков, а у нас совсем не факт, что что-то "выполняется". Может и "оцениваться", например). Если оценка формализована, то это сводимо к выполняется на специфичной абстрактной машине. К примеру, в Coq, доказательство теоремы, сводится к конструированию функции, которая потом "оценивается" системой: система вычисляет ее тип, ну и проверяет, что он сводим к целевому типу (то что нужно доказать, формулируется в виде типа). Поскольку proof-term редко конструируют вручную, то программер пишет всякие конструкции/программы, которые вычисляют доказательство (транслируются в него), а потом система оценивает, что получилось то что нужно.

Вот-вот: суп из топора. Но это общий тренд: чтобы получить "более простой и декларативный" спецязык нужно воспользоваться "более сложным и более декларативным" общим языком, а то и несколькими. Я ведь согласен: все это резкие движения в сторону разнопарадигмальности. Ибо сказать "декларативный" -- это всего-навсего "неимперативный", т.е. парадигм в этом может быть миллион и маленькая тележка. Однако замечу, что передо мной лежит сейчас книжка Metamodeling for Method Engineering (http://mitpress.mit.edu/catalog/author/default.asp?aid=36884), которую увезут сейчас в Питер. Так в этой книжке определяется "универсальный моделер для моделирования всего" -- а внутре у него логики первого порядка. Эти логики первого порядка сейчас торчат изо всего, уже неинтересно. Интересна история, которую рассказывают про эти логики ребята из ISO 15926: -- сначала моделируем ортогональное описание мира в небольшом количестве понятий (у них это 201 понятие) -- на этих понятиях моделируем протошаблоны наших высказываний (ожидается, что их будет около 300) -- а на этих протошаблонах уже описываем мир, вводя по пути шаблоны и целые OIM. Все это высокоуровневое уже и может быть с приличными нотациями, которое быстро прощелкивается до исходной FOL. Несколько лет назад рассуждали по-другому: ежели FOL, то подъем уровня языка проходил без изменения синтаксиса, и это было нечитаемо и неописуемо абсолютно. А сейчас основной тренд: исходную непривычность для мозгов прятать под капот каких-нибудь workbenches.

Крутость телевизора тоже раньше не могли прятать вовнутрь: я помню, у моего телевизора по шесть рукояток типа "частота кадров" сбоку торчала. Сейчас все это упрятали. Все эти workbenches по сути сводятся к projector editors: модные штуки из сферы накручивания нотаций на метамодель. То есть вся сложность уходит в интерфейс, а не в собственно движки.

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

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

В точку. Я сейчас как раз про это пост планирую написать: про онтологию и нотацию. И про "отладку".

ФОЛ - хорошая штука, но для всего не потянет :). В частности, на ней невыразима проблема связанности графа. Ну и там всякие обходные пути довольно громоздкие, при том что ФОЛ реально плохо читаема (особенно если не sorted). Для целей ИСО конечно ее достаточно, фактически там достаточно более простой Дескрипшн Логики, которая дисайдабл (т.е. есть автоматическая процедура принятия решений верна формула или нет). Интересен подход ФОЛ+мета-программирование. Т.е. некие макросы для генерации ФОЛ выражений - что-то вроде ИСО 15926 темплейтов. Так действительно можно сделать понятнее записи (особенно если есть обратное преобразование: из ФОЛ в темплейты, распознование темплейтов). Плюс это позволяет частично компенсировать отсутствие Хаер Ордер фич.

Именно! Эти ребята из ISO 15926 как раз и предлагают такую пирамидку: FOL на дне, а затем повышается уровень абстракции языка. Я им как раз и предложил механизмы для "штатной" удобочитаемости (добавить словарный и языковый уровни): http://wp.me/p3DYC-7