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

N>Dynamic class loading и в Java и в D есть через либы
N>JDK (Custom ClassLoader) и DDL соответственно. Почему у Java — yes, а у D — no?
N>Насчет остальных языков — ничего не могу сказать.

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

N>Default parameter value есть в D и C++

С++ перепутан с С. По Ди опять же информация бралась с их таблицы (если речь о первой таблице).

N>Console interpreter. теоретически, программу на D можно запустить как dmd -run main.d но это не совсем то.
N>А для C/C++ — Ch

Мне мало верится, что С++ можно полноценно интерпретировать. Текстуальные макросы и инклюды все таки.

N>Typesafe variant — как уже было упомянуто, std.boxer

Ага. Ошибок много.

N>tuple data type — есть в D, но только compile-time

Не понял.

N>spliced strings... резать строки в D можно вроде: writef("Hello, world!"[0 .. 5]);
N>или даже writef("Hello, world!"[0 .. $ — ", world!".length]);
N>и не только строки.
N>Или spliced strings — это какой-то новый тип string literal?

Речь не о том. Работу со строками в PHP, Руби или Немерле видел? Вот это о том.

N>Lazy evaluation: В D есть, но не по умолчанию.
N>void log(lazy char[] msg)
N>{
N> if (logging)
N> fwritefln(logfile, msg);
N>}

Видимо он появился после того как была скопирована таблица. Вообще, она устарела и не полноценна.

N>void foo(int i)
N>{
N> log("Entering foo() with i set to " ~ toString(i));
N>}

N>Analyze AST и Modify AST для D планируется.

Ой, если описывать планы, то можно очень далеко зайти.

N>IDE support и Refactoring — у descent скоро появится семантический анализатор со всеми вытекающими последствиями, такими как рефакторинг, подсветка ошибок на лету, в том числе в шаблонах и CTFE... www.dsource.org/projects/descent

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

Так что когда убдет, тогда и запишем.

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

VE>По-моему, единственный способ оценить инструмент — как он соответствует тому, для чего создавался, или где используется (если вдруг используется не там и не так, для чего создавался).
VE>Остальное — пенисометрия.

Дык и это тоже будет пенисометрия.

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

N>>IDE support и Refactoring — у descent скоро появится семантический анализатор со всеми вытекающими последствиями, такими как рефакторинг, подсветка ошибок на лету, в том числе в шаблонах и CTFE... www.dsource.org/projects/descent

VD>1. Скоро появистя — это не серьзно.
VD>2. От момента когда появится компонент помогающий собирать метаданные, до момента когда будет реализованы хотя бы основные фичи того же рефакторинга может пройти очень много времени. В том же Немерле для анализа кода испоьзуется просто код компилятора, и тем не менее многих фич среда не поддерижвает.

VD>Так что когда убдет, тогда и запишем.

Для D есть не только descent
Есть еще Entice Designer:

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

E>>А можно пример RAII в Nemerle? Или ты в качестве RAII конструкцию using рассматриваешь?

VD>using (x = SomeResource())
VD>{
VD>    используем ресурс.
VD>} // здесь, что бы не произошло, ресурс освободится.

VD>Причем, можно и С++-аналог сделать, в общем-то. Только потребности нет. Люди решают в первую очередь те задачи которые вызвают проблемы.

Извините что встреваю в разговор годичной давности. Но раз уж кто-то naryl и поднял эту ветку.

Тут знаете в чём особенность. В С++ не просто Resource Acquision Is Initialization, но ещё и ... Is Definition.
Фактически, объявление каждой локальной переменной открывает новый блок видимости (немножко урезанный в правах, естественно)

{Foo x;
 .....
 {Bar y;
  .....
  // урезан в том плане, что нельзя написать
  Buz x; // error: redefinition
  .....
}}

То есть, обычно мы основательно экономим на скобках.
Точно так же, как в ML-языках конструкция let-in

let x = foo in
 let y = bar in
  (* можно *)
  let x = buz in
   .....
   ;;

let
 x = foo
 y = bar
 x = buz
in
 .....
;;

То есть, своего рода синтаксический сахар. Поэтому RAII в С++ удобно использовать — хотя и с риском разнообразных граблей.
Но это вообще в духе С/С++ — были бы они русскими, назывались бы Ш__ и Ш____ соответственно (детские грабли и недетские грабли).

А в других языках — извольте попрыгать-поплясать. Скобки и табуляцию расставить, как минимум.

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

VD>Дык и это тоже будет пенисометрия.

Ну это да
Но по крайней мере она может оказаться полезной и более объективной.
А то так можно привести таблицу сравнения какого-нибудь профессионального фотоаппарата и карманной мыльницы. Будет 100 пунктов, в каждом из которых профессиональный будет "рвать" мыльницу, и только 2 пункта за мыльницу — размер и цена
Т.е. если и проводить сравнение, то сначала между группами (типа про-фотики лучше кач-вом, а мыльницы — размерами), а потом сравнения внутри группы.
Хотя от пенисометрии не деться, конечно

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

VE>Уточню. Сравнение инструментов между собой может помочь в выборе инструмента, но тогда надо указывать, для чего он создавался/использовался, а уже ЯПы в этих группах сравнивать по "фичам".
VE>А то так можно и LUA с Haskell'ем сравнивать.

Я не скажу за LUA, но то что люди используют для решения совершенно однотипных задач и Haskell, Java, и даже С++ с Nemerle — это факт. Треп о том, что для каждого дела нужен свой инструмент звучит обычно чтобы оправдать свою лень (нежелание изучать другие инструменты (языки)). На практике язык выбирается тот, что известен и очень часто это язык наименее подходящий для решения стоящей перед программистом проблемы. Классический пример — описание бизнес-логики на С++. (Тот же Дворкин занимался этим регулярно.) Какой тут критерий выбора С++? Да самый банальный. Человек просто не хорошо знает С++ и или вообще не знаком с другими языками, или знаком с ними посредственно, или знаком только с еще менее мощьными зыками. Причем в защиту С++ будут приводиться просто фиеричные аргументы... фиеричные для тех кто хорошо знает кроме С++ еще и другие языки.

Конечно есть критерии типа: Мене не приемлем .NET потому что я пишу высокопроизводительные программы под IBM AIX дремучей версии и для нее банально нет даже Mono или Mono не обеспечивает приемлемой производительлности. Или: Я ищу .NET-язык (тип подставить по вкусу). Но как раз так ставят вопрос еденицы. В большинстве случаев выбор определяется банальными домыслами.

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

E>Для D есть не только descent
E>Есть еще Entice Designer:...

Как я понял из описания полноценного комплита там нет (Simplified code completion for dfl, std and tango), т.е. комлейшон только для стандартных библиотек. О рефакторинге инавигации по коду, хинтах, а темболее о рефакторинге речь вообще не идет. Сюдя по всему не хватает качественного движка парсинга, о чем и говорил naryl.

Так что... когда сделают, "будем погядеть".

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

VE>А то так можно привести таблицу сравнения какого-нибудь профессионального фотоаппарата и карманной мыльницы. Будет 100 пунктов, в каждом из которых профессиональный будет "рвать" мыльницу, и только 2 пункта за мыльницу — размер и цена

1. Ну, дык так оно и есть. Еще, правда, простота использования, что очень важно для не профи.
2. С ценой не факт. Nikon 40D стоит около 15 000 руб., что сопоставимо с мыльницами.
3. Порвут они далеко не все. Многие мыльницы очень даже могут посоревноваться.
4. Многие "про" типа того же Sony A проиграют даже мыльницам.

Так что если не профи решит выборать фотоаппорат, то такое сравнение ему будет очень интересно.

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

VE>Т.е. если и проводить сравнение, то сначала между группами (типа про-фотики лучше кач-вом, а мыльницы — размерами), а потом сравнения внутри группы.

В общем, согласен. Но только если у фотоаппоратов есть четкие разграничения:
* Мыльница / Зеркалка со сменной оптикой.
* Полупроффесиональная зеркалка / проффесиональная зеркалка.
* Корманная мыльница / рюкзачная мыльнца .
и т.п.

То вот ЯП так не деляся. Почти на всех можно решать большую часть задач. Отличие будет:
1. Нэйтив / управляемый (платформный).
2. Динамический / статически типизированный.
3. По поддерживаемым парадигмам.
и т.п.

VE>Хотя от пенисометрии не деться, конечно

Дык это она и есть.

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

VD>Я не скажу за LUA, но то что люди используют для решения совершенно однотипных задач и Haskell, Java, и даже С++ с Nemerle — это факт. Треп о том, что для каждого дела нужен свой инструмент звучит обычно чтобы оправдать свою лень (нежелание изучать другие инструменты (языки)). На практике язык выбирается тот, что известен и очень часто это язык наименее подходящий для решения стоящей перед программистом проблемы. Классический пример — описание бизнес-логики на С++. (Тот же Дворкин занимался этим регулярно.) Какой тут критерий выбора С++? Да самый банальный. Человек просто не хорошо знает С++ и или вообще не знаком с другими языками, или знаком с ними посредственно, или знаком только с еще менее мощьными зыками. Причем в защиту С++ будут приводиться просто фиеричные аргументы... фиеричные для тех кто хорошо знает кроме С++ еще и другие языки.

К сожалению, одним из очень сильных "плюсов инструмента" (в кавычках — ибо на самом деле не его это плюс) является умение им пользоваться. И так очень много где
Поэтому обычно, чтобы заставить человека учить другие ЯПы (если он сам вдруг не интересуется), его еще надо убедить, что на другом он получит преимущество.
А вот конкретно в плюсы инструмента можно порог вхождения написать. Я хотел тут Curry глянуть, но то ли не туда смотрел, но простого а-ля WinHUGS интерпретатора не нашел.

naryl wrote:
> C>Минус стоит правильно — в D сейчас возможно использовать только
> C>консервативный GC, сама семантика языка (юнионы, например) не позволяет
> C>использовать точный GC.
> Почему это консервативный GC = плохой GC?
По определению. Для него недоступно огромное количество оптимизаций.

> На самом деле, семантика разрабатывалась с учетом возможности написания
> максимально точных сборщиков мусора при поддержке всех типов C.
> Копирующий/уплотняющий сборщик мусора для D написать можно.
Нельзя. Некоторые вещи (типа union'ов) не позволяют точно сказать,
является ли число 0x23410921 в поле структуры указателем или просто
таким странным int'ом.

> Есть добровольцы? =)
Я как-то думал заняться (года три назад), но сейчас точно займусь
чем-либо более интересным.

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

VE>К сожалению, одним из очень сильных "плюсов инструмента" (в кавычках — ибо на самом деле не его это плюс) является умение им пользоваться. И так очень много где

+1

VE>Поэтому обычно, чтобы заставить человека учить другие ЯПы (если он сам вдруг не интересуется), его еще надо убедить, что на другом он получит преимущество.

А вот это бесполезно. Знаешь что такое Блаб?

VE>А вот конкретно в плюсы инструмента можно порог вхождения написать. Я хотел тут Curry глянуть, но то ли не туда смотрел, но простого а-ля WinHUGS интерпретатора не нашел.

От части согласен. Проблема в том, что кроме это только один из останавливающих фактовро. И не самый значимый. Я знаю многих людей которые могли бы освоить много чего, но замкнулись на произведениях Страуструпа, МС или Сана.