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

Ну да, нет иммутабельности - нет и проблем с ней.

Что тебе мешает обеспечить мутабельность?

Что тебе мешает обеспечить мутабельность?

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

? Если это broadcast или multicast, то в чем моя дурость?

В том, что переспрашиваешь очевидные вещи.

AFAIK, не запрещено передавать между нитями обычные мутабельные объекты.

Здесь я показал, в чем выгода в передаче иммутабельных объектов. В С++ я могу пользоваться для этих целей контролем со стороны компилятора. В D, где якобы пошли дальше и сделали лучше, не могу.

Т.е. язык вроде как мощнее, а как пытаешься сделать нужное себе, а не Александреску, то никак. Программируй тогда как на убогой Java.

Языковые механизмы одинаковы что для concurrency, что для parallelism (и вообще разница между concurrency и parallelism высосана из пальца)

Эту вещь я комментировать не буду.

Распространённая ошибка - считать, что immutable в D решает те же задачи, что и const в C++. Это не так и никогда не планировалось таковым.

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

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

Теперь, собственно, по теме. Эквивалентный по сути код на D:

``` struct log_message { immutable string sender, action, description;

// mutable payload }

// ...

void handler(/* const */ shared ref log_message msg) { // const как parameter attribute примерно эквивалентен таковому в C++, способен ссылать как на mutable, так и на immutable, гарантирует отсутствие изменений.

// shared указывает на то, что доступ к структуре может происходить из разных нитей

msg.action = «WTF?»; // будет нелегально во всех случаях msg.payload = 42; // будет нелегально только если параметр const }

```

Однако приведённый пример не очень хорош из-за того, что struct - value-type, для которых понятия «сам объект» и «данные объекта» почти эквивалентны. Если бы это был указатель или class, тогда мог бы возникнуть вопрос о том, зачем делать неизменяемым указатель (я, собственно, изначально предполагал именно этот случай).

(упс, ссылку на LORCODE заметил поздновато, пардон)

переспрашиваешь очевидные вещи.

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

Распространённая ошибка - считать, что immutable в D решает те же задачи, что и const в C++. Это не так и никогда не планировалось таковым.

Я всего лишь приводил примеры того, что в C++ const можно использовать гибче, чем immutable в D. Что лично для меня делает пользу от D-шных immutable и const сомнительной.

Ну и кроме того, если из-за тараканов в голове Александреску вместо

class log_message {
  string sender;
  string action;
  string description;
}

immutable log_message msg = ...;

class log_message {
  immutable string sender;
  immutable string action;
  immutable string description;
}

log_message msg = ...;

Отвечу в этом сообщении на часть предыдущих, в том числе и от других авторов. Налицо непонимание значения immutable и для чего его нужно применять. Пример про якобы гарантии С++ с иммутабельными данными в корне не верен. Плюсы не поддерживают концепцию immutable. Точка. То что вы описали, является соглашением между разработчиками. Потому что ваш вариант абсолютно не гарантирует, что кто-то другой не передаст ваше сообщение в функцию, которая изменит его. И вся стройная система просто рухнет. В D immutable дает вам такую гарантию - вы точно знаете, что immutable аргумент нигде и никогда не будет изменен. И за это отвечает компилятор. Чувствуете разницу? Уровень соглашения и уровень компилятора? В первом случае вам нужно набирать команды внимательных разработчиков, во втором случае компилятор освободит разработчиков от подобной нагрузки - отслеживать выполнение соглашений. В результате чего они могут больше уделить времени решению задачи, а не способа его оформления. D просто не даст сделать ряд ошибок, возможных на плюсах. Насчет передачи сообщений по цепочке - вы просто не до конца разобрались с концепцией. Речь идет о ФП и поэтому, ясное дело, вы не можете использовать императив и модифицировать само сообщение. Сам принцип другой, не скажу что я приведу самый удачный пример, но приведу. Вы можете передавать мутабельный массив immutable данных. При генерации сообщения он у вас будет содержать только одно сообщение. После обработки одной ступенью, вместо модификации первоначального сообщения, вы создаете еще одно сообщение с новой информацией и добавляете его в исходный массив сообщений и передаете его дальше и дальше. Если на каком-то этапе вы точно знаете что первоначальное сообщение вам уже не нужно, вы просто удаляете его из массива и сборщик мусора позаботится о нем. ВСЕ. Вы полностью избавлены от каких-либо примитивов синхронизации. Вы просто пишете код в естественном порядке. Да, это расход памяти. На этапе прототипирования можно обойтись штатным гц, но в релизе конечно не помешают кастомные аллокатор - но в D они просто прелесть и очень могущественные и хотя от увеличенного расхода памяти они окончательно не избавят, но от проседания быстродействия избавят точно. Итого мы имеем в D гарантии на уровне компилятора и отсутствие необходимости писать на низком уровне при сравнимом быстродействии с плюсами. Что означает сокращение сроков разработки. А при желании можно и ручками поработать, с теми же примитивами/lock-free структурами и т.д. и будете иметь то же быстродействие, что и плюсы.

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

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

Мне нужно иметь простую штуку. Есть мутабельный объект A. Ссылка на него находится в иммутабельном объекте B. Ссылка на иммутабельный объект B передается в N параллельно работающих нитей. Которые могут сохранить ссылку на A у себя и обращаться к мутабельным методам A (предполагается, что A сам обеспечивает thread safety).

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

Я нахожу этот подход менее гибким, чем в C++.

Потому что ваш вариант абсолютно не гарантирует, что кто-то другой не передаст ваше сообщение в функцию, которая изменит его. И вся стройная система просто рухнет. В D immutable дает вам такую гарантию - вы точно знаете, что immutable аргумент нигде и никогда не будет изменен.

Молодой человек, вы C++-то хоть знаете? Если у меня есть константная ссылка или указатель на объект, я не могу просто так передать ее куда-то, где требуется неконстантная ссылка/указатель. Нужно применять const_cast, а это явный хак со стороны разработчика. Не вижу оснований при таком раскладе верить в то, что подобные хаки невозможны в D.

Я всего лишь приводил примеры того, что в C++ const можно использовать гибче, чем immutable в D.

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

Ну и кроме того, если из-за тараканов в голове Александреску вместо

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

Кстати, Dicebot вам показывает решение через shared, я вам показал решение через immutable. Через shared это решение в старом добром императивном стиле и оно наиболее естественно ложиться на сознание плюсиста, как показывает типичные вопросы новичков. Подход с immutable совсем отличается от подхода с shared и требует определенной перестройки в сознании. Часто вызывает даже ступор, но после переоценки начинаешь понимать силу подхода. Immutable не плохой, он наоборот очень мощный, но его применять нужно по другому.

Мне нужно иметь простую штуку. Есть мутабельный объект A. Ссылка на него находится в иммутабельном объекте B. Ссылка на иммутабельный объект B передается в N параллельно работающих нитей. Которые могут сохранить ссылку на A у себя и обращаться к мутабельным методам A (предполагается, что A сам обеспечивает thread safety).

Просто перестаньте называть желаемую модель «иммутабельностью» и можно с чистой совестью сказать что, да, инструментарий D вам не подходит. Если вас это утешит, я бы за подобную архитектуру бил канделябром и в C++.

То, что вы называете «гибкостью», на самом деле является полным отсутствием каких-либо гарантий от системы типов и вечным источником труднонаходимых багов в плюсах.

Молодой человек, вы C++-то хоть знаете? Если у меня есть константная ссылка или указатель на объект, я не могу просто так передать ее куда-то, где требуется неконстантная ссылка/указатель. Нужно применять const_cast, а это явный хак со стороны разработчика. Не вижу оснований при таком раскладе верить в то, что подобные хаки невозможны в D.

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

const и immutable значительно разные концепции, не мешайте их в кучу.

С чего бы они стали разными концепциями? Это всего лишь усиление одного и того же эффекта.

const — это read only view на непонятно что. Если у тебя есть const-ссылка, то ты не можешь изменить объект по этой ссылке. Но тебе не гарантируется, что сам объект не изменится со временем.

immutable — это read only view on read only data. Т.е. через immutable ссылку ты не можешь изменить объект и тебе гарантируется, что сам объект, на который ты ссылаешься, так же никогда не изменится.

Если я ошибаюсь в определениях const и immutable, то прошу меня поправить.

то это не есть хорошо и удобно, на мой взгляд.

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

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

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

В D можно было бы пойти еще дальше. Гарантировать, что не только получатели сообщения, но и отправитель не может менять сообщение. Только все это получается как-то неочевидно и неоднозначно.

Мне нужно иметь простую штуку.

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

template<class T> class C {
  T *contents;
};

void f(immutable C& c)
{
/* а тут мы меняем содержимое иммутабельного контейнера */
}

Вполне разумно, что в D эту цену решили не платить.

Для решения твоей задачи есть вариант Dicebot; еще можно попробовать сохранить в иммутабельном объекте ссылку на функцию (лямбду), возвращающую ссылку на мутабельный объект (нет под рукой компилятора, чтобы проверить).

Я нахожу этот подход менее гибким, чем в C++.

А я нахожу Си++ бессмысленно гибким.

Молодой человек, вы C++-то хоть знаете? Если у меня есть константная ссылка или указатель на объект, я не могу просто так передать ее куда-то, где требуется неконстантная ссылка/указатель. Нужно применять const_cast, а это явный хак со стороны разработчика. Не вижу оснований при таком раскладе верить в то, что подобные хаки невозможны в D.

Ой, вот только не надо пытаться тыкать носом, это вас не красит. Хотя я, возможно, не совсем четко выразился. А вы этим воспользовались, впрочем вполне разумно, поскольку вы просто уже ерничаете, а не хотите узнать правду. :) Я имел в виду, что вы можете в плюсах делать так:

void foo(const int i)
{
    // do something
}
...
int i;
foo(i);

void foo(immutable int i)
{
    // do something
}
...
int i;
foo(i); // compile error!!!

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

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

В D можно было бы пойти еще дальше. Гарантировать, что не только получатели сообщения, но и отправитель не может менять сообщение. Только все это получается как-то неочевидно и неоднозначно.

Именно это immutable и гарантирует. После того как immutable данные созданы, они не могу быть изменены никем и никогда. В том числе создателем.

Пример ошибочный, квалификаторы не сохраняются при передачи параметра по значению. Будет корректным если добавить `ref`.

Вполне можно передавать мутабельный массив немутабельных данных и это работает.

Вполне можно передавать мутабельный массив немутабельных данных

Да, наверное. Это меняет что-то в моем утверждении?

Вполне разумно, что в D эту цену решили не платить.

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

В качестве примера. Изначально Брайт делал D без шаблонов. За что получал долю критики, но стоял на своем, доказывая, что шаблоны не нужны. Потом все таки шаблоны сделал. Жизнь таки заставила.

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

Красиво.

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

Не добавит, если все обработчики сообщений *всегда* получают константные ссылки на сообщения. Что элементарно гарантируется на уровне фреймворка.

Так же на уровне фремворка можно гарантировать, что оправитель больше не будет владеть объектом сообщения. Например, если отсылка сообщения делается методом вроде:

template<class MSG>
void send(std::unique_ptr<MSG> msg);

Именно это immutable и гарантирует. После того как immutable данные созданы, они не могу быть изменены никем и никогда. В том числе создателем.

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

class Logger { /* thread-safe но с немутабельными методами. */ };

class CurrentConfig {
  ...
  public Logger logger() { return logger_; }
  ...
  private Logger logger_ = ...;
}

immutable CurrentConfig cfg = new CurrentConfig( new Logger() );

Т.е. никто не может менять объект cfg. Все могут к нему обращаться. И все могут работать с Logger-ом, который доступен через cfg.

Где здесь источник потенциальных багов?

Так понятнее, в чем отличие immutable от const и в чем его мощь?

Вы лучше расскажите, что в моих определениях D-шных const и immutable неправильно.

Блин, все на мелочах попадаюсь :). Действительно, ты прав, спасибо за поправку. Выложу с поправкой: C++

class Bar {};

void foo(const Bar & b)
{
    // do something
}

int main()
{
    Bar bar;
    foo(bar); // bar may be modified anywhere else except foo()
    return 0;
}

class Bar {}

void foo(immutable Bar b)
{
    // do something
}

int main()
{
    auto bar = new Bar;
    foo(bar); // compile error: (immutable(Bar) b) is not callable using argument types (Bar)
	
    auto baz = new immutable(Bar);
    foo(baz); // you're absolutly sure that nowhere baz will be changed anyhow
    
    return 0;
}

Не наброса ради: 1. на фига с FFT с учетверённой точностью? и с какой длиной окна ? (в своё время написал шаблонный класс ФФТ, в который подставляешь в качестве параметра тип хоть скакой точностью, лишь бы для него был определён некоторый набор операций и функций.) 2. как там, в этом самом фортране число с учетверённой точностью объявляется ? (честное слово, интересно просто).

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

Можно конкретный пример с immutable, в котором можно увидеть контроль этих гарантии со стороны компилятора и нельзя было бы получить подобный контроль в C++?

Не добавит, если все обработчики сообщений *всегда* получают константные ссылки на сообщения. Что элементарно гарантируется на уровне фреймворка.

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

что такое на самом деле «иммутабельность», почему в С++ её нет (и быть не может)

Я не знаю, что там у вас за иммутабельность, но я использую иммутабльные структуры данных и в Haskell и в Scala и в C++. И не вижу никаких препятствий к этому.

именно 128 бит вещественное число или таки 128-битный вектор ? чо-то нигде упоминаний не встречал про плавучую арифметику с такой точностью. В гцц есть __float128 - именно он четырёхкратной точности, но он программно реализован. В интеле есть _Quad - тоже самое. И, ясень пень, - нестандарт, что сильно снижает его ценность.

Определения-то вы верно написали, хотя и не полностью. А вот используете их неправильно. Для меня это разные концепции и между ними, ИМХО, нужно проводить разницу. Immutable это значительно более строгое ограничение и immutable типы являются подтипом const типов. На мой взгляд это важные моменты. Переменная типа const(T) может принять значение типа T и типа immutable T, а переменная типа immutable T не сможет принят никакой другой тип чем immutable T. И за счет этой строгости программист получает ряд серьезных гарантий, которых const, тем более не транзитивный, никогда не даст. Про гарантии на уровне фреймворка скажу, что это половинчатое решение, если не четверичное и проистекает как раз от отсутствия в языке immutable.

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

В С++ есть фреймворк ACE, высокоуровневые конструкции которого (например, ACE_Reactor-ы и ACE_Event_Handler-ы) обеспечивают гарантии закрытия ресурсов (конкретно сокетов, пайпов, файлов и т.д.). Чего не может сделать компилятор в принципе.

Так что вопросы уровня гарантий не такие простые, как могут показаться.

Оно?

template<typename T>
struct immut {
    const T data;
};

Ну вы же серьезный разработчик, будьте же серьезным до конца. Я знаю про ACE, но я не понимаю почему вы ставите знак равенства между гарантиями фреймворка и гарантиями языка? Это же разные вещи и вы не можете этого понимать.

И чем это отличается от

const some_type x;

Определения-то вы верно написали, хотя и не полностью.

Ну уже прогресс.

А вот используете их неправильно.

А вот теперь давайте таки представим, что я имею представление о двух вещах: a) о возможностях, которые мне может дать D и b) о потребностях, которые у меня есть.

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

double-double реализован напр., в glibc на PowerPC как тип long double. И там скалярный плавучий вычислитель, а не векторный. И таки да, совсем не метеор, впрочем и на векторном вычислителе тоже не стоит ожидать рекордов скорости.

Что мешает сделать immutable как шаблон типа, который хранит const данные некоторого типа?

Гарантии уровня фреймворка и гарантии уровня компилятора - чувствуете разницу?

Да, не надо в язык тащить то, что не требуется в него тащить.

почему же в D нельзя сохранить ссылку на мутабельный объект Logger в иммутабельном объекте CurrentConfig?

Вот честное слово, вы издеваетесь? Вы же сами написали определение immutable. Прочитайте его еще раз, в конце концов. Вы же сами написали, что это read-only данные и они никогда не изменяются в ходе работы приложения. Если вы добавите к read-only data еще и mutable data, то это не будет уже immutable, согласитесь?

Да, не надо в язык тащить то, что не требуется в него тащить.

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

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

я думал про D речь.

Ну там речь о том, какие последствия для D имела бы нетранзитивная иммутабельность :)

Я не знаю, что там у вас за иммутабельность, но я использую иммутабльные структуры данных и в Haskell и в Scala и в C++.

В D был сделан очень хороший шаг в сторону иммутабельности данных как в чистых функциональных языках. Сделанные иммутабельными данные (а они могут стать таковыми только один раз — во время своего создания) уже больше никогда не меняются.

Это реально намного круче, чем просто C++ный const, который не более чем квази read-only view на данные (учитываем возможность наличия mutable атрибутов даже у полностью константных объектов). Что позволяет вообще без опасений разделять read-only данные между параллельными нитями.

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

Если вы добавите к read-only data еще и mutable data, то это не будет уже immutable, согласитесь?

Не соглашусь. Я не добавляю объект Logger к иммутабельному объекту cfg. Объект Logger существует сам по себе. В cfg лишь ссылка на него.

А от объекта cfg мне нужно, чтобы ссылка на logger в нем никогда больше не менялась. И чтобы это гарантировалось языком.

Не наброса ради: 1. на фига с FFT с учетверённой точностью? и с какой длиной окна ?

На самом деле FFT там можно и обычный использовать. 4-ная точность нужна, чтобы матрицы ворочать потом. Просто в этом случае придётся типы приводить, но ничего страшного.

Объявляется в старых добрых традициях в лоб:

real(16) :: x

Вы же сами написали, что это read-only данные и они никогда не изменяются в ходе работы приложения.

Оказалось, что я опечатался.

Должно было быть так:

class Logger { /* thread-safe но c мутабельными методами. */ };

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

Зря не соглашаетесь. В этом и ключевая особенность immutable - он транзитивен.