Re[5]: Мартин Фаулер о развитии систем программирования (Rep - Философия программирования

mkizub,

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

Теперь вернёмся.

M>Вначале о внутреннем представлении. Всё, что мы с него имеем, это именованые типы семантических узлов, именованые атрибуты и под-узлы этих семантических узлов, минимальные констрайнты (вроде — это необязательный скалярный атрибут, а это вектор под-узлов типа "expression").
M> ...
M>Правильней было-бы создать некий стандарт на это описание, который будет поддерживаться всеми средами.
M>Так же как есть единый стандарт на текст (включая кодировки).

Пока всё понятно. Хотя есть сомнения в том, что возможен стандарт на это описание. Так как всегда возможна ситуация, что какая-то фича уже не будет укладываться в стандарт. В данном случае получается, что нам надо будет выбрать внутреннее представление таким образом, что оно будет покрывать и язык Scala, и язык Java и язык опкодов JVM как частные случаи. То есть будет очень низкоуровневым! И каждый новый не укладывающийся в прежние рамки язык будет раздувать и дробить это внутреннее представление. Есть языки, где тела функций отделены от сигнатур, и сигнатуры являются FCO, есть языки где ветки в паттерн-матчинге являются FCO, есть Хаскелл со своей страшной системой типов, есть наконец Epigram, который я даже не представляю как подогнать под Java+Scala+JVM, настолько он другой. Естественно, общая база есть — это лямбда-исчисление. Или система команд x86. Или опкоды LLVM.

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

M>Так вот, теперь назад к Scala, Java, JVM и прочим.

M>Перво наперво, наша среда разработки программ должна позволить отображать и редактировать эти объявленные
M>узлы дерева. Для этого можно задавать "отображатели", некий "синтаксис".
M>...
M>Кстати, это конечно не должно быть однозначным и полным отображением. Мы можем отображать в некоем текстовом
M>представлении, которое не сможет распарсить ни один парсер. Мы можем отображать только часть атрибутов узла.
M>И т.д.

Хм, а почему отображение не должно быть однозначным? Возможна ведь какая ситуация: код на Скале содержащий хвостовую рекурсию преобразуется во внутреннее представление, затем мы это поддерево (в форме внутреннего представления) редактируем на уровне Джавы (в Джаве этот кусок виден как цикл). И потом мы снова переключаемся в Скалу. Что теперь?
В какой код нужно преобразовывать это? В тупой for? Или всё же попытаться представить в виде хвостовой рекурсии? Как долго нужно пытаться представить в виде хвостовой рекурсии?

Если не нравится пример с рекурсией, можно рассмотреть паттерн матчинг. Мы создаём выражение в Скале, редактируем в Джаве и снова переключаемся на Скалу. Выражение "взорвётся" из паттерн-матчинга в тучу if-ов и обилием синтетических переменных. Что будем делать? Пытаться подогнать паттерн-матчинг и свернуть if-ы? Или бить линейкой по рукам при любой попытке поправить "паттернматчинговое поддерево" не из Скалы?

M>Итак, мы задали некие семантические узлы для Scala, Java, JVM и их отображение. Можем не задавать отображения
M>некоторых узлов. Скажем, не задавать отображение для GOTO узла (семантического понятия), который есть в JVM.
M>И теперь мы пишем программу. При этом мы можем использовать любые известные системе (описанные во внутреннем
M>представлении) семантические узлы. Можем использовать скаловские трейты и абстрактные типы, которых нет в Java.
M>Можем использовать Java return и wildcard-ы в типах, которых нет в Scala. Можем использовать GOTO из JVM,
M>которого нет ни в Scala ни в Java. В смысле редактирования мы можем использовать всё, что угодно, постольку,
M>поскольку оно соответствует констрайнтам заданным во внутреннем представлении. Скажем, во внутреннем представлении
M>у нас сказано, что у InfixExpression есть скаляреый под-узел Operator — так мы в этот слот не сможем вставить
M>больше одного под-узла, или вставить туда узел типа Expression.

Хм, вот мы берём веточку, переключаемся в JVM и пошли:

public void bar(scala.runtime.BoxedArray, java.lang.Object);
0:    aload_1
1:    iconst_0
2:    aload_2
3:    invokevirtual    #18; //Method scala/runtime/BoxedArray.update:(ILjava/lang/Object;)V
6:    return

public void foo();
0:    iconst_3
1:    newarray int
3:    astore_1
4:    aload_0
5:    new    #28; //class scala/runtime/BoxedIntArray
8:    dup
9:    aload_1
10:    invokespecial    #31; //Method scala/runtime/BoxedIntArray."":([I)V
13:    iconst_3
14:    invokestatic    #37; //Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
17:    invokevirtual    #41; //Method bar:(Lscala/runtime/BoxedArray;Ljava/lang/Object;)V
20:    return

Потом переключаемся на Скалу. Отобразит ли оно нам вышеупомянутую веточку в виде:

def foo = {
    val baz = new Array[Int](3);
    bar(baz, 3);
}
def bar[T](ts : Array[T], t : T) = ts(0) = t;

? Я очень, очень сильно сомневаюсь. Это ведь опять задача декомпиляции.

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

M>Теперь о компиляции всего этого бардака
M>. ...
M>А если мы не сможем трансформировать дерево так, чтоб привести к набору узлов target платформы?
M>Сюрприз — выдадим ошибку компиляции.

Да! Именно. Как только AST одного внешнего языка будет достаточно сильно отличаться от AST другого внешнего языка, мы будем получать ошибку компиляции. А это будет очень и очень часто, потому что некоторые локальные конструкции в одном языке могут иметь глобальное действие — на уровне всего AST или его большого куска. Например, директива package, использование макросов или аспектов, использование какого-то типа или объекта повсюду в программе (его изменение может сломать весь остальной код). Если в другом языке нет непосредственного доступа к подобным вещам, то AST языков будут очень сильно различаться, и следовательно преобразование между ними невозможно. Введение промежуточного шага преобразования во внутреннее представление ничуть не облегчит задачу преобразования между AST.

Таким образом завязавшись на один язык будет очень трудно переключаться на другой, следовательно это будут делать очень и очень редко. Будет иметь смысл только в случаях, когда AST языков примерно одинаковы, как скажем для C# и Джавы (и то проблемы, как клеить полноценные дженерики с уничтожаемыми). Как только появляется перекос в какую-либо сторону, автоматически появляются сложности с переводом из менее высокоуровневого языка в более высокоуровневый.

M>Проблема здесь в чём? Проблема в том, что программист должен будет иметь квалификацию лучше, чем
M>обычно имеют сейчас. Если сейчас программист на java пишет static и не задумывается о том,
M>что при этом реально происходит, и это скомпилируется и будет работать — то программируя
M>в SymADE он должен будет понимать всю семантику происходящего, в том числе и понимать,
M>почему он неожиданно получить ошибку компиляции используя одновременно static и скаловские
M>семантические узлы. Или в крайнем случае, он добавит свой плагин для трансформации дерева,
M>который позволит в его конкретном случае таки скомпилировать программу в target платформу.

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

M>С другой стороны, программист может иметь и меньшую квалификацию и всё равно работать
M>в SymADE. Если ему сказать, или настроить редактор так, чтоб нельзя было использовать
M>произвольные узлы (семантические понятия), а только узлы из определённого набора
M>(то есть фактически написать некий DSL) — то он и не напорется на проблемы с тем,
M>что его программа неожиданно стала выдавать ошибку компиляции. А этот DSL язык может
M>быть намного проще, чем Java. И в то же время, его будет вполне хватать для задачь,
M>которые должен решать этот малоквалифицированный программист.

Вот именно, посадить его за написание бизнес рулов на DSL, и потом эти скрипты вызвать откуда нибудь. Ну на крайняк распарсить. Как сейчас и делают. Ты же предагаешь этому товарищу загаживать наше дерево, делая ветку на неком DSL, которая потом должна быть преобразована в основной таргет-язык. Здесь будет замена шила на мыло, картинка примерно такая (IR=inner representation):

классический путь:
DSL ----------> DSL_AST ---------> Scala
      ^                     ^
      |                    анализ и генерация, может быть довольно сложным
      для обычных DSL это легко, antlr в зубы и вперёд
      
путь СиМэйд:
DSL -> IR -> Scala
    ^     ^
    |     жопа
    |
    это примерно равно анализу и генерации из классического пути

Мы избавились от парсера и лексера (за нас это сделала СиМэйд), но зато получили очень нетривиальный шаг. Я не прав?

M>Больше того, SymADE будет легче в освоении этим малоквалифицированным программистом
M>(или скорее квалифицированным специалистом в своей области, но который не программист -
M>скажем, некий менеджер программирующий workflow). Потому как SymADE намного гибче
M>в отображении кода с одной стороны, и будет подсказывать неопытному пользователю -
M>какие именно конструкции можно вставить конкретно в этом месте. Ему не надо будет
M>знать, что объявление функции пишется как "def $name ( $args ) : $return_type".
M>Он скажет среде — вставить в это место новый узел, она ему скажет — можно вставить
M>объявление метода или поля. Он говорит — мне нужно метод вставить. Ему этот метод
M>и вставят. Потом он заполнит поле имени метода, и ему скажут — а теперь вставь
M>тип результата, это может быть то-то и то-то. И так далее.

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

M>С точки зрения осовения нового языка (онтологии семантических понятий) это намного
M>легче, чем выучивать синтаксис и продиратся через дебри, пока не освоишь этот
M>язык более полно. С точки зрения удобства, ну привык он к C-style синтаксису -
M>выберет отображалку объявления методов в виде "$return_type $name($args) { ... }",
M>а если он привык к паскалевскому синтаксису, он тот-же узел сможет отображать как
M>"method $name ($args) : $return_type begin ... end". И ему не надо будет
M>напрягаться с изучением нового синтаксиса только потому, что он захотел использовать
M>ScalaTrait в своей программе.
Здесь будет всё хорошо, потому что с такими тривиальными заменами, AST одного и AST другого языков будут практически 1-в-1. Задача весьма специфическая, и на моей памяти был только один случай её возникновения. Это когда мы на первом курсе учили Паскаль, а на втором учились программирвать на C. В то время, чтобы снизошло озарение, как работает список на С (построенный на указателях ессно) потребовалось сперва написать аналог на Паскале.

Ы? Где у меня поломалась логическая цепочка?

... << RSDN@Home 1.2.0 alpha 4 rev. 1079>>

Здравствуйте, Severn, Вы писали:

M>>Потом в репозитории сделали мержинг исправлений. Делайте ваши ставки

S>И? Это вполне обычный сценарий для copy-modify-merge, не имеющий прямого отношения к теме разговора. Не нравится мержить — делайте блокировки.
S>Разговор о том, если я меняю что-то в IDE, то при бинарном хранилище нельзя понять, что же фактически изменилось, нельзя просмотреть лог и сравнить коммиты.

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

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

Здравствуйте, Sinclair, Вы писали:

M>>Потом в репозитории сделали мержинг исправлений. Делайте ваши ставки

S>Во-первых, в большинстве реальных применений подобной хрени не встречается. Потому что физического смысла переименовывать васю в петю нет.
S>Во-вторых, те проблемы, с которыми сталкивается text-based XML мерджер, очевидны и разрешимы. Техники продвинутого diff & merge для XML существуют и уже давно.

Ага. Например проект harmony, который через нечто называемое ими "линзы" задаёт преобразования, а
фактически задаёт семантическое значение данным в XML. И после этого уже мержит.
То есть эмулирует для текста то, что для AST дерева уже задано — семантическое значение узлов/данных.
Ваше "существуют и уже давно" — это и есть зачатки того, о чём пишет Фаулер.

Здравствуйте, mkizub, Вы писали:

M>и трудный, но по моему глубокому убеждению — неизбежный.

Если ты не заметил, то M$ эту экосистему уже давно и упорно создаёт. Лна называется XML...

Здравствуйте, WolfHound, Вы писали:

M>>Ага. Например проект harmony, который через нечто называемое ими "линзы" задаёт преобразования, а фактически задаёт семантическое значение данным в XML.
WH>Линзы это однозначные двусторонние преобразования.
WH>Те для любой линзы (lens a <=> b) при любых значениях A верно что A == inv(lens)(lens(A))
WH>ВСЕ!
WH>Никакой семантики.

Линзой задаётся семантика, а не в семантике линзы семантика конкретного XML-я.
Они в своих примерах с той-же телефонной книжкой это показывают.
Задают линзу, которая указывает, что уникальным идентификатором для записи
в телефонной книжке является имя человека. И когда секретарша правит имя
Васи на Петю, то при помощи этой линзы мержингу задаётся, что фактически
запись для Васи удалена и добавлена новая запись для Пети. И мержинг
в этом случае скажет — одна секретарша удалила запись для Васи, а другая
поменяла в этой записи номер телефона. Вот вам конфликт. А не будет
заменять Петин телефон Васиным. Благодаря семантике конкретного XMLя
обозначенной конкретной линзой. Что тебе тут непонятно?

Здравствуйте, mkizub, Вы писали:

M>Линзой задаётся семантика, а не в семантике линзы семантика конкретного XML-я.
Причем тут вобще XML?

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

M>И мержинг в этом случае скажет — одна секретарша удалила запись для Васи, а другая поменяла в этой записи номер телефона.
M>Вот вам конфликт. А не будет заменять Петин телефон Васиным. Благодаря семантике конкретного XMLя обозначенной конкретной линзой.
Чтобы тебе было понятно:
Есть линза которая переводит url encoding в xml encoding и обратно
url2xml : lens UrlEncodedText <=> XmlEncodedText

теперь если в эту линзу засунуть что-то является валидной url encoded строкой то мы получим валидную xml encoded строку.
А если мы туда засуним строку в которц есть символы не допустимые для url encoded строки то мы получим по башке.
ВСЕ!

В твоем случае у нас есть вот такая вот веселая линза:
ТекстСВасей <=> ТекстСПетей
Эта линза заменяет имя Вася на имя Петя и обратно.

И вторая линза:
ТекстСВасей <=> ТекстСВасей
Эта линза меняет один телефон на другой и обратно.

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

Где ты тут нашол семантику ХЗ.

M>Что тебе тут непонятно?
Что тебе тут непонятно?

... << RSDN@Home 1.2.0 alpha rev. 745>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mkizub, Вы писали:
M>>У меня нет VS. По причине линуховской операционки, и вообще.
S>Ну так подними ее в VM. А то ты тут свою IDE пытаешься изобрести, при этом ничего про реальные IDE не знаешь.
M>>Так ты сделай там два класса с одним именем, и сохрани/восстанови. Расскажи как они справились.
S>

Ну нет так нет.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, FR, Вы писали:

M>>>Кроме тулзов работающих с текстом как таковым, вроде regexp-ов, но у них и нет такого понятия как
M>>>"функция f(x)", и никуда они единицу не прибавляют. Нечем, не умеют, у них нет такого понятия как
M>>>функция или сложение.

FR>>Да ладно при желании и из regexp-ов можно выстроить Марковскую цепочку с полной подержкой арифметики

M>Вот это и будет некий интерпретатор, у которого будет понятие арифметики, чисел и функций,
M>который и будет через некое своё внутреннее понимание реализовывать трансформации согласно
M>меры своего понимания. У этой твоей Марковской цепочки будет понимание, семантика арифметики,
M>а не у текста и не у regexp-ов.

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

Далеко пойдёте.

Здравствуйте, mkizub, Вы писали:

M>Ну, сказать, что это M$ создаёт XML будет сильным преувеличением.
M>Скорее он создаётся и поддерживатся в Java. А остальные подтягиваются.
M>XML имеет кучу неудобств как внутренее представление для программ.
Внутреннее представление программ никого не скребет, на то оно и внутреннее.
А как persistence — формат XML для всего, чего ты хочешь, подойдет вполне хорошо.

M>Во-первых, он не ОО. Я могу сказать, что мой phonebook содержит
M>тип данных entry, и entry содержит name и phone данные.
M>phonebook { entry* }; entry { name; phone }
M>А если я захочу my_entry extends entry { e-mail }?
M>Низзя, это только my_entry { name; phone; e-mail }, и менять
M>phonebok { (entry | my_entry)* }.
Тут ты путаешь XML и его схему. Вообще говоря, есть несколько способов описать схему XML документа; как минимум три.
Они не являются семантически равнозначными. Если тебя не устраивает ни одна из них — придумай свой формат описания схемы, и используй. Никаких проблем.
M>Во-вторых, у него именованые только атрибуты. А child ноды
M>неименованые, сваленные все в кучу.
Это как это неименованные?
M>Мне, чтоб найти name в entry
M>надо будет лазить по всему списку child узлов?
Непонятно, что значит "лазить"? Итерироваться? Откройте для себя XPath.

M>Вместо чтоб по имени
M>поля просто получить его значение? Любой компилятор использующий
M>XML (фактически DOM) как внутреннее представление, сразу станет
M>работать раз в 100 медленее.
DOM и XML — это две слабо связанные между собой вещи. DOM — это всего лишь одна (не самая, к слову, удачная) реализация представления загруженного XML документа в памяти.
Надеюсь, ты в курсе, что для работы с XML DOM не обязателен?
Дальнейшие жалобы, происходящие от каши в голове, поскипаны.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Курилка, Вы писали:

К>Даёшь вкусовое и слуховое программирование!
К>Ну а если серьёзней, то какими чувствами кроме зрения ты воспринимаешь программу? Ну и какие чувства кроме зрения есть в том, что пишет Фаулер?

На слух, при парном программировании или когда коллега объясняет что-то.
Кстати, видел плагин для IntelliJ IDEA, который играет код, как музыку

Есть проект reactable, где музыку пишут с помощью осязания и зрения.
Да и то же зрение можно очень по разному использовать, можно сделать трёхмерную модель программы
и совсем поломать мозг её отлаживая

Кстати, да — http://ru.wikipedia.org/wiki/Piet

mkizub,

M>Конечно. Ты тоже можешь задуматься над тем, отличается ли твоё понимание байткода
M>от понимания им JVM, и есть ли в этих процессах принципиальная разница. Узнаешь
M>о себе много нового. И чем больше нового узнаешь — тем дальше пойдёшь

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

Рассмотрим код на Cкале:

trait Type1 {
  type T1
}

trait Monad {
  type M <: Type1

  def return[A](a : A) : M { type T1 = A }

  def bind[A,B](m : M { type T1 = A }, f : A => M { type T1 = B }) 
      : M { type T1 = B }
}

Здесь трейт Type1 определяет атрибут-тип T1, к которому потом осуществляется доступ в трейте Monad. Компиляция этого года выдаёт некий байт-код, который невоспроизводим в Java. (Есть аналогичные случаи для Немерла и C#, то есть существует код на Немерле который будучи скомпилирован в MSIL недостижим из C#).

Если мы возьмём внутреннее представление = байт-коду JVM, то окажется что внешнее преставление в виде Скалы возможно, а в виде Джавы — нет.

Если мы возьмём более крупноблочное преставление, скажем в виде AST для Джавы, то с помощью этого AST мы не сможем закодировать не только параметры-типы, а вообще почти любую скалистую фичу, которая идёт дальше обычного ООП.

Если мы возьмём внутреннее преставление = AST Скалы, то скажем банальный static не будет иметь аналога в Скале (static плохо дружит с компонентностью, поэтому он был выброшен).

И что теперь?

... << RSDN@Home 1.2.0 alpha 4 rev. 1079>>

Здравствуйте, Andrei F., Вы писали:

AF>

AF>The abstract representation may be edited through multiple projections, each projection can show a limited amount of the total information which isn't tied to the actual structure of the abstract representation. Repository systems thus usually show a wider range of editing environments — including graphical and tabular structures — rather than just a textual form.

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

Здравствуйте, Курилка, Вы писали:

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

Просто есть люди, и много, лучше воспринимающие информацию графически. В "Экстремальном программировании" Кента Бека об этом упоминается.
По собственному опыту могу сказать, что тоже так легче воспринимаю информацию,
часто при объяснении предметов сокурсникам в инстутуте переводил измышления преподавателей в каракули на бумажке со словесным описанием,
которые товарищами усваивались лучше, конечно, стоит учитывать, что объяснял я им при этом персонально.

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

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Andrei F., Вы писали:

C>>>Сегодняшняя практика показывает, что лучший формат для сериализации таких репозиториев — это файлы с текстом.
AF>>Я так не думаю.
C>А примеры?

C>Пока что все суперкрутые графические системы программирования (hint: UML, MDA) успешно проваливаются, хотя в них и вложены огромные деньги.

GUI designer в дельфях.

Здравствуйте, Курилка, Вы писали:

К> (хотя в уме транслировать координаты кнопок в картинку не особо сподручно)

А теперь тебе осталось понять разницу между форматом хранения и способом отображения/редактирования,
и ты поймёшь о чем статья писалась. На своём собственно примере и попробуй понять разницу
между редактированием XML файла и GUI designer-ом.

Здравствуйте, Cyberax, Вы писали:

C>Сегодняшняя практика показывает, что лучший формат для сериализации таких репозиториев — это файлы с текстом.

+1
Если хранилище текстовое то в экстренных случаях его можно использовать как yet another editable representation.

У нас на работе парень мучаеся с Wise Installer. С ростом сетапа уровень мистики в поведении wise растет экспонецниально. Причем сравнить стабильный и сбоящий wsi файлы просто так не получится, т.к. формат хранения — кастомизированные MSI таблички.
Еслы бы хранилице было текстовым, то на причуды IDE можно былобы забить. Это сейчас — оновная причина для переноса сетапа на wix, у которого хранилище в XML.

Здравствуйте, Курилка, Вы писали:

К>>> (хотя в уме транслировать координаты кнопок в картинку не особо сподручно)

M>>А теперь тебе осталось понять разницу между форматом хранения и способом отображения/редактирования,
M>>и ты поймёшь о чем статья писалась. На своём собственно примере и попробуй понять разницу
M>>между редактированием XML файла и GUI designer-ом.

К>Сорри за личный вопрос, но тебе доставляет удовольствие считать других глупее себя и показывать это самомнение другим?

В психологии есть фундаментальный факт — человек судит других по себе. Он приписывает им свои мысли, свои мотивы
и т.д. Это естественно — у него просто нет другой мерки, кроме себя, поэтому он и меряет остальных по себе.

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

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Severn, Вы писали:

C>>>Пока что все суперкрутые графические системы программирования (hint: UML, MDA) успешно проваливаются, хотя в них и вложены огромные деньги.
S>>Не понял мысль. UML и проч описания модели — это то что ты видишь в редакторе. совсем не обязательно хранить сам документ в бинарном виде.
C>Это я просто о ненужности "альтернативных" представлений как класса, по большей части.

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

)

Здравствуйте, Severn, Вы писали:

S>>>Еслы бы хранилице было текстовым, то на причуды IDE можно былобы забить. Это сейчас — оновная причина для переноса сетапа на wix, у которого хранилище в XML.

M>>А попробует сделать merge для XML-я, ощутит всю прелесть процесса и поймёт наконец, что разницы
M>>между бинарным и текстовым представлением по сути нет.

S>По сути — нет, на практике — есть. Где то опять же у фаулера было отмечено, что основная проблема бинарного репозитория — это плохая поддержка со стороны средств контроля версий. Т.е. мержить XML в любом случае легче чем wmi файлы. Причем проблемы с мержем — довольно редкий случай, иначе CVS/SVN не имели бы успеха.

<phonebook>
<name>Вася</name>
<phone>123</phone>
</phonebook>

Вася обменялся телефоном с Петей, одна секретарша сделала исправление

<phonebook>
<name>Петя</name>
<phone>123</phone>
</phonebook>

другая секретарша сделала исправление

<phonebook>
<name>Вася</name>
<phone>456</phone>
</phonebook>

Потом в репозитории сделали мержинг исправлений. Делайте ваши ставки

Здравствуйте, Severn, Вы писали:

S>Тут не соглашусь. Возможность использования projectional editors — это особенность бОльшего числа современных IDE. Представление совсем не обязательно должно быть графическим, главное то, что IDE (aka language workbench) сама использует некую внутреннюю абстрактную структуру, в то время как пользователи работают с многочисленными прокциями. В первую очередь, конечно, с текстовым редактором, но также и со всякими Class Views, Object Browsers, фичами для рефакторинга... IntelliSence тоже в каком-то смысле альтернативное представление, т.к. он генерится из внутреннего представления IDE и зависит от текстового редактора лишь опосредованно (через это самое внутренне представление)

Угу, вот только останавливаться на формулировке "будут много всяких разных представлений одного и того же" могут себе позволить только архитектурные астронавты.
Реальные пацаны изобретают реальные решения: class diagram, которая 100% синхронизована с кодом в обе стороны (вместо всяких two-way generation process), immediate window, и так далее. С год назад пробегали скриншоты MS VS 2010. Там — никаких абстрактных разговоров про представление выражений в C-style или Lisp-style. Там про визуализацию control flow и прочие штуки, рядом с которыми class diagram смотрится блекло, как Мэрилин Монро распечатанная на ASCII принтере.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, mkizub, Вы писали:

C>>>Сегодняшняя практика показывает, что лучший формат для сериализации таких репозиториев — это файлы с текстом.
M>Гы-гы. Текст сам по себе нисколько не лучше бинарника. Скажем, существует множество взаимнооднозначных
M>преобразований бинарного кода в текстовый. hex dump, base64 и пр. Но они вам ничем не помогут при
M>хранении данных в репозитории, равно как и XML и прочие форматы дампа иерархических структур, потому как
Естественно, я имею в виду осмысленный текст. Типа отформатированого XML, который ПРЕКРАСНО кладётся в репозиторий.

M>А попробует сделать merge для XML-я, ощутит всю прелесть процесса и поймёт наконец, что разницы
M>между бинарным и текстовым представлением по сути нет.
Вот сегодня сделал как раз:

...
        <properties>
<<<<<<< .mine
                <build.version>299</build.version>
=======
                <build.version>292</build.version>
>>>>>>> .r1632
        </properties>
...

И какие тут непреодолимые проблемы?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mkizub, Вы писали:

M>>Проблемы начинаются когда происходить export/import в текст.
S>Нет. Проблемы начинаются сразу, как только я нажимаю Save. Я говорю не про roundtrip engineering, а про банальную совместную работу над розовской моделью. Остальные рассуждения, основанные на неверных постулатах, поскипаны.

S>P.S. Посмотри на то, как работают class diagrams в Visual Studio. Всё прекрасно работает без всяких "читать не сможешь" и "представления в AST".

У меня нет VS. По причине линуховской операционки, и вообще.
Так ты сделай там два класса с одним именем, и сохрани/восстанови. Расскажи как они справились.

Здравствуйте, Severn, Вы писали:

S>Ага, о том и речь. Хорошо когда абстрактное представление отделено от редактируемого. но нашему парню с wise-ом от этого не легче

S>Т.е. практика показывает, что сохранять все равно лучше опять таки в чем-нибудь human-readable. Чтобы когда среда в конец заглючит, открыть старый добрый FAR

....

Оно конечно. Но невозможность редактирования MS Word-овских документов FAR-ом сыграла очень мало значения в
распространении этого MS Word-а

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

Здравствуйте, mkizub, Вы писали:

M>Ага. Например проект harmony, который через нечто называемое ими "линзы" задаёт преобразования, а фактически задаёт семантическое значение данным в XML.
Линзы это однозначные двусторонние преобразования.
Те для любой линзы (lens a <=> b) при любых значениях A верно что A == inv(lens)(lens(A))
ВСЕ!
Никакой семантики.

... << RSDN@Home 1.2.0 alpha rev. 745>>

Здравствуйте, Курилка, Вы писали:

M>>В harmony они линзами преобразовывают XML (или другой иерархический формат данных)
M>>в некое внутренне своё представление, понимаемое их мержером.

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

Я говорю о реализации мержинга иерархических данных, в частности XML, в harmony, а не о функциях и линзах вааще.

К>Для тебя функция f(x)=x+1, тоже приводит x сначала к какому-то внутреннему представлению, прежде чем единицу прибавить?

Да. Функций "вааще", "самих по себе" не существует. Для тебя это новость, да?
Функции существуют в нашем воображении, в понимании их интерпретаторами или компиляторами и т.д.
А то, что ты нарисовал — это не функция, это текст, последовательность букф (впрочем, тоже существующая
только в нашем воображении, а для компа это, например, набор чисел, для электронщика это набор
состояний транзисторов в памяти комп и т.д.).
И я и ты, и компиляторы, и кто угодно — преобразует текст "f(x)=x+1" в некое внутренее представление,
и потом занимается преобразованием этого внутреннего представления согласно неким своим правилам.
Кроме тулзов работающих с текстом как таковым, вроде regexp-ов, но у них и нет такого понятия как
"функция f(x)", и никуда они единицу не прибавляют. Нечем, не умеют, у них нет такого понятия как
функция или сложение.

Здравствуйте, mkizub, Вы писали:

M>Кроме тулзов работающих с текстом как таковым, вроде regexp-ов, но у них и нет такого понятия как
M>"функция f(x)", и никуда они единицу не прибавляют. Нечем, не умеют, у них нет такого понятия как
M>функция или сложение.

Да ладно при желании и из regexp-ов можно выстроить Марковскую цепочку с полной подержкой арифметики

Здравствуйте, FR, Вы писали:

M>>Кроме тулзов работающих с текстом как таковым, вроде regexp-ов, но у них и нет такого понятия как
M>>"функция f(x)", и никуда они единицу не прибавляют. Нечем, не умеют, у них нет такого понятия как
M>>функция или сложение.

FR>Да ладно при желании и из regexp-ов можно выстроить Марковскую цепочку с полной подержкой арифметики

Вот это и будет некий интерпретатор, у которого будет понятие арифметики, чисел и функций,
который и будет через некое своё внутреннее понимание реализовывать трансформации согласно
меры своего понимания. У этой твоей Марковской цепочки будет понимание, семантика арифметики,
а не у текста и не у regexp-ов.

Здравствуйте, Курилка, Вы писали:

M>>>>Кроме тулзов работающих с текстом как таковым, вроде regexp-ов, но у них и нет такого понятия как
M>>>>"функция f(x)", и никуда они единицу не прибавляют. Нечем, не умеют, у них нет такого понятия как
M>>>>функция или сложение.

FR>>>Да ладно при желании и из regexp-ов можно выстроить Марковскую цепочку с полной подержкой арифметики

M>>Вот это и будет некий интерпретатор, у которого будет понятие арифметики, чисел и функций,
M>>который и будет через некое своё внутреннее понимание реализовывать трансформации согласно
M>>меры своего понимания. У этой твоей Марковской цепочки будет понимание, семантика арифметики,
M>>а не у текста и не у regexp-ов.

К>Забавная у вас логика, однако...
К>Тогда выходит у JVM есть понимание байткода,

Конечно есть. Она умеет много чего относительно байткода — верифицировать, исполнять и т.п.
У неё есть некое своё внутреннее представление байткода, она это представление умеет трансформировать,
скажем для оптимизации выполнения.

К>а у светофора понимание красного и прочих цветов

У светофора нет понимания красного цвета. Он умеет включать и выключать лампочки.
А понимание красного цвета у светофора есть у человека.

К>Далеко пойдёте.

Конечно. Ты тоже можешь задуматься над тем, отличается ли твоё понимание байткода
от понимания им JVM, и есть ли в этих процессах принципиальная разница. Узнаешь
о себе много нового. И чем больше нового узнаешь — тем дальше пойдёшь

Здравствуйте, serg baburin, Вы писали:

SB>Здравствуйте, Курилка, Вы писали:

К>>Ну а если серьёзней, то какими чувствами кроме зрения ты воспринимаешь программу? Ну и какие чувства кроме зрения есть в том, что пишет Фаулер?
SB>Как сказал один мой знакомый — "ж..ой чую, что там ошибка!"

Ну, ж..ой — не ж..ой, но чем-то бессознательным — точно. Особенно в 4-5 утра...

Здравствуйте, AndrewVK, Вы писали:
AVK>Это какие то мысли вслух какого то левого чувака были.

AVK>Вот если бы ты появился в Редмонде в апреле, у тебя был бы шанс посмотреть на редактор Dev10, отцепленный от умершего наутилуса.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mkizub, Вы писали:

M>>Ну, сказать, что это M$ создаёт XML будет сильным преувеличением.
M>>Скорее он создаётся и поддерживатся в Java. А остальные подтягиваются.
M>>XML имеет кучу неудобств как внутренее представление для программ.
S>Внутреннее представление программ никого не скребет, на то оно и внутреннее.
S>А как persistence — формат XML для всего, чего ты хочешь, подойдет вполне хорошо.

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

http://martinfowler.com/bliki/RepositoryBasedCode.html

An important difference between repository and source based environments is the split between persistent storage and editing. Repositories can choose any persistence mechanism that they choose, while source systems need to have some universal storage mechanism — which is why they are almost always text files.

The abstract representation may be edited through multiple projections, each projection can show a limited amount of the total information which isn't tied to the actual structure of the abstract representation. Repository systems thus usually show a wider range of editing environments — including graphical and tabular structures — rather than just a textual form.

Здравствуйте, VUspenskiy, Вы писали:

VU>Вообще, думаю, что развитие в детстве лучшего восприятия одними из органов чувств, чем другими не влияет на способность алгоритмизировать
VU>и чем через большее количество чувств мы будем воспринимать идеи, заложенные в программе, тем легче можно будет в ней разбираться и её менять.

Даёшь вкусовое и слуховое программирование!
Ну а если серьёзней, то какими чувствами кроме зрения ты воспринимаешь программу? Ну и какие чувства кроме зрения есть в том, что пишет Фаулер?

Здравствуйте, Курилка, Вы писали:

К>Ну а если серьёзней, то какими чувствами кроме зрения ты воспринимаешь программу? Ну и какие чувства кроме зрения есть в том, что пишет Фаулер?

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

Здравствуйте, Andrei F., Вы писали:

AF>Любой инструмент можно использовать во вред, и без любого инструмента можно обойтись.

В том числе и без мозга?

Здравствуйте, Andrei F., Вы писали:

AF>http://martinfowler.com/bliki/RepositoryBasedCode.html

А то, что это подмножество tree-based сред разработки (SymADE, IP, MPS) ты не заметил? :D

Здравствуйте, mkizub, Вы писали:

M>А то, что это подмножество tree-based сред разработки (SymADE, IP, MPS) ты не заметил? :D

С чего ты решил, что не заметил?

И никакое не подмножество, это абсолютно та же идея.

Здравствуйте, Cyberax, Вы писали:

C>Сегодняшняя практика показывает, что лучший формат для сериализации таких репозиториев — это файлы с текстом.

Я так не думаю.

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, Cyberax, Вы писали:

C>>Сегодняшняя практика показывает, что лучший формат для сериализации таких репозиториев — это файлы с текстом.

AF>Я так не думаю.

Попробуй, может понравится

А если чуть серьёзней — покажи пример чего-то, что непредставимо в текстовом формате.

Здравствуйте, Курилка, Вы писали:

AF>>Я так не думаю.

К>Попробуй, может понравится

ты о чем?

К>А если чуть серьёзней — покажи пример чего-то, что непредставимо в текстовом формате.

зачем?

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, Курилка, Вы писали:

AF>>>Я так не думаю.

К>>Попробуй, может понравится

AF>ты о чем?

О представимости редактируемых данных в текстовом виде.

К>>А если чуть серьёзней — покажи пример чего-то, что непредставимо в текстовом формате.

AF>зачем?

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

Здравствуйте, Курилка, Вы писали:

К>О представимости редактируемых данных в текстовом виде.

А это кто-то оспаривал?

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, Курилка, Вы писали:

К>>О представимости редактируемых данных в текстовом виде.

AF>А это кто-то оспаривал?

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

Здравствуйте, Курилка, Вы писали:

К>Тогда поясни, что же именно ты оспаривал, если, конечно, не сложно.

"Лучший" и "пригодный" — это немного разные вещи, ты не находишь?

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, Курилка, Вы писали:

К>>Тогда поясни, что же именно ты оспаривал, если, конечно, не сложно.

AF>"Лучший" и "пригодный" — это немного разные вещи, ты не находишь?

It depends...
Хотелось бы услышать какой "лучший" формат для тебя и по каким конкретно параметрам.

Здравствуйте, Курилка, Вы писали:

AF>>"Лучший" и "пригодный" — это немного разные вещи, ты не находишь?

К>It depends...

К>Хотелось бы услышать какой "лучший" формат для тебя и по каким конкретно параметрам.

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

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, Курилка, Вы писали:

К>>Хотелось бы услышать какой "лучший" формат для тебя и по каким конкретно параметрам.

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

В статье вижу только:

Repositories can choose any persistence mechanism that they choose

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

Я же попросил твоё мнение, но, судя по всему его нету.

Здравствуйте, Andrei F., Вы писали:

C>>Сегодняшняя практика показывает, что лучший формат для сериализации таких репозиториев — это файлы с текстом.
AF>Я так не думаю.
А примеры?

Пока что все суперкрутые графические системы программирования (hint: UML, MDA) успешно проваливаются, хотя в них и вложены огромные деньги.

Здравствуйте, mkizub, Вы писали:

C>>Пока что все суперкрутые графические системы программирования (hint: UML, MDA) успешно проваливаются, хотя в них и вложены огромные деньги.
M>GUI designer в дельфях.
В бинарном формате хранится только дизайн, код — в виде старого доброго текста.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, mkizub, Вы писали:

C>>>Пока что все суперкрутые графические системы программирования (hint: UML, MDA) успешно проваливаются, хотя в них и вложены огромные деньги.
M>>GUI designer в дельфях.
C>В бинарном формате хранится только дизайн, код — в виде старого доброго текста.

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

Здравствуйте, Cyberax, Вы писали:

C>>>Пока что все суперкрутые графические системы программирования (hint: UML, MDA) успешно проваливаются, хотя в них и вложены огромные деньги.
M>>GUI designer в дельфях.
C>В бинарном формате хранится только дизайн, код — в виде старого доброго текста.

Бинарный, или XML или любой другой формат хранения не имеет никакого значения.
Тебе осталось понять, что эти данные — и есть код.

Вот тебе ещё пример. Парсеры. В исходниках (текстовых, yacc, antlr и пр., из которых потом генерируется С/Java/etc код) — смешаны
в кучу синтаксис, код в target языке который обрабатывает события парсинга, разметка генерации AST дерева и т.п.
Это всё можно смотреть и редактировать отдельно — и это будет удобнее, чем разбираться в сваленом в одну кучу разнородном
тексте.

А так-же GUI designer-s баз данных, или Far/GUI shell/bash удобно представляющие бинарные
данные в file system, и т.д. и т.п.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Курилка, Вы писали:

К>> (хотя в уме транслировать координаты кнопок в картинку не особо сподручно)

M>А теперь тебе осталось понять разницу между форматом хранения и способом отображения/редактирования,
M>и ты поймёшь о чем статья писалась. На своём собственно примере и попробуй понять разницу
M>между редактированием XML файла и GUI designer-ом.

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

Здравствуйте, mkizub, Вы писали:

M>Тебе осталось понять, что эти данные — и есть код.

Лисперы (да и не только они), давным давно уже в курсе...
[наезд на личность поскипан]

Здравствуйте, mkizub, Вы писали:

C>>В бинарном формате хранится только дизайн, код — в виде старого доброго текста.
M>Бинарный, или XML или любой другой формат хранения не имеет никакого значения.
M>Тебе осталось понять, что эти данные — и есть код.
Для интерфейса — нифига это не код. Это картинка. В лучшем случае — декларативное описание.

M>Вот тебе ещё пример. Парсеры. В исходниках (текстовых, yacc, antlr и пр., из которых потом генерируется С/Java/etc код) — смешаны
M>в кучу синтаксис, код в target языке который обрабатывает события парсинга, разметка генерации AST дерева и т.п.
M>Это всё можно смотреть и редактировать отдельно — и это будет удобнее, чем разбираться в сваленом в одну кучу разнородном
M>тексте.
Это всё нельзя редактировать отдельно. Так как семантические действия зависят от кода синтаксического парсера. Так что в нормальных парсерах банально выделяют сложные семантические действия в отдельные модули/файлы.

Более того, оказывается проще организовать совместное редактирование нескольких языков. Например, это как раз в roadmap'е следующей IDEA.

Здравствуйте, Cyberax, Вы писали:

C>В бинарном формате хранится только дизайн, код — в виде старого доброго текста.

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

Здравствуйте, Cyberax, Вы писали:
C>В бинарном формате хранится только дизайн, код — в виде старого доброго текста.
Начиная с версии 6.0 дизайн стал по умолчанию храниться в текстовом формате. До этого разработчики пользовали самописанные приблуды для перевода .dfm в текст, т.к. бинарный формат оказался катастрофически несовместимым с системами контроля версий.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Cyberax, Вы писали:

C>Пока что все суперкрутые графические системы программирования (hint: UML, MDA) успешно проваливаются, хотя в них и вложены огромные деньги.

Не понял мысль. UML и проч описания модели — это то что ты видишь в редакторе. совсем не обязательно хранить сам документ в бинарном виде.

Здравствуйте, Andrei F., Вы писали:
AF>Так было далеко не сразу, первые версии Дельфи использовали бинарный формат. Потом стали использовать текст, чтобы не было проблем с системами контроля версий, и когда железо стало помощнее

Ты с чем несогласен-то? С тем, что текстовость формата не влияла на производительность дельфи приложения даже на железе образца 1995 года?

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Severn, Вы писали:

C>>Пока что все суперкрутые графические системы программирования (hint: UML, MDA) успешно проваливаются, хотя в них и вложены огромные деньги.
S>Не понял мысль. UML и проч описания модели — это то что ты видишь в редакторе. совсем не обязательно хранить сам документ в бинарном виде.
Это я просто о ненужности "альтернативных" представлений как класса, по большей части.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Severn, Вы писали:

S>>Не понял мысль. UML и проч описания модели — это то что ты видишь в редакторе. совсем не обязательно хранить сам документ в бинарном виде.
C>Это я просто о ненужности "альтернативных" представлений как класса, по большей части.

Тут не соглашусь. Возможность использования projectional editors — это особенность бОльшего числа современных IDE. Представление совсем не обязательно должно быть графическим, главное то, что IDE (aka language workbench) сама использует некую внутреннюю абстрактную структуру, в то время как пользователи работают с многочисленными прокциями. В первую очередь, конечно, с текстовым редактором, но также и со всякими Class Views, Object Browsers, фичами для рефакторинга... IntelliSence тоже в каком-то смысле альтернативное представление, т.к. он генерится из внутреннего представления IDE и зависит от текстового редактора лишь опосредованно (через это самое внутренне представление)

из фаулеровской книги по DSL

A consequence of projectional editors is that you can have multiple projections for the same part of the abstract representation. This allows you to project the same information in different forms, or to project different subsets of information depending on how you want to use it. A good example of the former is a common demonstration of Intentional Software's language workbench where a conditional expression can be projected in C-like syntax, lisp-like syntax, or a tabular form.

Здравствуйте, mkizub, Вы писали:

M>Мне бы доставило удовольствие, если бы кто-то понял о чём идёт речь в этой статье Фаулера, и вообще в
M>семантическом/intentional программировании, и заинтересовался этим настолько, что стал бы в этом
M>направлении что-то делать.

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

Есть в Магнитогорске такая крупная компания Компас Плюс. Она является одним из лидеров банковского софта в России. И свои продукты разрабатывает с помощью FloraWare -- как раз такого инструмента, о котором пишет Фаулер. Эту FloraWare они разработали очень давно (в середине 90-х она позиционировалась как инструмент для задач АСУТП). Но вот продвинуть в массы не смогли, т.к. очень специфическая вещь.

И еще вопрос, смогли бы они разработать и FloraWare и свой банковский софт на ней где-нибудь в Москве, Питере, Новоссибирске или Киеве. Поскольку найти желающих писать программы в такой специфической среде будет сложно. А вот в Магнитогорске народу просто податься некуда. Вот и пользуются разработчики FloraWare.

Здравствуйте, eao197, Вы писали:

E>В этом направлении уже сделано больше, чем вы, вероятно, можете себе представить.

E>Есть в Магнитогорске такая крупная компания Компас Плюс. Она является одним из лидеров банковского софта в России. И свои продукты разрабатывает с помощью FloraWare -- как раз такого инструмента, о котором пишет Фаулер.

Я знаком с FloraWare — это совершенно другой инструмент.

Здравствуйте, Severn, Вы писали:

C>>Сегодняшняя практика показывает, что лучший формат для сериализации таких репозиториев — это файлы с текстом.

Гы-гы. Текст сам по себе нисколько не лучше бинарника. Скажем, существует множество взаимнооднозначных
преобразований бинарного кода в текстовый. hex dump, base64 и пр. Но они вам ничем не помогут при
хранении данных в репозитории, равно как и XML и прочие форматы дампа иерархических структур, потому как —

S>У нас на работе парень мучаеся с Wise Installer. С ростом сетапа уровень мистики в поведении wise растет экспонецниально. Причем сравнить стабильный и сбоящий wsi файлы просто так не получится, т.к. формат хранения — кастомизированные MSI таблички.
S>Еслы бы хранилице было текстовым, то на причуды IDE можно былобы забить. Это сейчас — оновная причина для переноса сетапа на wix, у которого хранилище в XML.

А попробует сделать merge для XML-я, ощутит всю прелесть процесса и поймёт наконец, что разницы
между бинарным и текстовым представлением по сути нет.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Severn, Вы писали:

S>>Еслы бы хранилице было текстовым, то на причуды IDE можно былобы забить. Это сейчас — оновная причина для переноса сетапа на wix, у которого хранилище в XML.

M>А попробует сделать merge для XML-я, ощутит всю прелесть процесса и поймёт наконец, что разницы
M>между бинарным и текстовым представлением по сути нет.

По сути — нет, на практике — есть. Где то опять же у фаулера было отмечено, что основная проблема бинарного репозитория — это плохая поддержка со стороны средств контроля версий. Т.е. мержить XML в любом случае легче чем wmi файлы. Причем проблемы с мержем — довольно редкий случай, иначе CVS/SVN не имели бы успеха.

Здравствуйте, mkizub, Вы писали:

M>А попробует сделать merge для XML-я, ощутит всю прелесть процесса и поймёт наконец, что разницы
M>между бинарным и текстовым представлением по сути нет.
Это сильно зависит от конкретного использования текста. Вот Розовский формат диаграмм — текстовый, но кретины ухитрялись апдейтить идентификаторы всех объектов при каждом сохранении. Естественно, любой коммит — это merge с конфликтами на ровном месте. Ну так это от того, что в rational эту функцию делали некомпетентные люди. В бинарнике они бы получили вообще diff в 100% при каждом сейве.
А вот Wix, о котором идет речь, вполне себе friendly к SVN.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Severn, Вы писали:

M>Потом в репозитории сделали мержинг исправлений. Делайте ваши ставки

И? Это вполне обычный сценарий для copy-modify-merge, не имеющий прямого отношения к теме разговора. Не нравится мержить — делайте блокировки.
Разговор о том, если я меняю что-то в IDE, то при бинарном хранилище нельзя понять, что же фактически изменилось, нельзя просмотреть лог и сравнить коммиты.

Здравствуйте, Sinclair, Вы писали:

S>..могут себе позволить только архитектурные астронавты.

Это да, фаулер любит общее из частного выводить.

Здравствуйте, mkizub, Вы писали:

M>Потом в репозитории сделали мержинг исправлений. Делайте ваши ставки

Во-первых, в большинстве реальных применений подобной хрени не встречается. Потому что физического смысла переименовывать васю в петю нет.
Во-вторых, те проблемы, с которыми сталкивается text-based XML мерджер, очевидны и разрешимы. Техники продвинутого diff & merge для XML существуют и уже давно.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Severn, Вы писали:

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

Согласен — принципиальной разницы есть. На практике — есть, т.к.

A significant pragmatic problem with repository based systems is the fact that there is no generally accepted way format for the storage representation. The fact that programmer-readable text is the universal choice for source files means that a whole slew of tools can be built to process them: editors, source-code control, difference visualizers etc.

M>Так вот, хранение кода в виде AST дерева позволяет лучше решать проблемы мержинга и вообще
M>трэкинга изменений. Потому как известно больше информации об элементах. Это уже не безликие
M>строки текста, это структурные, семантические понятия — переменная, имя, оператор, декларация
M>и т.д. В каком виде это будет физически лежать, в виде XML дампа дерева, или в виде
M>бинарного файла с сериализованным деревом или ещё каком виде — совершенно не важно.

Ага, о том и речь. Хорошо когда абстрактное представление отделено от редактируемого. но нашему парню с wise-ом от этого не легче

Т.е. практика показывает, что сохранять все равно лучше опять таки в чем-нибудь human-readable. Чтобы когда среда в конец заглючит, открыть старый добрый FAR

....

Здравствуйте, Sinclair, Вы писали:

M>>А попробует сделать merge для XML-я, ощутит всю прелесть процесса и поймёт наконец, что разницы
M>>между бинарным и текстовым представлением по сути нет.
S>Это сильно зависит от конкретного использования текста. Вот Розовский формат диаграмм — текстовый, но кретины ухитрялись апдейтить идентификаторы всех объектов при каждом сохранении. Естественно, любой коммит — это merge с конфликтами на ровном месте. Ну так это от того, что в rational эту функцию делали некомпетентные люди. В бинарнике они бы получили вообще diff в 100% при каждом сейве.
S>А вот Wix, о котором идет речь, вполне себе friendly к SVN.

Проблема несколько глубже, чем некомпетентность розовских программеров.
При tree-based программировании все вынуждены использовать некие уникальные идентификаторы для символов/деклараций.
Скажем, кто-то завёл класс с именем Foo, а потом завёл другой класс с тем-же именем. Ситуация вполне нормальная,
поскольку это разные объекты моделирования. Это может быть промежуточный вариант редактирования имени класса,
или он появился в процессе переноса из другого namespace-а и т.п. Текстовый редактор же не должен падать, если у тебя
в тексте два класса с одинаковым именем. Поэтому и структурные редакторы должны нормально переживать такую
ситуацию. И больше того, они должны пережить эту ситуацию при сохренении и чтении промежуточного кода.

Поэтому практически все используют некие UUID/GUID идентификаторы для всех имён/деклараций.

Проблемы начинаются когда происходить export/import в текст. Если в текст (пусть в виде комментариев,
или аннотаций) пихать эти UUID для всех имён — то такой код ты читать не сможешь. Поэтому их
и не экспортят. А при импорте вынуждены генерировать все эти UUID по новой, естественно они будут
другими.

Если бы мы пользовались UML как кодом, а не кодогенерилкой — то проблем бы этих не возникло.
Эта, и многие другие проблемы совместимости текстового (в смысле имеющего определённый текстовый
синтаксис) кода и структурного кода не позволяют их удобно использовать вместе.
Неудобно сидеть на двух стульях.
Надо сесть на какой-то один стул, тогда не будет ни проблем с репозиториями, ни многих прочих.

Здравствуйте, mkizub, Вы писали:

M>Если бы мы пользовались UML как кодом, а не кодогенерилкой — то проблем бы этих не возникло.
Агащаззз. Есть такой новый способ вытягивания денег, называется MDA (Model-Driven Architecture). Это когда в UML рисуется модель приложения, а оно потом генерирует из неё всё что нужно.

Там даже инструменты сравнительно вменяемые. Только ВСЕ (в скобочках: все) компании, которые попытались это использовать — в итоге отказались. Так как картинки редактировать ничуть не удобнее, чем код.

Здравствуйте, mkizub, Вы писали:

M>Проблемы начинаются когда происходить export/import в текст.
Нет. Проблемы начинаются сразу, как только я нажимаю Save. Я говорю не про roundtrip engineering, а про банальную совместную работу над розовской моделью. Остальные рассуждения, основанные на неверных постулатах, поскипаны.

P.S. Посмотри на то, как работают class diagrams в Visual Studio. Всё прекрасно работает без всяких "читать не сможешь" и "представления в AST".

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Cyberax, Вы писали:

C>Естественно, я имею в виду осмысленный текст. Типа отформатированого XML, который ПРЕКРАСНО кладётся в репозиторий.

бинарники тоже там отлично лежат

C>И какие тут непреодолимые проблемы?

посмотри на мой пример в http://rsdn.ru/forum/message/2974514.1.aspx

Здравствуйте, WolfHound, Вы писали:

M>>Это процесс долгий и трудный,
WH>И нафиг не нужный ибо текст ничему не мешает.

Совсем ничему?
Давай на примере Nemerle.
Если бы компилятор Nemerle поддерживал C#-повский синтаксис — он разве не получил бы большего распространения?
А закатывание неудобного для Nemerle синтаксиса в строки — это разве не мешает?
Пока это какие-то примитивные синтаксисы, то ещё сходит. А если вы захотите обеспечить
полноценную поддержку SQL запросам, XPath синтаксису и пр. — на каждый из них вам надо будет
писать отдельный парсер и т.п.

У Nemerle нет будущего. Не в краткосрочной перспективе, а в долгосрочной. Именно потому, что
он пытается сидеть на двух стульях, сочетать мета-программирование и текстовый синтаксис.
Да и подход, когда вся семантика нового семантического понятия выражается лишь макросом,
который задаёт rewriting этого понятия через старые — слишком ограничивает возможности
мета-программирования.

Здравствуйте, mkizub, Вы писали:

WH>>И нафиг не нужный ибо текст ничему не мешает.
M>Совсем ничему?
Совсем.
Все проблемы лежат в модели системы.

M>Давай на примере Nemerle.
M>Если бы компилятор Nemerle поддерживал C#-повский синтаксис — он разве не получил бы большего распространения?
А если бы в С++ были продолжения?
А если бы у бабушки был...?

M>А закатывание неудобного для Nemerle синтаксиса в строки — это разве не мешает?
Это политические проблемы.
Если продавят более мощьные лексичиские макры то этого не будет.

M>Пока это какие-то примитивные синтаксисы, то ещё сходит.
M>А если вы захотите обеспечить полноценную поддержку SQL запросам,
Какой именно диалект? И они далеко не только синтаксисом отличаются.
M>XPath синтаксису и пр. — на каждый из них вам надо будет писать отдельный парсер и т.п.
А тебе семантические узлы и редакторы к ним.

M>У Nemerle нет будущего. Не в краткосрочной перспективе, а в долгосрочной.
У твоей сумаде тем более ибо любой пионер сможет сделать дерево которое само себе протеворечит.
Причем далеко не всегда эти противоречия можно будет даже засечь...
Система будет просто делать совершенно непонятные действия.

M>Именно потому, что он пытается сидеть на двух стульях, сочетать мета-программирование и текстовый синтаксис.
Это не проблема.
Проблемы немерла в другом.

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

... << RSDN@Home 1.2.0 alpha rev. 745>>

Здравствуйте, mkizub, Вы писали:

C>>Естественно, я имею в виду осмысленный текст. Типа отформатированого XML, который ПРЕКРАСНО кладётся в репозиторий.
M>бинарники тоже там отлично лежат
До первого конфликта.

C>>И какие тут непреодолимые проблемы?
M>посмотри на мой пример в http://rsdn.ru/forum/message/2974514.1.aspx
Я не вижу в чём там проблема.

Здравствуйте, mkizub, Вы писали:

M>Если бы компилятор Nemerle поддерживал C#-повский синтаксис — он разве не получил бы большего распространения?
Не получил бы — проблема в семантике.

Для Nemerle, AFAIR, были несколько вариаций синтаксисов.

M>А закатывание неудобного для Nemerle синтаксиса в строки — это разве не мешает?
Нет.

M>Пока это какие-то примитивные синтаксисы, то ещё сходит. А если вы захотите обеспечить
M>полноценную поддержку SQL запросам, XPath синтаксису и пр. — на каждый из них вам надо будет
M>писать отдельный парсер и т.п.
И что? Парсер-то всё равно придётся писать, хоть и в виде адаптера для древесной системы.

Здравствуйте, mkizub, Вы писали:
M>У меня нет VS. По причине линуховской операционки, и вообще.
Ну так подними ее в VM. А то ты тут свою IDE пытаешься изобрести, при этом ничего про реальные IDE не знаешь.
M>Так ты сделай там два класса с одним именем, и сохрани/восстанови. Расскажи как они справились.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Ты с чем несогласен-то? С тем, что текстовость формата не влияла на производительность дельфи приложения даже на железе образца 1995 года?

С какой версии Дельфи формат описания форм стал текстовым?

Здравствуйте, Andrei F., Вы писали:
AF>С какой версии Дельфи формат описания форм стал текстовым?
Насколько я помню, с 6й. Имеется в виду — формат хранения. Редактор форм в текстовом формате был как максимум в тройке.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, WolfHound, Вы писали:

WH>Что тебе тут непонятно?

Мне непонятно твоё употребление слова "семантика".
В словаре это слово расшифровывается как "значение", "понимание" обозначений.
Эрго — семантика существует только при наличии понимателя этих обозначений.
У понимателя семантика, а не сама по себе и не у обозначений, не у знаков и символов.
Это символы чего-то для наблюдателя, для читающего.

Соответственно, линзы задающие однозначные преобразования в какую-то другую форму и обратно,
задают семантику (значение) для некоего понимателя (в нашем примере — мержера),
поскольку эта новая форма имеет другую семантику для этого понимателя.
Простой пример с XML-ем и текстом — для XML-я формы "<tag/>" и "<tag></tag>"
имеют одну и ту-же семантику, а для текста (редактора, diff-а и прочих текстовых
"понимателей") это семантически разные вещи.

В harmony они линзами преобразовывают XML (или другой иерархический формат данных)
в некое внутренне своё представление, понимаемое их мержером. Этим они и задают
семантику конкретного XML-я для своего мержера. Тот производит слияние изменений
и через линзы делается обратное преобразование, задающее семантику для XML
парсера и прочих XML-евских тулзов.
Преобразование XML-я во внутреннее представление можно сделать по разному, и это
задаст разную семантику для мержера, варьируя которую мы задаём семантику
для себя. Скажем,
<phonebook>
<name>Вася</name>
<phone>123</phone>
</phonebook>
может быть преобразовано в
phonebook:{ name:{Вася} phone:{123}}
а может быть преобразовано и в
phonebook:{ name:{Вася phone:{123}}}
что будет для мержера иметь совершенно разную семантику, в первом случае name и phone
независимые данные, а во втором случае phone является под-элементом name.
В первом случае он будет мержить name и phone независимо, а во втором случае он
при изменении name (фактически удалении узла с name:Вася и вставки узла с name:Петя)
будет удалять и все под-узлы удалённого узла.
Для нас, секретарш и программистов, второе поведение мержера является правильным,
вторая модель трансформации данных является правильной — с точки зрения нашей семантики,
нашего понимания данных в phonebook. Таким образом эта линза и задаёт семантику.

SymADE в данном случае отличается от других средств программирования тем, что у него
уже задана стандартная внутренняя форма, внутренее представление. И больше того, программа
и хранится в виде внутреннего представления. Скажем, phonebook уже задан и хранится
в виде phonebook:{ name:{Вася phone:{123}}}, а не phonebook:{ name:{Вася} phone:{123}}.
Этим и задаётся семантика узлов, одинаковая для всех "понимающих" эту программу — редактора,
компилятора, отладчика, репозитория исходников и diff/merge утилит и т.д. и т.п.

Здравствуйте, mkizub, Вы писали:

M>В harmony они линзами преобразовывают XML (или другой иерархический формат данных)
M>в некое внутренне своё представление, понимаемое их мержером.

Сделав ложную предпосылку, врядли ты получишь что-либо вменяемое. Линза по сути есть лишь пара функций, преобразующих данные (какие угодно, не обязательно иерархические) "туда и обратно".
Для тебя функция f(x)=x+1, тоже приводит x сначала к какому-то внутреннему представлению, прежде чем единицу прибавить?

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, Курилка, Вы писали:

К>>В том числе и без мозга?

AF>А как же манагеры?

Это пять!!!!!

Здравствуйте, Sinclair, Вы писали:

S>С год назад пробегали скриншоты MS VS 2010.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

Здравствуйте, Sinclair, Вы писали:

C>>В бинарном формате хранится только дизайн, код — в виде старого доброго текста.
S>Начиная с версии 6.0 дизайн стал по умолчанию храниться в текстовом формате.

Раньше.

S> До этого разработчики пользовали самописанные приблуды для перевода .dfm в текст, т.к. бинарный формат оказался катастрофически несовместимым с системами контроля версий.

+1

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

Здравствуйте, Курилка, Вы писали:

К>Плюс в студии (которая явно отчасти продолжает идеи дельфи), вроде же resx (или как там оно зовётся, года 4 студию не трогал) нормально читаемый xml (хотя в уме транслировать координаты кнопок в картинку не особо сподручно)

resx это конечно xml, только формы храняться не в нем, а в коде на C#. А resx это просто файл с ресурсами.

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

Здравствуйте, Sinclair, Вы писали:

S>Насколько я помню, с 6й. Имеется в виду — формат хранения. Редактор форм в текстовом формате был как максимум в тройке.

Ну и вот. Зачем тогда говорить о "железе образца 1995 года"?
Но речь шла вообще не об этом.

AF>Ну и вот. Зачем тогда говорить о "железе образца 1995 года"?
Еще раз поясняю на пальцах: текстовый формат мог работать и в 1995. И это бы никак не повлияло на производительность.
Не сделали его не по техническим причинам, а потому что у разработчиков был клин в голове.
Так что я 100% уверен, что его поддержку сделали не потому, что "железо доросло", а потому что product manager пришел в команду и дал дюлей кому надо, основываясь на фидбеке от пользователей Delphi.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

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

LCR>Если мы возьмём внутреннее представление = байт-коду JVM, то окажется что внешнее преставление в виде Скалы возможно, а в виде Джавы — нет.

LCR>Если мы возьмём более крупноблочное преставление, скажем в виде AST для Джавы, то с помощью этого AST мы не сможем закодировать не только параметры-типы, а вообще почти любую скалистую фичу, которая идёт дальше обычного ООП.

LCR>Если мы возьмём внутреннее преставление = AST Скалы, то скажем банальный static не будет иметь аналога в Скале (static плохо дружит с компонентностью, поэтому он был выброшен).

LCR>И что теперь?

Вначале о внутреннем представлении. Всё, что мы с него имеем, это именованые типы семантических узлов, именованые атрибуты
и под-узлы этих семантических узлов, минимальные констрайнты (вроде — это необязательный скалярный атрибут, а это
вектор под-узлов типа "expression"). Это налагает достаточно мало ограничений, и достаточно удобно для работы.
Собственно, это почти лисповский список, разве только его элементы поименованы, а не имеют фиксированный индекс,
и заданы кой-какие вспомогательные данные. Можно уменьшать количество данных в описании узла (отказаться от имён,
или разрешить каждому атрибуту быть как скаляром так и вектором, отказаться от типизации вообще — любой атрибут
будет любого типа и т.п.), можно увеличивать требования к количеству данных в описании типа узла — каждый
из создающих tree-based среду разработки программ (IP, MPS, SOP) выбирает как ему удобнее.
Правильней было-бы создать некий стандарт на это описание, который будет поддерживаться всеми средами.
Так же как есть единый стандарт на текст (включая кодировки).

Так вот, теперь назад к Scala, Java, JVM и прочим.

Перво наперво, наша среда разработки программ должна позволить отображать и редактировать эти объявленные
узлы дерева. Для этого можно задавать "отображатели", некий "синтаксис". Узлы могут отображаться как
в виде текста, так и в виде графики, и конечно в смешанном виде. Скажем, мы можем задать отображение
таких узлов как "AccessModifier_Private" и "AccessModifier_Public" в виде иконки

соответственно,
а узел "InfixExpression { Operator op; Expression left, right}" в виде последовательности $left$ $op$ $right$,
где $...$ означает, что отображение задаётся отображениями для этих children узлов.
Конечно, если отображение для встретившегося конкретного типа узла не задано, то среда разработки
будет использовать некое отображение по умолчанию. Скажем, рисовать <<InfixExpression:{ $op$ $left$ $right$ }>.
Или рисовать <<InfixExpression>> и позволять редактировать его атрибуты в отдельном окне, где узел отображается
в виде дерева и т.п.
То есть отобразить среда сможет всё, и всё позволит редактировать — но если задать синтаксис отображения и
редактирования — работать с этими узлами будет удобней.
Кстати, это конечно не должно быть однозначным и полным отображением. Мы можем отображать в некоем текстовом
представлении, которое не сможет распарсить ни один парсер. Мы можем отображать только часть атрибутов узла.
И т.д.

Итак, мы задали некие семантические узлы для Scala, Java, JVM и их отображение. Можем не задавать отображения
некоторых узлов. Скажем, не задавать отображение для GOTO узла (семантического понятия), который есть в JVM.
И теперь мы пишем программу. При этом мы можем использовать любые известные системе (описанные во внутреннем
представлении) семантические узлы. Можем использовать скаловские трейты и абстрактные типы, которых нет в Java.
Можем использовать Java return и wildcard-ы в типах, которых нет в Scala. Можем использовать GOTO из JVM,
которого нет ни в Scala ни в Java. В смысле редактирования мы можем использовать всё, что угодно, постольку,
поскольку оно соответствует констрайнтам заданным во внутреннем представлении. Скажем, во внутреннем представлении
у нас сказано, что у InfixExpression есть скаляреый под-узел Operator — так мы в этот слот не сможем вставить
больше одного под-узла, или вставить туда узел типа Expression.

Теперь о компиляции всего этого бардака.
Компиляция происходит просто. Это tree rewriting. Задача среды программирования переписать дерево так, чтоб
в нём остались только узлы понимаемые target платформой. Скажем, у нас target платформа — это набор узлов
определённых для Java (то есть мы хотим, видимо, выдать на выходе явовский исходный текст).
А в программе у нас есть скаловские трейты.
Можем мы переписать наше дерево, заменив эти трейты на явовские узлы? Можем. Заменим узел ScalaTrait
на пару JavaInterface, а код из методов повставляем во все классы, которые extends наш трэйт.
Чаще всего это сработает, но иногда и не получится, как в твоём примере с монадой и абстрактным типом.

Можем мы заменить GOTO из JVM на явовский исходный код? Иногда можем. Скажем, заменим код

{
  foo();
  label: bar();
  goto label;
}

на

{
  int $label = 0;
$dogoto: for(;;) {
  switch ($label) {
  case 0:
    foo();
  case 1:
    bar();
    $label = 1; continue $dogoto; // goto "label"
  }
}

А если мы не сможем трансформировать дерево так, чтоб привести к набору узлов target платформы?
Сюрприз — выдадим ошибку компиляции.

Проблема здесь в чём? Проблема в том, что программист должен будет иметь квалификацию лучше, чем
обычно имеют сейчас. Если сейчас программист на java пишет static и не задумывается о том,
что при этом реально происходит, и это скомпилируется и будет работать — то программируя
в SymADE он должен будет понимать всю семантику происходящего, в том числе и понимать,
почему он неожиданно получить ошибку компиляции используя одновременно static и скаловские
семантические узлы. Или в крайнем случае, он добавит свой плагин для трансформации дерева,
который позволит в его конкретном случае таки скомпилировать программу в target платформу.

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

Больше того, SymADE будет легче в освоении этим малоквалифицированным программистом
(или скорее квалифицированным специалистом в своей области, но который не программист —
скажем, некий менеджер программирующий workflow). Потому как SymADE намного гибче
в отображении кода с одной стороны, и будет подсказывать неопытному пользователю —
какие именно конструкции можно вставить конкретно в этом месте. Ему не надо будет
знать, что объявление функции пишется как "def $name ( $args ) : $return_type".
Он скажет среде — вставить в это место новый узел, она ему скажет — можно вставить
объявление метода или поля. Он говорит — мне нужно метод вставить. Ему этот метод
и вставят. Потом он заполнит поле имени метода, и ему скажут — а теперь вставь
тип результата, это может быть то-то и то-то. И так далее.
С точки зрения осовения нового языка (онтологии семантических понятий) это намного
легче, чем выучивать синтаксис и продиратся через дебри, пока не освоишь этот
язык более полно. С точки зрения удобства, ну привык он к C-style синтаксису —
выберет отображалку объявления методов в виде "$return_type $name($args) { ... }",
а если он привык к паскалевскому синтаксису, он тот-же узел сможет отображать как
"method $name ($args) : $return_type begin ... end". И ему не надо будет
напрягаться с изучением нового синтаксиса только потому, что он захотел использовать
ScalaTrait в своей программе.

Здравствуйте, Sinclair, Вы писали:

S>Еще раз поясняю на пальцах: текстовый формат мог работать и в 1995. И это бы никак не повлияло на производительность.

Интересный вывод, только абсолютно беспочвенный.

Но речь шла, еще раз повторю, не об этом.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>mkizub,

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

Ок, интересно, посмотрю сейчас.

LCR>Теперь вернёмся.

M>>Вначале о внутреннем представлении. Всё, что мы с него имеем, это именованые типы семантических узлов, именованые атрибуты и под-узлы этих семантических узлов, минимальные констрайнты (вроде — это необязательный скалярный атрибут, а это вектор под-узлов типа "expression").
M>> ...
M>>Правильней было-бы создать некий стандарт на это описание, который будет поддерживаться всеми средами.
M>>Так же как есть единый стандарт на текст (включая кодировки).

LCR>Пока всё понятно. Хотя есть сомнения в том, что возможен стандарт на это описание. Так как всегда возможна ситуация, что какая-то фича уже не будет укладываться в стандарт. В данном случае получается, что нам надо будет выбрать внутреннее представление таким образом, что оно будет покрывать и язык Scala, и язык Java и язык опкодов JVM как частные случаи. То есть будет очень низкоуровневым! И каждый новый не укладывающийся в прежние рамки язык будет раздувать и дробить это внутреннее представление. Есть языки, где тела функций отделены от сигнатур, и сигнатуры являются FCO, есть языки где ветки в паттерн-матчинге являются FCO, есть Хаскелл со своей страшной системой типов, есть наконец Epigram, который я даже не представляю как подогнать под Java+Scala+JVM, настолько он другой. Естественно, общая база есть — это лямбда-исчисление. Или система команд x86. Или опкоды LLVM.

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

LCR>Ы? Где у меня поломалась логическая цепочка?

Э-э-э... нигде не поламалась, всё правильно, только это не имеет к SymADE никакого отношения.
Это здорово, что ты так всё расписал. И теперь мне совершенно ясно, в чём именно ты напутал с концепцией.

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

Всё обстоит прямо противоположным образом.

Если сравнивать, скажем с XML. У XML есть внутреннее представление. Упрощённо, это
text, element, attribute, entity и набор констрайнтов которые можно в этих entity задавать
(например, можно задать, что element с именем phonebook содержит список элементов
с именем entry, и каждый элемент с именем entry может содержать только один элемент
с именем name и один элемент с именем phone, а элементы с именем name и phone
содержат только текст). Всё, это внутреннее представление XML-я. А потом, при помощи
DTD, мы задаём конкретный набор element-ов и их attribute-ов, это уже будет
конкретный язык, онтология.
Аналогично, я под внутренним представлением имел в виду именно это — набор того, что
мы можем задавать относительно свойств семантического узла. Это его тип (аналог
tag-name в XML, но в отличии от XML типы наследуются, как в OOP). Это список
аттрибутов узла (как и в XML — именованный, но в отличии от него — типизированный,
а не просто текст). Это список child узлов (в отличии от XML — именованный
список).
Именно об этом внутреннем представлении я говорил, что его надо-бы стандартизировать.
Так же как стандартизирован XML. Но стандартизирован XML, а не каждый конкретный
DTD надо стандартизировать.

Далее.
Мы можем определять новые типы семантических узлов, и их онтологии. То есть язык это
некий аналог DTD в XML-е. Его, конечно, можно делать как закрытым (то есть
нельзя вставлять узлы из другого языка), а можно и открытым (как в XML — можно
вставлять какие угодно элементы и атрибуты, если это не запрещено констрайнтами
в DTD).

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

Трансформация дерева в target набор узлов — это и есть компиляция. Если тебе
компилятор трансформировал твоё дерево — ты, конечно, можешь его редактировать
дальше, но зачем? Ты же не редактируешь ассемблер, полученный из компиляции
С-шного кода. И не редактируешь C-шный код полученный из парсера написанного
на yacc.

В чём фишка, зачем нужно отказываться от единого внутреннего представления,
куда всё приводится, как в Nemerle? Для того, чтоб поддерживать разные
target платформы.

Скажем, если мы имеем unerasable type arguments у generic типа. Мы его
можем скомпилировать в Java, вставляя hidden аргумент в конструктор и сохраняя
его в final поле. Скажем, преобразовать

@unerasable class Vector<E> {
  E[] data;
  Vector(int size) { data = new E[size]; }
}
...
new Vector<String>(5);

public class TypeInfo {
  final Class cls;
  TypeInfo(Class cls) { this.cls = cls; }
  Object[] makeArray(int sz) { return this.cls.newArray(sz); }
}
class Vector {
  public static class VectorTypeInfo extends TypeInfo {
    TypeInfo arg$E;
    VectorTypeInfo(Class cls, TypeInfo arg$E) {
      super(cls);
      this.arg$E = arg$E;
    }
  }
  private final VectorTypeInfo $typeinfo
  Object[] data;
  Vector(int size, VectorTypeInfo $typeinfo) {
    this.$typeinfo = $typeinfo;
    data = this.$typeinfo.arg$E.newArray(size);
  }
}
...
new Vector(5, new VectorTypeInfo(Vector.class,String.class))

Уф. Приблизительно так оно делается у меня. И работает под JVM, хотя в ней
нет ран-тайм информации об аргументах generic типов.

А вот для .NET всей этой кодогенерации не нужно!!! Там мы так и оставим,
new Vector<String>(5), и оно будет работать. Потому как CLR это понимет,
и информацию о типах запомнит. И старый код будет работать эффективней
на CLR, но сможет скопилироваться и под JVM.

А если у нас фиксированное внутреннее представление, то эффективно под CLR
мы компилировать не сможем. Оно будет всё так-же вставлять ненужные
hidden параметры и генерировать ненужные классы. Потому как оно уже
преобразовалось в это внутреннее представление, а в нём нет понятия
"взять аргумент типа в рантайме". Или нам надо будет менять внутреннее
представление компилятора, а это как правило очень и очень сложно.
В SymADE мы просто напишем плагин, который будет трансформировать
дерево (в процессе компиляции), или не трансформировать, если не нужно.

Мы не переключаемся между языками. Мы в одно и то-же дерево (то есть в код)
можем вставлять семантические узлы из разных онтологий. В коде мы можем
вставлять и scala trait-ы и java interface-ы, и можем вставить
call-with-recursion, и можем вставить match. И оно скомпилируется
в target платформу, если есть плагины, которые смогут трансформировать
call-with-recursion в loop, и match в набор switch/if/else.
Или не трансформировать, если наша target платформа уже поддерживает
call-with-recursion или pattern-matching. А если такого плагина
нет — его можно написать, для данной конкретной target платформы,
или некий обобщённый — скажем, преобразовать match в набор if/else-ов,
и преобразовать if/else в match, и выбирать эти плагины при компиляции
в зависимости от того, что для target платформы является родным,
if-else или match, loop или call-with-recursion.

Здравствуйте, Sinclair, Вы писали:

S>Это неработающая утопия. Проблема разработки софта — вовсе не в синтаксисе. Синтаксис — это такая вещь, которая изучается за 15 минут.
S>Собственно разработка состоит в том, чтобы вставлять "в дерево" то, что нужно, в нужном порядке. Вот изучение этого "того, чего нужно" и представляет основную сложность.

Это заблуждение. Это всё равно, что сказать — я могу выучить алфавит за 15 минут, и значит я смогу читать текст
с этим алфавитом. Ну сможешь. А толку? Человек учится читать годами, он распознаёт слова не по буквам, а словами
и даже целыми строками. И синтаксис языка программирования после 10 лет кодинга распознаётся так-же
автоматом, а не "по буквам" через 15 минут.

S>А ты по какой-то причине считаешь, что боль — в продирании через дебри синтаксиса. Ну вот у Java и C# синтаксис близкий к С++. И что? Основная боль разработчиков C++ при миграции в управляемые среды — непонимание того, куда девать деструкторы.

Я не писал о миграции С++ в ява. Я писал об освоении нового языка.

S>Для того, чтобы применять ScalaTrait в своей программе, нужно сначала понять, что такое trait. Если этого не понять, то никакой синтаксис не поможет — будь то C, Pascal, или Basic. А если понять — то синтаксис никаких проблем не вызовет.

Для того, чтоб его там применять — надо вначале иметь компилятор, который его поймёт.

Здравствуйте, mkizub, Вы писали:
M>Это заблуждение. Это всё равно, что сказать — я могу выучить алфавит за 15 минут, и значит я смогу читать текст
M>с этим алфавитом. Ну сможешь. А толку? Человек учится читать годами, он распознаёт слова не по буквам, а словами
M>и даже целыми строками.
Для того, чтобы "распознавать слова", слова надо сначала знать. А ты, фактически, предполагаешь, что от переписывания в другой алфавит станет понятнее.
Ну вот тебе "переписанный" текст:

Зей хэд кроссд онли хаф ов зе вэст стоун холл уэн Опалин со Дельфен ху уоз джаст ин франт оф хё бай зис тайм глэнс куикли ту зе сайд. Фарзер эхед, Арагорн хэд лукед ап уиз э кёрс, энд Пиппин, лэггинг бихайд, гейв э край. Энд зен Опалин реализед зе хоррибл труф — зей вё сарраундед, энд зе сёркл уоз тайтенинг. Оркс вё раннинг эт зем фром олл дайрекшнс, ивен кроулинг даун фром зе сейлинг фар эбав. Зе шрикинг энд йеллз он олл сайдз вё дефенин, анд дроуинг ниаре.

Что, стало сильно понятнее, чем во вражеском алфавите?
M>И синтаксис языка программирования после 10 лет кодинга распознаётся так-же
M>автоматом, а не "по буквам" через 15 минут.
Лично я за 10 лет научился распознавать синтаксисы далеко не одного языка. Наверное, у меня какой-то быстрообучаемый автомат.

M>Для того, чтоб его там применять — надо вначале иметь компилятор, который его поймёт.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mkizub, Вы писали:
M>>Это заблуждение. Это всё равно, что сказать — я могу выучить алфавит за 15 минут, и значит я смогу читать текст
M>>с этим алфавитом. Ну сможешь. А толку? Человек учится читать годами, он распознаёт слова не по буквам, а словами
M>>и даже целыми строками.
S>Для того, чтобы "распознавать слова", слова надо сначала знать. А ты, фактически, предполагаешь, что от переписывания в другой алфавит станет понятнее.
S>Ну вот тебе "переписанный" текст:
S>

Зей хэд кроссд онли хаф ов зе вэст стоун холл уэн Опалин со Дельфен ху уоз джаст ин франт оф хё бай зис тайм глэнс куикли ту зе сайд. Фарзер эхед, Арагорн хэд лукед ап уиз э кёрс, энд Пиппин, лэггинг бихайд, гейв э край. Энд зен Опалин реализед зе хоррибл труф — зей вё сарраундед, энд зе сёркл уоз тайтенинг. Оркс вё раннинг эт зем фром олл дайрекшнс, ивен кроулинг даун фром зе сейлинг фар эбав. Зе шрикинг энд йеллз он олл сайдз вё дефенин, анд дроуинг ниаре.

S>Что, стало сильно понятнее, чем во вражеском алфавите?

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

M>>И синтаксис языка программирования после 10 лет кодинга распознаётся так-же
M>>автоматом, а не "по буквам" через 15 минут.
S>Лично я за 10 лет научился распознавать синтаксисы далеко не одного языка. Наверное, у меня какой-то быстрообучаемый автомат.

Так я тоже не одного. Но 10 лет — это не 15 минут.

M>>Для того, чтоб его там применять — надо вначале иметь компилятор, который его поймёт.
S>

Это как раз самое простое. В компиляторе парсер — далеко не самое сложное. Те "трансформации", которые ты предлагаешь оставить в качестве домашнего упражнения, как раз и являются самым сложным. Ты случайно Аппеля не читал? Серию про modern compiler?

Ответ правильный, но только в теории.
На практике дело выглядит совсем иначе.
Предположим, я захотел в Java добавить enum-ы. Сколько у меня займёт переписывание парсера? Час максимум.
А потом это всё компилятор должен будет понять. Вначале мы затрахаемся менять потроха компилятора. Не потому,
что enum-ы так сложно выразить через классы. А потому, что в почти любом компиляторе слишком много семантики
захардкодено. Чтоб легко можно было вставить enum-ы в java, нам нужно, чтоб javac был написан крайне абстрактно.
Такие компилеры для java есть, кстати. На них обкатываются всякие расширения к языку. Но это не бесплатно.
Сейчас мало кто согласится, чтоб время компиляции занимало раз в 100 больше времени, только ради того,
чтоб легко можно было добавить расширение в язык. В 100 раз дольше оно будет компилироваться у всех,
а расширяют язык мало кто. О причине этого чуть ниже. А о решении проблемы со временем компиляции — это
просто. Надо работать в IDE. Тогда она компилит в фоновом режиме, и только изменения. Проблем с тормозами
компиляции от слишком обобщённо написанного компилера ты, как правило, не заметишь.

Теперь о том, почему в яву не делают расширений.
А потому, что компилятор — это только одна из многих утилит, используемых при разработке программ.
Есть ещё, скажем, IDE. Ну, хотя-бы редактор в IDE. С подсветкой синтаксиса, с автокомплитом и пр.
Современные IDE увеличивают производительность труда программиста в разы. Ты согласишься
добавить enum-ы для своего проекта, понимая при этом, что тебе прийдётся отказаться от Eclipse/IDEA?
Врядли.
А кроме редактора есть ещё много чего, нужного для разработки. Те-же отладчики.
Я вот не могу использовать ни один GUI отладчик для отладки SymADE-а. Только jad, консольный отладчик.
Остальные не могут предоставить полноценной отладки не пройдясь парсером по исходному коду.
А ещё есть всякие анализаторы кода, которые в нём отлавливают потенциальные ошибки, которые
следят за code conventions, которые строят из исходников UML диаграмы, которые строят
из исходников документацию и другие.

Так вот. Тебе, для добавления enum-ов в java надо поправить все эти средства разработки.
А чтоб не зависить от конкретной, то лучше поправить несколько компиляторов, несколько IDE
и т.п.

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

Синтаксис языке — это не просто парсер. Это точка сборки, это точка координации всех средств
разработки для данного языка программирования. Измени синтаксис — и их взаимодействие
развалится. Именно поэтому добавление новых фич в яву занимает годы. Хотя чего там сложного,
сгенерировать class из enum-а?!

SymADE написан с учётом всего вышеизложенного. Поскольку на всё это я напоролся, когда писал
свой компилятор с расширениями к яве.
SymADE — это IDE. Компиляция в фоне. Хотя batch компиляция самого себя у него занимает где-то
полторы минуты на хорошей машине и 128 мег памяти (это я ещё слежу за оптимизацией, а финальные
фичи потребуют 256 памяти и минут 5 компиляции), а до того, когда у него была приблизительно
та-же функциональность (как компилятора), он компилировался на много более слабой машине
за пятнадцать секунд и кушал 16 мег. Это цена за лёгкую расширяемость. Скажем, enum-ы
я бы в него добавил за пару дней. Но когда он дойдёт до релиза, эта цена не покажется
большой, так как компилится он будет в фоне. А по памяти — так современные IDE жрут
не меньше (по той-же причине — они держат всё AST дерево программы, иначе их
крутые фичи реализовать невозможно).
Вставка новых семантических узлов не вызовет никакого напряга у SymADE. Практически
все расширения явы начиная с версии 1.1 у меня так и реализованы, как плагины к компилеру,
которые просто трансформируют дерево в процессе компиляции. Да, у меня этих расширений
раза в два больше, чем те, которые ява получила с версии 1.1 до версии 1.6. И отлично
себя редактор чувствует. Отладчик бы тоже чувствовал себя хорошо, но всё нет времени
его сделать.
В самом SymADE написаны DSL языки, которые не имеют текстового синтаксиса. Они прям
в виде дампа дерева и сохраняются. Это язык для определения отображения и
редактирования узлов, и язык для макро-подстановок (то есть простой трансформации
дерева, настолько простой, что удобней написать макрос, чем городить целый
новый плагин, который будет шоркаться по потрохам AST дерева).

Вот что было-бы круто, так это всё-таки выработать единый стандарт на внутренее
представление дерева, что-то вроде стандарта на XML. Тогда один и тот-же код
можно было-бы редактировать и в MPS от JetBrains, и в SymADE, и в IP и в прочих.
И такой стандарт будет в конце концов. Может не один, может их будет два или три.
Впрочем, это дело будущего.

Здравствуйте, Erop, Вы писали:

M>>и трудный, но по моему глубокому убеждению — неизбежный.

E>Если ты не заметил, то M$ эту экосистему уже давно и упорно создаёт. Лна называется XML...

Ну, сказать, что это M$ создаёт XML будет сильным преувеличением.
Скорее он создаётся и поддерживатся в Java. А остальные подтягиваются.
XML имеет кучу неудобств как внутренее представление для программ.
Во-первых, он не ОО. Я могу сказать, что мой phonebook содержит
тип данных entry, и entry содержит name и phone данные.
phonebook { entry* }; entry { name; phone }
А если я захочу my_entry extends entry { e-mail }?
Низзя, это только my_entry { name; phone; e-mail }, и менять
phonebok { (entry | my_entry)* }.
Во-вторых, у него именованые только атрибуты. А child ноды
неименованые, сваленные все в кучу. Мне, чтоб найти name в entry
надо будет лазить по всему списку child узлов? Вместо чтоб по имени
поля просто получить его значение? Любой компилятор использующий
XML (фактически DOM) как внутреннее представление, сразу станет
работать раз в 100 медленее.
В третих, он избыточен для структурированных данных. Он предназначен
для markup-а текста, то есть <p>hello <b>world</b>!</p>. Нафиг
мне описание my_entry { name; (phone | e-mail)* }, куда я его
в структуру данных (чтоб компилер получил быстрый доступ к данным) засуну?
Ну и вообще, его DOM модель просто ужасна. В Node засунуты методы,
которые есть только у Attribute или Entry. И мне надо сделать
getNodeType(), перед тем, как вызвать метод для Entry, иначе я схлопочу
эксцепшином по голове. Или getParentNode() работающая у всех, кроме
Attribute, а у Attribute надо вызывать getParentElement().
Я уже молчу про полный кабздец с namespace-ами.

Не, хай MS и Java и остальные упорно работают над XML, а я сбоку
постою. Для внутреннего представления программ он совершенно не подходит.

Здравствуйте, mkizub, Вы писали:
M>Менее понятно, так как я уже надцать лет учил именно во вражеском алфавите.
M>Но пример замечательный. Ты представь, чтоб англичанина это заставить читать, просто по той причине,
M>что автор очередного литературного шедевра написал его именно так.
Я не буду это представлять, потому что никакому реальному сценарию это не соответствует.
С чего это автор будет писать в чуждом синтаксисе? Как правило, реальные языки сбалансированы — синтаксис выбирается для семантики. Всё. Ни один англичанин не будет писать кириллицей.

M>Автор просто тащщится от
M>этого алфавита. А читать потом простому человеку.
Автор тащится не от алфавита, а от языка. И пишет слова из того же языка, из которого алфавит.

M>Так и автор очередного языка, просто тащщится от своего синтаксиса. А я почему должен
M>этому синтаксису радоваться?!

Потому что в другом синтаксисе нет адекватной семантики. Тебе уже приводили массу примеров.

M>Ответ правильный, но только в теории.
M>На практике дело выглядит совсем иначе.
M>Предположим, я захотел в Java добавить enum-ы. Сколько у меня займёт переписывание парсера? Час максимум.

M>А потом это всё компилятор должен будет понять. Вначале мы затрахаемся менять потроха компилятора. Не потому,
M>что enum-ы так сложно выразить через классы. А потому, что в почти любом компиляторе слишком много семантики
M>захардкодено. Чтоб легко можно было вставить enum-ы в java, нам нужно, чтоб javac был написан крайне абстрактно.
Ну так я тебе об этом и толкую! Твоя убогая SymADE решает исключительно проблемы парсера. А дальше-то что?

M>Такие компилеры для java есть, кстати. На них обкатываются всякие расширения к языку. Но это не бесплатно.
M>Сейчас мало кто согласится, чтоб время компиляции занимало раз в 100 больше времени, только ради того,
M>чтоб легко можно было добавить расширение в язык. В 100 раз дольше оно будет компилироваться у всех,
M>а расширяют язык мало кто. О причине этого чуть ниже. А о решении проблемы со временем компиляции — это
M>просто. Надо работать в IDE. Тогда она компилит в фоновом режиме, и только изменения. Проблем с тормозами
M>компиляции от слишком обобщённо написанного компилера ты, как правило, не заметишь.
Вот это мне непонятно. Какие там тормоза от енумов??? Откуда в 100 раз больше времени? Там вопрос принципиальный — как отладить генератор джавного AST, чтобы для всех corner cases для енумов генерировались правильные классы.

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

А ведь бывают и хардкорные вещи, которые влияют на проект в целом — скажем, те же extension methods в дотнете. Они влияют на семантику совершенно постороннего, казалось бы, кода.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, mkizub, Вы писали:

E>>Если ты не заметил, то M$ эту экосистему уже давно и упорно создаёт. Лна называется XML...

M>Ну, сказать, что это M$ создаёт XML будет сильным преувеличением.
А я этого не утверждал. Просто MS ожно время явно имела курс всё хранить в XML. Например документы ворда...

Здравствуйте, WolfHound, Вы писали:

M>>Давай на примере Nemerle.
M>>Если бы компилятор Nemerle поддерживал C#-повский синтаксис — он разве не получил бы большего распространения?
WH>А если бы в С++ были продолжения?
WH>А если бы у бабушки был...?

Она была-бы дедушкой. А Nemerle так бабушкой и останется.
Вроде, MS ничего не помешало иметь для CLR несколько разных синтаксисов (C#, VB).
А вот в Nemerle квази-цитирование сдохнет, если ему подсунуть C# синтаксис.

M>>А закатывание неудобного для Nemerle синтаксиса в строки — это разве не мешает?
WH>Это политические проблемы.
WH>Если продавят более мощьные лексичиские макры то этого не будет.

А чем обосновывают ненужность более мощных макросов?

M>>Пока это какие-то примитивные синтаксисы, то ещё сходит.
M>>А если вы захотите обеспечить полноценную поддержку SQL запросам,
WH>Какой именно диалект? И они далеко не только синтаксисом отличаются.

А любой и все вместе взятые. У SymADE с этим проблем не возникнет.
Совпадающую семантику описать едиными семантическими узлами, семантику добавленную в
диалекты их семантическими узлами.
Я тебе больше скажу. На 90% добавленная семантика у разных диалектов совпадает.
Ну, скажем, автоинкрементация уникального ключа. Она есть у всех, но реализована
по разному. А в SymADE для этого делается семантический узел, один, и он будет
выдавать разный конечный код (SQL запрос посылаемый на сервер).

M>>XPath синтаксису и пр. — на каждый из них вам надо будет писать отдельный парсер и т.п.
WH>А тебе семантические узлы и редакторы к ним.

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

M>>У Nemerle нет будущего. Не в краткосрочной перспективе, а в долгосрочной.
WH>У твоей сумаде тем более ибо любой пионер сможет сделать дерево которое само себе протеворечит.
WH>Причем далеко не всегда эти противоречия можно будет даже засечь...
WH>Система будет просто делать совершенно непонятные действия.

А тебе не мешает, что твои действия предсказать порой невозможно?
Другого выхода нет. Или это будет система, действия которой всегда можно уверенно
предсказать, но она будет примитивной и ограниченной, или это будет сложная, умная
система, которая порой будет выдавать неожиданные результаты.
Разве в Nemerle ты не столкнулся с тем, что написанный тобой макрос может
странным образом повлиять на процесс компиляции?

M>>Именно потому, что он пытается сидеть на двух стульях, сочетать мета-программирование и текстовый синтаксис.
WH>Это не проблема.
WH>Проблемы немерла в другом.

Ну поделись.

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

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

Здравствуйте, mkizub, Вы писали:

M>Вроде, MS ничего не помешало иметь для CLR несколько разных синтаксисов (C#, VB).
Забыл еще кучу языков.
Проблема в том что декомпилировать код сгенеренный немерлом в C# нереально.
А если и получится то будет такое что лучше бы не получилось.

M>А вот в Nemerle квази-цитирование сдохнет, если ему подсунуть C# синтаксис.
Если поправить одну из первых стадий компилятора то нет.
Только это нафиг не нужно.
Ибо синтаксис немерла и так от C# не сильно отличается.

M>А чем обосновывают ненужность более мощных макросов?
Недетерминированностью данных макросов.
Сейчас компилятор точно знает где макра начинается и где заканчивается.
Если сделать эти макры то перестанет.

M>А любой и все вместе взятые. У SymADE с этим проблем не возникнет.
Ну и немерла в тойже степени не возникнет.

M>Совпадающую семантику описать едиными семантическими узлами, семантику добавленную в диалекты их семантическими узлами.
И переписывать код под каждую БД... очень умно.

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

M>А тебе не мешает, что твои действия предсказать порой невозможно?
Ты демагогию не разводи.

M>Другого выхода нет. Или это будет система, действия которой всегда можно уверенно предсказать, но она будет примитивной и ограниченной, или это будет сложная, умная система, которая порой будет выдавать неожиданные результаты.
Граници данной "ограниченности" могут проходить очень далеко.
При этом получим огромные плюсы из-за стандартизации и отлова массы багов компилятором.
Скажем я уже придумал систему типов которая с одной стороны предотваращает race condition'ы и с другой не делает процесс написания программ мучительным. Скорее наоборот.

Твоя сумаде может дать гарантии отсутствия race condition?

M>Разве в Nemerle ты не столкнулся с тем, что написанный тобой макрос может странным образом повлиять на процесс компиляции?
Ну я нигде и не говорил про то что немерле идеал.
Он лучшее что есть под .NET но не идеал.
В любом случае настолько непредсказуемых последствей как в твоей сумаде там не будет.

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

1)Попрошу не выражаться.

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

... << RSDN@Home 1.2.0 alpha rev. 745>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mkizub, Вы писали:
M>>Менее понятно, так как я уже надцать лет учил именно во вражеском алфавите.
M>>Но пример замечательный. Ты представь, чтоб англичанина это заставить читать, просто по той причине,
M>>что автор очередного литературного шедевра написал его именно так.
S>Я не буду это представлять, потому что никакому реальному сценарию это не соответствует.
S>С чего это автор будет писать в чуждом синтаксисе? Как правило, реальные языки сбалансированы — синтаксис выбирается для семантики. Всё. Ни один англичанин не будет писать кириллицей.

Фигня. Семантика C и Pascal соответствует друг другу почти один в один. А синтаксис не имеет ничего общего.
При одинаковой семантике VB и C# у них разный синтаксис.
Какой из них более сбалансирован?

M>>Так и автор очередного языка, просто тащщится от своего синтаксиса. А я почему должен
M>>этому синтаксису радоваться?!

S>Потому что в другом синтаксисе нет адекватной семантики. Тебе уже приводили массу примеров.

Не понял. Приведи пример.

M>>Ответ правильный, но только в теории.
M>>На практике дело выглядит совсем иначе.
M>>Предположим, я захотел в Java добавить enum-ы. Сколько у меня займёт переписывание парсера? Час максимум.

M>>А потом это всё компилятор должен будет понять. Вначале мы затрахаемся менять потроха компилятора. Не потому,
M>>что enum-ы так сложно выразить через классы. А потому, что в почти любом компиляторе слишком много семантики
M>>захардкодено. Чтоб легко можно было вставить enum-ы в java, нам нужно, чтоб javac был написан крайне абстрактно.
S>Ну так я тебе об этом и толкую! Твоя убогая SymADE решает исключительно проблемы парсера. А дальше-то что?

А дальше у меня и компилятор написан расширяемо. А дальше и VM будет написана расширяемо.
А дальше оно и на расширяемом железе будет работать.

M>>Такие компилеры для java есть, кстати. На них обкатываются всякие расширения к языку. Но это не бесплатно.
M>>Сейчас мало кто согласится, чтоб время компиляции занимало раз в 100 больше времени, только ради того,
M>>чтоб легко можно было добавить расширение в язык. В 100 раз дольше оно будет компилироваться у всех,
M>>а расширяют язык мало кто. О причине этого чуть ниже. А о решении проблемы со временем компиляции — это
M>>просто. Надо работать в IDE. Тогда она компилит в фоновом режиме, и только изменения. Проблем с тормозами
M>>компиляции от слишком обобщённо написанного компилера ты, как правило, не заметишь.
S>Вот это мне непонятно. Какие там тормоза от енумов??? Откуда в 100 раз больше времени? Там вопрос принципиальный — как отладить генератор джавного AST, чтобы для всех corner cases для енумов генерировались правильные классы.

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

Ага. Ну ладно ещё из enum-а класс сгенерировать. Но его же ещё и в switch хотелось-бы засунуть.
Вот тут все прелести жизни и обнаружатся. Хардкоднутый switch ждёт только int, и его case ждёт
int. И со страшным грохотом порушаться, когда им туда подсунуть object.
Вот чтоб оно не грохнулось, и нужны эти тормоза. Когда у switch и case лежит в выражении что угодно.
А некий плагин, реализующий enum-ы, пройдётся по дереву и поменяет на getCardinal() или как там
enum-ы преобразуются в int-ы.
Вот при компиляции switch уже проверит, что тип выражения int, и если не — то будет выдавать ошибку.
Это ещё мелочи. А когда я сделал singleton, и писал

@singleton S {...}
...
Object o = S;

То при резолвинге, вместо expression мы получали typedecl, и оно не падает. Потому как
плагин для singleton-ов проходит по коду, и меняет те места, где нам нужно expression,
на S.getInstance().

S>И енумы — это еще цветочки, потому что предлагаемые ими изменения локальны. Это всего лишь такой специальный способ описания отдельных классов.

S>А ведь бывают и хардкорные вещи, которые влияют на проект в целом — скажем, те же extension methods в дотнете. Они влияют на семантику совершенно постороннего, казалось бы, кода.

Ага. Посмотрел я на них. В SymADE это можно добавить за день.
Только не нужно, есть несколько другие средства, которые дают аналогичную функциональность.
Так вот, добавить их за один день можно именно по этой причине — абстрактность компилятора.
Резолвер имён проходит по всем доступным ему узлам и областям видимости, и те выдают ему кандидатов.
Область видимости обращается ко всем своим под-узлам и спрашивает — не знают ли они такого
идентификатора (или метода). Скажем, FileUnit проходится по своим членам и спрашивает их.
Обычно это import-ы всякие, typedef-ы, декларации типов.
Вот extension method и должен выдать себя как кандидата.
А потом пройтись по коду плагинчиком, и заменить вызов instance метода на вызов static метода.

S>Мне совершенно непонятно, как ты собираешься с ними работать.
S>Я не понимаю, каким образом ты собираешься экономить усилия на разработку инфраструктуры, если всё, что ты предложил, сводится к отказу от синтаксиса. Откуда возьмется семантика? Откуда возьмется автодополнение в текстовом редакторе? Откуда возьмется отладка, с маппингом точки исполнения в исходник? Ничего этого не видно. Или ты полагаешь, что пользователи будут писать реально более-менее объемный код при помощи кликов мышкой? Я в это не верю.

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

Скажем, у меня есть некий абстрактный резолвер. Он резолвит все узлы, которые наследуются от DNode
(declaration node) и Symbol (интерфейс, кстати DNode implements Symbol).
Если ты хочешь, чтоб твой узел нашёл резолвер — сделай ему implements Symbol, и его автоматом
будет резолвер находить.
У резолвера есть параметры, которые уточняют, какие именно Symbol-ы нужны ищущему. Скажем,
можно задать, что мы ищем только поля, или только переменные, или и те и те, или только
декларации типов и т.п.
Резолвер написан на чём-то вроде prolog-а. И работает так-же. Находит первый подходящий
символ и возвращает его. Если попросят (не подошёл) — будет искать дальше, найдёт следующий.
Можно искать пока не найдёт все подходящие симоволы. Все символы ищутся при автодополнении,
и из них выбираются только те, которые начинаются на наше имя. Если тебе нужен какой-то
конкретный тип узлов — задаёшь этот фильтр в резолвере или фильтруешь его результаты.
Если ты ищешь переменную для резолвинга при компиляции — ты ищешь первый, и на этом
останавливаешься. Поля ищутся через форвардинг (переменная this форвардит поиск в свой
класс). Скажем, поля outer класса будут найдены через форвардинг this.this$0 (this$0
это поле указывающее на outer instance).
В общем, всё довольно абстрактно сделано. Потому и тормозит...

Кликать мышкой для написания кода не надо. Ты можешь использовать short-cut-ы.
Нажать клавишу "вставить следующий элемент", оно тебе выдаст список из
Import, Typedef, TypeDecl (подменю> Class, Interface, Enum), и ты выбираешь элемент
из списка набирая на клаве соответствующее имя (как при автокомплите), или
стрелочками, или мышкой если хочешь. Оно тебе вставляет нужный узел, скажем,
class, ты редактируешь ему имя, и нажимаешь клавишу "вставить новый под-элемент",
оно тебе выдаёт список из Field, Method, и так далее. Или нажимаешь клавишу
"добавить мета-данные" и выбираешь "@public", или ещё что.
Я так работал с декларативными описаниями — это достаточно удобно, по количеству
нажатий клавиш не больше, чем нужно набирать при работе с текстом.

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

Всё это работает если задать синтаксис. А если не задавать, и редактировать "сырые"
узлы, то да, там менее удобно. Зато можно сделать вообще всё, что можно сделать с
деревом.

	От:	serg baburin
	Дата:	01.06.08 10:18
	Оценка:

	От:	Andrei F.
	Дата:	03.06.08 02:39
	Оценка:	-3

	От:	WolfHound
	Дата:	03.06.08 13:44
	Оценка:	+5

	От:	Andrei F.
	Дата:	02.06.08 02:16
	Оценка:

	От:	Cyberax
	Дата:	02.06.08 16:15
	Оценка:	1 (1) +2

От:	Sinclair	https://github.com/evilguest/
Дата:	03.06.08 03:15
Оценка:	+1 -2

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	06.06.08 11:43
Оценка:	6 (1) +1

От:	mkizub	http://symade.tigris.org
Дата:	03.06.08 12:37
Оценка:	-2

От:	Курилка	http://kirya.narod.ru/
Дата:	04.06.08 11:16
Оценка:	+1

	От:	VUspenskiy
	Дата:	01.06.08 18:27
	Оценка:	2 (1)

От:	eao197	http://eao197.blogspot.com
Дата:	03.06.08 10:45
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	04.06.08 15:10
Оценка:

От:	VladD2	www.nemerle.org
Дата:	18.06.08 19:02
Оценка: