Была ( а скорее всего и есть ) проблема, связанная с тем, что opDispatch без статических ограничений делает класс полностью нерабочим в сочетании с duck-typing алгоритмами. Он будет проходить все мыслимые constraints. Но это, кажется, неизбежная расплата.
D может подсчитать сколько нужно стековой памяти на этапе компиляции, если использовать самописные compile-time врапперы при объявлении переменных. Если добавить пару до сих пор не востребованных __traits в компилятор — можно и просто так.
Шаблонов будет, конечно, кромешный ад, но это проблемы автора библиотеки :)
Увидев первый вариант opUnary уже было хотел разразится праведным generic гневом, но успел прочитать чуть дальше :)
Важный момент — range не должны имплементировать интерфейс и даже не обязаны иметь методы с таким именем. Необходимое и достаточное условие — должен компилироваться код с использованием этих методов. Думаю в контексте вашего же Dynamic должно быть понятно, почему это принципиальное отличие.
Необходимость замены С++ очевидна уже давно, особенно для любителей С++ — но задача эта ой как не проста. Сделают в итоге хоть один — будет уже замечательно.
О, а вот эта концепция мне нравится, в отличие от Go. Typestate — вообще великолепная задумка, надо подумать, как его можно реализовать библиотекой на D :)
К сожалению, знаком с CSP исключительно по википедии и «научно-популярным» заметкам, так что тему поддержать не смогу. Формально это сделать можно, все инструменты в языке есть, в том числе, чтобы и держать за вас в голове нюансы ( в отличие от С++ ). Как это сделать технически — ни малейших идей, как уже говорил, слишком мало знаю про CSP.
Go мне кажется неудачным не в сравнении а по дизайну вообще — у него слишком странная ниша. Для системного языка не приемлемо отсутствие контроля над garbage collector, для высокоуровневого — пренебрежение generic парадигмой. Возможно, чего-то не понял, виноват.
Что касается go-routines и CSP — это реализуется в любом языке с помощью библиотек, поэтому не понятно мне в качестве фичи именно языка. На D проскальзывало когда-то объявление о выпуске библиотеки с говорящим названием DCSP, но начинание не вызвало достаточного интереса со стороны коммьюнити и на данный момент заброшено — даже доменное имя уже не используется, как я только что проверил.
Это вообще проблема замкнутого круга в D — недостаточная популярность т.к. нехватка библиотек, и мало библиотек, т.к. нет достаточной целевой аудитории для мотивации разработки :(
Кстати, в области веб-программирования D очень интересен, я немножко экспериментирую с разными набросками на эту тему. Увы, основная работа пока не даёт времени на попытаться сделать что-то конкретное, но именно за счёт метапрограммирования можно радикально изменить подход к добавлению контента, статически генерируя сервер специализированный конкретными данными. Но это так, из области любопытных мечтаний, на статью пока не тянет :)
Вообще-то даже на newsgroup его называют D2, если из контекста не ясно, о какой из версий идёт речь.
Различия слишком велики, чтобы называть и то, и то просто D. Говорить же «язык D второй версии» — громоздко.
Да, про это забыл. Правда встречал использование подобной идиомы не для вынесения секретных констант, а как раз для вынесения DSL в отдельный файл. ЕМНИП, Goldie использует подобный подход для статической генерации парсеров грамматик.
Можно, но это уже моё личное предпочтение — явное указание типа возврата в сочетании с typeof(return) даёт дополнительный контроль компилятора над корректностью контрактов в коде. Стараюсь получить от статической типизации максимум ;)
Люблю RAII и С++, простите :) Не могу представить на самом деле ни единой причины не желать возможностей С++, если нужны возможности С. В случае с D просто получается сильный контраст в выразительности в gc-managed кодом, это не эстетично :)
Должен признать, что в текущей имплементации с этим есть некоторые проблемы, т.к., например встроенные ассоциативные массивы при отключении GC становятся неюзабельны ( память течёт ), стандартная библиотека D тоже к этому не очень готова. В итоге, по сути, идёт возврат к С, а не С++. На эту тему велись ожесточённые споры, не знаю, к какому решению пришли в итоге.
Зачем — мне неизвестен другой язык с такими разнообразными возможностями и последовательным дизайном. Да и выбор компилируемых языков с современными возможностями не слишком богат (назовите хоть один, сравнимый с D по возможностям — будет любопытно). Если же эти параметры для вас непринципиальны — учить его незачем, даже предлагать не буду. Целевая аудитория его, на мой взгляд, — не корпоративный сегмент, а одиночки-перфекционисты, желающие выжать максимум из инструмента.
С IDE, дебаггером, кроссплатформенностью и взаимодействием с другими платформами у него всё ограничено. Оно есть, но далеко от ожиданий того, кто привык к инфраструктуре той же Java. ( из IDE выделяется, пожалуй, VisualD плагин для VisualStudio ). Стандартная библиотека хороша, но мала. Создание автоматической документации встроено в язык ( все доки на официальном сайте сделаны с её помощью ). Юнит-тесты встроены в язык.
Почему не Kotlin? Ну, например, драйвера на нём особо не попишешь, судя по тому, что оно Java-based. А я люблю, когда есть один язык, на котором можно написать всё, от скриптов до ОС. На D — можно. Mixin, кстати, в моих глазах — уже достаточный аргумент для перехода, имеющий мало аналогов в других языках. Просто попробуйте реализовать приведённый пример на чём-нибудь другом, причём реализовать без хаков, с полным контролем ошибок и т.п. Это killing feature для писателей библиотек.
D может всё то же, что может и С++11, и ещё много сверху. Но имеет намного худший toolchain. Вот, собственно и всё описание задач, в которых он применим. ( Go — очень неудачный язык, после прочтения спеков не вызвал желания даже на «hello, world» ).
Извините, если вышло резковато, просто вопрос о том, что у D отвратительный toolchain поднимался уже столько раз, что не хочется про это говорить в рамках статьи, посвящённой вполне конкретной части дизайна языка.
Шаблонов будет, конечно, кромешный ад, но это проблемы автора библиотеки :)
obj.AddMethod(«front»,… );
obj.AddMethod(«popFront»,… );
Философский вопрос — имплементировано ли в этом случае искомое? :)
Важный момент — range не должны имплементировать интерфейс и даже не обязаны иметь методы с таким именем. Необходимое и достаточное условие — должен компилироваться код с использованием этих методов. Думаю в контексте вашего же Dynamic должно быть понятно, почему это принципиальное отличие.
;)
Вполне возможно, что тут вы абсолютно правы.
Что касается go-routines и CSP — это реализуется в любом языке с помощью библиотек, поэтому не понятно мне в качестве фичи именно языка. На D проскальзывало когда-то объявление о выпуске библиотеки с говорящим названием DCSP, но начинание не вызвало достаточного интереса со стороны коммьюнити и на данный момент заброшено — даже доменное имя уже не используется, как я только что проверил.
Это вообще проблема замкнутого круга в D — недостаточная популярность т.к. нехватка библиотек, и мало библиотек, т.к. нет достаточной целевой аудитории для мотивации разработки :(
Различия слишком велики, чтобы называть и то, и то просто D. Говорить же «язык D второй версии» — громоздко.
Это чтобы не обвиняли в крушении ожиданий :)
Я когда писал статью проверял, на базовых типах точно работает. malloc, конечно, не выйдет использовать, но работать с ассоциативными массивами и генерацией строк — вполне.
С IDE, дебаггером, кроссплатформенностью и взаимодействием с другими платформами у него всё ограничено. Оно есть, но далеко от ожиданий того, кто привык к инфраструктуре той же Java. ( из IDE выделяется, пожалуй, VisualD плагин для VisualStudio ). Стандартная библиотека хороша, но мала. Создание автоматической документации встроено в язык ( все доки на официальном сайте сделаны с её помощью ). Юнит-тесты встроены в язык.
Почему не Kotlin? Ну, например, драйвера на нём особо не попишешь, судя по тому, что оно Java-based. А я люблю, когда есть один язык, на котором можно написать всё, от скриптов до ОС. На D — можно. Mixin, кстати, в моих глазах — уже достаточный аргумент для перехода, имеющий мало аналогов в других языках. Просто попробуйте реализовать приведённый пример на чём-нибудь другом, причём реализовать без хаков, с полным контролем ошибок и т.п. Это killing feature для писателей библиотек.
D может всё то же, что может и С++11, и ещё много сверху. Но имеет намного худший toolchain. Вот, собственно и всё описание задач, в которых он применим. ( Go — очень неудачный язык, после прочтения спеков не вызвал желания даже на «hello, world» ).
Извините, если вышло резковато, просто вопрос о том, что у D отвратительный toolchain поднимался уже столько раз, что не хочется про это говорить в рамках статьи, посвящённой вполне конкретной части дизайна языка.
bibliotekar.ru/encSlov/3/204.htm