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

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

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

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

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

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

Здравствуйте, 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 не имели бы успеха.

Здравствуйте, 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 принтере.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>
...

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

Здравствуйте, 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 ....

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

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

Здравствуйте, 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".