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

_>В соседней темке идёт длинная вялотекущая дискуссия на тему сочетания одновременной красоты (удобности, корректности и т.п. субъективных понятий) кода и его быстродействия. В контексте сравнения различных парадигм, а так же сравнения мультипарадигменных языков с так сказать чистыми. Кстати, забавно (см. ниже), что при этом упоминался язык D и рассматривались примеры с обработкой изображений. Ну и лично моя позиция всегда заключалась в том, что будущее за мультипарадигменными языками, которые впитают в себя всё лучшее.

_>Так вот, на днях я натолкнулся на эту http://habrahabr.ru/post/218429/ замечательную статью и хочу поделиться ею с вами. Очень советую внимательно посмотреть на примеры кода там — на мой взгляд это как раз код максимально в стиле языка D (который ярко выраженный мультипарадигменный). Здесь взято всё лучшее из функциональной и императивной парадигмы и щедро приправлено сверху метапрограммированием. В итоге получился очень красивый, удобный, строгий код, который при этом является ещё и очень быстродействующим.

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

Что отсутствует в языке D
Совместимость с исходным кодом на языке C. Уже существуют языки программирования, в полной мере или практически полностью совместимые с исходным кодом, написанным на языке C (Objective-C, C++ и Vala). Авторы посчитали, что дальнейшая работа в этом направлении препятствует реализации существенных возможностей. Однако они постарались не допускать нестандартного поведения заимствованых из C операторов, которое может приводить к трудно исправляемым ошибкам.
Препроцессор[13]. Включение файлов посредством #include заменено на модули с собственным пространством имён. Неструктурированные директивы типа #ifdef заменены на структурированные блоки version и debug.[14] Выполнение кода во время компиляции, включение любых константных выражений, а также чтение файлов во время компиляции могут в большинстве случаев эмулировать макро-язык C с большей надёжностью (тем не менее, некоторые возможности C утрачены, например, нельзя написать аналог #define TEXT(quotes) L ## quotes), а также открывают множество дополнительных возможностей, например перевод кода другого языка программирования в D «прямо во время компиляции».
Множественное наследование. Однако это частично компенсируется более надёжными интерфейсами, работа с которыми поддерживается языком D.
Пространства имён (namespaces). Пространства имён были попыткой решить проблему, возникающую при объединении разработанных независимо друг от друга кусков кода, когда пересекаются имена переменных, типов данных и так далее. Модульный подход выглядит проще и удобнее для использования.
Битовые поля (bit fields) произвольного размера. Битовые поля сложны, неэффективны и достаточно редко используются. Компенсируется модулем в стандартной библиотеке D 2.0[15]
Поддержка 16-битных компьютеров. В языке D нет никаких решений для генерирования качественного 16-битного кода.
Взаимная зависимость проходов компилирования (compiler passes). В языке C++ успешная обработка исходного кода основывается на таблице символов (symbol table) и различных командах препроцессора. Это делает невозможным предварительную обработку кода и значительно усложняет работу анализаторов кода.
Оператор разыменования с обращением к члену класса ->. В языке D оператор обращения к члену класса производит разыменование по умолчанию при необходимости.

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

Я сравнил результат работы с эквивалентной командой ImageMagick:
convert \
input/*.bmp \
-depth 16 \
-gamma 0.454545 \
-filter box \
-resize 25% \
-gamma 2.2 \
-depth 8 \
output-im/%02d.bmp
Версия на D выполняется в 4-5 разра быстрее. Конечно, это нечестное сравнение: даже если обе используют 16-битную глубину цвета, гамма коррекцию, многопоточность и оптимизированы под одинаковые архитектуры, D программа содержит код специально оптимизированный для этой задачи. Если не брать в расчет различные JIT техники, пакет нельзя сравнивать с библиотеками обработки изображений общего назначения.

Истинно правильным было бы написать такой же код на С++ и сравнить. Причём баловство с компилятором тоже играет не последнюю роль. А про маркетинг не согласен, что его нет. Язык переименовали с Марса на D, то есть как бы подмазались к C++, дескать это следующее поколение языков. Хотя опять же лично моё мнение, что выразительность языке не может заменить фазы проектирования проекта. Причём пока никакой особой выразительности не заметил, но не в этом суть. Говорят же, программируйте с помощью языка, а не на языке. Язык программирования не должен заменять мышление.

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

_> целом тут действительно видится излишество.
_> Правда опять же непонятно к чему подобное разнообразие (кстати, в коде выше это не ошибка — разделителем может служить любой одиночный знак) сделано. На мой взгляд было бы достаточно одного варианта.
_> С другой стороны подобное разнообразие не напрягает, т.к. все возможные варианты работают строго одинаково.
Вот именно, что куча вариантов, которые делают абсолютно одно и то же. По моему преимуществ тут нет, а недостаток, как минимум, лишняя сложность. Я не придираюсь, если что. Просто в С++, в основном, не нравится как раз накопившаяся гора кривостей и костылей, пусть они и оправданы из-за совместимости. А тут симпатичный язык, но постоянно всплывает какая-то фигня "в стиле С++" от которой и хотелось уйти.

_> кстати, в коде выше это не ошибка — разделителем может служить любой одиночный знак
Ну... вот тут четыре разделителя перечислены явно. А в остальном не очень ясно, что считается "подходящим символом". Буквы — нет, запятые/точки тоже. Восклицательные знак, тем не менее, таким образом использоваться может.

_>Если честно, я произвольные разделители вообще не использовал ни разу. А вот вариант записи просто row строк как раз в D удобнее.
Чем? В С++ (в этом моменте) как раз всё просто и логично:

auto s1 = R"(raw string)"; // 1
R"delimiter(raw string)delimiter" // 2

Если нужна просто raw строка — берём первый вариант. Не менее лаконично чем в D. Надо что-то более навороченное — второй. Причём он вытекает из первого, по сути, это одна конструкция. И нет 100500 отдельных правил на ровном месте.

_> Кстати, а тут ещё были пропущены шестнадцатеричные строки (типа auto s=x"00 FBCD 32FD 0A"; ) и самое интересное, строки токенов (типа auto s=q{token string}; ).
Они пропущены сознательно — это особые вещи, наличие которых понятно (и удобно).

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

C>Чем это лучше других языков с зелёными потоками? От C++ с boost.coroutine до Go, Rust и Python?

Да, действительно часть этой функциональности можно реализовать на C++ (хотя я бы наверное взял libevent/libev, чтобы писать поменьше велосипедов, правда фреймворк то в любом случае придётся в начале написать) и получить не меньшую производительность. С другими языками уже несколько сомневаюсь даже насчёт этой части. Но в любом случае это будет только часть, а самое интересное не получится даже на C++14. Я про встроенный язык шаблонов для страниц. Синтаксис там взят из известного по node.js jade'a, но при этом в качестве встроенного языка используется не JS, а полноценный D. Причём всё это в итоге статически компилируется... Т.е. имеем очень удобный и быстрый способ создания динамических страниц, который при этом автоматом даёт безумную скорость работы сервиса.

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

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

KP>Не хочу тебя расстраивать, но такое умеет даже Python с Twisted В чем плюс именно твоего решения, кроме того что оно на прекрасном D?

Хы, даже если забыть про то, что twisted покрывает только маленькую часть фич vibe.d (причём не затрагивая самое вкусное — см. моё предыдущее сообщение), в любом случае сравнение быстродействия D с Питоном выглядит несколько смешно.

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

V>

V>Что отсутствует в языке D
V>...

V>То что нет множественного наследования это очень плохо. Отговорка про надёжность интерфейса звучит очень сомнительно, так как ничто не мешает при множественном наследовании сделать один интерфейс главным, а все остальные дополнительными. Плохо, когда такой возможности в принципе нет.

С учётом того, что такое интерфейсы в D, думаю можно сказать, что множественное наследование практические есть. )))

V>

V>Я сравнил результат работы с эквивалентной командой ImageMagick:
V>...

V>Истинно правильным было бы написать такой же код на С++ и сравнить. Причём баловство с компилятором тоже играет не последнюю роль.

А прямо такой не напишешь. Ни на C++, ни на чём-то другом. А если обойтись только аналогичной функциональностью, то ImageMagick как раз на C и написана. )

V>А про маркетинг не согласен, что его нет. Язык переименовали с Марса на D, то есть как бы подмазались к C++, дескать это следующее поколение языков. Хотя опять же лично моё мнение, что выразительность языке не может заменить фазы проектирования проекта. Причём пока никакой особой выразительности не заметил, но не в этом суть. Говорят же, программируйте с помощью языка, а не на языке. Язык программирования не должен заменять мышление.

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

Насчёт проектирования я частично согласен — в первую очередь за красоту кода отвечает человек, а не язык. К примеру я видел код на языке D, написанный в классических традициях старого голого C. Однако язык может позволяет некоторые возможности просто недостижимые с помощью других инструментов. И тут D явно один из лидеров.

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

DE>Вот именно, что куча вариантов, которые делают абсолютно одно и то же. По моему преимуществ тут нет, а недостаток, как минимум, лишняя сложность. Я не придираюсь, если что. Просто в С++, в основном, не нравится как раз накопившаяся гора кривостей и костылей, пусть они и оправданы из-за совместимости. А тут симпатичный язык, но постоянно всплывает какая-то фигня "в стиле С++" от которой и хотелось уйти.

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

DE>Ну... вот тут четыре разделителя перечислены явно. А в остальном не очень ясно, что считается "подходящим символом". Буквы — нет, запятые/точки тоже. Восклицательные знак, тем не менее, таким образом использоваться может.

Это перечислены так называемые "парные разделители", а ещё могут быть не парные — просто "любой знак". Это я книжку Александреску цитирую. )

DE>Чем? В С++ (в этом моменте) как раз всё просто и логично:
DE>

DE>auto s1 = R"(raw string)"; // 1
DE>R"delimiter(raw string)delimiter" // 2
DE>

Если нужна просто raw строка — берём первый вариант. Не менее лаконично чем в D. Надо что-то более навороченное — второй. Причём он вытекает из первого, по сути, это одна конструкция. И нет 100500 отдельных правил на ровном месте.

Ну так как минимум лишние скобки. А если взять вариант `raw string` на D, то ещё и префикс лишний. T.e. в D чуть меньше синтаксического мусора, хотя конечно же это всё несущественные мелочи.

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

Можно спорить о разных аспектах языка.
Но метапрограммирование на строках это просто несерьезно.
Далее __traits выглядит как костыль, а не как нормальная работа с API компилятора.

Боюсь когда там это все осознают, придут к выводу, что надо создавать D 3.0

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

_NN>Но метапрограммирование на строках это просто несерьезно.

Почему это? Это же не какой-то аналог eval, работающий во время исполнения. Функция mixin отрабатывает во время компиляции и соответственно весь переданный строкой код:
— проходит все проверки на стадии компиляции, как и обычный код
— полностью попадает под все возможные оптимизации, включай инлайн и т.п.

Чего собственно ещё желать то? )

_NN>Далее __traits выглядит как костыль, а не как нормальная работа с API компилятора.

А тут что не так? )

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

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

_NN>>Но метапрограммирование на строках это просто несерьезно.

_>Почему это? Это же не какой-то аналог eval, работающий во время исполнения. Функция mixin отрабатывает во время компиляции и соответственно весь переданный строкой код:
_>- проходит все проверки на стадии компиляции, как и обычный код
_>- полностью попадает под все возможные оптимизации, включай инлайн и т.п.

Вот именно, что аналог eval.
Я предпочитаю работать с объектной моделью.

Т.е. обычный код во времени компиляции:

auto x = someClass.getMethods();
if(x.contains("someMethod")) someClass.addMethod(<[ void otherMethod() { } ]>);

_>Чего собственно ещё желать то? )

_NN>>Далее __traits выглядит как костыль, а не как нормальная работа с API компилятора.

_>А тут что не так? )
См. выше.

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

_NN>Вот именно, что аналог eval.
_NN>Я предпочитаю работать с объектной моделью.

_NN>Т.е. обычный код во времени компиляции:
_NN>

_NN>auto x = someClass.getMethods();
_NN>if(x.contains("someMethod")) someClass.addMethod(<[ void otherMethod() { } ]>);
_NN>

Что-то я не понял как подобное может работать во время компиляции. Т.е. вот допустим у нас есть некий класс A. И плюс где-то по коду раскиданы различные вызовы A.AddMethod(...). Так каким будет тип данных A в итоге после компиляции?

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

_>2. Если говорить о проблемах языка вообще, то у D их действительно не мало. И главные как раз не в вышеописанном, а в отсутствие некоторых библиотек и инструментов (типа полноценной интеграции в ключевые IDE).

Наоборот, главные причины это именно описаные, а отсутствие библиотек, инструментов это следствие.

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

_>С учётом того, что такое интерфейсы в D, думаю можно сказать, что множественное наследование практические есть. )))
Можно немного подробнее?

Вообще, я не считаю это серьёзным недостатком, но один момент всё-таки смущает. Возможна ведь ситуация, когда есть две никак не пересекающиеся иерархии классов, причём без интерфейсов — просто линейное наследование. И в какой-то момент нам требуется создать наследника обеих иерархий. Так как они независимы, то никаких ужасов множественного наследования не будет. Но если в самом начале никто не позаботился об интерфейсах, то в С++ мы всё-таки можем отнаследоваться. В D (а так же С# и т.д.), насколько я понимаю, придётся всё-таки вводить интерфейсы. Так?
Понятное дело, можно заявить про "кривой дизайн" и т.д. Но тем не менее, на С++ "проблема" решается, вернее её даже нет.

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

_>Да, есть такое. Но с другой стороны и C++ и D обладают известным положительным качеством — в них понапихано очень много всего, но совершенно не обязательно это всё использовать (или даже знать, хотя всё же рекомендуется) для нормальной работы.
Ну да, но шутки типа этой

Автор: Qbit86
Дата: 19.02.14

не на ровном месте возникают. Всё-таки одно дело, когда это именно разные "части" языка добавляющие дополнительные возможности (скажем, шаблоны в С++) и другое когда куча всякой фигни, которая (почти) ничего не упрощает. Похожие мысли у меня "uniform initialization" вызывает. "Есть много способов с нюансами, которые сложно запомнит" (почти цитата), поэтому сделаем ещё один.
Оно всё логично, если знать почему, но если бы не совместимость, то можно было бы проще сделать.

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

_>Что-то я не понял как подобное может работать во время компиляции. Т.е. вот допустим у нас есть некий класс A. И плюс где-то по коду раскиданы различные вызовы A.AddMethod(...). Так каким будет тип данных A в итоге после компиляции?

А в чем проблема то ?
В Nemerle/Scala это работает

Каждый макрос добавляет метод и компилятор создает класс со всему нужными методами.

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

По-моему автору(авторам) языка D не хватает критики со стороны. Уж больно похоже, что разные вещи включены в язык непродуманно, а просто потому, что авторам захотелось. Это, опять же мой взгляд со стороны. D я, можно сказать, вижу впервый раз. Кстати, не понравился синтаксис, и дело тут не в похожести или непохожести на С/C++, а в недостаточной продуманности — опять же это моё впечатление только от просмотра исходников. Всё-таки, если взять С++, там есть коммитет, то есть порядочное число людей с разными мнениями. И они всё-таки делают свою работу: новые вещи, включаемые в язык, не вызывают когнетивного диссонанса, и вписываются в старый язык органично. D же выглядит как полигон для разных идей, а ни как серьёзный, продуманный до мелочей язык программирования. Опять же это моё мнение.

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

_NN>Можно спорить о разных аспектах языка.
_NN>Но метапрограммирование на строках это просто несерьезно.

Да, с т.з. теории это полное безобразие. Авторы Ди — прожженые плюсовики-практики, слово теория им незнакомо, они сначала делают потом думают. Выходит странная штука с кучей ручек, но удивительно удобная на практике. Не в теории.

Но конкретно про метапрограммирование на строках — эта штука на крайний случай, большинство задач решаются без ее применения. Даже когда поначалу кажется, что нужно использовать ее, потом раз-раз, тут поменял, тут упростил, все свелось к сочетанию шаблонов, компайл-тайм интроспекции и static if. Не раз это испытывал на себе.

Недавний пример. Сделал себе отслеживальщик всех аллокаций в GC-куче, чтобы быть уверенным, что в нужном мне месте конпелятор не наделал неявных аллокаций под замыкания. У Дивного рантайма есть структурка с указателями на все основные функции менеджера памяти, изначально используется для возможности задействовать один GC на несколько DLL-ок. Выглядит как-то так:

struct Proxy // copied from proxy.d (d runtime)
{
    extern (C)
    {
        void function() gc_enable;
        void function() gc_disable;
        void function() gc_collect;
        void function() gc_minimize;

        uint function(void*) gc_getAttr;
        uint function(void*, uint) gc_setAttr;
        uint function(void*, uint) gc_clrAttr;

        void*   function(size_t, uint) gc_malloc;
        BlkInfo function(size_t, uint) gc_qalloc;
        void*   function(size_t, uint) gc_calloc;
        size_t  function(size_t) gc_reserve;
...
    }
}

Мне нужно сгенерить аналогичный набор функций с теми же самыми типами, где будет делаться определенное действие сначала, потом вызываться оригинальная функция из той структурки, потом делаться еще одно мое действие. Отличный повод для метапрограмминга, и полностью решается без использования строк.

Завожу структурку myProxy того же типа и генерю функции так:

    foreach(funname; __traits(allMembers, Proxy)) 
        __traits(getMember, myProxy, funname) = &genCall!funname;

где genCall — шаблон, генерящий нужную функцию по имени:

auto genCall(string funname)(FunArgsTypes!funname args) {
    действие_1;
    scope(exit) действие_2; 
    return __traits(getMember, pOrg, funname)(args);
}

где FunArgsTypes — тайп-левел функция, возвращающая типы аргументов указанной по имени функции из структуры Proxy:

template FunArgsTypes(string funname) {
    alias FunType = typeof(*__traits(getMember, myProxy, funname));
    alias FunArgsTypes = ParameterTypeTuple!FunType;
}

И все! Тип возвращаемого результата генерящихся функций тут выводится автоматически. Генерятся они посредством шаблонов, никаких манипуляций со строками. И все это в пределах одного маленького модуля, который элементарно импортируется. Никаких заморочек с раздельными стадиями компиляции.
Если не лень, можете показать, как такая задача решается в других статически типизированных языках, сравним.

_NN>Далее __traits выглядит как костыль, а не как нормальная работа с API компилятора.
_NN>Боюсь когда там это все осознают, придут к выводу, что надо создавать D 3.0

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

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

_>С другими языками уже несколько сомневаюсь даже насчёт этой части. Но в любом случае это будет только часть, а самое интересное не получится даже на C++14. Я про встроенный язык шаблонов для страниц. Синтаксис там взят из известного по node.js jade'a, но при этом в качестве встроенного языка используется не JS, а полноценный D.
JSP в Java, как и куча других *SP. Есть даже C++ Server Pages со встроенным С++.

Здравствуйте, DarkEld3r, Вы писали:
DE>Вообще, я не считаю это серьёзным недостатком, но один момент всё-таки смущает. Возможна ведь ситуация, когда есть две никак не пересекающиеся иерархии классов, причём без интерфейсов — просто линейное наследование. И в какой-то момент нам требуется создать наследника обеих иерархий.
А можно сколь-нибудь убедительный пример? На первый взгляд кажется, что такой класс-наследник нарушает всякие принципы типа SRP.
Для задач типа "давайте сделаем наш класс сериализуемым" поддержка в D есть, и значительно лучше, чем в С++.

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

_>Да, действительно часть этой функциональности можно реализовать на C++ (хотя я бы наверное взял libevent/libev, чтобы писать поменьше велосипедов, правда фреймворк то в любом случае придётся в начале написать) и получить не меньшую производительность. С другими языками уже несколько сомневаюсь даже насчёт этой части. Но в любом случае это будет только часть, а самое интересное не получится даже на C++14. Я про встроенный язык шаблонов для страниц. Синтаксис там взят из известного по node.js jade'a, но при этом в качестве встроенного языка используется не JS, а полноценный D. Причём всё это в итоге статически компилируется... Т.е. имеем очень удобный и быстрый способ создания динамических страниц, который при этом автоматом даёт безумную скорость работы сервиса.

Yet another template engine

_>Ну и ещё благодаря множеству приятных фич языка программирование реально приятное — позволяет делать разные мелочи так, как в других языках невозможно в принципе. Но это уже скорее приятный бонус, а главное всё же в той необычной архитектуре фреймворка.

Это сказки. vibe это как Node.js только на D и с меньшими возможностями.

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

I>Это сказки. vibe это как Node.js только на D и с меньшими возможностями.

Ну да, там нет callback hell, нет проблем с многопоточностью, нет тормозов, нет откладывания тупых ошибок до рантайма, и еще много чего нет.