D vs C++ , почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?

Цитата applegame @ 27.10.15, 15:19

Цитата Flex Ferrum @ 27.10.15, 08:19

Ну ты же понимаешь, что при желании всё это можно сделать и на C++.

Интересно как можно compile-time посчитать длину строки передаваемой как параметр функции, которая парсит соответствующий json-объект?

template<size_t N>
json_value operator[](const char (&ch)[N]);

Цитата MyNameIsIgor @ 27.10.15, 15:23

template<size_t N>
json_value operator[](const char (&ch)[N]);

Круто, подзабыл я плюсы. А есть возможность из этой функции передать эту строку дальше?

Исправьте, если не затруднит:
http://ideone.com/MuFqEk

Цитата applegame @ 27.10.15, 18:20

Исправьте, если не затруднит:

Я вот об этом уже говорил

calc<sum<N>(ch)>

Не получится аргумент функции запихнуть в шаблон.

Цитата MyNameIsIgor @ 27.10.15, 19:21

Не получится аргумент функции запихнуть в шаблон.

В том то и дело, даже несмотря на то что этот аргумент по идее известен compile-time. В D параметром шаблона может быть не только строка, но и любой символ включая переменную или функцию:
http://dpaste.dzfl.pl/f3c84b792ae3

import std.stdio;
 
void calc(alias something)(int a) {
    writeln(something + a);
}
 
void calc2(alias something1, alias something2)() {
    writeln(something1 + something2);
}
 
int fun() {
    return 10;
}
 
void main() {
    int var = 10;
    calc!var(20);
    calc!fun(20);
    calc2!(var, fun);
}

Цитата applegame @ 27.10.15, 20:44

В том то и дело, даже несмотря на то что этот аргумент по идее известен compile-time

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

constexpr type foo(bool b) { /* implementation */ }

сделать так, чтобы type менялся в зависимости от истинности b, не решаема - это сделает типизацию динамической, т.к. эта же функция должна работать и во время исполнения.

Цитата applegame @ 27.10.15, 20:44

В D параметром шаблона может быть не только строка, но и любой символ включая переменную или функцию

Угу, читал. Как я уже говорил, метапрограммирование в новом языке (тем более исполняющем код во время компиляции) надо было делать совсем не так, как в D. Потому подобные факты не только не агитируют меня в пользу D, а вызывают отвращение. К сожалению, Александреску не смог осилить ничего, кроме шаблонов.

Сообщение отредактировано: MyNameIsIgor - 27.10.15, 21:05

Цитата MyNameIsIgor @ 27.10.15, 21:05

Угу, читал. Как я уже говорил, метапрограммирование в новом языке (тем более исполняющем код во время компиляции) надо было делать совсем не так, как в D

А как надо было?

Сообщение отредактировано: applegame - 28.10.15, 13:20

Цитата applegame @ 28.10.15, 13:13

Цитата MyNameIsIgor @ 27.10.15, 21:05

Угу, читал. Как я уже говорил, метапрограммирование в новом языке (тем более исполняющем код во время компиляции) надо было делать совсем не так, как в D

А как?

Дать доступ к AST, возможность его обходить, конструировать. Как во время компиляции, так и во время исполнения. Как в Nemerle.
В том же C# (.NET) есть такая возможность, но только во время исполнения. Во многом на этом работает LINQ.

Цитата MyNameIsIgor @ 28.10.15, 13:16

Дать доступ к AST, возможность его обходить, конструировать. Как во время компиляции, так и во время исполнения. Как в Nemerle.
В том же C# (.NET) есть такая возможность, но только во время исполнения. Во многом на этом работает LINQ.

А как это связано с шаблонами и прочей уже реализованной метапрограммируемой фигней в D? Доступ к AST и гигиеничные макросы могут добавить, и что, после этого отвращение исчезнет?

Сообщение отредактировано: applegame - 28.10.15, 13:24

Цитата applegame @ 28.10.15, 13:23

А как это связано с шаблонами и прочей уже реализованной метапрограммируемой фигней в D? Доступ к AST и гигиеничные макросы могут добавить, и что, после этого отвращение исчезнет?

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

Цитата MyNameIsIgor @ 28.10.15, 13:27

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

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

WAT

WAT.

LINQ можно успешно реализовать и без макросов. Нечто похожее - http://code.dlang.org/packages/dquery.

Что касается Nemerle, то там действительно много интересных фич (после изучения Haskell это стало особо ясно), но у меня вызывает отвращение .NET/Mono. Поэтому Nemerle сразу был исключен мною из кандидатов на следующий проект.

В целом после реального опыта использования D в коммерческом продакшн проекте, могу сказать следующее:

- D полон крайне раздражающих косяков (в том числе и в дизайне языка) и недоделок. Настолько, что иногда хочется его бросить.
- Сборщик мусора сильно упрощает написание кода, но работает он не лучшим образом, из-за чего многие библиотеки избегают его, некоторые совсем не используют.
- Возвращаться на C++ не получается. C++ после D кажется очень неуклюжим и уродливым.
- Недурно показал себя в разработке web-сервисов, пишется легко, как на каком-нибудь Python или Ruby, но многие ошибки отсекаются compile-time.
- Писать на D легко и приятно, пока не столкнешься с неведомой грёбаной фигнёй и не потратишь на ее решение полдня.
- Быстро развивается, отзывчивое и активное коммьюниьти.

Буду ли я дальше писать на D? Не уверен если честно. Скорее всего буду писать пока не найду приемлемую для меня альтернативу.
Язык должен быть компилируемым, без использования виртуальных машин (кроме LLVM, которая не совсем виртуальная машина) и с автоматическим выведением типов.
Пока погладываю на Rust, Crystal и Nim. Crystal кажется очень интересным, но пока не напишешь чего-нибудь не поймешь.

Сообщение отредактировано: applegame - 28.10.15, 14:28

Цитата applegame @ 28.10.15, 14:27

Макросы заметно сложнее, чем шаблоны, поэтому (со слов знакомых) используются редко в небиблиотечном коде.

Цитата applegame @ 28.10.15, 14:27

LINQ можно успешно реализовать и без макросов.

Он и реализован без макросов

Цитата applegame @ 28.10.15, 14:27

Что касается Nemerle, то там действительно много интересных фич (после изучения Haskell это стало особо ясно), но у меня вызывает отвращение .NET/Mono. Поэтому Nemerle сразу был исключен мною из кандидатов на следующий проект.

Я и не рекомендовал Nemerle. Но его основные достоинства вовсе не функциональщина, а метапрограммирование.

Цитата applegame @ 28.10.15, 14:27

В целом после реального опыта использования D в коммерческом продакшн проекте, могу сказать следующее

А я вот не стал его использовать. Когда-то возлагал на него надежды, но он разочаровал. Язык пытается объять необъятное, противоречив. В качестве конкурента C/C++ себя не оправдал, т.к. не следует принципу нулевой стоимости.
В этом смысле пока что лучше всех выглядит Rust, Go слишком примитивен, остальные просто маргинальные.

Цитата MyNameIsIgor @ 28.10.15, 14:50

Язык пытается объять необъятное, противоречив.

Верно подмечено, так и есть.

Цитата MyNameIsIgor @ 28.10.15, 14:50

В этом смысле пока что лучше всех выглядит Rust

Отпугивает отсутствие исключений и обилие unwrap().

Добавлено 28.10.15, 15:18

Цитата MyNameIsIgor @ 28.10.15, 14:50

В качестве конкурента C/C++ себя не оправдал, т.к. не следует принципу нулевой стоимости.

Это о "принцип абстракции с нулевой стоимостью"? Сборщик мусора нарушает этот принцип?

Цитата applegame @ 28.10.15, 15:15

Это о "принцип абстракции с нулевой стоимостью"? Сборщик мусора нарушает этот принцип?

Это "не плачу за то, чего не использую". Как я понимаю, на практике полностью отключить сборку мусора в D нереально.

Сообщение отредактировано: MyNameIsIgor - 28.10.15, 15:24

Цитата applegame @ 28.10.15, 14:27

Кроме того слишком гибкие макросы - прямой путь к

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

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

К сожалению, я не знаю перспективных языков, претендующих на нишу С++, с действительно хорошим метапрограммированием (уровня Nemerle). Rast хоть и нравится в целом, но имеет в этом отношении немало проблем.

Цитата applegame @ 28.10.15, 15:15

Отпугивает отсутствие исключений и обилие unwrap().

Обилие unwrap - это фича. А вот с исключениями и правда досадно, тем более, что их "нет" исключительно из-за упрямства. В том смысле, что в языке имеется всё необходимое кроме сахара для удобной обработки.

Сообщение отредактировано: DarkEld3r - 28.10.15, 15:29

Цитата MyNameIsIgor @ 28.10.15, 15:20

Как я понимаю, на практике полностью отключить сборку мусора в D нереально.

Реально. Но придется отказаться от многих встроенных приятных вещей и от половины стандартной библиотеки. Тем не менее есть либы совсем не использующие GC.
Развитие D похоже на тыкания слепого котенка в разные углы. Не прошло и 10 лет, как создатели языка таки убедились, что этот ваш GC далеко не всегда кошерен, а чаще всего нафик не нужен. И что именно GC - главный аспект, из-за которого плюсовики не желают перелезать на D.
Сейчас основное развитие языка идет в направлении отключения GC везде, где это возможно.
Ввели очередной атрибут @nogc, помеченный им код гарантированно не используют GC (проверятся компилятором).
Александреску написал целую либу самых разных аллокаторов выстроенных в иерархию и способных строится в цепочки и собирается писать либу контейнеров с использованием этих самых аллокаторов.
Также разработали концепцию опциональной поддержку RC (на уровне языка) для классов и планируют ее запилить.

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

P.S. Александреску может и дурно повлиял на развитие языка, но надо отдать ему должное - он открыт для диалога (так же как и Брайт) и не страдает бессмысленным упрямством.

Добавлено 28.10.15, 15:52

Цитата DarkEld3r @ 28.10.15, 15:27

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

Ну D-шные шаблоны вполне читаемы. Макросы мне представляются тяжелой артиллерией для каких-то особо сложных случаев. Можно ли вообще отказаться от шаблонов/дженериков в пользу макросов?

Цитата DarkEld3r @ 28.10.15, 15:27

Обилие unwrap - это фича. А вот с исключениями и правда досадно, тем более, что их "нет" исключительно из-за упрямства. В том смысле, что в языке имеется всё необходимое кроме сахара для удобной обработки.

Странная какая-то фича, и, насколько я понял, это обилие unwrap() как раз и есть следствие отсутствия исключений, нет?

Сообщение отредактировано: Qraizer - 28.10.15, 16:40