Comments 38
Было очень интересно почитать сравнение D и других языков программирования применительно к разным задачам.
То есть «было бы», как я понимаю? Очень уж объемная и расплывчатая задача. Если выбрать один какой-то другой язык программирования и одну какую-то задачу — это уже будет тянуть на неплохой обзор.
Быть может, немного конкретизируете?
Быть может, немного конкретизируете?
Да, «было бы», ошибся. :)
Если конкретно, то мне интересно, какие задачи D решает эффективнее других языков. Зачем его учить, для чего? От количества языков и технологий у меня лично уже кружится голова. И вот, новый (относительно) язык — D с лямбдами, шаблонами, миксинами, свойствами и прочим блекджеком. А как у него с IDE, дебаггером, кросплатформенностью, взаимодействием с другими платформами? Хороша ли стандартная библиотека, как быстро на нем можно разрабатывать? Какие есть средства для создания, скажем, автоматической документации, создания и запуска юнит-тестов?
Недавно смотрел доклад про новый язык от JetBrains: как и положено современному языку, реализованы лямбды, свойства (полей вообще нет!), вывод типов и авто-касты, дженерики, паттерн матчинг есть. Есть прекрасная IDE и обратная совместимость с Java.
Почему бы не использовать для нового проекта Kotlin, а не D? Или остановится на уже зарекомендовавшей себя платформе .NET? Не из-за миксинов же на D переходить.
Есть задачи, где использование C++ против С# будет оправдано. Есть такие для D против C++11 или, скажем, Go?
Если конкретно, то мне интересно, какие задачи D решает эффективнее других языков. Зачем его учить, для чего? От количества языков и технологий у меня лично уже кружится голова. И вот, новый (относительно) язык — D с лямбдами, шаблонами, миксинами, свойствами и прочим блекджеком. А как у него с IDE, дебаггером, кросплатформенностью, взаимодействием с другими платформами? Хороша ли стандартная библиотека, как быстро на нем можно разрабатывать? Какие есть средства для создания, скажем, автоматической документации, создания и запуска юнит-тестов?
Недавно смотрел доклад про новый язык от JetBrains: как и положено современному языку, реализованы лямбды, свойства (полей вообще нет!), вывод типов и авто-касты, дженерики, паттерн матчинг есть. Есть прекрасная IDE и обратная совместимость с Java.
Почему бы не использовать для нового проекта Kotlin, а не D? Или остановится на уже зарекомендовавшей себя платформе .NET? Не из-за миксинов же на D переходить.
Есть задачи, где использование C++ против С# будет оправдано. Есть такие для D против C++11 или, скажем, Go?
Зачем — мне неизвестен другой язык с такими разнообразными возможностями и последовательным дизайном. Да и выбор компилируемых языков с современными возможностями не слишком богат (назовите хоть один, сравнимый с D по возможностям — будет любопытно). Если же эти параметры для вас непринципиальны — учить его незачем, даже предлагать не буду. Целевая аудитория его, на мой взгляд, — не корпоративный сегмент, а одиночки-перфекционисты, желающие выжать максимум из инструмента.
С IDE, дебаггером, кроссплатформенностью и взаимодействием с другими платформами у него всё ограничено. Оно есть, но далеко от ожиданий того, кто привык к инфраструктуре той же Java. ( из IDE выделяется, пожалуй, VisualD плагин для VisualStudio ). Стандартная библиотека хороша, но мала. Создание автоматической документации встроено в язык ( все доки на официальном сайте сделаны с её помощью ). Юнит-тесты встроены в язык.
Почему не Kotlin? Ну, например, драйвера на нём особо не попишешь, судя по тому, что оно Java-based. А я люблю, когда есть один язык, на котором можно написать всё, от скриптов до ОС. На D — можно. Mixin, кстати, в моих глазах — уже достаточный аргумент для перехода, имеющий мало аналогов в других языках. Просто попробуйте реализовать приведённый пример на чём-нибудь другом, причём реализовать без хаков, с полным контролем ошибок и т.п. Это killing feature для писателей библиотек.
D может всё то же, что может и С++11, и ещё много сверху. Но имеет намного худший toolchain. Вот, собственно и всё описание задач, в которых он применим. ( Go — очень неудачный язык, после прочтения спеков не вызвал желания даже на «hello, world» ).
Извините, если вышло резковато, просто вопрос о том, что у D отвратительный toolchain поднимался уже столько раз, что не хочется про это говорить в рамках статьи, посвящённой вполне конкретной части дизайна языка.
С IDE, дебаггером, кроссплатформенностью и взаимодействием с другими платформами у него всё ограничено. Оно есть, но далеко от ожиданий того, кто привык к инфраструктуре той же Java. ( из IDE выделяется, пожалуй, VisualD плагин для VisualStudio ). Стандартная библиотека хороша, но мала. Создание автоматической документации встроено в язык ( все доки на официальном сайте сделаны с её помощью ). Юнит-тесты встроены в язык.
Почему не Kotlin? Ну, например, драйвера на нём особо не попишешь, судя по тому, что оно Java-based. А я люблю, когда есть один язык, на котором можно написать всё, от скриптов до ОС. На D — можно. Mixin, кстати, в моих глазах — уже достаточный аргумент для перехода, имеющий мало аналогов в других языках. Просто попробуйте реализовать приведённый пример на чём-нибудь другом, причём реализовать без хаков, с полным контролем ошибок и т.п. Это killing feature для писателей библиотек.
D может всё то же, что может и С++11, и ещё много сверху. Но имеет намного худший toolchain. Вот, собственно и всё описание задач, в которых он применим. ( Go — очень неудачный язык, после прочтения спеков не вызвал желания даже на «hello, world» ).
Извините, если вышло резковато, просто вопрос о том, что у D отвратительный toolchain поднимался уже столько раз, что не хочется про это говорить в рамках статьи, посвящённой вполне конкретной части дизайна языка.
Ну я не писал на Go, потому про неудачность говорить не буду, но вот тоже никакого желания писать не возникает. А D прямо-таки влюбляет в себя программиста.
UFO just landed and posted this here
Go мне кажется неудачным не в сравнении а по дизайну вообще — у него слишком странная ниша. Для системного языка не приемлемо отсутствие контроля над garbage collector, для высокоуровневого — пренебрежение generic парадигмой. Возможно, чего-то не понял, виноват.
Что касается go-routines и CSP — это реализуется в любом языке с помощью библиотек, поэтому не понятно мне в качестве фичи именно языка. На D проскальзывало когда-то объявление о выпуске библиотеки с говорящим названием DCSP, но начинание не вызвало достаточного интереса со стороны коммьюнити и на данный момент заброшено — даже доменное имя уже не используется, как я только что проверил.
Это вообще проблема замкнутого круга в D — недостаточная популярность т.к. нехватка библиотек, и мало библиотек, т.к. нет достаточной целевой аудитории для мотивации разработки :(
Что касается go-routines и CSP — это реализуется в любом языке с помощью библиотек, поэтому не понятно мне в качестве фичи именно языка. На D проскальзывало когда-то объявление о выпуске библиотеки с говорящим названием DCSP, но начинание не вызвало достаточного интереса со стороны коммьюнити и на данный момент заброшено — даже доменное имя уже не используется, как я только что проверил.
Это вообще проблема замкнутого круга в D — недостаточная популярность т.к. нехватка библиотек, и мало библиотек, т.к. нет достаточной целевой аудитории для мотивации разработки :(
В теории, всё что угодно реализуется в любом языке. Практика, как обычно, от теории сильно отличается. Если я ничего не забыл, лёгкие нити с каналами в стиле CSP сейчас можно нормально использовать в Plan9 C, Limbo, Go и Erlang.
Ещё вроде бы Stackless Python, но я не уверен, готово ли оно к использованию — как ни гляну в ту сторону, вечно натыкаюсь на описания каких-то проблем с использованием stackless в реальных проектах. Опять же, теоретически для Perl есть модуль Coro, но практически та же фигня, что и с Python — попытка выяснить, насколько хорошо оно работает за пределами того проекта под который он писался показывает исключительно наличие разных проблем. Вообще, попытка прикрутить CSP туда, где его изначально не было как правило оказывается крайне болезненной и не очень жизнеспособной.
Ещё вроде бы Stackless Python, но я не уверен, готово ли оно к использованию — как ни гляну в ту сторону, вечно натыкаюсь на описания каких-то проблем с использованием stackless в реальных проектах. Опять же, теоретически для Perl есть модуль Coro, но практически та же фигня, что и с Python — попытка выяснить, насколько хорошо оно работает за пределами того проекта под который он писался показывает исключительно наличие разных проблем. Вообще, попытка прикрутить CSP туда, где его изначально не было как правило оказывается крайне болезненной и не очень жизнеспособной.
UFO just landed and posted this here
К сожалению, знаком с CSP исключительно по википедии и «научно-популярным» заметкам, так что тему поддержать не смогу. Формально это сделать можно, все инструменты в языке есть, в том числе, чтобы и держать за вас в голове нюансы ( в отличие от С++ ). Как это сделать технически — ни малейших идей, как уже говорил, слишком мало знаю про CSP.
Вполне возможно, что тут вы абсолютно правы.
Вполне возможно, что тут вы абсолютно правы.
UFO just landed and posted this here
D может подсчитать сколько нужно стековой памяти на этапе компиляции, если использовать самописные compile-time врапперы при объявлении переменных. Если добавить пару до сих пор не востребованных __traits в компилятор — можно и просто так.
Шаблонов будет, конечно, кромешный ад, но это проблемы автора библиотеки :)
Шаблонов будет, конечно, кромешный ад, но это проблемы автора библиотеки :)
Утрируя такой подход можно говорить, что все тьюринг-полные языки одинаковы. Конечно D ничем не мощнее С++ или джавы, но он существенно выразительнее.
Но даже это не главное. Главное — он потрясающе продуман. Уделено огромное внимание мелочам. Именно это в первую очередь я пытаюсь донести своими статьями. Тот же mixin — мелочь, но вы не представляете сколько кода он позволяет элементарно убрать в связке с CTFE.
Я как раз готовлю статью в которой продолжение темы вроде бы мелочей, но очень удобных, добавляющих выразительности и потрясающе круто работающих вместе.
Но даже это не главное. Главное — он потрясающе продуман. Уделено огромное внимание мелочам. Именно это в первую очередь я пытаюсь донести своими статьями. Тот же mixin — мелочь, но вы не представляете сколько кода он позволяет элементарно убрать в связке с CTFE.
Я как раз готовлю статью в которой продолжение темы вроде бы мелочей, но очень удобных, добавляющих выразительности и потрясающе круто работающих вместе.
Есть одно не шибко полноценное сравнение с языком Rust versusit.ru/rust-vs-d может будет интересно, но скорее в плане синтаксиса, чем реальных задач, правда версия какая-то Rust древняя была взята.
Ну а так лучше спросить на самом dlang.ru там было пару человек, которые в продакшене язык использовали.
Ну а так лучше спросить на самом dlang.ru там было пару человек, которые в продакшене язык использовали.
Разве есть такое слово «страньше»?
Спасибо за хорошее дополнение к моим статьям!
Очень приятно, что потихоньку получается продвинуть в массы этот замечательный язык.
Очень приятно, что потихоньку получается продвинуть в массы этот замечательный язык.
Может, у меня не совсем современные данные, но в книжке Александреску где-то написано, что как раз динамическое выделение памяти CTFE не поддерживает (пока). Вероятно, в последнее время это доделали, но на всякий случай надо бы проверить.
ЕМНИП, вот в этом коммите: github.com/D-Programming-Language/d-programming-language.org/pull/21
Я когда писал статью проверял, на базовых типах точно работает. malloc, конечно, не выйдет использовать, но работать с ассоциативными массивами и генерацией строк — вполне.
Я когда писал статью проверял, на базовых типах точно работает. malloc, конечно, не выйдет использовать, но работать с ассоциативными массивами и генерацией строк — вполне.
D вообще очень интересный язык: с одной стороны, у него удобный («сладкий») синтаксис, включая ООП, строки, массивы и прочие радости из коробки (минуcы: есть сборщик мусора), с другой стороны, он строго типизируемый и компилируемый, что означает во-первых, более высокое качество кода, во-вторых, большую скорость выполнения в сравнении с Java, Javascript, Python, Ruby, PHP, дотнетом и прочими модными современными языками. А, еще он позволяет подключать C-библиотеки.
Жаль, что пока нет первопроходцев (как 37 signals когда-то раскрутили Руби), которые бы привлекли внимание к этому несомненно перспективному языку. Ведь на нем можно писать более быстрые веб-приложения (в отличие от скриптовых языков), и более памятеэкономные десктопные приложения (в сравнении с тяжелыми и неуклюжими явой и дотнетом).
Жаль, что пока нет первопроходцев (как 37 signals когда-то раскрутили Руби), которые бы привлекли внимание к этому несомненно перспективному языку. Ведь на нем можно писать более быстрые веб-приложения (в отличие от скриптовых языков), и более памятеэкономные десктопные приложения (в сравнении с тяжелыми и неуклюжими явой и дотнетом).
GC — не минус. 99% времени от него нет проблем с производительностью, а если у вас критическое в этом плане место в D вы можете пользоваться неуправляемой кучей (и прочей стандартной библиотекой) C.
Должен признать, что в текущей имплементации с этим есть некоторые проблемы, т.к., например встроенные ассоциативные массивы при отключении GC становятся неюзабельны ( память течёт ), стандартная библиотека D тоже к этому не очень готова. В итоге, по сути, идёт возврат к С, а не С++. На эту тему велись ожесточённые споры, не знаю, к какому решению пришли в итоге.
Это чтобы не обвиняли в крушении ожиданий :)
Это чтобы не обвиняли в крушении ожиданий :)
Ну по-моему, как раз возврат к C++ существенно уступает возврату к C. Раз уж надо копошиться в машине вручную — так делай вручную. С++ — это некоторая полумера все-таки. И вообще, разработчики честно предупреждают же, что если уж пользуетесь, то корректность работы с памятью на вашей совести.
Кстати, в области веб-программирования D очень интересен, я немножко экспериментирую с разными набросками на эту тему. Увы, основная работа пока не даёт времени на попытаться сделать что-то конкретное, но именно за счёт метапрограммирования можно радикально изменить подход к добавлению контента, статически генерируя сервер специализированный конкретными данными. Но это так, из области любопытных мечтаний, на статью пока не тянет :)
// pure, nothrow и in тут, конечно, не обязательны, но нужно же привыкать к правилам хорошего тона :)
Кстати об этом — double[int] тоже не обязательно :)
Можно ограничиться:
auto precompute_sqrt_lookup(int from,int to )
И еще хочу добавить, вы забыли одну приятную для программистов на С/С++ особенность.
С помощью string mixin D можно имитировать широко известное выражение:
#include «file.h»
Делается это таким вот образом:
mixin(import(«file.h»));
Так что, если вы любитель сложностей или просто очень скрытны, можно выносить секретные константы, функции и даже классы в отдельные файлы.
Замечу, что таким образом удобно делать всякие настройки для ./configure
С помощью string mixin D можно имитировать широко известное выражение:
#include «file.h»
Делается это таким вот образом:
mixin(import(«file.h»));
Так что, если вы любитель сложностей или просто очень скрытны, можно выносить секретные константы, функции и даже классы в отдельные файлы.
Замечу, что таким образом удобно делать всякие настройки для ./configure
«Не так давно Monnoroch опубликовал несколько прекрасных вступительных статей по языку D2».
Вообще-то D, а не D2. Не выдумывайте, пожалуйста.
Вообще-то D, а не D2. Не выдумывайте, пожалуйста.
Вообще-то даже на newsgroup его называют D2, если из контекста не ясно, о какой из версий идёт речь.
Различия слишком велики, чтобы называть и то, и то просто D. Говорить же «язык D второй версии» — громоздко.
Различия слишком велики, чтобы называть и то, и то просто D. Говорить же «язык D второй версии» — громоздко.
Оба варианта верны. Я использую «D» потому, что «D2» говорить неудобно, но формально все верно, статьи именно о второй версии языка. Это как C++98 и C++11, никто так не говорит, но это все равно верно.
Sign up to leave a comment.
Язык D2 и метапрограммирование: всё страньше и страньше