[D] Чё-каво?

> Ну, не, я про то, что "помощь дедушки" еще тоже никто не отменял, и C-подмножество языка вполне пригодно для реализации debug output-а, если вдруг boost-а нет

ключевое слово "typesafe" и ф-и с переменным количеством аргументов в стиле C здесь совершенно не помощник.

// wbr

> при грамотном проектировании это не нужно

Мне этот аргумент несколько наскучил, пока вы не возьмёте на себя труд раскрыть его чуть подробнее, дискутировать с вами не интересно.

> Костыль :) printf проще.

лёгким движением руки boost::format превращается в printf-line версию? никаких проблем. потоки или printf-line - это уже скорее дело вкуса.

> Возьмём абстрактного программиста в вакууме. Он не умеет читать boost.

это лишь означает, что его уровень подготовки к разработке на C++ находится где-то между 2 и 3 баллами по 5ти бальной шкале. только и всего.

> В D он может использовать writef так же, как использовал printf в C, не особо задумываясь о том, как на самом деле оно работает. В C++ ему придётся хорошо представлять, что как работает (иначе он от первой же простыни ошибок сойдёт с ума). Например почему он не может писать format("%d") % 2 + 3; Пример утрирован, но, надеюсь, он мою мысль доносит.

> И вообще для меня оператор % это остаток от деления, использовать его для других вещей, как минимум, некрасиво. Я видел, как оператором ~= добавляли child-окна. Это было жутко :)

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

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

// wbr

> лёгким движением руки boost::format превращается в printf-line версию? никаких проблем. потоки или printf-line - это уже скорее дело вкуса.

printf-like естественно.

// wbr

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

Так используйте только POD-ы для вывода, и не-typesafe-ность не будет так критична, если это отключаемый debug output.

Гм. Ну вот ещё пример.

List get(SchemeExpression[] items ...) {
    List rv = new EmptyList();
    foreach_reverse(e; items) {
        rv = new NonemptyList(e, rv);
    }
    return rv;
}

Вызывается как List.get(e1, e2, e3, e4) например. Цикл foreach_reverse раскрывается во время компиляции, 
для функции с четырьмя аргументами получается 

List rv = new EmptyList();
rv = new NonemtpyList(e1, rv);
rv = new NonemtpyList(e2, rv);
rv = new NonemtpyList(e3, rv);
rv = new NonemtpyList(e4, rv);
return rv;

Как это сделать в C++ я сейчас плохо представляю. Можно наверное, перегрузив, например, запятую. Но выглядеть это будет страшновато.

Это не пример универсальной typesafe функции. Нужно это, и вправду, совсем нечасто, в основном во всяком библиотечном коде.
Но когда это нужно, и оно есть под рукой, это сильно помогает.

>раскрыть его чуть подробнее

Пожалуйста: имеется язык, имеются требуемый инструментарий, в рамках данного языка лучше (лучше - не значит проще, а значит легче в сопровождении, менее провоцирующем на ошибки, реюзабильнее) всего реализующейся определенными конструкциями и построениями. Если инструментарий кажется вам неудобным и/или сложным, вполне вероятно, что вы не верно выбрали язык для задачи. Заметьте, не как вам удобнее, а как правильнее с точки зрения языка.

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

А вы вот со своей стороны приведите, зачем вам нужны функции с переменным кол-вом аргументов? Сигнал-слоты не в счет, там все можно и простов в std::list<IVariant*> запихать

> Нужно это, и вправду, совсем нечасто

Значит можно и обойтись и совсем без.

> Так используйте только POD-ы для вывода, и не-typesafe-ность не будет так критична, если это отключаемый debug output.

a) а я не хочу использовать только PODы. я хочу один раз объявить оператор вывода объекта в ostream [причём любого объекта] и в последствии пользоваться только им. в "обычной" версии printf() это по понятным причинам не проходит.
b) short v; printf("%lu", v) -> жопа. линт & K конечно иногда помогают, но это всё равно костыль.

// wbr

> зачем вам нужны функции с переменным кол-вом аргументов?

Сугубо для улучшения читабельности. Очевидно, что всё можно запихать в список. Можно даже круче сделать (примерный фрагмент из реального индусокода):

Map params = new Map();
params.put("arg1", 1);
params.put("arg2", 2);
f(params);

void f(Map params) {
    for (int i = 0;; ++i) {
        Object o = params["arg" + i];
        ...
    }
}

Тоже "typesafe функция с переменным количеством аргументов". Но f(1, 2) читается и поддерживается таки проще.

>А вы вот со своей стороны приведите, зачем вам нужны функции с переменным кол-вом аргументов?

Естественно, ничего не нужно. Достаточно ассемблера. Если бы в стандарт не входили стандартные библиотеки, C++ был бы не так уродлив.

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

> вторая версия D будет биндится к С++

http://www.digitalmars.com/d/2.0/faq.html#cpp_interface И тем не менее, интерфейс к C++ обещан был.

> Большой минус — нет хорошей, semantic-aware IDE для D

http://www.youtube.com/asterite - можно посмотреть снапшот Descent в действии.

> Ида дело десятое - пользую vim.

+1 :) описание синтаксиса для .d уже давно входит в стандартный комплект vim. Только не забудь в .vimrc сказать, что .di нужо красить так же, как и .d.

Ну и пара ссылок на последок:

http://dsource.org/projects/dsss - автоматическая билдилка и инсталилка софта с _автоматическим_ определением зависимостей. Осилить в обязательном порядке в кратчайшие сроки.

И вообще http://dsource.org - хостилка для свободных проектов.

>> Запихать все аргументы в tuple, как делается в Ъ языках?

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

Loki::Tuple. Удачи.

>Большой минус — нет хорошей, semantic-aware IDE для D.

её и для C++ толком нет.

> Если Emacs с подсветкой в качестве IDE устроит, прекрасно

в качестве IDE можно попробовать Code::Blocks ( при установке сам определяет, что D установлен, и куда, прописывает пути в настройках для компилятора D (если задан в PATH)), плагин Descent для Eclipse.

Пытаются писать какие-то другие IDE, http://dblog.aldacron.net/category/ide-related-news/, см. по ссылке с http://dsource.org/projects/ , в том числе, и на самом D. Там должно быть просто с семантикой (в списке рассылки был парсер D на самом D, 1600 строк (Dparser): http://www.dsource.org/projects/scrapple/browser/trunk/dparser/dparse.d , см. также http://www.prowiki.org/wiki4d/wiki.cgi?GrammarParsers http://64.233.183.104/search?q=cache:_mbBJS5NbDIJ:www.digitalmars.com/d/archives/digitalmars/D/Parser_47866.html+parser&hl=... )

Отладчики начинают появляться, см. http://www.dsource.org/projects/descent/wiki/DebuggingPrograms -- но конечно, ждём релиза ZeroBugs

Ещё у D интересная фича, compile-time функции. В итоге, например вот в этой работе встроили схему в D http://v04bvs.livejournal.com/3641.html интересным образом: "лисповые макры" из Схемы прозрачно переносятся на compile-time функции в D.

То есть, можно написать "типа макры", которые полностью отработают во время компиляции (как тот же Dparser/Scrapple)

> То есть, можно написать "типа макры", которые полностью отработают во время компиляции (как тот же Dparser/Scrapple)

Может вам стоит уже пересесть на Lisp или Scheme, а не зацикливатся на убогих диалектах (D) ?

биндинги к dotNet, если вдруг понадобятся: http://channel9.msdn.com/forums/TechOff/22246-DNET-The-D-Programming-Language...

мда, ссылки битые.. DDotNet : http://www.wikiservice.org/wiki4d/wiki.cgi?DDotNet

> биндинги к dotNet, если вдруг понадобятся: http://channel9.msdn.com/forums/TechOff/22246-DNET-The-D-Programming-Language.. .

А когда в v-студию включат D ? :)

> А когда в v-студию включат D ? :)

ну вот как появится #D так и включат

// wbr

> Я видел, как оператором ~= добавляли child-окна. Это было жутко :)

кстати, в какой-то GUI библиотеке на D так сигнал-слоты делали. Коллбеками-делегатами.

а полностью пересесть не получается. Самое интересное происходит на стыке двух языков. Просто в D ту же схему, кажется, проще встраивать чем в С++.

Вот есть например Qt, в котором много всего понапихано, но мне в конкретном приложении нужен GUI, XML, QtScript. И хочется туда встроить какой-то минималистичный лисп (например, PicoLisp). Он на С довольно просто встраивается, получается нужно на Qt просто написать обёртки extern "C" {..}.

Но что дальше получается -- сам по себе Qt и C++ мне не очень-то нужен, только для GUI (от QtScript я как раз хочу избавиться). А само приложение к тому же под qt3, порт под qt4 пишется довольно вяло. А когда появится порт под qt4, выйдет qt5 на 150Мб исходников в архиве, при том что мне из них как раз немного функционала надо. То есть, при раскладе Qt/C++ проект всегда будет в позиции догоняющего.

А того, что надо, нужно помодульнее, и поудобнее для встраивания. При таком раскладе, если Qt только для GUI, проще отвязаться от Qt, и взять более простой и модульный GUI на D, и остальные модули перетащить из того же С или D.

мда, ссылки битые, и это кажется неспроста.. нафига MS конкурент C# в лице D.NET ?

> Ещё у D интересная фича, compile-time функции. В итоге, например вот в этой работе встроили схему в D http://v04bvs.livejournal.com/3641.html интересным образом: "лисповые макры" из Схемы прозрачно переносятся на compile-time функции в D.

На всякий случай предупрежу, что по ссылке очень глубокий Proof of Concept, к реальности не пригодный. Надеюсь, через полгодика осилю нормальный вариант.

PS чисто ради интереса, как вы нашли эту ссылку? Ссылка была сугубо для себя :)

> как тот же Dparser/Scrapple

Посмотри в словарике значение слова Scrapple ;) Это не название проекта.

> чисто ради интереса, как вы нашли эту ссылку? Ссылка была сугубо для себя :)

Зопалилсо? 8)

> Зопалилсо? 8)

Да не :) Там просто реально было написано, лишь бы сдать курсовую. Рассчитывал довести до ума и выложить в паблик на четвёртом курсе, в итоге времени не хватило, но родилась куча новых идей, вроде реализации компилятора полностью в compile-time и возможности писать D-шные compile-time функции на схеме. Через полгодика будет видно, реально это или нет.

>На всякий случай предупрежу, что по ссылке очень глубокий Proof of Concept

мне понравилось, концептуальненько так:) как раз встраиваю PicoLisp в Qt приложение на C++, получается не так красиво, как в D :)) делаю для прототипа, PicoLisp интерпретируемый, потом наверно попробую встроить нормальный ECL и тут становится непонятно что делать с лисповыми макрами на C++ :)) там получается чёткое разделение runtime/compile-time. А у вас красиво прозрачно всё получилось, парсер простой, хотя и пример простой совсем :)

>PS чисто ради интереса, как вы нашли эту ссылку? Ссылка была сугубо для себя :)

ваш ник засветился на sql.ru в топике про С++ и Луговского, погуглил вокруг -- о, да тут же залежи мяса !!! :-))

Успехов!

там где-то писалось что это подпроект такой у Dparser. А вообще в списке рассылки какой-то парсер на шаблонах был, около 1000 строк, это оно или что-то другое?

> мне понравилось, концептуальненько так

На самом деле концептуально это то же самое, что www.intelib.org, можете посмотреть, оно как раз для C++, там интерпретатор лиспа на С++ написан, и, вроде, неплохо вылизан.

> ваш ник засветился на sql.ru в топике про С++ и Луговского

Действительно палюсь :) Понятно.

> Успехов!

Спасибо.

это я, на всякий случай.

Ну пля, хочешь пощупать и понять, так щупай и понимай.

Кстати, интересная идея про суперкомпилятор. Преобразовывать один входной язык в другой.
Понятно, что забивать гвозди микроскопом не надо, и что один язык лучше подходит для одной
задачи, другой -- для другой. Хочется поточнее определить границы применимости разных подходов
(в пределах одного приложения), оценить производительность. И чтобы стыковалось это максимально
прозрачно, с минимумом cruft и максимальным сохранением семантики моделей в разных подходах.
Или несколько моделей разных, под свой аспект, в рамках единой метамодели, та же SOA с реестром
сервисов и моделей.

--как возможное применение:

Вот есть например, убогие клоны 1С-Бухгалтерии, невозбранно унылые (я про опенсорс говорю).
Или интерпретатор/компилятор языка предметной области есть, оболочка есть, движка с транзакциями нет,
функционала нет. Или вообще ничего толком нет, голая оболочка торчит.
Или язык свой совсем, вот в Ананасе например на QtScript завязан (причём старый QSA).
Перепланируют они объектную модель Ананаса, эти скрипты-"прикладные решения" можно будет выкинуть
(или "портировать скрипты").

Причем движок сам по себе на "старом" qt3, на "новый" qt4 его самого надо портировать.
Порт делается ни шатко, ни валко, а где-то в декабре, между прочим, будет EOL QSA.
И накроется этот Ананас медным тазом -- будет ситуация как с дровами под ядро 2.4,
которые не собираются под ядро 2.6 (например, тот же rlocate).

И даже если бы перспективы того же Ананаса были радужны, -- они в качестве языка предметной области
выбрали свой велосипед, слишком завязаный на реализацию "платформы". Если бы входной язык взяли тот же,
что и в прототипе 1С (как например, в проекте 2C gpl) -- по идее готовые конфигурации 1С сразу должны были
бы заработать (ну примерно как игрушки под wine'ом, с отладочными STUB'ами вроде "not implemented" :P)

Вообще в том же Ананасе/1С'е -- есть 2-3 языка внутри, платформа-движок на C++,
реализация "сервера приложений", убогий императивный нерасширяемый скриптовый
мини-DSL, декларативный SQL с транзакциями и запросами от "сервера приложений" к БД.

Зоопарк целый, при этом на стыке языков явно возникает дыра в семантике.

Хотя вот например в примерах к PCL "изобретали" свой SQL на лиспе, а в PicoLisp -- свою ООП систему,
сервер приложений, ORM и "базу знаний".

Где-то на границах этих языков что-то невозбранно теряется: нету чётко выраженных транзакций,
поэтому "движок" тупо делает giant lock'и БД. Если бы DSL мог более чётко указать зависимости
по данным, а хитрый компилятор/интерпретатор "скриптового DSL" не просто тупо исполнять скрипт
в терминах объектной модели платформы-движка, а учитывать хинты, -- можно было бы более точно
группировать транзакции. Можно было бы сделать язык более расширяемым, причём с единой,
унифицированной моделью данных и функциями, как сервисами в SOA, транзакциями.
Можно было бы иметь единую модель на всё, из которой автоматом генерировать несколько аспектов
в разных местах на разных языках: C++/D для оболочки и монитора транзакций, какой-нибудь лисп/пролог
для декларативного описания транзакций, готовый входной язык на каком-нибудь императивном быдлоскрипте
для генерации того самого лиспа/пролога и описания транзакций (например, замыкания/продолжения для
описания транзакций). Получается, не нужен отдельный интерпретатор, отдельный свой язык -- входной язык
берём готовый и последовательно расширяем нужной для облегчения работы монитора транзакций семантикой.
Которая достраивается по ситуации в нужном месте системы для сохранения целостности семантики общей
исходной метамодели задачи :))

Это правда, тоже ковыряется потихоньку в свободное время, в основном на уровне идеи и прототипов :))
кажется, что без Qt и С++ получится сильно проще :))

Кстати, если ты разбираешься в предмете...

Можно ли макросами D сделать синатксис, аналогичный match в Nemerle:

match (v) {
| Sometype(42, _) => expr
| vv isa Someclass => another_expr
}

Писал я как-то на этом вашем D. Простейший сетевой сервер, селект и все дела. Так эта сволочь просто в режиме ожидания жрала неизвестно на что 5% CPU. Отключаю gc — перестаёт жрать. Я от удивления даже разбираться не стал, в чём там дело, переписал на перле и забыл как страшный сон.

Кстати, уже больше двух месяцев не могут пофиксить порепорченную мной тогда багу в dmd: http://d.puremagic.com/issues/show_bug.cgi?id=1959

> Можно ли макросами D 

В D нет макросов. Возможно будут.

Вся магия в строковом mixin-е. Там можно делать

mixin("int a;"); эквивалентно int a;
здесь вместо строкового литерала можно подставить любое выражение, вычисляющееся в compile-time в строку,
например свою compile-time-executable функцию.

Сделать можно, при большом желании. Но будет неорганично (что то вроде) 
mixin(match("v",
    "Sometype(42, _) => expr",
    "v isa Someclass => expr"));
тяжело (придётся парсить эти строки, а на подмножестве D парсеры писать не очень удобно, хотя можно), медленно,
с нечитаемыми сообщениями об ошибке и т.д. Для таких задач миксины подходят плохо.
Хороший аналог — C++-ные навороченные шаблоны (а-ля boost::spirit) — сделать можно, но лучше не делать.

Нормальные макросы, в моём представлении, должны как то работать с AST программы. Таких нет. С немерлевскими макросами D тягаться не может.

> В D нет макросов. Возможно будут.

Уже обещано :) http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf

> Нормальные макросы, в моём представлении, должны как то работать с AST программы

И они будут работать именно с AST (правда, я не понимаю, как именно).

> Уже обещано :)

Ну будем надеяться. Блин, стектрейс сделали бы. Трудно что ли.. Вся эта высокоуровневость куда то девается, когда в main-е ловишь исключение и фиг его знает откуда оно прилетело. Т.е. представляешь конечно, но приходится printf-ами делать бинарный поиск. Ну ладно, это я так, о своём, наболевшем :)

Teak, ни для кого не секрет, что текущая реализация gc в D ужасно медленная и неэффективная. Есть планы по замене текущей реализации на stop-and-copy GC. И баги фиксятся на основании того, как часто с ними сталкиваются, а не на основании ЧСВ человека их запостившего.

Legioner, при компиляции с ключами -g -debug с библиотекой tango стектрейсы есть. :)

Ну про багу я просто так сказал, в дополнение, она действительно мне жить не помешала. :) А «есть планы по замене» как раз и переводится «пока что использовать не стоит, и неизвестно, будет ли стоить потом».

Вообще-то странно это. Deadlock видел? Entice Designer? Poseidon? Никто из них почему-то не страдает загрузкой проца на 5%. Может проблема в программе?

> А «есть планы по замене» как раз и переводится «пока что использовать не стоит, и неизвестно, будет ли стоить потом».

Есть планы по замене Mesa3D на Gallium3D, поэтому Mesa3D пока использовать не стоит и неизвестно, будет ли стоить использовать Gallium3D.

> Может проблема в программе?

Может быть, конечно, но почему она пропала после gc.disable? Я не спорю, я не эксперт, наверное в другой программе этого бы не было. :)

И почему кстати она у меня памяти жрёт сразу метров 14, а аналог на перле метра полтора? При том, что я хотел как раз попробовать компилируемый язык с нормальной работой со строками и НЕ C++, чтобы типа память и проц сэкономить (ну и чтоб зависимостей не было никаких), ан не вышло.

Короче, у меня осталось ощущение, что писать на нём стоит разве что что-то большое, при этом нужно быть экспертом в этом языке.

ощущения смешанные. написал пару утилит; для сравнения параллельно писал на C++ и сравнивал. вначале сильно мешает другая семантика значений (ближе к Java/C#), но привыкаешь практически сразу; из фич языка больше всего понравились design by contract (насколько я понимаю, один к одному содранный из Eiffel), mixin'ы, и работа с выравниванием в структурах. не понравился - размер рантайма. не понравилось - отсутствие динамической линковки. в общем ощущения "языка низкого уровня" нет, модуло компилируемость по ощущениям ближе к упоминавшимся уже Java/C# - даже несмотря на плюшки с обобщённым и метапрограммированием

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

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

Уолтера постоянно пинают насчет рантайма и динамической линковки, но, видимо, он хочет сначала финализировать сам язык.

ИМХО llvmdc спасёт проект "язык D".