Здравствуйте, 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 в дотнете. Они влияют на семантику совершенно постороннего, казалось бы, кода.

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

Здравствуйте, 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 не обязателен?
Дальнейшие жалобы, происходящие от каши в голове, поскипаны.

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

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

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

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

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

Здравствуйте, 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?
2)Тем что когда два программаста нипишут 2 нормальных по отдельности дерева одно с продолжениями, а другое с деструкторами. А третий захочет их соеденить...

Здравствуйте, 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", или ещё что.
Я так работал с декларативными описаниями — это достаточно удобно, по количеству
нажатий клавиш не больше, чем нужно набирать при работе с текстом.

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

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

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

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

http://nlp-system.com/diagnostika_tipov_reprezentacii.php

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

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

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

ZS>http://nlp-system.com/diagnostika_tipov_reprezentacii.php

А теперь удосужься ответить какое отношение это имеет к моему вопросу?
(hint: репрезентация != восприятие)

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

К>картинки и диаграмки никогда не заменят наличие мозга у программиста

И исходный код не заменит.

К>и при некорректном применении только увеличат число "шума" мешающего решению задачи.

Это про что угодно.

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

Это необходимое условие, если "программист не читатель, чукча писатель". Бывает, нужно быстро получить картину в целом. Встречаются исходники без документации, на неизвестных языках, да не всегда хотя бы они есть.

Да и в дизайне, wicked problem требует иного представления. Так что хватило бы:
К>Всё это хорошо

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

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

Спокойно, Синклер! Дельфи плагиатор. Первый на Винде был VB и он был в текстовом виде (да и потом оставался... в плоть до сегодняшних дней). А еще до этого были форм-билдеры в Кларионе, Фоксе и т.п. И все они были текстовыми. И было это не в 1995-ом, а раньше. И производительности хватало.

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

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

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

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

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

VD>Думаю, что люди вроде Фаулера защищают скорее не бинарность форматов, а их структурированность. В принципе конечно было бы изумительно если системы хранения версий понимали, что хранят они не текст, а структурированные данные. Это позволило бы гибче их обрабатывать. Но это никак не противоречит идее хранения все же текста. Просто, по-моему, сами системы контроля версий должны стать по-умнее. Вот и все.

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