Место для D

Original author: Andrei Alexandrescu
  • Translation
На хабре уже публиковался перевод статьи The Case For D за авторством Андрея Александреску. Перевод, к сожалению, был сделан на скорую руку, без посторонней помощи и советов, что не могло не отразиться на его качестве. Позднее был коллективно создан более качественный и, главное, верный перевод, который мы и хотим показать. Старый перевод будет удалён, чтобы не создавать путаницы.

Андрей Александреску — Место для D [ссылка на pdf]
(статья посвящена D — «системному языку высокого уровня», одним из разработчиков которого является сам Александреску)

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

Участники: Volfram, naryl, karbin — перевод; maxter — грамматика и орфография; eldar, digited, Nekuromento, karbin, RISC — технические вопросы. ( Они будут рады ответить на любые вопросы, если им предоставить такую возможность ;) )


D FAQ


Что за путаница с компиляторами и библиотеками, что мне в итоге использовать?

Строго говоря, никакой путаницы нет. Достаточно разобраться в том, что, как и у любого достаточно широко используемого языка, у D есть несколько реализаций.
Сейчас существует две ветви языка:
  • D1.0 — стабильная ветка языка, развитие функционала которого искусственно заморожено и он подвергается только исправлению ошибок
  • D2.0 — развивающаяся в данный момент ветка языка, куда периодически вносятся изменения функционала и новые возможности. Эта ветвь жертвует некоторой обратной совместимостью с D1.0 ради большей выразительности. Планируется, что добавление новых возможностей будет заморожено в этой ветке вместе с выходом книги Александреску «The D Programming Language» (март 2010).

В планах находится D3.0, но о нём пока известно не слишком много. Известно лишь, что его разработка начнётся только после перехода D2.0 в стабильное состояние и разработки инструментария к нему.
Имеется два активно развивающихся компилятора DMD и LDC:
  • DMD — написан первоначальным создателем языка Волтером Брайтом (Walter Bright) и является, по сути, определением языка. Компилятор существует в версиях для D1.0 и D2.0. Есть поддержка для x86 Linux, x86 FreeBSD 7.1, x86 Windows и x86 Mac OSX 10.5
  • LDC — проект, использующий front-end от DMD и LLVM в качестве back-end'а. Благодаря LLVM, LDC уже способен генерировать код часто более производительный, чем код генерируемый DMD. Компилятор поддерживает D1.0, хотя есть эксперементальная ветка поддерживающая D2.0. Существует в версиях для x86 и x64 Linux. Поддержка Windows на данный момент ограничена (не работает механизм исключительных ситуаций) из-за внутренних проблем LLVM (эта информация, впрочем, не достоверна).

Для D1.0 существует две несовместимые стандартные библиотеки. Точнее стандартная (Phobos) и альтернативная (Tango). Phobos развивался слишком медленно и сообщество, не довольное подобных ходом событий, создало новую библиотеку, вскоре развившуюся до индустриального качества. В связи с этим в мире D1.0 возникла некоторая путаница, т.к. некоторые библиотеки и проекты поддерживали Phobos, в то время как другие использовали Tango, что автоматически создавало проблемы при необходимости использования проектов, требующих разные библиотеки.
В мире D2.0 такой проблемы не существует. Phobos вырос, возмужал и окреп, в то время как Tango все еще не портирована на D2.0. Также Phobos использует в качестве своей основы библиотеку druntime, основанную на коде Tango, что позволит в будущем их бесконфликтное сожительство в одном проекте.
Так что, если вам нужен совет, какой компилятор и библиотеку вам использовать, то всё просто:
Для D1.0 используйте DMD в Windows и LDC в Linux, а Tango в качестве основной библиотеки (большинство проектов использует именно её)
Для D2.0 используйте DMD и Phobos.

Почему же тогда нету задокументированного стандарта языка?

Как уже говорилось, по сути, определением языка является компилятор DMD. Было бы очень нерациональной тратой времени писать стандарт для D2, учитывая скорость, с которой он меняется. Для D1 существует неофициальное описание на сайте wiki4d и, видимо, авторы языка считают это достаточной временной альтернативой, пока не произойдёт стабилизация D2. По некоторой информации, есть договор между Вальтером и Андреем приурочить к выходу книги «The D Programming Language» не только заморозку добавления новых возможностей в D2, но и выпуск официальной спецификации языка.

Какие существуют IDE, чем они отличаются?

Существуют две основных IDE:
  • Descent — плагин к Eclipse.
  • Poseidon — IDE полностью написанное на D.

Poseidon, к сожалению, давно не обновлялся, однако остается полностью готовым к использованию. Имеет встроенную хорошую поддержку дебаггера. IDE поддерживает D1.0
Descent же развивается активно и творит чудеса вроде отладки шаблонов и полного семантического анализа кода, выявляя ошибки еще во время написания кода. Плагин полностью поддерживает D1.0 и имеет экспериментальную поддержку D2.0

Так же недавно был начат подающий надежды проект Code Poet.

Языку уже 10 лет, почему всё так плохо (грустно, печально, не вдохновляюще)?

Для начала стоит определиться, что считать моментом рождения языка и какие к нему должны быть требования.
По хорошему, неправильно говорить, что языку 10 лет. Прежде чем мы получили готовый к использованию компилятор и стандартную библиотеку прошло много времени, и именно этот момент, как мне кажется, и стоит считать рождением языка. Язык прошел через долгие предродовые муки и, сформировавшись, явился на свет.
Потом, совершенно не уместна фраза «почему так плохо». Как «так плохо»?
Почему язык не является флагманом промышленности? Потому что за ним не стоит денежный мешок. Язык создается и поддерживается сообществом ради сообщества. А промышленности нужны гарантии, что язык не исчезнет и через 10 лет, что он будет стабилен, что будет предоставлять возможности, которые требует индустрия. D не может дать этих гарантий. Неизвестно, хорошо это или нет, но я ( мы :) ) буду его использовать, если у меня ( нас :) )будет такая возможность.
Почему до сих пор нет хорошего инструментария и отлаженной цепи разработки? Создание хорошего инструментария требует больших затрат сил и времени. Далеко не все готовы тратить свое время на что-то что может перестать существовать через пару лет, но те, кто решается, помогают D двигаться дальше, обращая все новых людей. Волтер Брайт собирался после приведения D2.0 в стабильное состояние (что произойдет очень скоро) заняться созданием вещей, упрощающих жизнь D разработчика.

Какие планы по развитию языка у авторов?

О планах в целом было немного рассказано в предыдущих ответах.
Касательно D2.0 в ближайшем будущем будет добавлено следующее:
  • Новая более мощная перегрузка операторов
  • В библиотеку Phobos добавятся механизмы для обмена сообщениями, что значительно облегчит написание параллельного кода.

Для D3.0 запланировано следующее:
  • AST макросы.
  • система типов, предложенная Бартошем Милевски (Bartosz Milewski), как средство против «гонок» данный (data races).

Так же о развитии языка можно почитать здесь (тырк).

Какие реальные программы уже написаны на D и в полной мере работоспособны?

Сложно назвать список, т.к. программ на самом деле много и они все разные.
Просто что бы не оставаться голословным:
  • интерпретаторы скриптовых языков MiniD и Monster, а также интерпретатор Lisp
  • системы сборки xfbuild и DSSS
  • браузер серверов игр, использующих «движок» Quake 3 — Monster Browser
  • есть игры, есть редакторы кода и IDE, есть множество разнообразных библиотек.

Список множества текущих open-source проектов на D можно посмотреть здесь: (тырк). Не пугайтесь того, что половина из них заброшена — это компенсируется их количеством. Всё-таки open-source есть open-source :).

Есть ли тесты производительности (относительно С++)

Есть, но, к сожалению, shoutout исключил D из последних тестов и результаты не очень актуальны, но даже они дают представление, что D практически не отстает по производительности от C++.
По этой ссылке можно взглянуть на сравнительные тесты разных компиляторов D по множеству параметров.

А что бы такого интересного почитать по этой теме?

http://prowiki.org/wiki4d/wiki.cgi?FrontPage
http://dprogramming.ru
http://www.digitalmars.com/d/
http://www.digitalmars.com/webnews/newsgroups.php?search_txt=&group=digitalmars.D
http://www.dsource.org
http://ru.wikibooks.org/w/index.php?title=D

Я хочу помочь развитию языка, что я могу сделать?

Прежде всего, обратить внимание на соответствующий раздел wiki4d. Вот краткая выдержка оттуда в переводе:
Компиляторы. Многие считают, что D невозможно воспринимать всерьёз, покуда не будет создано хотя бы несколько полноценных компиляторов. Вы можете влиться в разработку LDC, поучаствовать в убеждение Вальтера реализовать ещё что-нибудь в DMD или, быть может, оживить почти мёртвый проект GDC.
Дебаггеры. Пока что не существует ни одного в полной мере рабочего дебаггера для D. Но стоит присмотреться как минимум к разработке патча для gdb для поддержки схемы именования D.
Документация. Её никогда не бывает мало.
Библиотеки. Пройдя по вышеприведённой ссылке можно найти целые тематические «виш-листы».

А что вы думаете о Go? :)

Go — интересный, но пока еще слишком молодой проект. Он, конечно, привнесет свежую струю в разработку серверных программ, но на звание системного языка не годится (по крайней мере, в том значении, в каком мы понимаем термин «системный язык»). Через год-полтора, пожалуй, можно будет второй раз взглянуть на Go, что бы оценить проделанную работу и решить для себя необходимость использования этого языка.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 56

    +2
    Спасибо. Интересно.
      +1
      Еще одно подтверждение тезису, что делать тщательно и правильно нужно с первого раза (о переводе). Переводчикам — спасибо!
        0
        [ответ ниже, прискорбно промахнулся]
        0
        Моя вина, слишком уж хотелось поделиться с миром интересной находкой.
        О коллективном переводе узнал уже после публикации.
          +2
          язык интересный, но(!):
          1) Я не понимаю что они там такого наворотили, что столько портировали на родственную ОС — FreeBSD;
          2) Нету нормальной поддержки x86_64. Я с большим удовольствием наваял на D простой каркас MVC cgi фреймворка, но этот недостаток ставит на нем крест. Мне нужна поддержка x86_64 как минимум для Linux и FreeBSD.
          К сожалению пока он не выглядит очень вкусным=(
            0
            +Tango, индустриального качества, бывало не собиралась на некоторых релизах.
            0
            Для Linux x64 есть ldc. FreeBSD — да, увы.
            Впрочем, никто из коммьюнити/авторов особо и не скрывает — ещё пилить и пилить, человекоресурсов не хватает. В FAQ это довольно подробно отмечено.
              0
              A можно Хелло Ворлд?! А то искать неохота =)
                +2
                [см. ниже, я сегодня умудрился промазать при ответе три раза (facepalm)]
                +1
                Вообще-то, приведено в самом начале второй части статьи. Копирую исключительно в честь пиар-кампании ;)
                import std.stdio;
                void main()
                {
                  writeln( "Hello, world!");
                }
                  0
                  Задаю вопросы.

                  Хочется, чтобы, например, вот такое:

                  > FILE f;
                  > fopen(f, «foo.txt», «rw»);
                  > fread(… );
                  > // забыли закрыть :)

                  или такое:

                  > unsigned char *ptr = malloc(512);
                  >… // какой-то код, использующий ptr
                  > free(ptr);
                  >… // еще код
                  > *ptr = 0; // попытка чтения по висячему указателю (dangling pointer)

                  не компилировалось. Такое возможно в D?
                    0
                    Первое решается и в С++, для этого создано ООП и RAII.

                    Второе невозможно отследить во время компиляции, ведь обращение к указателю может быть где угодно. Однако против таких ситуации тоже спасет ООП и RAII, если для хранения одиночных объектов в хипе использовать boost::shared_ptr, например, а вместо выделений массивов — std::vector.
                      0
                      Спасибо за коммент, но разговор идет именно о проверке этих инвариантов во время компиляции, а не об идиомах (RAII) и контейнерах, позволяющих обойти эти проблемы.
                        0
                        Нет, без макросов не решается при компиляции. По крайней мере я не нашёл способ. Анализ данных вроде зачаточный есть и некоторые обращения по нулевому указателю DMD ловит, но рассчитывать на это не нужно.

                        Если есть открытый ресурс, я обычно пишу в стиле LISP:

                        with_open_file("foo.txt", "rw", (File fd) {
                            fd.read(...);
                        });


                        Вот реализация:
                        void with_open_file(string name, string access, void delegate(File file) dg) {
                            fd = File(name, access);
                            scope(exit) fd.close;
                            dg(fd);
                        }
                          0
                          > with_open_file(«foo.txt», «rw», (File fd) {
                          > fd.read(...);
                          > });

                          Ну да, знакомо. :) А почему бы не использовать enum вместо «rw»/«r»/etc.?

                          А делегат где располагается? В куче? Можно ли выделить его в стеке?

                          В ATS такие штуки отслеживаются без накладных расходов в рантайме. Вот минимальный пример, функция opfile:

                          > fn opfile (path:string): void = let
                          > val (pfopt | fp) = fopen_err (path, file_mode_r)
                          > in
                          > if fp null then let
                          > prval Some_v (pf) = pfopt
                          > in
                          > fclose_exn (pf | fp)
                          > end else let
                          > prval None_v () = pfopt
                          > in
                          > prerrf («opfile(\»%s\"): failed to open\n", @(path))
                          > end
                          > end

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

                          Надо бы попробовать такую штуку написать, как with_open_file.

                          PS: ага, выглядит жутковато.
                            +1
                            В данном случае — на стеке. Для делегатов решение о выделении памяти под него на куче выполняется на основе (консервативного, не точного) escape анализа. т.е. если бы делегат получался из функции:
                            with_open_file("foo.txt", "rw", getProcessDelegate());

                            то объявление его в недрах getProcessDelegate произошло бы на куче.
                              0
                              Делегат, как я понимаю — просто указатель на кусок кода, вроде указателя на функцию в Си (+ указатель на кусок памяти с переменными для closure), т.е. 2 числа, так что не сказал бы, что он несет какие-то особые накладные расходы.

                              Перемнные, завернутые в closure выделяются на куче, да, а как иначе они могут пережить родную функцию?

                                0
                                по-моему, делегат еще обязательно должен быть объектно-ориентированным
                                  0
                                  Объектно-ориентированный делегат? :D
                                    0
                                    А в D все хитрее: там есть делегат- — анонимный метод объекта, а есть делегат — вложенная функция (т.е. находящаяся внутри другой функции), имеющая доступ к ее переменным даже после завершения той (замыкание).

                                    В принципе, делгат — указатель на функцию + указатель на область с данными.а что там хранится, объект или локальные перемннные внешней функции, делегату пофиг.

                                    И кстати, по моему это круто: компилируемый язык с делегатами и замыканиями, нет? При том, что ему не нужны многогмегабайтные тормозные сборки .NET или явы.
                                    0
                                    > Делегат, как я понимаю — просто указатель на кусок кода, вроде указателя на функцию в Си (+ указатель на кусок памяти с переменными для closure), т.е. 2 числа, так что не сказал бы, что он несет какие-то особые накладные расходы.

                                    Угу, замыкание это указатель на функцию + указатель на окружение (которое, по сути просто struct какой-то).

                                    Выделение всего этого дела в куче — вот накладные расходы (хотя во многих случаях этим можно пренебречь).

                                    Вот тут описано, как в ATS память под замыкание можно выделить на стеке вызывающей функции:

                                    www.ats-lang.org/TUTORIAL/contents/stack-allocation.html
                                      0
                                      Почему в ats все (почти) слова в идентификаторах и кейвордах сокращены до трёх букв? :D

                                      clo, lam, arr, ptr.
                                        0
                                        Ну хранить переменные в стеке можно, если например, замыкание передается внутрь функции, там используется и отбрасывается (что кстати чаще всего и бывает).

                                        По поводу оверхеда — думаю, небольшой. Никто (я надеюсь) не использует замыкания для часто вызваемых процедур к примеру, если их использовать для вещей типа with_open_file ( как в примере выше в комментах) — операции открытия файла намного медленнее выделения небольшого кусочка памяти.

                                        А в ATS невменяемый синтаксис, уж извините. ни Лиспа, ни Си не люблю из-за этого ((
                                          0
                                          /offtopic{У Lisp'а прекрасный синтаксис на самом деле. Простой и понятный. С остальным согласен, к сожалению, но синтаксис — не главное}
                                            +1
                                            Да, пример именно с with_open_file немного отвлекает от темы (уж там замыкание можно и выделить на куче :) — хотя, может быть, в embedded или каких-то особых ситуациях такое делать не рекомендуется).

                                            На самом деле, хотелось показать то, чего нет в D:
                                            — возможность записывать сложные пред- и постусловия прямо в коде (и давать компилятору проверить их выполнение до запуска программы)
                                            — возможность сочетать эффективность и безопасность (для сравнения, RAII — это безопасность и выразительность)

                                            В D типы обычно не используются для улучшения безопасности (по-моему, там основной фокус в увеличении выразительности и абстрагирования от некоторых деталей, что тоже дает безопасность: например, можно сравнить ссылки и указатели). В ATS же можно указать некоторые аннотации для стандартных функций POSIX и облегчить их безопасное использование (если эти функции удовлетворяют тем предпосылкам, которые даны в их типе, то все будет хорошо).
                                              +2
                                              Ну по поводу проверки — в D есть неплохие штуки типа assert() (работает только в дебаг режиме), что-то с инвариантами классов, и что-то для фанатов юнит-тестов — по мне, не так уж мало.
                                                +2
                                                Да, я даже пользовался этим. ^_^ Очень удобно, особенно когда модифицируешь код (хотя, надо признать, Contracts в PLT Scheme все же лучше).

                                                Жаль, что в D весьма куцые возможности по проверке программ во время компиляции. :(
                                                  +1
                                                  Разработчик и коммьюнити на ATS даже краем глаза не смотрели. Если я хоть немного умею читать незнакомые языки (:]), то в D можно реализовать пару фичей, не изменяя уже имеющиеся и так, что они не будут выглядеть прикрученными сбоку.

                                                  А пока есть только static assert, который можно использовать для проверки условий в разворачивании шаблонов или CTFE. Чего нет у C++. Например, функция sort, написанная Александреску, ругается, если в качестве предиката ей передать что-нибудь вроде «a = b».
                                                    +2
                                                    Ага. Было бы интересно посмотреть, что из ATS можно приделать к D.
                                                    Например, реализовать индексированные монады, а с помощью них — легковесные зависимые типы (как у Киселева тут).
                                      0
                                      В реализацию стоит еще добавить try/catch, ну или вообще обработку ошибок)

                                      И разве в D перед делегатом/анонимной функцией не пишут function/delegate() или как-то так?
                                        +1
                                        > В реализацию стоит еще добавить try/catch, ну или вообще обработку ошибок)

                                        Она есть. :) scope(exit) выполняется в любом случае. scope(failure) — при выходе из stack-frame'а по exception. scope(success) — при выходе по return. Если в пользовательском коде произойдёт ошибка, выполнится fd.close;

                                        > И разве в D перед делегатом/анонимной функцией не пишут function/delegate() или как-то так?

                                        Это сокращённая форма. Полностью будет так:
                                        with_open_file("foo.txt", "rw", delegate void (File fd) {
                                            fd.read(...);
                                        });


                                        Но delegate компилятору не нужен. Синтаксис и без него получается контекстно-независимым. А возвращаемый тип определяется автоматически по возвращаемым значениям в делегате. Если их нет — значит void.
                                          0
                                          Точно. scope() я как-то не заметил! Но ведь try… catch ..finally, по моему проще для восприятия, нет?

                                          А счинтаксис без слова delegate мне нравится :) Почти что руби получается )) да и реализация замыканий в D вроде не самая плохая.
                                            +1
                                            try… catch… finally добавляет облась видимости там где он не нужен.

                                            Сравните
                                            auto fd = File(name, access);
                                            scope(exit) fd.close;

                                            и

                                            File fd = null;
                                            try {
                                                fd = File(name, access);
                                            } finally {
                                                fd.close;
                                            }
                                      0
                                      А каким вообще образом компилятор может проверить такие вещи? Если файл открыт в одной функции, а закрывается в другой. Или указатель освобождается в одной функции, но используется в других. Это можно увидеть только во время выполнения. А чтобы гарантировать что-то во время компиляции, нужно накладывать дополнительные ограничения на стиль использования ресурсов, то есть пользоваться идиомами.
                                        0
                                        > А каким вообще образом компилятор может проверить такие вещи?

                                        Способы есть, они обычно основываются на соответствии между типами и логическими формулами (т.н. изоморфизм Карри-Говарда).

                                        Иными словами, типы в программе — это и есть логические формулы! :) Ну а программы — это доказательства теорем, которые описаны типами.
                                        Например, тип такой функции:

                                        fun {a:type} identity(x:a):a = x

                                        (то есть функция, которая для любого терма типа a возвращает его же: id(1) = 1, id(«foo») = «foo», etc.) в логике будет

                                        forall a:type. a -> a

                                        Как-то так.
                                    0
                                    Как уже сказали ниже, используйте RAII. Выдавать ошибку при компиляции можно, написав обёртку для fopen, fread. Если интересно — приведу пример. Но принято решать эти проблемы так:
                                    fopen(f, "foo.txt", "rw");
                                    scope(exit) close(f);
                                    fread(...);


                                    Второй можно решить так же, но лучше доверить сборщику мусора:
                                    auto ptr = new char[512];
                                    +2
                                    JFYI есть ещё отечественный D (http://okante.narod.ru/D/). Автор безумен чуть более, чем полностью. Чтение материалов по Д (коих множество) доставляет. Д не имеющий никакого отношени к D.
                                      +1
                                      Как и следовало ожидать, всю карму получит тот из переводчиков, кто опубликует статью. FAQ — тоже коллективное усилие. Определённого единственного автора нет.
                                        0
                                        Не знаю как у вас, товарищи, а у меня dprogramming.ru уже неделю-другую как не открывается ни под каким видом. Если быть точным, DNS не находит хост.
                                          0
                                          Как я только что узнал, владелец домена проворонил его оплату со всеми вытекающими. Пока не знаю, чем это закончиться.
                                          0
                                          А вы не в курсе про портирование D на Native Client? Пробовал через гугл поискать на эту тему, но что-то все глухо… Просто я думаю гугл будет активно продвигать NaCl и у D в этом плане есть неплохой шанс выстрелить, т.к. С++ довольно сложен для тех кто привык к Java или C# и пока не понятно появятся ли они на NaCl (ибо там сложно всё с динамическим изменением кода), а вот у D есть возможность заработать на NaCl уже сейчас.
                                            0
                                            Насколько мне известно, ничего подобного не планируется. Можно, конечно, предложить это направление в официальном newsgroup.
                                            Не думаю, впрочем, что это найдёт большой отклик, ибо:
                                            а) Сейчас однозначным приоритетом ялвяется создание безбажного компилятора, реализующего спецификации и стандартных библиотек ( под обычные платформы )
                                            б) «Заработать» на какой-то определённой нише противоречило бы позиционированию D как языка широкого применения, это задача для тех, кому нужен D в NaCl, но не авторов D.
                                              0
                                              Угу это уже есть — www.digitalmars.com/d/archives/digitalmars/D/pNaCl_107771.html

                                              Просто это реальный шанс языку приобрести популярность, потому что на NaCl будет нужен более простой язык, чем C++, когда Actionscript, Java, C# программеры захотят программить для Chrome OS. И D просто идеальный вариант для этого. Впрочем, может портанут Java примерно как для Android, но в любом случае тут у всех будут равные шансы и у D их больше всего.
                                                0
                                                Я предвзят и не люблю NaCl как концепцию, так что воздержусь: )
                                                Newsgroup покажет.
                                            0
                                            Хороший язык! Удобненький.
                                            Orfo Switcher я писал именно на нем.
                                            Но теперь приходится все переписывать назад опять на C++ :)
                                              0
                                              По какой причине?: )
                                                0
                                                Теперь над программой работаю не я один, а мой напарник не знает этого языка, а C++ привычен нам обоим. Да и, если кто-то еще за проект возьмется, опять же ди — по-прежнему экзотика, возможны проблемы. Я даже исходники выкладывал программы — редкая душа бралась подправить их :)
                                                C++ как-то по-популярнее все-таки
                                                  0
                                                  Не быстрее ли научить напарника D, чем переписать всё под С++? :)
                                                    0
                                                    Не, он уже старенький
                                              0
                                              А как у D ситуация с различными библиотеками, фреймворками, биндингами и прочим?
                                                0
                                                С нативными — средней паршивости, хотя стандартная библиотека ( phobos ) за последние месяцы набрала невероятный темп развития. Большинство открыто доступных родных библиотек\биндингов можно найти на dsource.org — главное не путать D1 и D2.

                                                С другой стороны, возможно использование напрямую любой Cишной библиотеки, для этого необходимо лишь преобразовать сишные заголовочные файлы в D модули по формальным правилам и соответствующая библиотека будет слинкована с D кодом. Для windows есть официальная тулза, автоматизирующая этот процесс — www.digitalmars.com/d/2.0/htod.html; Для Linux я хочу написать аналогичную, но всё как-то некогда, да и руками достаточно быстро получается :)
                                                  0
                                                  Поддержки либ C++ значит как не было, так и нет?

                                                  Насколько возможно из D пользоваться либами Qt, wxWidgets, GTK?

                                                  Да и вообще насколько при разработке софта на D приходится писать велосипеды?
                                                    0
                                                    Отчасти есть, но очень ограниченная проблемами C++ ABI, подробнее здесь: www.digitalmars.com/d/2.0/cpp_interface.html. Насколько мне известно даже обсуждалось предложение выкинуть эту функциональность как малоиспользуемую и глючную :) Обычно просто делают оболочку к С++ либе с extern «C», и линкуют уже её.

                                                    Родные биндинги к Qt и GTK есть на dsource.org точно, wxWidgets — не знаю. Не могу судить об их качестве, т.к. ничего с GUI на D я не писал. Велосипеды писать чаще хочется, чем приходится — использование C библиотек покрывает большинство требований, но потратив некоторое время на велосипед, можно получить намного более изящный интерфейс :)

                                                    Если речь о production-ready — не знаю. Компилятор теперь, пожалуй, да. Библиотеки, скорее, всё же нет — сейчас как раз период активных изменений.
                                                      0
                                                      Не расскажете, о каких активных изменениях идёт речь?

                                                      И когда, по вашему, D более-менее устаканится и перестанет ломаться совместимость, так что можно будет с чистой совестью вкладывать в эту версию своё время, усилия и писать на ней код?
                                                      А то возникает соблазн ещё обождать, пока наконец не будет достигнута окончательная стабильность.
                                                        +1
                                                        Не могу пошерстить newsgroup'ы с работы, когда окажусь дома — сделаю выборку интересных сообщений :)
                                                –1
                                                DMD даже не может нормально скомпилировать: DMD1 — «не является приложением Win32» (такая же проблема и с DMC!), а файл, созданный DMD2, вызывает ошибку обращения к нулевому адресу, даже если нет кода — один main («больше не придётся часами искать ошибку»).

                                                У меня сложилось впечатление, что это — урезанный вариант C++: сделали более строгим, добавили ограничений, загнали всё в классы, и так «изобрели гениальный язык взамен устаревшего Си»

                                                Информация по языку отсутствует: в сети, включая сайт разработчиков, — одна «вода». Авторы Си — Керниган и Ритчи — когда-то написали отличную книжку, а эти только жалуются, что их язык не популярен…

                                                Only users with full accounts can post comments. Log in, please.