Facebook платит за устранение багов в реализации языка программирования D

Я не имею в виду ничего особо сильного в духе Haskell.

хорошо, если у нас есть функция (пишу в синтаксисе с++)

float* transform( float* src, int array_length, float f(float) ) {
  float* dst = new float[array_length];
  for( int i=0; i<array_length; ++i) {
    dst[i] = f(src[i]);
  }
  return dst;
}

то к ней можно написать pure?

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

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

именно, оптимизатор обычно умеет переставлять циклы и условные операторы; для операций над целыми массивами надо уметь переставлять эти операции и условные операторы, что усложняет оптимизатор, поэтому естественно возникает мысль сначала перевести операции в циклы, а только затем оптимизировать

еще блиц позволяет укладывать массивы в стиле фортрана

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

... и тут мне непонятно, о чем мы, собственно, говорим

фортрановская укладка массива нужна для для того, чтобы вызывать бинарный фортановский код, если че

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

Мощности вырастут и это пройдёт.

а вот мощности батареек если и будут расти, то очень-очень медленно

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

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

Про кастомизацию HTTP body для страниц со статусами 4xx/5xx? Вообще это делается на уровне сервера через http://vibed.org/api/vibe.http.server/HTTPServerSettings.errorPageHandler . Отделение логики приложения от логики представления как бы говорит, что делать за это ответственным код API - не очень хорошо.

В целом у меня складывается ощущение, что неверно понята задача, решаемая конкретно этим модулем. Здесь не идёт речь о просто рендеринге какой-то веб-страницы, этим занимается vibe.http.server, это похоже на аналогичный код на C/C++ (+- пара магических плюшек) и это не очень интересно.

Речь идёт о сетевом сервисе, который предоставляет чистое REST API, как для AJAX-запросов, так и для каких-нибудь консольных клиентов. Что обычно получается в таком случае:

1) И рендеринг статических (non-js) страниц, и API используют одну и ту же реализацию логики. При этом для API по сути никакой дополнительной обвязки вроде рендеринга не требуется, достаточно просто регистрации маршрутов и сериализации.

2) Хочется, чтобы всё описание публичного API было сосредоточено в одном месте, чтобы новый человек мог быстро получить о нём представление.

3) Хочется иметь «из коробки» консольный клиент для всей этой радости, с хорошей гарантией синхронизации API.

4) Надоело дублировать одну и ту же информацию в куче разных мест - именах методов, строках URL, именах параметров, сериализации и т.п. Но при этом необходимо разделять представление и логику.

vibe.http.rest предназначен для удобной декларации API именно в контексте этих задач/проблем (которые выстраданы как раз таки сетевым прошлым на C++). Я выбрал его в качестве примера просто потому что, во-первых, этот модуль писал я сам и знаю каждую деталь реализации, а во-вторых, там как раз активно используется преимущество D над C++ в статической интроспекции.

Правильно читать так:

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

«Facebook считает, что Александреску уже взрослый мальчик и ему можно выделить микроскопический бюджет для шалостей. Ничего не испортит так уж точно, а польза какая может и выйти»

например, на одной странице могут быть page?action=view&foo=123&bar=baz вмете с page?action=edit&foo=123&bar=baz — это хорошо ложится именно на класс с двумя полями foo bar и двумя методами view() и edit(), а не на 2 функции view(int foo, string bar) и edit(int foo, string bar)

Это не имеет ничего общего с RESTful API. Cкорее модель для vibe.http.form

это так в хорошем языке; а на практике, в Д, как ты будешь выражать проверку «для любого f, названия аргументов метода f интерфейса и метода f реализации интерфейса совпадают»?

Зачем для любого? Для тех, что будут использованы в фреймворке:

static assert ((ParameterIdentifierTuple!method1 == ParameterIdentifierTuple!method2) && (ParameterTypeTuple!method1 == ParamaterTypeTuple!method2);

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

Другое дело, что стоило бы вообще запретить изменять имена параметров между определениями (и это обсуждалось в сообществе), но это как раз гнусное наследие C :)

то к ней можно написать pure?

В приведённом виде нельзя, так как в этом нет уверенности. В таком виде можно (изменил синтаксис на D-шный):

float[] transform( const float[] src, float function(float) pure f ) pure {
  float[] dst = new float[src.length];
  for (int i=0; i < src.length; ++i) {
    dst[i] = f(src[i]);
  }
  return dst;
}

http://dpaste.dzfl.pl/6f74ef39

Ключевым фактором тут является то, что f тоже должно быть чистой функцией. Или необходимость транизитивности для pure тоже вызывает сомнения? :)

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

Не будет, конечно. Потому что мне уже предложили 2 такие реализации: std::Vector и std::Array. Завтра примут C++14, там будет ещё одна, какой-нибудь std::Range, потому что кому-то эти две не угодили. В C++17 будет следующая, какой-нибудь std::Diapason. И получится как со строками: есть C строки, но не UTF, C++ строки (вроде бы даже с UTF теперь), а разработчики пользуются кто QT-строками, кто ещё другими велосипедами. В результате писатели сторонних либ буду использовать либо что-то одно, что им больше по душе. А те, кому важно, чтобы их поделием пользовались другие --- будут по-прежнему передавать данные через указатель и выделять/очищать память вручную.

а вот мощности батареек если и будут расти, то очень-очень медленно

Производительность на ватт растёт также, если что.

Отделение логики приложения от логики представления как бы говорит, что делать за это ответственным код API - не очень хорошо.

потому я и написал про исключения, только код API знает, что именно пошло не так, например, если запрос к БД не прошел, то можно вернуть описание ошибки

И рендеринг статических (non-js) страниц, и API используют одну и ту же реализацию логики.

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

Facebook платит за устранение багов в реализации языка программирования D (комментарий)

в том числе за счет обработки исключений

При этом для API по сути никакой дополнительной обвязки вроде рендеринга не требуется

только для очень простых случаев, и, кстати, а как у тебя обрабатываются опциональные параметры? посмотри серьезное API, например twitter, там их огромное кол-во (как и в любом серьезном API), на твоей библиотеке это будет сущий ад

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

тем более в нем нафиг не нужна логика специфичная для REST

Это не имеет ничего общего с RESTful API

у вас очень своеобразное представление о RESTful API, весь остальной мир использует параметры в POST Data или URL, почитайте про реально используемые REST API к популярным сервисам

потому что кому-то эти две не угодили

У них разные цели.

а разработчики пользуются кто QT-строками, кто ещё другими велосипедами

Qt-строками пользуются в Qt-проектах, потому что разработчики Qt так решили(когда делали Qt, С++ еще не был стандартизирован).

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

Нет, так не делают.

Не будет, конечно. Потому что мне уже предложили 2 такие реализации: std::Vector и std::Array

Они, кстати, реализуют не то, что вы тут последнее время обсуждаете. А почему не будет оптимизации?

@safe практически неактивен в *текущем* dmd. Это задел на будущее.

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

Потому что мне уже предложили 2 такие реализации: std::Vector и std::Array. Завтра примут C++14, там будет ещё одна, какой-нибудь std::Range, потому что кому-то эти две не угодили. В C++17 будет следующая, какой-нибудь std::Diapason. И получится как со строками: есть C строки, но не UTF, C++ строки (вроде бы даже с UTF теперь), а разработчики пользуются кто QT-строками, кто ещё другими велосипедами. В результате писатели сторонних либ буду использовать либо что-то одно, что им больше по душе. А те, кому важно, чтобы их поделием пользовались другие --- будут по-прежнему передавать данные через указатель и выделять/очищать память вручную.

Ситуация, насколько понимаю ее я, совсем другая.

С++ появился как язык с крайне скудной стандартной библиотекой. В качестве таковой у него была стандартная библиотека C + iostreams. Быстро стало очевидно, что для объектно-ориентированного языка этого недостаточно и нужно что-то большее. Т.к. какого-то одного толкателя языка (как в случае с Java/C#/Go) не было, то имеющуюся пустоту стали заполнять вендоры C++ компиляторов и независимые умельцы. Дело усугубил еще крайне непростой и длительный процесс стандартизации C++, после которого было еще несколько лет, в течении которых поддержка C++98 и C++03 в С++ компиляторах была далеко не на высоте.

Тем не менее, печальный опыт прошлого учитывается и в стандарт языка (а значит и в его стандартную библиотеку) включается все больше и больше успешно зарекомендовавших себя и широко применяющихся на практике инструментов. Так, в C++98 были включены std::vector и std::valarray. В C++11 добавлен в std::array. Вероятно, в следующие стандарты войдет еще что-то полезное.

Причем вещи вводятся в стандарт не для того, чтобы что-то там отменить. А для того, чтобы стать базисом, на который будут затем опираться производители сторонних библиотек. Например, в C++ уже давно считается плохим тоном использовать new T[n], т.к. то же самое, но с большей безопасностью, можно получить как std::vector<T>(n). Аналогично и со строками. Кстати говоря, в Qt уже давно есть интеграция с STL-ными вещами. И те же QtString могут получать в конструкторе ссылки на std::string.

По-моему опыту сейчас в C++ такими вещам, как передача данных через указатели, ручное вычисление адресов, явное освобождение динамически выделенной памяти и др. наследием C занимаются только люди из следующих категорий:

* те, кто не удосужился проштудировать хотя бы третье издание «Языка программирования C++»;

* те, кто занимается совсем уж низкоуровневыми вещами

* или же сопровождает старый-старый код.

И, кстати говоря, C++ доказал, что он может учитывать собственные просчеты, двигаться вперед не разрывая совместимости с давно написанным, но работающим и, следовательно, полезным кодом. Можно, наивно, полагать, что в D все сразу сделают правильно. Но это явно не так. И как потом D будет решать свои «детские» проблемы — это еще большой вопрос.

Зато очень к месту (pure хорошо, но недостаточно) при использовании комбинированного функционального — императивного подхода.

И как, по вашему, мнению, это может выглядеть?

Не вижу никаких причин зачем в Д нужен аналог сишного каста, который что угодно перереработает во что угодно.

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

А я не берусь прямо сейчас, с кондачка, пытаться приводить обоснованные примеры, тут нужно очень основательно подумать. Если угодно, это интуитивное ощущение, обоснованное некоторым реальным опытом. Во всяком случае, утверждение не выглядит откровенно идиотским, нет?

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

Из нескольких известных мне людей, пишущих сугубо прикладные программы на C++ (не только из университетской среды, но и из промышленности), все используют передачу по указателям, ручное вычисление адресов и явное освобождение памяти. Есть множество книг по C++, особенно старых, где предлагают так делать, а преподаватели в вузах и школах используют, как правил, старые книги.

У меня есть коллега, которых не видит разницы между C и C++, инициализирует данные через malloc, использует главным образом C-шные библиотеки и признаёт исключительно Borland C++ 3.1 compiler. Этому он учит студентов и использование других средств карает, а стандарт C99 для него «никому не известная фигня».

А я не берусь прямо сейчас, с кондачка, пытаться приводить обоснованные примеры, тут нужно очень основательно подумать.

Ну вот я (и не только я) не зря же здесь уже несколько раз просили привести примеры. Т.к. чуть-чуть начинаешь задумываться и все... Смысл immutable теряется.

В чистых ФП языках все данные изначально неизменяемые, насколько я помню. Поэтому, если мы попытаемся натянуть структуру из, к примеру, такого XML-я:

<articleInfo>
  <title>A title</title>
  <author>John Smith</title>
  <author>Bob Robson</title>
  <summary>Some text</summary>
</articleInfo>

type ArticleInfo = struct
   title string,
   author list<string>,
   summary string;

Но если мы попробуем сделать отображение в D, то у нас есть два варианта:

1. Делать все крайне простыми структурами без методов. Дабы в случае immutable и const модификатором все это применялось автоматически:

class ArticleInfo {
  public string title;
  public string[] author;
  public string summary;
}

auto a1 = new ArticleInfo; // Обычный объект.
auto a2 = new(immutable) ArticleInfo; // Вообще неизменяемый объект.

Но что, если нам потребуется сделать класс ArticleInfo более сложным? Скажем, закрыть атрибуты и сделать к ним доступ через методы. Что-то вроде:

class ArticleInfo {
  private string title;
  private string[] author;
  private string summary;

  public string getTitle() { return title; }
  ...
}

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

class ArticleInfo {
  private string title;
  private string[] author;
  private string summary;

  public string getTitle() { return title; }
  public immutable(string) getTitle() immutable
    { return title; }
  ...
}

Вот и получается, что либо нужно использовать совсем простые структуры данных без методов. Либо городить разные варианты структур данных. Например, обычный ArticleInfo и ImmutableArticeInfo. Первый тип можно использовать в обычном императивном коде. Второй — и в императивном (в качестве констант), и в функциональном.

Только вот нужно ли разработчикам связываться с таким дублированием структур?

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

у вас очень своеобразное представление о RESTful API, весь остальной мир использует параметры в POST Data или URL, почитайте про реально используемые REST API к популярным сервисам

Очень мало кто из сервисов, предоставляющих подобное API, реализует его на самом деле в соответствии с RESTful принципами. Например такая вещь, как параметр «action» - дичайшее их нарушение. Концепция REST в моделировании абстракций приложения в качестве URL и работа с ними как с HTTP сущностями. Поэтому действия ограничены набором методов HTTP, а изрядная часть значимых параметров являют собой часть URL как таковой.

POST-параметры есть, конечно же, но не десятками.

И нет, это не я придумал :(

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

Поэтому-то и предпринимаются попытки создания замены C++ в виде простого в изучении и использовании языка для нейтива. В свое время активно этим занимался Вирт, разрабатывая семейство наследников Pascal (Modula-2, Oberon). Сейчас одна из самых ярких подобных попыток — это Google-овский Go (правда он заточен на нишу server-side приложений на мой взгляд).

Но, на мой взгляд, ирония в том, что это заведомо неудачный путь. Ведь как-только с помощью простого языка создается какой-то работающий простой продукт, из него пытаются сделать работающий сложный продукт. И тут оказывается, что сложность инструмента должна соответствовать сложности продукта. Поэтому-то сложный C++ широко используется. А более простые и безопасные Modula/Oberon остались где-то далеко на периферии.

Тот же D, имхо, так же прошел стадию, когда он был бы более простой, но более мощной заменой C++. Остановись авторы на D1 в 2007-м, накопи в течении трех-четырех лет фидбэк от реальной эксплуатации языка и учти/исправь замечания/проблемы в следующих релизах, глядишь все было бы иначе. А так дай D2 в руки тем, кто не захочет его старательно изучить... И будут передовые фишки языка (те же const/immutable) валяться себе где-то без реального использования.

потому я и написал про исключения, только код API знает, что именно пошло не так, например, если запрос к БД не прошел, то можно вернуть описание ошибки

Можно, я именно так сейчас и делаю. Для этого у исключений и есть поле msg.

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

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

кстати, а как у тебя обрабатываются опциональные параметры

Как родные опциональные параметры методов D.

только для очень простых случаев

Какой пример ты можешь привести, требующий рендеринга именно в API? В моей практике это всегда чистый блок сериализованных данных. Изредка требуются дополнительные фильтры для этих данных, для этого был добавлен атрибут @after, но это очень редко.

посмотри серьезное API, например twitter

Я всегда изучаю предметную область перед тем, как что-то делать ;)

тем более в нем нафиг не нужна логика специфичная для REST

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

tl; dr: произвольное HTTP API != RESTful API

Ведь как-только с помощью простого языка создается какой-то работающий простой продукт, из него пытаются сделать работающий сложный продукт. И тут оказывается, что сложность инструмента должна соответствовать сложности продукта. Поэтому-то сложный C++ широко используется...

Неверное утверждение!

Неверное утверждение!

Очень содержательное и доступное опровержение!

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

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

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

Oberon может быть намного более простым, чем C++, но если это вынуждает разработчика делать кучу копи-пасты там, где на С++ можно обойтись шаблонами, то простота Oberon-а работает против него.

Вы не поняли о чем я Вам говорю. Компилятор Оберона может быть гораздо сложнее чем компилятор С++. Компилятор, это не только лексер и парсер, если Вы не в курсе.

Нет верное!

Это я к тому, что нужно аргументировать=)

Всё правильно, но, имхо, забыта целевая группа пользователей.

Я в теме с Ди не с 01 года, нет. Гораздо позже. Но, пожалуй, энтузиаст D (в разумных пределах). Однако в теме Питона с 96 года. И полагаю, между развитием этих двух инструментов имеется некоторое сходство, дающее основание надеяться на вхождение Ди в мэйнстрим.

Си и ++ отродясь позиционировались как универсалы, для системного и прикладного программирования. И жизнь показала, что народ, при прочих равных, выбирает свободу системного инструмента. И при первой возможности мигрирует на инструмент, не пытающийся «зажимать» низкоуровневый доступ. Это потом сегодняшние фавориты стали обзаводиться продвинутыми средствами, без которых нечего и думать за разумное время родить что-либо, близкое к современным изделиям.

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

1) системно — прикладных универсалов, обладающих, тем не менее, полным джентльменским набором сложившихся к настоящему времени наворотов а-ля ООП, мета и функциональное программирование и т.д.

2) строгих языков, принципиально не допускающих, либо сильно ограничивающих «излишне низкоуровневые операции», но способных генерировать эффективный код и

3) динамичных прикладных языков, не обращающих особого внимания на эффективность кода. Плюс попытки гибридизации, типа Objective-C (гибкость 1 + динамизм 3 групп).

С первой группой всё понятно. Почти безальтернативно C, C++. Со второй, тоже --- от Ada до C#. И с третьей, тоже: всяческие JS, Ruby и Питон на троне. Причём для всех групп характерно стремление обзавестись современными «наворотами», даже ценой чистоты идеологии.

Интереснее по области применения. Как можно судить (поправь, если говорю глупость, но складывается именно такое впечатление), хорошая доля проектов, начатых на инструментах второй группы, рано или поздно переделывается на всё том же неизбежном C++. По разным причинам, включая тонкости поведения контролируемых сред, типа .Net/C#.

Это всё достаточно очевидно, но мы постоянно забываем ещё об одной детали: целевой аудитории. А вот тут, кроме программистов, есть программирующие пользователи и прикладники. Я сам склонен позиционироваться как программирующий пользователь, но по факту, приходится заниматься самым настоящим низкоуровневым, системным программированием (задачи поддержки эксперимента, например). И таких прикладников, очень много.

И вот тут начинается паноптикум. C++ развивался методом навешивания рюшек на инструмент, идеологией которого было максимально точное отображение написанного на машинный код. Те же Си-строки, это вовсе не неудачный инженерный приём. Напротив, очень сбалансированное решение с точки зрения получения кода, максимально близкого к написанному вручную аналогу.

К чему это привело, все понимают: Шамански выглядящий код и костыли и подпорки везде, где идеология выходит за рамки изначальных идей Си. Например, в удивительно кривой системе шаблонов. C++11, конечно, это удивительный прорыв и наверное, даже не диалект, а новый язык но... невразумительного шаманства меньше вовсе не стало.

Библиотеки, это хорошо (кстати, в теме о вычислениях --- кроме blitz, посмотрите eigen3), но в мире C++ (именно из-за его изначальных особенностей, время создания программы всё равно оказывается очень большим!

Народ (ещё раз, я говорю о программирующих пользователях, а не профессиональных программерах!) быстро стал осознавать, что нужны ДОСТУПНЫЕ инструменты трёх групп: 1) крайне низкоуровневые, 2) крайне высокоуровневые 3) универсальные. Отсюда и прошлая популярность Дельфи, и популярность Питона.

Питон, кстати, тоже был встречен издевательскими комментариями и очень немногие поняли, что это такое, и зачем (поэтому меня очень порадовал этот тред: очевидно, что достигнута стадия э... саркастического :) интереса к Д). Впрочем, часть дискуссии весьма конструктивна и читается как приключенческий роман, так что можно порадоваться вдвойне!

Нишу высокоуровнего инструмента, вполне может занять C# (если развитие Mono будет непосредственно поддержано Майкрософтом, без этого текущее состояние C# на платформах, отличных от Windows, имхо, можно рассматривать только как весьма отягощённое рисками.

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

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

Поэтому попытка убрать костыли, осмыслив накопленный опыт, попытка зубров со стороны системного (Брайт) и ООП (Александреску) уровней, не могла не быть очень интересной.

Пока состояние инструментария D выглядит довольно убогим (откровенно слабо оптимизирующие компиляторы, небогатая библиотечная поддержка). Пока D больше обещает, чем даёт. Но состояние быстро меняется и то, что уже достигнуто, уже позволяет включиться в процесс сообществу. По аналогии с Питоном, сейчас на календаре Ди 2005 год. Остаётся только пожелать --- полный вперёд!

C++ тоже не предоставляет многих важных и нужных средств языка и ничем в этом смысле не выделяется.

Тут всё-таки есть некоторая разница. В С++ не выкидывали имеющиеся в С возможности, а надобавляли новых. Конечно, добавляют зачастую медленно, но и не выкидывают.

А новые языки претендующие на замену С++ отказываются от части имеющихся возможностей.

Мне вот кажется, что без модулей, полной статической интроспекции и pure функций

Модули обсуждаются, может когда-то и будут. Рефлексия статическая точно будет. pure есть в виде расширений.

Кстати, что модули принципиально меняют? Удобнее, быстрее компиляция, но есть ли чего нельзя добиться в С++?

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

Они важны, поскольку при широком использовании и распространении языки первых трех групп становятся менее динамичными, в них все медленнее и медленнее решаются проблемы, с которыми сталкиваются программисты (достаточно вспомнить, как медленно развивается самая что ни есть мейнстримовая Java). Пользователей, которых это не устраивает, притягивают к себе языки вроде Haskell, ATS, Agda и т.д.

Да, конечно. Rust --- яркий пример.

А вот D, пожалуй, всё-таки ПОЧТИ готовый универсал. Но без включения широкого(!) сообщества, останется мертворождённым.

D позиционируется как системно — прикладной язык. В таковом качестве, пусть и редко,но очень сильный каст может быть жизненно важен.

Это всё понятно. Изначально меня интересновало почему в D не разделили касты по возможностям, как в С++.

А зачем? В ++ специализированные касты появились для повышения безопасности при работе с указателями. В D это просто излишне, вероятность нарваться на грабли много меньше изначально, by design.

В ++ специализированные касты появились для повышения безопасности при работе с указателями.

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

В D это просто излишне, вероятность нарваться на грабли много меньше изначально, by design.

Да ладно?

class T1
{}

class T2
{}

// Классы T1 и T2 вообще никак не связаны.
auto t1 = new immutable T1;
T2 t2 = cast(T2)(t1); // Ok?

Плюс ещё один момент:

int i = 10;
char c = reinterpret_cast<char>(i); // Suppress warning.

В общем, я не вижу где тут «меньше граблей by design».

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

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

Клиенты это те кто платит. Остальным никто ничего не должен.

Ну-ну. За С++ тоже не платят обычно. Тем не менее, если вдруг решат всё поломать, то его быстро похоронят.

сыграет плохую шутку именно с плюсами

Пока им нет нормальной альтернативы.

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

Ну я в этой сфере не эксперт, но можно в википедию заглянуть:

около 86 % мирового производства электроэнергии производится паровыми турбинами), кроме того, они часто используются в качестве судовых двигателей (в том числе на атомных кораблях и подводных лодках)

Там и другие применения указаны. А вообще аналогии редко когда правильными оказываются.

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

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

Оптимизировать свою стандартную библиотеку компилятор обычно тоже умеет.

Кстати, насчёт реализации в библиотеках. Когда начал D изучать и дошел до ассоциативных массивов, то меня наоборот не подародовало, что они «настолько встроены в язык». В смысле, что для них особый дополнительный синтактис придумали (всякие там «in»).

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

Это исследовательский язык. Проект создания наилучшего языка.

Ну хорошо, если так. Впрочем, наилучшесть несколько субъективна, особенно если говорить об «языке общего назначения».

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

Да ладно, критика на пользу может идти. Ведь претензии не только к тому что язык «нестабилен».

Кстати, уж если на то пошло, C++ так активно развивается благодаря изменению сознания разработчиков, которое принёс в том числе D.

Ну не уверен... что В D есть такого, чего не было нигде до этого?

Будет. Однозначно. Потому что проблема взаимопонимания между программистом и клиентом она только усугубляется. Клиенту абсолютно без разницы, как можно использовать immutable, ему без разницы есть ли в языке static_cast/dynamic_cast и т.д. Ему неинтересно слушать проповеди от программиста, который говорит, что вот так вот нельзя, а вот прошлый вы раз вы говорили вот это и т.д. И платит деньги именно он. И когда заказчик получит инструмент, который позволит ему самому делать то что он хочет, пусть и медленнее - он откажется от услуг программиста. Потому что в целом связка суперпрофессиональный программист-клиент будет работать медленнее чем сам клиент. Потому что профессиональный программист будет тупо простаивать большую часть времени, пока клиент будет продумывать задание. Ведь успех QML же отсюда растет - дизайнер может обойтись без программиста. Вангую дальнейшее размытие понятия программист и вскоре программист реже всего будет ассоциироваться у людей с узкими специалистами, способными вывернуть наизнанку определенную архитектуру в узкой области, а это будет человек, способный заставить компьютер выполнить нужные ему действия. А крутые программисты на крутых языках будут в начале редкими и цениться на вес золота, а потом эта уникальность сыграет с ними злую шутку и им придется резко вымирать - потому что никто не будет ориентироваться на редких специалистов, которые еще и условия диктовать будут. А насчет legacy - ну фортран же используют до сих пор. Также будут и плюсы использовать. Но что-то я смутно припоминаю, когда видел в вакансия требования к знанию Fortran на высоком уровне.

Конечно это даст повод ворчать некоторым что дескать совсем народ обленился, то ли дело мы в свое время CGA адаптер программировали, а не шейдерами баловались. Немного художественно, но это мое ИМХО. :)

Вы прекрасно понимаете, что в С++ никогда не будет ни GC ни модулей, по понятным причинам.

Ну да, «прекрасно понимаем», а вот тут и тут люди зачем-то фигнёй маются.

Какой-никакой, но ГЦ для С++ уже есть. Плюс в новом стандарте добавили вещи для облегчения релизации. Другое дело, что это не особо востребовано.

Ну не уверен... что В D есть такого, чего не было нигде до этого?

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

Вы обманываетесь утверждая, что вам язык интересен. Вы ищете повод не изучать язык и подводите под это обоснование. Что тоже ошибочно - никто вас не заставляет этого делать. Просто скажите, что мне язык не нравится и все. Уверяю, что никому не придет в голову спрашивать у вас - а почему он вам не нравится?

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

Где это в стандарте?