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

unittest сделаны не для этого, ИМХО, разумеется.

А для чего?

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

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

внезапно, upd.12 Oct 2013 Facebook is using D in production starting today

есть ли какие-то планы по реализации аннотаций ?

DIP6 это ранние спекуляции на тему User-Defined Attributes, которые были добавлены в язык около года назад:

http://dlang.org/attribute.html#uda

Что такое «нормальный язык»? И почему C++ пользуются, а CL не очень?

В нормальном языке

Языки скорее делятся на полезные и нет, чем на «нормальные» и «ненормальные».

В крестах смешались в кучу ...

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

Кто-нибудь может мне внятно объяснить, как ref влияет на тип?

ref int foo(ref int x)
{
	return x;
}

typeof(foo) выдает ref int(ref int x).

int[] a = [1,2,3,4,5];
foreach(ref int e; a)
    ...

typeof(e) выдает int, без ref.

На объявление в духе

int x;
ref int y = x;

Однако, дает сделать alias

alias ref int ref_int;

int x;
ref_int y = x;
y = 100500

При этом typeof(y) выдает int.

Более того, с таким alias'ом даже foreach лажает

alias ref int ref_int;
int[] a = [1,2,3,4,5];
foreach(ref_int e; a) {
    e = 100500;
}

Оставляет массив без изменений.

Я совсем запутался. И я пока не вижу оснований соглашаться с тем, что D проще C++.

Идиотизм какой-то

Идиотизм какой-то

Это не идиотизм. ref означает передачу по ссылке, в результате изменения будут доступны в запускающем коде. ref не является отдельным идентификатором общего пользования, как и inout.

Тогда почему разрешен alias. И почему, если он разрешен, он не работает?

ref это как var в Паскале в процедурах и функциях. За его пределами у него нет смысла. Ещё есть ref функции, там смысл немного другой.

Тогда почему разрешен alias. И почему, если он разрешен, он не работает?

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

Это баг, добавил в bugzilla : https://d.puremagic.com/issues/show_bug.cgi?id=11632

Что такое «нормальный язык»?

язык — это в первую очередь, инструмент для выражения мыслей.
нормальный язык — это такой, который позволяет адекватно эти мысли выражать.
адекватно не языку, исторически сложившемуся ранее; и даже не каким-то нормам культуры или какой-то там морали. это всё вторично.

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

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

это просто среда, посредник, medium. и medium is not just a message, it's little more than this.

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

каждый участнег — такой метациклический вычислитель

знакомься, именно это и есть язык — та конструкция в голове, которая разворачивается у тебя в голове, участнег, читая эти строки.

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

проще придумать новое слово: «штангенциркуль» из двух составных, чем изобретать «круговую палку», «снегоходы» и «мокроступы». или, как в языке индейцев навахо называли самолёт-бомбардировщик: большая железная птица, бросающая взрывающиеся яйца, потому что язык был просто недостаточно гибок — не позволял конструировать ad-hoc, по ситуации новые слова и понятия.

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

если он не нормален — надо его сначала попробовать расширить. а потом уже выкинуть.

И почему C++ пользуются, а CL не очень?

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

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

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

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

потому что смысл надо осиливать, а это — отдельная работа.

которую лень делать.

потому что 95% и всё такое..

Да я так и подумал, но поведение-то странное.

Понятно...

по дискуссии на тему «встроенные ли должны быть тесты» — во всяком случае, инварианты и постусловия точно должны быть встроенные (а заодно и предусловия); иногда они маппятся 1 к 1 на тесты, но отнюдь не всегда

пример использования видимо тоже должен быть встроенным (а это практически готовый тест)

а почему кстати нет ref как языковой сущности, а только параметр функций?

и да, я все время хотел сказать, и все откладывал из-за более интересных вопросов в треде, так вот — лучше бы они 1500 баксов потратили на написание нормальной документации и design rationale, чтобы вот таких вот сомнений насчет «это такие странные правила, или может баг» у перебезчиков с с++ не возникало :-)

Уже. https://github.com/jacob-carlborg/dstep

пригодится как пример использования libclang

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

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

есть мнение, что она растет *исключительно* за счет техпроцесса (35 нм, например), который улучшаться будет очень медленно,

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

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

наличие бесплатных компиляторов с открытыми исходниками и довольно приличным качеством, реализующих это «минимально обязательное», может считаться объективной предпосылкой?

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

и получаем 2-й пункт: хороший язык должен быть спроектирован так, чтобы быть отличным eDSL контейнером (т.е. хостом для eDSL)

(1-й, как мы помним — это одновременно стабильность и возможность развития; 2-й пункт представляет собой практический способ реализации 1-го пункта)

из языков, явно поставивших задачу п.2, мне известна только jetbrains mps, но у нее свои заморочки; с точки зрения п.2 с++ и d, похоже, находятся на близких уровнях (хотя у d возможностей больше из-за интроспекции/рефлексии)

Можно посмотреть на то, во что со временем превратился C#, первая версия которого не имела даже генериков.

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

RESTful принципами. Например такая вещь, как параметр «action» - дичайшее их нарушение.

почему?

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

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

плюс к этому исследование на уровне детского сада — общего эффект полиморфизма нет, есть только частные случаи

но да, изучать то, что они там делают — *определенно* имеет смысл ради интересных идей

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

как показал опыт явы, слабые ссылки *нужны* в обычном прикладном программировании (другое дело, что синтаксис gc ссылок может быть короче и удобнее, чем ссылкок других типов)

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

ну да, это заусенцы с++, убранные напильником

* У большинства базовых вариантов: массивов, ассоциативных массивов (словарей), кортежей, строк и прочих комплексных чисел должна быть одна стандартная реализация. Её отсутствие или недостаточная проработанность ведёт к зоопарку (что мы уже видели даже на примере самого D1 с двумя «стандартными» библиотеками).

ммм... а разве не у *Д2* 2 стандарнтых библиотеки?

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

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

* unittest должны быть встроены в те модули, где написан сам тестируемый код, иначе они теряются и на них все забивают. Их включение/исключение из проекта регулируется ключом компиляции...

мелкое консервативное расширение с++

поэтому меня очень порадовал этот тред: очевидно, что достигнута стадия э... саркастического :) интереса к Д

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

и получаем 2-й пункт: хороший язык должен быть спроектирован так, чтобы быть отличным eDSL контейнером (т.е. хостом для eDSL)

Можно смотреть на это так:

- язык либо вообще не должен давать возможности делать eDSL. Но предоставлять простые средства для использования результатов работы внешних DSL;

- либо же возможности для встроенных DSL должны быть очень хорошими.

Тот же C++, имхо, не есть дружелюбный язык для eDSL. Но и не ограничивает желающих (что не есть хорошо на мой взгляд), что и приводит к вещам вроде старой Boost.Lambda или нынешнего Boost.Spirit. С другой стороны, #include позволяют легко интегрировать в C++код результаты кодогенерации из внешних DSL.

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

C# в этом смысле, AFAIK, лучше Java. В одной из его версий дали возможность размещать код одного C#-класса в нескольких исходных файлах. Что упрощает использование кодогенераторов.

D с его string mixin-ами удобнее всего вышепречисленного. Поэтому для меня не суть важно, насколько у D хорошие средства для eDSL. Может лучше, чтобы они были совсем примитивными.

RESTful принципами. Например такая вещь, как параметр «action» - дичайшее их нарушение.
почему?

Таким уж его придумали :) http://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_Web_S...

«The PUT and DELETE methods are idempotent methods. The GET method is a safe method (or nullipotent), meaning that calling it produces no side-effects.»

Хотя чёткого стандарта на RESTful не существует, это довольно строгие правила построения API, согласно которым всё должно быть выражено в виде URI-объектов и операций над ними через HTTP-методы. Очень часто так называют любое HTTP RPC, но это ошибка.

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

наличие бесплатных компиляторов с открытыми исходниками и довольно приличным качеством, реализующих это «минимально обязательное», может считаться объективной предпосылкой?

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

а почему кстати нет ref как языковой сущности, а только параметр функций?

А чёрт его знает :) Я когда-то задал такой же вопрос и мне даже что-то ответили, но это было очень давно и я забыл. Мне вообще ссылки в том виде, что они есть в D и C++ кажутся излишеством, дающим слишком мало относительно обычных указателей, чтобы оправдать введение новой языковой конструкции. Вот если бы это были гарантированные non-nullable сущности...

и да, я все время хотел сказать, и все откладывал из-за более интересных вопросов в треде, так вот — лучше бы они 1500 баксов потратили на написание нормальной документации и design rationale, чтобы вот таких вот сомнений насчет «это такие странные правила, или может баг» у перебезчиков с с++ не возникало :-)

Насчёт спецификации - я заверяю тебя, это розовая мечта любого разработчика на D :) Вот только реалистичный бюджет для такой задачи будет больше примерно на два порядка - для этого нужно знать нюансы языка _очень_ детально. Таких людей мало и их время очень дорого ;)

А design rationale очень много в книге Александреску - The D Programming Language.

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

Сдается мне что Вы не понимаете что такое GC.

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

Может в D вы про ссылки и правы. Но вот в C++ ссылки дают довольно много по сравнению с указателями. Вот, например, сразу навскидку:

* нельзя создать неинициализированную ссылку. Т.е. с указателями такое компилятор пропустит:

my_type_t * p; // Забыли проинициализировать.

my_type_t & p; // Будет ошибка компиляции.

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

class my_type_t
{
  private :
    another_type_t * m_obj;

  public :
    my_type_t( another_type_t * obj ) : m_obj( obj ) {}
};

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

void write_data_to( const data_t & data, const std::string & file_name );

const data_t some_data = generate_some_data();
const std::string file_name = create_file_name();
write_data_to( some_data, file_name );

write_data_to( generate_some_data(), create_file_name() );

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

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

Так что по поводу ссылок в C++ вы погорячились.

Это ты не понимаешь. Мягкие и слабые ссылки есть в Java, например. Они действительно полезны, т.к. утечки бывают связаны не с ошибками в программе. Ты можешь поместить какой-то объект в какой-нибудь список каких-нибудь подписчиков, но при этом объект не будет иметь смысла существования, если не будет доступен в каком-то другом месте. В результате объект реально не нужен, но он не будет собран сборщиком, т.к. на него есть ссылка в том самом списке. Это как пример.

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

Это логическая ошибка.

Хранение ссылки в поле объекта, кроме специальных случаев(локов, лямбд и пр.)чревато висячими ссылками...

Чревато не более, чем хранение указателя на чужой объект.

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

Хотя, как я только что проверил, изменить ссылку после иницализации нельзя. Этого я не помнил и это очень хорошо :) Так что ссылки в С++ реально полезнее чем в D, хотя всё ещё и недостаточно полезны на мой взгляд.

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

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

Это логическая ошибка.

Очень часто это вообще не ошибка. Тебе, скажем, нужны подписчики, но заставлять их жить только ради тебя бессмысленно. И тут как раз различные виды нежестких ссылок выходят на сцену.

Более, т.к. в случае указателя очевидно, что нужно следить за временем жизни.

Правда что ли? В чем же принципиальная разница между:

another_type_t a;
my_type_t b( &a );
a.some_method();

another_type_t a;
my_type_t b( a );
a.some_method();

Это кривая архитектура, не надо ее оправдывать.

есть мнение, что она растет *исключительно* за счет техпроцесса (35 нм, например), который улучшаться будет очень медленно,

Это мнение беспочвенно. Вы можете сравнить Ivy Bridge и Haswell. Техпроцесс один и тот же, разница в производительности на той же частоте порядка 10%.

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

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

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

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

Вот если бы это были гарантированные non-nullable сущности...

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

Ну не скажи. Обычно сохранение указателя будет «заметно» как для создателя класса, так и для клиента. Так что скорее всего, разработчики позаботятся о корректности(а если нет, то это будет легче обнаружить при code review или при следующих модификациях). Я уже не говорю о том, что обычно используются не сырые указатели, а умные.

& говорит о том, что передается не объект, а его адрес. В то время как в случае ссылки вообще не ясно, что туда будет передано, копия, ссылка и пр. И потому логично не сохранять такой объект, поскольку это не очевидно синтаксически.

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

А какая правильная?

Обычно сохранение указателя будет «заметно» как для создателя класса, так и для клиента.

Для клиента точно не будет.

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

Если речь про shared_ptr/weak_ptr, то таким образом явно обозначается совместное владение. Не всегда оно нужно. Кроме того, в многопоточной программе shared_ptr может вести к лишним накладным расходам.

Если речь по unique_ptr — то это отличный способ передать владение другому объекту. Именно он должен использоваться в этом случае.

Если же код пишет нормальный разработчик, то возможны следующие варианты:

// Передача для чтения и изменения объекта.
// Объекта может не быть, т.е. разрешена передача nullptr.
void f1( std::string * s );

// Передача для чтения.
// Объекта может не быть, т.е. разрешена передача nullptr.
void f2( const std::string * s );

// Передача для чтения и изменения объекта.
// Объект должен существовать.
void f3( std::string & s );

// Передача для чтения.
// Объект должен существовать.
void f4( const std::string & s );

// Передача для полного владения и уничтожения.
// Существование объекта не гарантируется.
void f5( std::unique_ptr< std::string > s );

// Передача для совместного владения.
// Существование объекта не гарантируется.
void f6( const std::shared_ptr< std::string > & s );

Только про функции f5 и f6 пользователь может заранее знать, что им позволено сохранять у себя s. В остальных случаях из прототипа функции никакого вывода сделать нельзя, нужно смотреть либо в код, либо в документацию.

Так что в этом плане между ссылками и указателями разницы нет. Только ссылка явно требует существование объекта на момент вызова. Указатель же говорит, что вполне возможна передача nullptr.

Но это в случае нормального использования C++. Даже по «знатокам» в этом обсуждении видно, что этого ждать не приходится. Поэтому если в чужом коде видишь функции вида f1 или f2 ничего заранее не предугадаешь, нужно разбираться в подробностях.

PS. Rvalue references из C++11 специально не рассматривались, дабы не увеличивать объем текста.

Кстати, в C++14 возможно будет std::optional(сейчас есть boost::optional).

По сути я со всем согласен.

Для клиента точно не будет.

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

это не настоящая модульность

Дык, я не спорю. Говорю же - эмулировать. Впрочем, мне по прежнему интересно чего такая «ненастоящая модульность» не может, что может настоящая. Кроме, большего удобства, разумеется.

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

Кстати, в D можно несколько файлов в один модуль (неймспейс) запихнуть? на сате пишут однозначно «Modules have a one-to-one correspondence with source files». Конечно, есть пакеты. Но интересует можно ли несколько файлов в один общий неймспейс поместить.

constexpr в C++ явно требует указать, что это CTFE.

Во первых, в D местами тоже надо «подсказывать» - речь о «static if». Хотя он и для «условной компиляции», вроде как, использоваться может. Но в том числе и используется, чтобы показать, что это надо именно во время компиляции считать.

Во вторых, автоматическое вычисление «всего подряд» во время компиляции, насколько я вижу, иногда вызывает забавные последствия (access Violation when printing result of std.algorithm...).