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

Здравствуйте, 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 конечно же не помешает

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

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

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

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

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

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

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

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

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

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

Ну так а C/C++ приспособлены что ли? А при этом они до сих пор (а с учётом намечающихся тенденций сворачивания усилий по .Net скорее всего это ещё очень долго будет так) являются самыми широкоиспользуемыми по индустрии.

Здравствуйте, 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, Вы писали:

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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. Mon, Вы писали:

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

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

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


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

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

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

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

Если ужесточать, как я понимаю (запретить члены-указатели т.е.?), снизятся возможности по написанию ансейф кода.

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

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

ВВ>Если ужесточать, как я понимаю (запретить члены-указатели т.е.?), снизятся возможности по написанию ансейф кода.

Не снизятся, структур даже без наследования (с такой фишкой как alias this) вполне достаточно.

> G>Основная задача языка, это документирование, а для этих целей D-язык не был приспособлен.
>
> Что ты имеешь в виду под "документированием"?
> Если выразительность, то D язык примерно уровня C#.

А я не понимаю смысла в слове "выразительность". Выразительность, это синоним краткости, а краткость не всегда связана со способностью языка к документированию.

Документирование, это написание некоего документа. То есть написание для дальнейшего прочтения и понимания.
Поддержка возможности языка писать код двойного назначения, для трансляции в машинный код и для прочтения и понимания человеком.
В D на возможности языка к документированию сразу же на первой странице ставится большой жирный красный крест.

Вы сколько угодно можете меня не понимать и отрицать, но придет время и вы где-нибудь прочитаете это от "гуру" и сразу поймете и примете


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

С какого такого нужен Си-образный язык? Совсем не обязательно.


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

Не соглашусь. Это конечно только мнение, ну будь D лет 20 назад, он бы еще имел смысл, а сейчас он один из многих и без понимания сути, это просто еще одна чисто _техническая_ реализация.
Суть новизны-то в чем? Что-то-там-где-то-внутри-сделано-немного-по-другому-чуть-чуть -еще-не-доделано-но-мы-работаем-над-этим-лет-через-двадцать-сделаем.

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

ВВ>>Если ужесточать, как я понимаю (запретить члены-указатели т.е.?), снизятся возможности по написанию ансейф кода.
FR>Не снизятся, структур даже без наследования (с такой фишкой как alias this) вполне достаточно.

Странная штука. Это какое-то прототипное ООП получается
Не знаю, в общем. Может, конечно, этого и хватит. Но как бы Ди во второй C# так не превратился.

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

G>А я не понимаю смысла в слове "выразительность". Выразительность, это синоним краткости, а краткость не всегда связана со способностью языка к документированию.
G>Документирование, это написание некоего документа. То есть написание для дальнейшего прочтения и понимания.
G>Поддержка возможности языка писать код двойного назначения, для трансляции в машинный код и для прочтения и понимания человеком.
G>В D на возможности языка к документированию сразу же на первой странице ставится большой жирный красный крест.
G>Вы сколько угодно можете меня не понимать и отрицать, но придет время и вы где-нибудь прочитаете это от "гуру" и сразу поймете и примете

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

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

Си-образный нужен, потому что "паскали, ML образные и т. п. не прижились". Т.е. он не нужен, конечно, но другие языки популярностью не пользуются. Возможно, потому что они не слишком удачные. А, возможно, залогом популярности является си-подобный синтаксис. Глупо, да. Но если посмотреть на популярные языки...

G>Не соглашусь. Это конечно только мнение, ну будь D лет 20 назад, он бы еще имел смысл, а сейчас он один из многих и без понимания сути, это просто еще одна чисто _техническая_ реализация.
G> Суть новизны-то в чем? Что-то-там-где-то-внутри-сделано-немного-по-другому-чуть-чуть -еще-не-доделано-но-мы-работаем-над-этим-лет-через-двадцать-сделаем.

А какой новизны вы ждете? Есть для примера другой, более достойный, чем Ди, язык?

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

G>Документирование, это написание некоего документа. То есть написание для дальнейшего прочтения и понимания.
G>Поддержка возможности языка писать код двойного назначения, для трансляции в машинный код и для прочтения и понимания человеком.
G>В D на возможности языка к документированию сразу же на первой странице ставится большой жирный красный крест.

Почему? Вот C# в этом смысле лучше? Если да, то чем? Если нет, то какой язык лучше?

G>Не соглашусь. Это конечно только мнение, ну будь D лет 20 назад, он бы еще имел смысл, а сейчас он один из многих и без понимания сути, это просто еще одна чисто _техническая_ реализация.
G> Суть новизны-то в чем? Что-то-там-где-то-внутри-сделано-немного-по-другому-чуть-чуть -еще-не-доделано-но-мы-работаем-над-этим-лет-через-двадцать-сделаем.

По-хорошему, он оправдывает свое имя — это просто исправленная и улучшенная версия С++, без революционных решений типа хаскеля, эрланга или К. Что предлагает: нативный код, не требующий больших ВМ, ФП, кое-какой вывод типов, развитые средства компайл-тайм безобразий без плюсовых извращений с шаблонами, GC, нормальный параллелизм и эрланг-стайл акторы — все это довольно вкусный набор. Плюс управление иммутабельностью, контракты/инварианты и пр. Что-то из этого появилось в С++, что-то в С#, но сразу всего набора, кажется, нет нигде.

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

G>А я не понимаю смысла в слове "выразительность". Выразительность, это синоним краткости, а краткость не всегда связана со способностью языка к документированию.

Нет это не синоним краткости.

G>Документирование, это написание некоего документа. То есть написание для дальнейшего прочтения и понимания.
G>Поддержка возможности языка писать код двойного назначения, для трансляции в машинный код и для прочтения и понимания человеком.
G>В D на возможности языка к документированию сразу же на первой странице ставится большой жирный красный крест.

G>Вы сколько угодно можете меня не понимать и отрицать, но придет время и вы где-нибудь прочитаете это от "гуру" и сразу поймете и примете

А можно без загадок прямо сказать?


G>С какого такого нужен Си-образный язык? Совсем не обязательно.

Конечно не нужен, например по моему ML или питоновский во многом лучше.
Но массам требуется си к сожалению.

G>Не соглашусь. Это конечно только мнение, ну будь D лет 20 назад, он бы еще имел смысл, а сейчас он один из многих и без понимания сути, это просто еще одна чисто _техническая_ реализация.
G> Суть новизны-то в чем? Что-то-там-где-то-внутри-сделано-немного-по-другому-чуть-чуть -еще-не-доделано-но-мы-работаем-над-этим-лет-через-двадцать-сделаем.

А зачем новизна, она хороша в исследовательских языках, рабочий язык должен быть умеренно консервативным.
D как раз такой.
Вот мне не хватает такого же практичного грязного энергичного функционального языка, OCaml к сожалению
в плену своей однопоточной реализации, F# хорош, но завязан на NET, варианты ML уже во многом устарели и не
развиваются.

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

ВВ>Странная штука. Это какое-то прототипное ООП получается

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

ВВ>Не знаю, в общем. Может, конечно, этого и хватит. Но как бы Ди во второй C# так не превратился.

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

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

_>Т.е. язык еще до сих находится в экспериментальной стадии.

Мне это больше всего не нравится. Язык постоянно пилят, 1-я версия уже практически deprecated, 2 еще не доделана. А завтра объявят 2-ю версию deprecated и запилят 3-ю. Для студентов хорошо, а в серьезном проекте такое использовать нельзя. Уж на что меня раздражает медлительность комитета по C++, но при этом там хоть какой-то порядок и определенность есть.