Смущают две вещи. Нет Reflection, и проблемы с отладкой под разные платформы.
Вот советы из переписки типа под Win пользуйтесь windbg, под linux — gdb, сводят на нет идею создания платформо-независимой IDE.
Но больше отсутствие рефлексии тормозит. ИМХО, несмотря на все достоинства языка, этот минус очень жирный минус.
И еще проблема в том, что нету четкой грамматики языка. Из переписки понял, что грамматику последнюю выдергивают из доков.
Т.е. язык еще до сих находится в экспериментальной стадии.

К чему написал, хотел заняться раработкой плагина для NetBeans (что-то типа дембельского аккорда). А вот такие нюансы сдерживают. Цель не академическая, а практическая.

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

_>Смущают две вещи. Нет Reflection, и проблемы с отладкой под разные платформы.
_>Вот советы из переписки типа под Win пользуйтесь windbg, под linux — gdb, сводят на нет идею создания платформо-независимой IDE.

Как-то не вижу связи.
Ну и ничего ни мешает делать отладку например только для gdc будет везде gdb.
Посмотри Visual D там проблемы отладки решены, в том числе и для gdc и для dmd.

_>Но больше отсутствие рефлексии тормозит. ИМХО, несмотря на все достоинства языка, этот минус очень жирный минус.

Если тебе нужна рефлексия для IDE то посмотри на ключик компилятора -X (generate JSON file) тот же Visual D как раз эту информацию использует.

_>И еще проблема в том, что нету четкой грамматики языка. Из переписки понял, что грамматику последнюю выдергивают из доков.
_>Т.е. язык еще до сих находится в экспериментальной стадии.

Тут да проблема.

_>К чему написал, хотел заняться раработкой плагина для NetBeans (что-то типа дембельского аккорда). А вот такие нюансы сдерживают. Цель не академическая, а практическая.

Сейчас есть уже несколько плагинов к IDE, самый лучший это Visual D, но он не кроссплатформенный конечно.
По возможностям очень неплох Mono-D, но нестабильная версия MonoDevelop все портит.
Очень неплох DDT (eclipse plugin), но у него нет отладчика.
Хотя еще одна IDE конечно же не помешает

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

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

FR>Как-то не вижу связи.
FR>Ну и ничего ни мешает делать отладку например только для gdc будет везде gdb.
FR>Посмотри Visual D там проблемы отладки решены, в том числе и для gdc и для dmd.

Там с Visual D идет какая-то магическая утилита CV2PDB, которая извлекает отладочные символы из исполняемого файла в формат PDB. Исходников ее я не нашел. Хотя NetBeans заточен под GDB. Нужно покопать, как отладка у него под Win работает.

FR>Если тебе нужна рефлексия для IDE то посмотри на ключик компилятора -X (generate JSON file) тот же Visual D как раз эту информацию использует.

Для компилятора/design-time хорошо конечно. Почему не сделать в рантайм? Ведь тогда можно будет делать и сериализацию и все на свете.

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

FR>Ну и ничего ни мешает делать отладку например только для gdc будет везде gdb.
FR>Посмотри Visual D там проблемы отладки решены, в том числе и для gdc и для dmd.

А все, нашел

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

_>Смущают две вещи. Нет Reflection

Там довольно мощная compile-time рефлексия.
Вот такой код

module main;
import std.stdio, std.traits;

struct FileInfo {
    string name;
    ulong mtime, ctime;
}

void printRecord(R)(R r) 
{
    foreach(fld; __traits(allMembers, R))
        writeln(fld, ": ", __traits(getMember, r, fld));
}

int main(string[] argv)
{
    auto fi = FileInfo("a.txt", 10, 20);
    printRecord(fi);
    return 0;
}

выводит
name: a.txt
mtime: 10
ctime: 20

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

На счет сериализации, ( а может и отладки) вопрос открытым остается.

По сабжу:
при текущем наборе фич, без их урезания или серьезного редизайна, сделать хороший GC вряд ли возможно. А текущий довольно медленный. В моем тесте на одной задачке при практически одинаковой реализации окамл получился вдвое быстрее. Без активной нагрузки на GC, с помощью более низкоуровневого кода, удалось разогнать на порядок. Зато что порадовало — очень просто параллелится, окамлу такое не снилось.

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

_>На счет сериализации, ( а может и отладки) вопрос открытым остается.

А в чем сложность с сериализацией? В пределах языка передавать туда-сюда сериализованные объекты должно быть несложно, универсальный сериализатор на макросах и компайл-таймовых штуках пишется наверняка несложно и скорее всего уже написан и выложен, надо только поискать. А для IDE где нужна сериализация?

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

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

_>>На счет сериализации, ( а может и отладки) вопрос открытым остается.

DM>А в чем сложность с сериализацией? В пределах языка передавать туда-сюда сериализованные объекты должно быть несложно, универсальный сериализатор на макросах и компайл-таймовых штуках пишется наверняка несложно и скорее всего уже написан и выложен, надо только поискать. А для IDE где нужна сериализация?

Поймите меня тоже правильно. Я только осваиваю мир D. Я пришел в него из мира C#. Он мне очень понравился, поэтому буду дальше его осваивать. Ну а на счет макросов, разве D не отказывается от макросов? Мне лично понравилась GC, понравились встроенные юниттесты и еще много чего

Зато у меня есть впереди свободных полгода. Я не гуру, и не строю из себя такого.
Но мне кажется, в любую проблему можно вникнуть лишь со временем. Буду рад, если если окажите мне поддержку своими знаниями и опытом!

Я и сам пока новичок, только книжку прочитал да чуть-чуть поигрался. Понятно, что каких-то вещей, доступных в других языках, в D может не оказаться, но вряд ли именно сериализация окажется такой необходимой и отсутствующей вещью. С учетом доступной рефлексии она делается без особых сложностей, насколько я представляю. И еще я просто плохо представляю, насколько она нужна в IDE. Что касается макросов, пока от них никто не отказывается, наоборот в презентациях гордо показывают: смотрите как мы здорово на них делаем bitfields, например.

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

Будет будущее или нет к сожалению определяется не только чисто техническими нюансами, но и различными организационными/финансовыми/историческими. Если говорить исключительно о технических, то D, как язык, — это пожалуй лучшее что есть в своё классе и должен был бы давно занять нишу C++ и ему подобных. Но в реальности всё по другому, поэтому вопрос из заголовка остаётся открытым...

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

DM>Что касается макросов, пока от них никто не отказывается, наоборот в презентациях гордо показывают: смотрите как мы здорово на них делаем bitfields, например.

Текстовые миксины все-таки не макросы си хотя во многом и близкая родня.

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

DM>По сабжу:
DM>при текущем наборе фич, без их урезания или серьезного редизайна, сделать хороший GC вряд ли возможно. А текущий довольно медленный. В моем тесте на одной задачке при практически одинаковой реализации окамл получился вдвое быстрее. Без активной нагрузки на GC, с помощью более низкоуровневого кода, удалось разогнать на порядок. Зато что порадовало — очень просто параллелится, окамлу такое не снилось.

Интересно. Подозреваю, что если сравнить его с тем же C# (ну, минус время на Джит), ситуация будет аналогичной.
Вот только о чем это все-таки говорит? Реально ли невозможно написать для Ди такой же эффективный ЖЦ или все же это недоработки текущей реализации?

> Будет будущее или нет к сожалению определяется не только чисто техническими нюансами, но и различными организационными/финансовыми/историческими. Если говорить исключительно о технических, то D, как язык, — это пожалуй лучшее что есть в своё классе и должен был бы давно занять нишу C++ и ему подобных. Но в реальности всё по другому, поэтому вопрос из заголовка остаётся открытым...

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

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

ВВ>Интересно. Подозреваю, что если сравнить его с тем же C# (ну, минус время на Джит), ситуация будет аналогичной.
ВВ>Вот только о чем это все-таки говорит? Реально ли невозможно написать для Ди такой же эффективный ЖЦ или все же это недоработки текущей реализации?

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

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

G>Основная задача языка, это документирование, а для этих целей D-язык не был приспособлен.

Что ты имеешь в виду под "документированием"?
Если выразительность, то D язык примерно уровня C#.

G>Большинство же технических решений могут быть реализованы или доступны в других языках.

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

G>D-язык это всего-лишь одна поделка из ряда других, бесцельный перфекционизм.

Так можно практически про любой язык сказать, кроме узкоспециализированных.

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

FR>Мне кажется реально, но непросто, придется и язык местами рихтовать.
FR>Хотя по сравнению с C++ намного легче, есть явное разделение на POD типы (структуры D) и классы,
FR>все типы перемещаемые. Но проблемы с указателями в структурах тоже возможны.

Честно говоря, мне начинает казаться, что подход C++\CLI к данному вопросу не самый плохой. Делается просто два хипа — обычный и управляемый. Для создания объектов в управляемом хипе — особый синтаксис. Ну и на такие объекты можно накладывать дополнительные ограничения. И в итоге в плюсах получился быстрый ЖЦ.

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

ВВ>Вот только о чем это все-таки говорит? Реально ли невозможно написать для Ди такой же эффективный ЖЦ или все же это недоработки текущей реализации?

D сейчас уже поделен на safe и unsafe части, и в последней есть ряд фич, которые не дают сделать GC, двигающий объекты в памяти, а без этого не получится сделать нормальный generational GC. Соответственно, сейчас GC объекты не двигает совсем, поколений нет, и сканирование/сборка занимают порядочное время.

Мне представляется, что чтобы иметь быстрый GC, нужно или совсем отказаться от "системности" (управления представлением объектов в памяти, низкоуровневой работой с ней, указателей куда ни попадя), или четко на уровне системы типов отделить управляемую кучу от неуправляемой, и ограничить свободу операций с объектами управляемой кучи.

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

DM>Мне представляется, что чтобы иметь быстрый GC, нужно или совсем отказаться от "системности" (управления представлением объектов в памяти, низкоуровневой работой с ней, указателей куда ни попадя), или четко на уровне системы типов отделить управляемую кучу от неуправляемой, и ограничить свободу операций с объектами управляемой кучи.

+1
Собственно, если разделение на safe/unsafe уже есть, дело осталось за малым. Но, видимо, тут потребуется и какой-то отдельный синтаксис для аллокации объектов в управляемой куче, наподобие того, что было в CLI. Или атрибуты какие для объявления, но это хуже.
Вообще насколько уже язык сформирован? Мне реальный статус Ди, честно говоря, не очень понятен.

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


ВВ>Честно говоря, мне начинает казаться, что подход C++\CLI к данному вопросу не самый плохой. Делается просто два хипа — обычный и управляемый. Для создания объектов в управляемом хипе — особый синтаксис. Ну и на такие объекты можно накладывать дополнительные ограничения. И в итоге в плюсах получился быстрый ЖЦ.

В D и так уже объекты уже очень сильно отличаются от структур, они только ссылочные и перемещаемые если не использовать
члены указатели. Так что особый синтаксис и не нужен, достаточно ужесточить (не так и сильно) требования к объектам.