[D-lang] Итоги и небольшой обзор о состоянии языка

> но вот идеальность какого-нибудь D это просто-напросто признак невежественности.

а это только практикой познаётся. Взять какой-либо С++ проект, переписать на D, или начать новый. Или поставить Гайку, начать портировать софт. И сразу понятно будет — можно этим уже пользоваться, хотя и сыро, или обождать пока, или не связываться в принципе.

Проекты у всех разные, серебряной пули нету, идеальность платонова сосёт по сравнению с аристотелевым материализмом  — поэтому только так, trial & error.

> D просто неинтересен. У него не будет ярких фанатов

Я с тобой не согласен. Для фанатов (профи, пишуших just for fun) важным свойством языка является отсутствие ограничений (которые нужны Enterprize языкам, для того чтобы среднего уровня программист выдавал код приемлимого качества). В Python ограничением являются отступы (любой программер будет использовать какой-то стиль отступов, но P это навязывает), в Java обязательное использование GC и отсутствие множественного наследования.

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

В D, например, есть возможность в одном выполняемом файле использовать разные стратегии выделения памяти, причем как с использованием GC, так и без него. http://www.digitalmars.com/d/2.0/memory.html Ты много знаешь таких языков?

Потому я считаю, что для фанатов этот язык очень удобен. Хотя у него есть недоработки, обусловленные небольшим комьюнити, что ТС и пытается исправить.

P.S. Приятно, что ТС сменил точку зрения с «полумертвый» и «в анабиозе» но новую :-)

P.P.S. С развитием самого языка и сообщества D может стать языком не только для фанатов. И тут у него есть существенные преимущества перед C#.

>Есть живая ОС, написанная на CL (ядро + системные библиотеки)? Нет?

Есть, и не одна.

http://lispm.dyndns.org/

http://www.bitsavers.org/bits/TI/Explorer/zeta-c/ — Компилятор ZetaС : компилятор С на Лисп, для лисп-машин. Обрати внимание, как сделан интерфейс сисколлов, malloc через лисповую сборку мусора и вообще системный API лисп-машин.

Ну, ещё есть losak, movitz и т.п.

> и текстового препроцессора (просто не нужно)
Давайте только без догм. Если бы я Вам поверил, я бы эту тему закрыл и забыл про этот D. На самом деле, то, что утверждают про «ненужность» макросов в С++ и Java - это просто брехня. Доказательство - массированное использование макросов во всех виденных мной библиотеках на С++ (хотя видел я их не много). В Qt даже написали свой, специальный препроцессор! На сайте D вопрос о макропроцессоре рассматривается очень подробно и на множество вариантов сишных макр даются РАЗНЫЕ способы реализации подобного функционала в D. В некоторых случаях ответ меня не удовлетворил, например, вот это:

[quote]
# Assert function file and line number information:
The C Preprocessor Way

#define assert(e)   ((e) || _assert(__LINE__, __FILE__))

The D Way
assert() is a built-in expression primitive. Giving the compiler such knowledge of assert() also enables the optimizer to know about things like the _assert() function never returns.
[/quote]

Кроме того, я слёту могу привести макрос, которым я пользовался и которому я не вижу аналога в D.

#define TRY { some_code; {
#define FINALLY some_code; } some_other_code;

Возможно, это делается с помощью миксинов. Кстати, настоящим макропроцессором в D являются миксины, так что не нужно говорить, что там нет макросов.

Но вообще, я бы не сказал, что это - системный язык. Я не представляю, как на нём можно было бы написать Cakewalk, Guitar Processor by O'Razoff или Gigasampler. По-моему, со сборкой мусора это просто никак нельзя сделать.

> По-моему, со сборкой мусора это просто никак нельзя сделать.

Она не опциональная/её нельзя не использовать?

> Она не опциональная/её нельзя не использовать?

Можно. Я успешно писал jack-клиент. Ничего не выпадало. В process() сборщик мусора отключать даже не нужно. Достаточно не выделять память. Выделение памяти в любом случае не имеет верхнего предела на время выполнения, поэтому этого нельзя делать и без сборщика мусора.

> Я один не понимаю какое будущее ждет язык у которого нет стандарта,

Плюсы начали писать в 69-м, стандарт появился в 98-м. Для сей ситуация схожая. В плане стандартизованности в D действительно есть трудности - 2-я версия в стадии альфа.

нет поддержки платформ окромя x86

Это фатальная дыра в архитектуре языка или следствие малости сообщества и отсутсвия коммерческой поддержки? Насколько сложно будет довести GDC до рабочего состояния, если им будет заниматься не один, а аж два человека? В .NET уже появилась поддержка чего-либо кроме винды?

нет стандартизированной встроенной библиотеки (как оказывается их несколько и все разные)

Их две :-) и обе стандартные. Это нормальная ситуация, если нет одной, которая заметно лучше или дяди типа балмера, который скажет своим разработчикам, какая правильная. Фобосом занимается Александреску, Танго - сообщество. Если одна станет существенно лучше другой, проекты объединятся.

Наличие GTK и QT одновременно пока не привело к полному краху графики в линуксах.

Зачем он нужен ну кроме как «на поиграться».

Крутым ентерпрайзным спецам с ЧСВ более 9000 не нужен ни для чего. Остальные пишут свои проекты, создают биндинги к библиотекам, портируют dmd фронтэнд для gcc (GDC).

Не бред ли выставлять ЭТО как самый перспективный язык?

Не бред ли пыжиться, доказывая, что D не нужен вместо того, чтобы почитать документацию, примеры, посмотреть, чем он тебе может быть полезен. Может лучше задавать вопросы на фомумах, обмениваться инфомацией и сделать самостоятельный вывод о полезности технологии, вместо того, чтобы прокачивать ЧСВ и понтоваться.

P.S. У D есть куча как недоработок так и очень сильных сторон. Вопрос лишь в том, можно ли его уже сейчас использовать для своих проектов и что нужно сделать, что бы стало можно :-) А также нужно ли это конкретно тебе.

> Ядро ОС на языке X означает буквально, что этот язык применим для написания низкоуровневых вещей.

и что, если ядро на одном языке, то нельзя писать низкоуровневые штуки на другом? Можно, но нужен интерфейс между языком ядра и этим другим. То есть: прозрачный интерфейс с С ABI, если ядро на Си, или наоборот, языка Х с другими ABI. Либо, язык Х должен прозрачно транслироваться в тот же С.

#define TRY { some_code; {
#define FINALLY some_code; } some_other_code;

Вот такие штуки к счастью и на миксинах не сделаешь. Мне почему-то сразу вспомнилось

#define BEGIN {
#define END }

Но можно сделать так:

void myTry(void delegate() exp) {
    some_code;
    {
        exp();
        some_code;
    }
    some_other_code;
}

...
int a;
myTry( {a = a + some_func(); } );

Вообще, если вы так используете препроцессор, возможно вам стоит присмотреться к CL, Scheme или TCL.

>По-моему, со сборкой мусора это просто никак нельзя сделать.

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

http://www.digitalmars.com/d/2.0/memory.html

Кстати, а чем не устраивает assert?

> В process() сборщик мусора отключать даже не нужно. Достаточно не выделять память.
Для этого нужно, чтобы и библиотека не выделяла память. Или чтобы можно было переопределить аллокатор глобально, включая библиотеку, на freeList-ы или хотя бы на assert(0). Я обычно пишу на лиспе, который таких возможностей не даёт и ничего на тему выделения памяти не обещает. Например, сортировка, скорее всего, будет выделять память. Значит, нужно писать свою сортировку с выделением на стеке? В общем, пока что я ещё не вполне понял, как это можно.
В Cakewalk вряд ли получится не выделять память. Там во время воспроизведения и записи можно делать всё, что угодно, например, открывать новые окна. Вопрос - так ли это нужно? Я не могу сказать однозначно. Но это возможно.

> Вообще, если вы так используете препроцессор, возможно вам стоит присмотреться к CL, Scheme или TCL
Ну так я на CL обычно и пишу, если у меня есть выбор.
Вариант myTry, на первый взгляд выглядит невинно устраивает. Кстати, блок { someCode } может быть параметром mixin-а? Если да, то это уже почти CL (я уже понял, что gensym в них как бы есть).

Кстати, а чем не устраивает assert?

Тем, что макросы - это станок, а assert - это изделие.

Что мешает использовать обычный cpp вместе с D? Ему в общем то пофигу что процессить. Хоть XML.

Можно переопределять оператор new для классов. Учитывая отсутствие множественного наследования, можно сделать наследник Object, получающий память из free-list'ов и наследовать все объекты от него.

Но в моём случае всё решилось проще. Аудио и Видео подсистемы работают в разных процессах, общаясь через пайп. Как бы ни тормозило и сколько бы памяти не выделяло видео, jack-клиент работает без тормозов. Изначально это было фичёй, потом я уже понял, что при реализации в одном процессе могли бы быть проблемы из-за выделения памяти.

> Что мешает использовать обычный cpp вместе с D?
cpp - это вообще говно (более мягкое слово не подходит). Может быть, m4. Однако, лучше иметь один хороший механизм, чем несколько плохих.
Накладные расходы на подключение внешнего препроцессора достаточно велики, я пробовал уже.

> Можно переопределять оператор new для классов. Учитывая отсутствие множественного наследования, можно сделать наследник Object, получающий память из free-list'ов и наследовать все объекты от него.

А библиотеки?

ммм, я не знаток C, но у меня такое чувство, что в C можно переопределить выделение памяти глобально? Или я ошибаюсь? Вот что сказал поисковик:

http://mdf-i.blogspot.com/2008/12/blog-post.html

Не сказать, что я всё здесь понял, но, видимо, проблема имеет общее решение.

Кстати, блок { someCode } может быть параметром mixin-а?

Да. Есть только одно правило. Код, вставляемый mixin должен быть полным правилом парсера.

mixin("{") - нельзя

int i = mixin(getA); - можно, если getA это
auto getA = "42";
или
string getA() {
    return "4" ~ to!string(1+1);
}
и т.д.

Накладные расходы на подключение внешнего препроцессора достаточно велики, я пробовал уже.

Ну это скорее особенность конкретной реализации нежели языка. Запуская gcc мы в конечном итоге запускаем цепочку исполняемых, которые последовательно обрабатывают выход друг-друга. Что мешает нарисовать врапер для D, который бы позволял делать что-то схожее? Плюс внешний API для подключения собственных обработчиков по вкусу. Не нравится cpp - пусть будет m4 или кто-то ещё, не проблема. Собственно к языку как таковому пре/пост процессоры имеют косвенное отношение. Они могу быть а могут и не быть.

Всё равно при выделении памяти может закончиться free-list. Или могут быть тормоза при отрисовке (мало ли?) Лучше rt часть выделить в отдельный процесс.

> Аудио и Видео подсистемы работают в разных процессах, общаясь через пайп. Как бы ни тормозило и сколько бы памяти не выделяло видео, jack-клиент работает без тормозов
Ну, я так и думал, что без этого в итоге не обойдётся... Ну что, наверное, это нормально. Я правда, не знаю, насколько пайп тормозит работу и всегда ли это годится.

>> нет поддержки платформ окромя x86

Это фатальная дыра в архитектуре языка или следствие малости сообщества и отсутсвия коммерческой поддержки?

Это проблема конкретного тулчейна DMD, проблема решаемая, но в случае с dmd возможно, слишком сложно. Проще взять LDC или GDC и получить вагон оптимизаций llvm или gcc/graphite «из коробки», а DMD оставить Волтеру Брайту, как «референсный» компилятор

Насколько сложно будет довести GDC до рабочего состояния, если им будет заниматься не один, а аж два человека?

Какая-то работа в bitbucket goshawk ведётся, переводят на gcc 4.3.4. Может, через полгода и до gcc 4.4/4.5 доберутся. Или свежий dmd портируют.

В .NET уже появилась поддержка чего-либо кроме винды?

Этот компилятор вообще highly experimental. Пока, емнип, нет — с моной надо пытаться, пробовать.

Изначально это было сделано ради самого разделения и упрощения отладки. Проверить работоспособность аудио можно было просто смотря на его вывод.

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

Запуская gcc мы в конечном итоге запускаем цепочку исполняемых, которые последовательно обрабатывают выход друг-друга

С макросами проблема - это навигация по исходникам. Мой опыт убедил меня, что это должно быть решено на уровне IDE разработки и интегрировано в язык, хотя бы как это сделано в CL (хотя и там не идеально). В случае подключения внешнего препроцессора к C, усложняется makefile, увеличивается количество файлов. Могут восстать коллеги (у меня случился именно последний случай, после чего я был вынужден отказаться от m4 в проекте на С++, где шаблоны как раз не помогали, и писать всё на cpp). Ну ладно, что-то мне кажется, что вопрос адекватной замены макропроцессора в D действительно решён.

Однако я бы всё же предпочёл, чтобы в язык было включено что-нибудь вроде этого:

http://www.linux.org.ru/view-message.jsp?msgid=4358796

> Вообще, если вы так используете препроцессор, возможно вам стоит присмотреться к CL, Scheme или TCL.

К Go надо присмотреться, ога

http://research.swtch.com/2009/12/gofmt.html

И поверх этого — AST макросы в духе Dylan http://portal.acm.org/citation.cfm?id=504311.504285

Мне реализация GC показалась довольно примитивной, когда я на неё смотрел года 3 назад. Т.е. это тупейший «стопаем все потоки, бегаем по стеку, ищем всё, что похоже на указатели, строим дерево, удаляем всё что не в дереве».

Да. Leandro Lucarella занимается его апгрейдом в рамках дипломного проекта. :)

что ближе всего в юниксе к д ?
жаба ?

Пожалуй, нет такого. Скорее C++.

>И поверх этого — AST макросы в духе Dylan http://portal.acm.org/citation.cfm?id=504311.504285

а не желаете поделиться доступом на acm.org? =)

> К Go надо присмотреться, ога

Что в нём хорошего, кроме форсящего его гугла?

>а это только практикой познаётся. Взять какой-либо С++ проект, переписать на D, или начать новый.

дык вроде недавно какую-то игру (или что-то вроде того) как раз наоборот с D на плюсы перевели...

Качества D как языка, там никак не сказались. В той игре, если мне не изменяет память, были модули на D. А так же было некое сообщество писателей плагинов (или что то вроде этого). Большинство этих писателей восприняли переход на новый язык отрицательно. В общем там консерватизм победил.

Что в нём хорошего, кроме форсящего его гугла?

Форсящий его гугл? Все остальное - вторично.

>> Что в нём хорошего, кроме форсящего его гугла?

Форсящий его гугл? Все остальное - вторично.

И куда гугл его зафорсил?

Use Google, Luke! Речь о OpenMW, свободном Morrowind. Гляньте последнюю новость.

http://openmw.sourceforge.net/jaws/

И куда гугл его зафорсил?

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

>> И куда гугл его зафорсил?

Пока - никуда. Все лишь в зачатке. Куда он его зафорсит в будущем - время покажет.

Большой вопрос, зафорсит ли Гугл этот Go хоть куда-нибудь. Пока что он занимается допиливанием существующих языков под свои нужды (Dalvik, Unladen). А все эти Go и Noop - развлечения сотрудников.

Большой вопрос, зафорсит ли Гугл этот Go хоть куда-нибудь. Пока что он занимается допиливанием существующих языков под свои нужды (Dalvik, Unladen). А все эти Go и Noop - развлечения сотрудников.

Ну, знаешь, все когда то было тем или иным 'развлечением сотрудников'. Вопрос лишь в настойчивости да чуток удачи не помешает. Ни первого ни второго гуглу не занимать.

>> Пока что он занимается допиливанием существующих языков под свои нужды (Dalvik, Unladen). А все эти Go и Noop - развлечения сотрудников.

Ну, знаешь, все когда то было тем или иным 'развлечением сотрудников'.

Но не всё, что было «развлечением сотрудников», стало мэйнстримом.

Вопрос лишь в настойчивости да чуток удачи не помешает. Ни первого ни второго гуглу не занимать.

Никаких признаков форсинга Go я не вижу. Гуглу пофиг на Go.

Никаких признаков форсинга Go я не вижу. Гуглу пофиг на Go.

Толь 2 толь 3 года назад я спрашивал у их Дублинского AFAIR CTO - планируют ли ребята выпустить собственную OS? Все-таки мир-жвачка-линукс все такое. Народ лишь нехотя отнекивался. И что мы имеем сейчас? Андроида. И это, очевидно, не предел. Так что то, что 'вроде как не форсируют' ещё ничего не значит..

> я спрашивал у их Дублинского AFAIR CTO - планируют ли ребята выпустить собственную OS? Все-таки мир-жвачка-линукс все такое. Народ лишь нехотя отнекивался. И что мы имеем сейчас? Андроида.

И Хромос. И оба проекта - допиленный Линукс (Хромос - вообще убунта цельнотянутая).

И Хромос. И оба проекта - допиленный Линукс (Хромос - вообще убунта цельнотянутая).

Ну что, в общем, совершенно не удивительно, что именно Linux. Выбора фактически не было. Да и нет. Но язык - это не OS. Разработать, реализовать и, что главное, поддерживать свой собственный язык - это задача существенно бОлее простая, нежели свою GPOS. Тем более, если де-факто он ограничен той или иной средой применения и не претендует на звание Глобального Языка На Все Случаи Жизни Во Всех Мыслимых И Немыслимых Местах. Даже если, теоретически, он и мог бы на него претендовать.

>> И Хромос. И оба проекта - допиленный Линукс (Хромос - вообще убунта цельнотянутая).

Ну что, в общем, совершенно не удивительно, что именно Linux. Выбора фактически не было. Да и нет. Но язык - это не OS

Так зачем ты помянул ОС? :)

Разработать, реализовать и, что главное, поддерживать свой собственный язык - это задача существенно бОлее простая, нежели свою GPOS.

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

Тем более, если де-факто он ограничен той или иной средой применения

Ага, ага. Название JOVIAL тебе о чем-то говорит? Без гугля.

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

Я никогда не занимался разработкой под Max* -> лишь слышал, что есть некой Object C. Ну вот не встречался он мне на пути. Однакоб у меня есть подозрение, что на своей платформе и в своей среде именно он - мейнстрим. А не C или C++. Я угадал?

Ага, ага. Название JOVIAL тебе о чем-то говорит? Без гугля.

Ровным счетом ничего.

спасибо. чтд:

Very few people know D, lots of people know C++
Nobody has a D compiler, and setting one up is difficult on most platforms except for 32 bit Linux
Maintaining a mixed D/C++ code base is too much work, mostly because the compiler and tools don't work well together in this scenario (especially on Windows.)
I feel that if the D compiler and tools had been more mature and user-friendly, the benefits of the D language would have made the other problems worth it. But a lot of people have asked for this conversion now, and most seem to be happy about the decision (and so am I), so I think it's the right choice.

В общем, я всё понял. На данный момент языка моей мечты всё ещё не обнаружилось. Языка со следующими свойствами:

- простой дизайн, основанный на качественной и взаимно-ортогональной реализации простых понятий. Тут, конечно, лучше всего смотрится пока что Common Lisp.
- простой язык. Что-нибудь типа оберона, хотя настолько просто не получится, придётся несколько сложнее
- макросы как в лиспе
- статическая типизация, но с типом «полиморфный вариант»
- компилятор и интерпретатор в одном флаконе
- динамическая архитектура. Возможность менять функции и типы в уже запущенной программе. Такую я видел в лиспе (defun,defclass) и в SQL (alter table, alter procedure).
- компиляция во время исполнения программы в нативный код (но не JIT). Работа получаемого кода примерно со скоростью C, когда включена оптимизация по скорости.
- возможность работы как со сборщиком мусора, так и с явным выделением памяти при сохранении безопасности перекрёстных ссылок за счёт каких-то «сторожей».
- оптимизации за счёт деклараций const и других деклараций, ограничивающих ссылки между памятью, выделенной разными способами и в многопоточной среде. При этом просто отключаются ненужные «сторожа».
- локальные функции (замыкания) и локальные типы (то, что на самом деле составляет славу ФП, а вовсе не «чистота», как многие думают).
- возможность работы с памятью на уровне С.
- сериализация данных в текст и обратное чтение из текста, подобно тому, как это делает в лиспе функции print/read для списков, массивов и структур.

А вообще, уже в глазах малость пестрит от количества новых языков. Жаль, никто не может сделать то, что я хочу. Если бы это сделали, это был бы точно «хит сезона». Лисп может почти всё из перечисленного, но не всё. И его синтаксис ужасен, конечно. Наверное, самое простое было бы допилить какую-нибудь реализацию CL до этого уровня, хотя создание backend-ов - это очень далеко от области моих познаний.

+1

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

PS: капча какбе намекает -> // scheme deep

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

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

это да. Можно половину выкинуть/сократить, и оставить минимальное ядро.