Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>С этой стороны да. FR>>Но он позволяет в отличии от C++, реально писать на безопасном подмножестве языка. (Про необходимость ключика для комилятор я уже раньше говорил).
VD>C++ тоже позволят писать на безопасном подмножестве. Вот только обычно это никто не делает. Как показали первые же примеры кода на D тоже никто так делать не будет.
C++ реально не позволяет писать на безопасном подмножестве.
На D уже смогли в автоматическом режиме транслировать нетривиальную java библиотеку.
FR>>Вряд ли усложнение, все это вместе по моему проще чем объяснить например типы и предназначние конструторов для C++
VD>С++ без паттернов извращенческого программирвания довольно простой ООЯ. Так что как раз изучать его не так сложно. Сложности начинаются при реальной работе когда кроме знания языка нужно еще знать море паттернов для совершенно повседневных и примитивных операций.
Для меня изучить язык это значит научится реально на нем работать. А то что ты понимаешь под изучением это так ознакомится.
VD>Но без них можно жить. Просто вместо одной простой и понятной строки будет куча кода (например цикл для поиска элемента в списке).
Все равно будут сложности даже в базовых вещах.
VD>Другими словами простота синтаксиса С++ превращаетя в сложноть паттернов. Ну, и в купе с полнешей небезопастностью языка это выливается в горы геморроя.
Нет простота синтакиса совершено не причем. Скорее тут виновата непродуманость и противоречивость "модели языка", во многом из-за тотальной совместимости с си.
FR>>Пока язык для достаточно опытных программистов, которые "устали" от C++, но не хотели бы отказыватся от многих его возможностей.
VD>У этого языка одна возможнсоть — создавать геморрой людям его использующим. И зачем нужна замена которая уменшает геморрой вместо его полного устранения я лично не понимаю.
Полностью геморой ни один язык не устраняет, даже твой любимый сейчас язычок
VD>Для низкого уровня (возни с битами) вполне достаточно С++. Для прикладного программирования (влючая сервы и любой десктопный софт) придуманы гораздо более удобные и мощьные языки.
D практически содержит подмножество, в которое входит почти вся java и большая часть шарпа. Просто сейчас смотрю GUI библиотеки для D и что вижу: DWT полный клон явовской SWT, dfl который сделан по мотивам WinForms из NET.
FR>> Я знаю достаточно людей (включая и самого себя) которые в состоянии освоить вещи очень отличные от С++ и майнстрима вообще, но которым нравится и главное комфортно работать именно с С — С++, думаю многим из них и D понравится.
VD>Ну, что же. Приношу свои соболезнования. Лично я в жизни не буду использовать ни С++, ни ди, если у меня будет хоть какой-то выбор. Это пешерное програмирование для людей не ценящих свое время и не желающих получать удовольствие от самого процесса программирования. А я, знаете ли, люблю получать от программирования удовольствие.
Да да конечно, только надо еще немного злобной функциональности добавить
Вот я недавно ковырял Рефал, получил много удовольствия, очень интересный и очень мощный язык (не смотря на то что он наверно самый примитивный из всех функциональных, даже лисп со схемой отдыхают), но программировать на нем реально вряд ли когда буду, так что удовольствие и работу вполне можно и разделять.
Ну а D вполне позволяет и с удовольствием программировать, и уже близок к рабочему языку.
Здравствуйте, VladD2, Вы писали:
VD>C++ тоже позволят писать на безопасном подмножестве. Вот только обычно это никто не делает. Как показали первые же примеры кода на D тоже никто так делать не будет.
Это какие-такие примеры?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Другими словами простота синтаксиса С++ превращаетя в сложноть паттернов. Ну, и в купе с полнешей небезопастностью языка это выливается в горы геморроя.
Эта неизбежность... она из личного опыта как я понимаю?
Здравствуйте, eao197, Вы писали:
E>Насколько удобно будет пользоваться этим SWT.d и что из этого получится -- Но сам факт примечателен. Если, как говорит разработчик TioPort, конвертация происходила по большей части автоматически, то это открывает возможность портирования на D из Java и других библиотек. Что должно поспособствовать наполнению D хорошими и разными инструментами/библиотеками/фреймворками.
Жень, скажи честно, ты сам в это веришь?
Java и D настолько большие разницы... Java и D — разные домены задач.
Java code нещадно экплуатирует GC которые в Java в принципе более эффективный чем в D. По определению.
Тупая конвертация практически любой библиотеки Java это смерть для D.
Гораздо более реальным является автоматический порт C -> D. Тем более что на C кода для домена D приложений
больше в разы написано. Но это нафиг никому не надо ибо C и так c D нативно общается.
И по поводу SWT... Как бы есть Native Eclipse. Сделан он компилятором Java -> native code. Что
тоже самое (если не лучше) что и Java -> D -> native code. Много людей счастливы от этого?
На D нужно писать именно думая на D и четко понимая его идею, только тогда толк будет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Сдается мне, что процесс получения удовольствия слабо зависит от рода проблем, которые приходится решать. Кому то интереснее одно, кому то другое.
Для некоторых людей так и есть. Но есть немало людей, которые не получают никакого удовольствия от решения проблем, которые они создали себе своими же руками. По крайней мере — я надеюсь, что их немало. Но иногда после чтения форумов я начинаю в этом сомневаться
Здравствуйте, c-smile, Вы писали:
E>>Насколько удобно будет пользоваться этим SWT.d и что из этого получится -- Но сам факт примечателен. Если, как говорит разработчик TioPort, конвертация происходила по большей части автоматически, то это открывает возможность портирования на D из Java и других библиотек. Что должно поспособствовать наполнению D хорошими и разными инструментами/библиотеками/фреймворками.
CS>Жень, скажи честно, ты сам в это веришь?
CS>Java и D настолько большие разницы... Java и D — разные домены задач. CS>Java code нещадно экплуатирует GC которые в Java в принципе более эффективный чем в D. По определению. CS>Тупая конвертация практически любой библиотеки Java это смерть для D.
В то, что можно тупо перегнать исходники на Java в исходники на D и получить приличный результат я не верю.
Я надеюсь на то, что подобные преобразователи помогут выполнять большой объем рутинной работы, результаты которой затем можно будет дорабатывать напильником.
Имхо, все-таки для некоторых задач будет проще использовать сконвертированный Java код, чем писать его заново на D. Например, для Java есть библиотеки для работы с подписанным XML, с SOAP, с различными протоколами электронной коммерции. Я больше чем уверен, что существенный процент кода этих библиотек будет выглядеть практически одинаково что на Java, что на D, что на C#. Так зачем же этот одинаковый код руками переписывать.
Да, еще по поводу различия Java и D. Дело ведь не только в GC, например, есть еще и разные подходы к обработке строк на D и на Java. А еще в Java очень сильно любят использовать рефлексию (чего в D пока нет) и динамическую загрузку классов. Т.ч. более-менее сложный Java код все равно 1:1 в D не сконвертируется.
Что же до разных доменов задач, то вокруг происходят вещи, которые я понимаю, но смериться не могу. Вот, например, история масштабирования twitter. 8 Sun-ов для обработки 600 запросов в секунду
Я вот несколько раз наблюдал, что переписывание задачи с C++ на Java делало Java-вариант в несколько раз медленне, чем C++ный (правда не в Web-е, в других областях). Т.е. чтобы система обрабатывала такое же количество транзакций, как C++ вариант (либо, как в одном из случаев отрисовывала поступающие в soft-real-time данные) нужно было в 3(!) раза более мощное железо (более быстрый процессор, больше памяти).
Да, стоимость разработки на Java ниже, чем на C++. Причем здесь, имхо, 50% составляют особенности самого языка и еше 50% (а иногда и больше) библиотеки. Но в условиях, когда программу пишут, скажем 3 человека, а за эксплуатацию затем отвечают 6 администраторов, снижение стоимости разработки, имхо, затем компенсируется увеличением стоимости эксплуатации. Ведь обслуживать, к примеру, 3 машины на которых крутился C++ный вариант, проще, чем 9 машин, на которых должен будет крутиться Java вариант.
, в котором от самого-то языка практически ничего не требуется, там вся нагрузка ложится на примитивы синхронизации нитей в ОС. И тем не менее, Scala-вариант на ровном месте работает в 3(!) раза медленее, чем D-шный. При том, что Scala работает поверх JVM (в моем случае 1.5), в оптимизатор которой Sun вбухала офигенные ресурсы, а D использует отимизатор, разрабатываемый одним человеком. Т.е. при одинаковой сложности и сравнимом объеме исходного кода D за просто так оказывается быстрее и намного быстрее. Не хочется сбрасывать такое преимущество со счетов. Скажем сейчас мне нужно написать обработку исходящих/входящих транзакций согласно некоторым сложным, задаваемым оператором правилам. При этом требуется, чтобы обработка показывала скорость порядка 1000 транзакций в секунду и затраты на эту обработку составляли порядка 10%-15% от всего времени обслуживания транзакции. Поскольку здесь вообще будет работать только сам язык, без использования I/O или средств ОС, то не хочется просто так отказываться от преимуществ в скорости, которые дает D или C++.
CS>Гораздо более реальным является автоматический порт C -> D. Тем более что на C кода для домена D приложений CS>больше в разы написано. Но это нафиг никому не надо ибо C и так c D нативно общается.
Согласен.
Вот конвертер из C++ в D... Так это раз, и весь ACE есть в D, со всеми его реакторами, проакторами и прочими вкусностями А то пока Tango-писатели до этого доберуться?
CS>На D нужно писать именно думая на D и четко понимая его идею, только тогда толк будет.
Здесь, имхо, не так все просто. D, как и C++, мультипарадигменный язык. Поэтому в нем могут быть воплощены самые разные идеи. Начиная от обычного процедурного подхода, и заканчвая обобщенным программированием а-ля Boost.
И это хорошо.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
VD>>Это пешерное програмирование для людей не ценящих свое время и не желающих получать удовольствие от самого процесса программирования. А я, знаете ли, люблю получать от программирования удовольствие.
AVK>Сдается мне, что процесс получения удовольствия слабо зависит от рода проблем, которые приходится решать. Кому то интереснее одно, кому то другое.
Одному интересно рыать канавы лопатой, а другому бурить десяти километровые скважены. Если кто-то видит что-то интересное в первом занятии, то спору нет, лопата для него отличный инструмент. И конечно, при таких условиях, апгрэйд лопаты на более легкую для него является приемуществом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>C++ реально не позволяет писать на безопасном подмножестве.
Вопросы к ПК и Страуструпу. Они говорят, что позволяет. И я им верю.
FR>На D уже смогли в автоматическом режиме транслировать нетривиальную java библиотеку.
Вот если бы было наоборот, то я ничего не сказал бы. А так. Код на более высокоуровневом язые всегда можно транслировать в код на менее высокоуровневом. Вот обртаное не врено.
FR>Для меня изучить язык это значит научится реально на нем работать. А то что ты понимаешь под изучением это так ознакомится.
Тогда у нас тобой разное понимание понятия изучить мязык. Я не вкладываю в это понятие еще и понятие "стать гуру в области программирования на этом языке".
VD>>Но без них можно жить. Просто вместо одной простой и понятной строки будет куча кода (например цикл для поиска элемента в списке).
FR>Все равно будут сложности даже в базовых вещах.
Сложност? Это как сказать. На данном языке будет сложнее создать сложное приложение. Но это верно для разработчика любого уровня. На С++ в принцие сложнее создать сложне приложение. Но начать писать на С++ пожалуй даже проще чем на Ди. По крайней мере есть куча хороших книг и примеров кода.
VD>>Другими словами простота синтаксиса С++ превращаетя в сложноть паттернов. Ну, и в купе с полнешей небезопастностью языка это выливается в горы геморроя.
FR>Нет простота синтакиса совершено не причем. Скорее тут виновата непродуманость и противоречивость "модели языка", во многом из-за тотальной совместимости с си.
И это тоже. Но и простота тоже делает свой, немалый, вклад.
FR>Полностью геморой ни один язык не устраняет, даже твой любимый сейчас язычок
Понимаеш ли в чем дело. Под гемороем я понимаю ситуации когда я делаю, то что мог бы не далеть. Сегодняшний мой язык позволяет мне не делать всего того дебилизма что я вынужден делать на С++ и повзоляет мне автоматизировать мою деятельность в болшинстве мест где это требуется. Понятно, что объем работ это не устраняет. Но тем не менее у меня есть инструмент позоляющий решать проблемы и делющий это очень хорошо.
Конечно я не отказался бы если бы все стало проще, удобнее и быстрее. Но, к сожалени, пока что такого интрумента нет. Зато есть возможность улучшать имещийся инструмент (в отличии от С++ и даже Ди Немерле открыт для изменений, любой может повлиять на него).
FR>D практически содержит подмножество, в которое входит почти вся java
Это чушь. В Ди ЖЦ не основной инструмент управления памятью. Ди не только предоставляет возможность ползоваться голыми указателями, но и никак не уберегает от их использования.
К тому же ты прекрасно понимашь, что когда я говорю об более удобных языках я ни в коем случае не имею в виду Яву. Речь идет в худшем случае о C# 3.0. Ну, в в лучшем сам знаешь о чем (для остальных: Немерле и Скала). По сравнению с ними ди — это убогий мостадонт.
FR> и большая часть шарпа.
Что такое часть шарпа?
FR> Просто сейчас смотрю GUI библиотеки для D и что вижу: DWT полный клон явовской SWT, dfl который сделан по мотивам WinForms из NET.
Ну, что же подождем когда Ди доростет до WPF .
Кстати, для WinForms существует два нехилых визуальных дизайнера. Можно глянуть на их аналоги (пойдет даже альфа-версия)?
Что-то мне кажется, что на таком языке их будет очень не просто реализовать. Рефлексии ведь вроде нет и в помине?
FR>Да да конечно, только надо еще немного злобной функциональности добавить
В Ди-то? Что-то убого выходит. Хотя лучше чем в С++.
FR>Вот я недавно ковырял Рефал, получил много удовольствия, очень интересный и очень мощный язык (не смотря на то что он наверно самый примитивный из всех функциональных, даже лисп со схемой отдыхают), но программировать на нем реально вряд ли когда буду, так что удовольствие и работу вполне можно и разделять.
Разделяй. Только тогда зачем тебе Ди? Геморрой в лучшем виде создается на С++.
FR>Ну а D вполне позволяет и с удовольствием программировать, и уже близок к рабочему языку.
Ага. Если не видеть нормальных современных языков, то и на Ди можно программировать с удовольствием. Вот только после них на Ди смотреть противно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
FR>> Просто сейчас смотрю GUI библиотеки для D и что вижу: DWT полный клон явовской SWT, dfl который сделан по мотивам WinForms из NET.
VD>Ну, что же подождем когда Ди доростет до WPF .
VD>Кстати, для WinForms существует два нехилых визуальных дизайнера. Можно глянуть на их аналоги (пойдет даже альфа-версия)?
VD>Что-то мне кажется, что на таком языке их будет очень не просто реализовать. Рефлексии ведь вроде нет и в помине?
Здравствуйте, AndreiF, Вы писали:
E>>Нехилый визуальный дизайнер был у Qt для C++, хотя в C++ не было и нет рефликсии вообще.
AF>Нет, есть. В Qt для этого используют специальный компилятор — moc (Meta-object compiler). AF>Так что не надо сказки рассказывать.
moc-компилятор QtDesigner-ом не используется. QtDesigner хранит все необходимые описания в XML-файле проекта (с расширением .ui). Ui-файлы преобразуются в .hpp/.cpp файлы, которые уже затем передаются на вход moc-компилятору с помощью специальной утилиты uic.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>C++ реально не позволяет писать на безопасном подмножестве.
VD>Вопросы к ПК и Страуструпу. Они говорят, что позволяет. И я им верю.
Могу перефразировать, чтобы писать безопасно на C++ нужно быть очень опытным С++ программистом
FR>>На D уже смогли в автоматическом режиме транслировать нетривиальную java библиотеку.
VD>Вот если бы было наоборот, то я ничего не сказал бы. А так. Код на более высокоуровневом язые всегда можно транслировать в код на менее высокоуровневом. Вот обртаное не врено.
Не надо, код на любом тьюринг полном языке всегда можно транслировать на другой т — полный. Вот только на пратике это обычно только вручную получается, и мало зависит от уровней языков. (Даже нормальный си <-> паскаль трансляторов и то не видать)
FR>>Для меня изучить язык это значит научится реально на нем работать. А то что ты понимаешь под изучением это так ознакомится.
VD>Тогда у нас тобой разное понимание понятия изучить мязык. Я не вкладываю в это понятие еще и понятие "стать гуру в области программирования на этом языке".
"Стать гуру" и "научится работать" далеко не одно и тоже.
FR>>Все равно будут сложности даже в базовых вещах.
VD>Сложност? Это как сказать. На данном языке будет сложнее создать сложное приложение. Но это верно для разработчика любого уровня. На С++ в принцие сложнее создать сложне приложение. Но начать писать на С++ пожалуй даже проще чем на Ди. По крайней мере есть куча хороших книг и примеров кода.
Начать писать что на D что на C++ что на шарпе или java примерно одинаково сложно по моему. Вот дальше с C++ пойдут сложности, которых почти не будет в остальных.
FR>>Полностью геморой ни один язык не устраняет, даже твой любимый сейчас язычок
VD>Понимаеш ли в чем дело. Под гемороем я понимаю ситуации когда я делаю, то что мог бы не далеть. Сегодняшний мой язык позволяет мне не делать всего того дебилизма что я вынужден делать на С++ и повзоляет мне автоматизировать мою деятельность в болшинстве мест где это требуется. Понятно, что объем работ это не устраняет. Но тем не менее у меня есть инструмент позоляющий решать проблемы и делющий это очень хорошо.
У меня тоже и что?
VD>Конечно я не отказался бы если бы все стало проще, удобнее и быстрее. Но, к сожалени, пока что такого интрумента нет. Зато есть возможность улучшать имещийся инструмент (в отличии от С++ и даже Ди Немерле открыт для изменений, любой может повлиять на него).
А оно надо?
Если и надо то очень редко.
К тому же и N не позволяет улучшать инструмент неограничено. Попробуй например ввести туда объектную сиcтему из CLOS.
FR>>D практически содержит подмножество, в которое входит почти вся java
VD>Это чушь. В Ди ЖЦ не основной инструмент управления памятью.
При чем тут язык?
(При портировании конечно надо это учитывать)
VD>Ди не только предоставляет возможность ползоваться голыми указателями, но и никак не уберегает от их использования.
Как это мешает портировнию из явы?
VD>К тому же ты прекрасно понимашь, что когда я говорю об более удобных языках я ни в коем случае не имею в виду Яву. Речь идет в худшем случае о C# 3.0. Ну, в в лучшем сам знаешь о чем (для остальных: Немерле и Скала). По сравнению с ними ди — это убогий мостадонт.
По сравнению с третим шарпом, D вполне на уровне.
N и S из другой песочницы.
FR>> и большая часть шарпа.
VD>Что такое часть шарпа?
Посмотри на dfl не удивлюсь если нектоые примеры и на шарпе скомпилируются.
FR>> Просто сейчас смотрю GUI библиотеки для D и что вижу: DWT полный клон явовской SWT, dfl который сделан по мотивам WinForms из NET.
VD>Ну, что же подождем когда Ди доростет до WPF .
Фигня, язык все это позволяет реализовать.
VD>Кстати, для WinForms существует два нехилых визуальных дизайнера. Можно глянуть на их аналоги (пойдет даже альфа-версия)?
Порд рукой нет но в dfl во многих примерах комментарии что код сформирован альфой редактора форм.
VD>Что-то мне кажется, что на таком языке их будет очень не просто реализовать. Рефлексии ведь вроде нет и в помине?
Ну конечно куча редакторов форм на дельфи, бейсике, C++, и даже на си, подтверждают эту твою мысль
FR>>Да да конечно, только надо еще немного злобной функциональности добавить
VD>В Ди-то? Что-то убого выходит. Хотя лучше чем в С++.
В твою речь
FR>>Вот я недавно ковырял Рефал, получил много удовольствия, очень интересный и очень мощный язык (не смотря на то что он наверно самый примитивный из всех функциональных, даже лисп со схемой отдыхают), но программировать на нем реально вряд ли когда буду, так что удовольствие и работу вполне можно и разделять.
VD>Разделяй. Только тогда зачем тебе Ди? Геморрой в лучшем виде создается на С++.
Геморой он языконезависим
FR>>Ну а D вполне позволяет и с удовольствием программировать, и уже близок к рабочему языку.
VD>Ага. Если не видеть нормальных современных языков, то и на Ди можно программировать с удовольствием. Вот только после них на Ди смотреть противно.
Кому как, я не только шоколадом питаюсь но и кортошкой тоже не брезгую.
А вообще не смотри никто ни заставляет.
Здравствуйте, eao197, Вы писали:
E>moc-компилятор QtDesigner-ом не используется. QtDesigner хранит все необходимые описания в XML-файле проекта (с расширением .ui). Ui-файлы преобразуются в .hpp/.cpp файлы, которые уже затем передаются на вход moc-компилятору с помощью специальной утилиты uic.
Без разницы, что и в каком порядке создается. Главная цель редактора гуи — это возможность в конечном итоге получить рабочее приложение. Без moc рабочего приложения не будет — а редакторы, которые создают исключительно в эстетических целях, на этом форуме не рассматриваются.
Так что рефлексия в C++/Qt не только есть, но и очень активно используется.
Здравствуйте, AndreiF, Вы писали:
E>>moc-компилятор QtDesigner-ом не используется. QtDesigner хранит все необходимые описания в XML-файле проекта (с расширением .ui). Ui-файлы преобразуются в .hpp/.cpp файлы, которые уже затем передаются на вход moc-компилятору с помощью специальной утилиты uic.
AF>Без разницы, что и в каком порядке создается. Главная цель редактора гуи — это возможность в конечном итоге получить рабочее приложение. Без moc рабочего приложения не будет — а редакторы, которые создают исключительно в эстетических целях, на этом форуме не рассматриваются.
Если вам доводилось программировать на Qt, то вы должны знать, что moc-компилятор там используется безотносительно к GUI. Кроме того, поскольку QtDesigner не использует moc-компилятор, а именно moc-компилятор, по вашим словам добавляет в C++ Qt-шную рефлексию, то и QtDesigner не использует Qt-ную рефлексию.
AF>Так что рефлексия в C++/Qt не только есть, но и очень активно используется.
Пожалуйста, укажите на раздел стандарта C++, хоть от 98-го, хоть от 2003-го года, где фиксируется понятие рефлексии в C++.
Qt-шная рефлексия такая же стандартная для C++, как и моя ObjESSty-сериализация.
Генерируемый moc-компилятором код вообще с очень большой натяжкой можно назвать поддержкой рефлексии, поскольку все, что в нем есть -- это:
* className,
* qt_cast и
* qt_property, который, к тому же изымается при помощи QT_NO_PROPERTIES.
А где поиск описателя класса по имени? Где инстанцирование объекта по имени класса? Где список методов и атрибутов объекта (или вам хватает пропертей)? Где вызов метода по имени?
Вообще-то продолжайте, мне приятно видеть, как такой любитель минусов путается в двух соснах и выдает желаемое за действительное.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Если вам доводилось программировать на Qt, то вы должны знать, что moc-компилятор там используется безотносительно к GUI. Кроме того, поскольку QtDesigner не использует moc-компилятор, а именно moc-компилятор, по вашим словам добавляет в C++ Qt-шную рефлексию, то и QtDesigner не использует Qt-ную рефлексию.
Изначально речь шла про "рефлексии не было и нет", тему ты очень ловко перевел. Ладно, будем считать, что со своей ошибкой ты согласился. Теперь далее. Не использует moc... а результаты работы moc он тоже ни в каком виде не использует?
E>Qt-шная рефлексия такая же стандартная для C++, как и моя ObjESSty-сериализация.
Я и не говорю, что она стандартная. Но она есть.
Твоя самооценка крайне неадекватна. Qt используют многие тысячи программистов во всем мире, а твою библиотеку — хорошо, если десяток.
E>Генерируемый moc-компилятором код вообще с очень большой натяжкой можно назвать поддержкой рефлексии
Система конечно очень ограниченная, до полноценнной ей далеко. Но это всё равно система работы с метаданными, как ни крути.
Но сам факт примечателен. Если, как говорит разработчик TioPort, конвертация происходила по большей части автоматически, то это открывает возможность портирования на D из Java и других библиотек. Что должно поспособствовать наполнению D хорошими и разными инструментами/библиотеками/фреймворками.
А то пока Tango-писатели до этого доберуться? 
