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

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

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

Когда же вы, любители мертвых языков, наконец поймете, что в языке важнее всего не красота, правильные парадигмы или еще что-то невероятно полезное с точки зрения разработчика, а предсказуемость развития и поддержка. Язык может быть каким угодно красивым, правильным и т.д. но совершенно не предсказуемым, как D и посему недопустимым к использованию в подавляющем большинстве проектов, за редким исключением. Под редкое исключение попадают те проекты, где Сам Автор (как же я рад что он D, а не C++ увлекается в первую очередь) доступен на постоянной основе, т.е. в Фэйсбчке, да и все на этом.

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

KP>Когда же вы, любители мертвых языков, наконец поймете, что в языке важнее всего не красота, правильные парадигмы или еще что-то невероятно полезное с точки зрения разработчика, а предсказуемость развития и поддержка. Язык может быть каким угодно красивым, правильным и т.д. но совершенно не предсказуемым, как D и посему недопустимым к использованию в подавляющем большинстве проектов, за редким исключением. Под редкое исключение попадают те проекты, где Сам Автор (как же я рад что он D, а не C++ увлекается в первую очередь) доступен на постоянной основе, т.е. в Фэйсбчке, да и все на этом.

В языке прекрасна именно его эстетическая ценность. А на работе все равно писать приходится на том, на чем пишет команда (а это нередко десятки, если не сотни человек).

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

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

Ну, такие языки можно пересчитать по пальцам одной руки. Остальные языки не нужны?
Тот же Rust в настоящее время не живее D, и взлетит ли он — неизвестно.

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

ARK>Ну, такие языки можно пересчитать по пальцам одной руки. Остальные языки не нужны?

Ничего подобного. Подобных языков очень и очень много: C++, Java, C#, Python, Ruby, Scala, Erlang, Objective-C, Haskell, Clojure. Честно говоря, еще долго можно перечислять.

ARK>Тот же Rust в настоящее время не живее D, и взлетит ли он — неизвестно.

В настоящее время, язык которому 4 года не живее языка которому 13 лет. Это реально "достижение" со стороны D, т.к. за 13 лет уж можно было бы родить что-то применимое для промышленного использования или перестать насиловать труп.
Вероятность взлета выше по одной простой причине. D пишут потому, что Александреску интересно. Rust пишут потому, что Мозилле и Самсунгу он нужен в их проектах. Разница заметна?

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

XC>В языке прекрасна именно его эстетическая ценность. А на работе все равно писать приходится на том, на чем пишет команда (а это нередко десятки, если не сотни человек).

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

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

KP>Ничего подобного. Подобных языков очень и очень много: C++, Java, C#, Python, Ruby, Scala, Erlang, Objective-C, Haskell, Clojure. Честно говоря, еще долго можно перечислять.

Scala, Clojure, Haskell и Erlang из этого списка надо убрать. В Scala чуть ли не в каждом релизе компилятора ломающие изменения, Haskell развивается непредсказуемо, Clojure мертвый. Поддержка у всех тоже швах.
Erlang — нишевой язык, не является general purpose language.

В действительности, из более-менее стабильных и поддерживаемых языков общего назначения — C, C++, Objective-C, C#, Java, Ruby, Python. С большой натяжкой Ada и Go. Вроде все.

KP>В настоящее время, язык которому 4 года не живее языка которому 13 лет. Это реально "достижение" со стороны D, т.к. за 13 лет уж можно было бы родить что-то применимое для промышленного использования или перестать насиловать труп.

Ну, Python тоже долго не взлетал, насколько я помню.

KP>Вероятность взлета выше по одной простой причине. D пишут потому, что Александреску интересно. Rust пишут потому, что Мозилле и Самсунгу он нужен в их проектах. Разница заметна?

Да, согласен, что вероятность взлета выше. Но в истории есть случаи, когда и в таких ситуациях не взлетало.

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

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

Ну мы же здесь на форуме "философия программирования", а не на форуме "экономика программирования". Я рассматриваю это именно как интересную тему для обсуждения фич языков. А "взлетит/не взлетит" конкретный язык — какая разница? Все проекты открытые, если к примеру народу понравится какая-то фича в том же D, что мешает силами сообщества перенести ее в Rust или даже в C++?
Люди пишут reactos, haiku, colibri, вряд ли это можно рассматривать как коммерческие проекты, но пишут же. Да тот же linux пишут не только корпорации, но и простые программисты.

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

XC>Ну мы же здесь на форуме "философия программирования", а не на форуме "экономика программирования". Я рассматриваю это именно как интересную тему для обсуждения фич языков. А "взлетит/не взлетит" конкретный язык — какая разница? Все проекты открытые, если к примеру народу понравится какая-то фича в том же D, что мешает силами сообщества перенести ее в Rust или даже в C++?

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

XC>Люди пишут reactos, haiku, colibri, вряд ли это можно рассматривать как коммерческие проекты, но пишут же. Да тот же linux пишут не только корпорации, но и простые программисты.

Да и Brainfuck кто-то написал

Здравствуйте, alex_public, Вы писали:
Пользуясь случаем, хочу спросить про строки в D. Смущает, что как-то много вариантов есть. С обычными строками всё понятно, но ещё есть:

auto s1 = r"raw string\n\r";
auto s2 = `raw string\n\r`;

Ну тут ещё ладно, в документации даётся пояснение:

The ` character is not available on some keyboards and the font rendering of it is sometimes indistinguishable from the regular ' character. Since, however, the ` is rarely used, it is useful to delineate strings with " in them.

Впрочем, это довольно странно. Зачем было вводить второй вариант вообще? Да и раз не особо ломающих изменений боятся — убрали бы лишнюю сущность. Или хотя бы депрекейтед объявили.

Плюс строки с "особыми разделителями", список которых, впрочем, жестко задан ('[', '(', '<', '{'):

 
auto s3 =  q"(raw string\n\r)";
auto s4 =  q"[raw string\n\r]";
auto s5 =  q"<raw string\n\r>";
auto s6 =  q"{raw string\n\r}";
auto s7 =  q"|raw string\n\r|"; // По идее, это не разрешено. Но работает.

Причём разделители могут быть вложены, что мне тоже кажется не сильно полезным.

Ну и наконец произвольные разделители-ограничители:

auto s8 = q"EOS
raw string\n\r
EOS";

Причём записать в одну строчку нельзя. Имхо, плюсовый вариант получился как-то логичнее и удачнее, пусть и появился "недавно":

auto s = R"EOS(raw string\n\r)EOS"

Я что-то упускаю и в этом многообразии есть смысл?

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

DE>Причём записать в одну строчку нельзя. Имхо, плюсовый вариант получился как-то логичнее и удачнее, пусть и появился "недавно":
DE>

DE>auto s = R"EOS(raw string\n\r)EOS"
DE>

DE>Я что-то упускаю и в этом многообразии есть смысл?

Скорее всего, в данном случае разработчики стандарта С++ смотрели на ошибки дизайна D, а не наоборот.

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

KP>Когда же вы, любители мертвых языков, наконец поймете, что в языке важнее всего не красота, правильные парадигмы или еще что-то невероятно полезное с точки зрения разработчика, а предсказуемость развития и поддержка. Язык может быть каким угодно красивым, правильным и т.д. но совершенно не предсказуемым, как D и посему недопустимым к использованию в подавляющем большинстве проектов, за редким исключением. Под редкое исключение попадают те проекты, где Сам Автор (как же я рад что он D, а не C++ увлекается в первую очередь) доступен на постоянной основе, т.е. в Фэйсбчке, да и все на этом.

1. Вообще то это всё оффтопик в данной теме — она про красоту и эффективность кода, а не про подобные вопросы.
2. Если говорить о проблемах языка вообще, то у D их действительно не мало. И главные как раз не в вышеописанном, а в отсутствие некоторых библиотек и инструментов (типа полноценной интеграции в ключевые IDE).
3. Если же говорить о "непредсказуемости развития", то например мы используем D в пробном проекте уже почти год и не наткнулись ни на одно ломающее изменение (и это при использование некоторые жирные библиотеки на D, т.е. объём кода очень солидный), хотя стараемся использовать последнюю версию компилятора.

Ну и возвращаясь к теме — можно увидеть пример кода с подобной функциональностью и быстродействием на не "мёртвом языке"?

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

_>1. Вообще то это всё оффтопик в данной теме — она про красоту и эффективность кода, а не про подобные вопросы.

В чем красота? C++11/14 дает не менее красивый код Ну а по эффективности, думаю ты и сам понимаешь что тут мерить с плюсами бессмысленно.

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

О, а можно поподробнее? Некрофилов нужно знать в лицо, а то вдруг занесет ненароком, а таааам...

_>Ну и возвращаясь к теме — можно увидеть пример кода с подобной функциональностью и быстродействием на не "мёртвом языке"?

Где код на C++11/14 искать знаешь?

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

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

_>>1. Вообще то это всё оффтопик в данной теме — она про красоту и эффективность кода, а не про подобные вопросы.

KP>В чем красота? C++11/14 дает не менее красивый код Ну а по эффективности, думаю ты и сам понимаешь что тут мерить с плюсами бессмысленно.
В том-то и проблема, что ++ такими темпами попер в развитии, оставаясь языком, в котором _легко_ просчитать вплоть до инструкции, что куда скомпилируется, что будущее дей, грусти и гоев выглядит весьма и весьма безрадостным.

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

DE>Пользуясь случаем, хочу спросить про строки в D. Смущает, что как-то много вариантов есть.

Хыхы, а тут ещё и не все варианты перечислены. )))

DE> С обычными строками всё понятно, но ещё есть:
DE>

DE>auto s1 = r"raw string\n\r";
DE>auto s2 = `raw string\n\r`;
DE>

DE>Ну тут ещё ладно, в документации даётся пояснение:

DE>The ` character is not available on some keyboards and the font rendering of it is sometimes indistinguishable from the regular ' character. Since, however, the ` is rarely used, it is useful to delineate strings with " in them.

Впрочем, это довольно странно. Зачем было вводить второй вариант вообще? Да и раз не особо ломающих изменений боятся — убрали бы лишнюю сущность. Или хотя бы депрекейтед объявили.

Ну как раз иметь два вида строк с разными кавычками — это вполне удобно. Такое я уже видел в разных языках и вполне удачно используется. Правда тогда и r"" вводить не было смысла. Но тут ещё есть варианты совместимости с C/C++, да и вот вышеуказанные причины... В целом тут действительно видится излишество.

DE>Плюс строки с "особыми разделителями", список которых, впрочем, жестко задан ('[', '(', '<', '{'):
DE>

 
DE>auto s3 =  q"(raw string\n\r)";
DE>auto s4 =  q"[raw string\n\r]";
DE>auto s5 =  q"<raw string\n\r>";
DE>auto s6 =  q"{raw string\n\r}";
DE>auto s7 =  q"|raw string\n\r|"; // По идее, это не разрешено. Но работает.
DE>

DE>Причём разделители могут быть вложены, что мне тоже кажется не сильно полезным.

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

DE>Ну и наконец произвольные разделители-ограничители:
DE>

DE>auto s8 = q"EOS
DE>raw string\n\r
DE>EOS";
DE>

DE>Причём записать в одну строчку нельзя. Имхо, плюсовый вариант получился как-то логичнее и удачнее, пусть и появился "недавно":
DE>

DE>auto s = R"EOS(raw string\n\r)EOS"
DE>

Вариант с произвольным разделителем полезен для задания произвольного текста (в котором может встретится что-то вроде )"). Довольно специфическая вещь, но опять же есть во многих языках. В целом это выглядит как единая вещь с предыдущим пунктом. Насчёт сравнения с C++ — ну не знаю. Если честно, я произвольные разделители вообще не использовал ни разу. А вот вариант записи просто row строк как раз в D удобнее.

DE>Я что-то упускаю и в этом многообразии есть смысл?

В большей части этого действительно есть смысл. Но и подкорректировать есть что. Я бы всё же несколько подсократил разнообразие, при сохранение всех возможностей.

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

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

KP>В чем красота? C++11/14 дает не менее красивый код Ну а по эффективности, думаю ты и сам понимаешь что тут мерить с плюсами бессмысленно.

А ты точно внимательно смотрел на код в той статье? Лично я как раз специалист в C++ (гораздо больший чем в D) и я прекрасно вижу, что значительную часть того кода повторить на C++ просто невозможно. Т.е. я безусловно могу написать на C++ графическую библиотеку с той же итоговой функциональностью и быстродействием, но объём и выразительность кода этой библиотеки будет несравнима с этим вариантом на D.

KP>О, а можно поподробнее? Некрофилов нужно знать в лицо, а то вдруг занесет ненароком, а таааам...

Что поподробнее? )

KP>Где код на C++11/14 искать знаешь?

Подобный тому что в статье? ) Не знаю. )

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

_>А ты точно внимательно смотрел на код в той статье? Лично я как раз специалист в C++ (гораздо больший чем в D) и я прекрасно вижу, что значительную часть того кода повторить на C++ просто невозможно. Т.е. я безусловно могу написать на C++ графическую библиотеку с той же итоговой функциональностью и быстродействием, но объём и выразительность кода этой библиотеки будет несравнима с этим вариантом на D.

Внимательно. Не впечатляет. Ну код, ну не очень много его. И главный вопрос: и что с того?!

KP>>О, а можно поподробнее? Некрофилов нужно знать в лицо, а то вдруг занесет ненароком, а таааам...
_>Что поподробнее? )

Название компании в РФ где применяют D в проектах. Ты же явно не в Фэйсбучике.

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

KP>Внимательно. Не впечатляет. Ну код, ну не очень много его. И главный вопрос: и что с того?!

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

KP>Название компании в РФ где применяют D в проектах. Ты же явно не в Фэйсбучике.

Ну мы не то чтобы применяем на практике, а как раз запустили тестовый проект (который ведёт стажёр), чтобы понять можно ли применять D на практике или нет. Ну и за одно попрактиковаться в нём. Причём проектик этот даже не в нашей основной области (которая довольно специфическая), а так сказать в более приземлённой и доступной для быстрого и недорого одиночного коммерческого запуска в случае успеха. Реализуется всё на базе этого http://vibed.org фреймворка и пока что результаты можно сказать восхитительные — дохленький vds спокойно тянет нагрузку, которую при классической архитектуре потянуло бы только облако с ценой раз в 10 больше.

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

_>Реализуется всё на базе этого http://vibed.org фреймворка и пока что результаты можно сказать восхитительные — дохленький vds спокойно тянет нагрузку, которую при классической архитектуре потянуло бы только облако с ценой раз в 10 больше.
Чем это лучше других языков с зелёными потоками? От C++ с boost.coroutine до Go, Rust и Python?

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

_> Реализуется всё на базе этого http://vibed.org фреймворка и пока что результаты можно сказать восхитительные — дохленький vds спокойно тянет нагрузку, которую при классической архитектуре потянуло бы только облако с ценой раз в 10 больше.

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