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

алсо, этот же xml report в JUnit из Eclispe запускается одной кнопкой.

логично был бы и D-шный unittest из Eclipse/DDT запускать аналогично, а вот фиг.

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

Про CI - это не имеет никакого отношения к языку, вопрос исключительно инструментария. Я сейчас в свободное работаю над тем, чтобы предоставлять автоматический CI для всех проектов регистра code.dlang.org, по аналогии с Travis - к лету надеюсь закончить.

логично был бы и D-шный unittest из Eclipse/DDT запускать аналогично, а вот фиг.

В Mono-D есть. DDT сейчас вообще в роли догоняющего, два флагамана IDE в мире D это Mono-D и Visual D.

другое дело, что их можно генерить автоматически

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

> Сейчас речь про какой язык реализации идет?

вообще в принципе

«Вообще в принципе» не интересно :) Был конкретный язык, конкретная проблема. Решилась она идеоматичным для языка образом. Был бы вместо C++ Java или Ruby, там бы и решение было другое.

> Александреску не так давно говорил, что тестировщиков в FB нет.

я вот про это и оттуда по ссылке и обзор

Он не тестировщик, а разработчик. Просто в FB тестированием занимаются сами разработчики. Об этом Александреску недавно на reddit рассказывал.

18 страниц, ого. Чую, без лиспосрача не обошлось?

Странно. Только вялые попытки в районе 7-й страницы, да одиночные случаи бреда лиспонанимуса на 17-й.

Ну да ничего, никогда не поздно начать. Зачем D, если есть Common Lisp и Racket?

В Mono-D есть. DDT сейчас вообще в роли догоняющего, два флагамана IDE в мире D это Mono-D и Visual D.

Visual D эо виндовое поделие, насколько я понимаю. Mono-D есть ли под Линукс и откуда лучше качать?

статический анализатор

что умеет статический анализатор в эйфеле?

все это скорее d design rationale, а результатом исследования можно было бы назвать то, что написал eao197 (при условии, что оно было бы опубликовано самими исследователями)

вот, скажем, тройки александреску (или ranges) уже ближе к исследованию, правда это можно и не только в д делать

в общем, если какую-то академическую лицензию надыбать и кому-то читать лекции (собрав академической версию из SVN) — вполне вариант напоиграться, ИМХО.

В последние несколько лет ситуация переменилась. Есть возможность бесплатного использования EiffelStudio для проектов под лицензией GPL. И GPL-версию EiffelStudio можно загрузить с SourceForge: https://sourceforge.net/projects/eiffelstudio/

Для закрытых проектов нужно покупать коммерческую лицензию (стоимостью от $7.5K). Причем складывается впечатление, что 32-х и 64-х битовые версии EiffelStudio нужно покупать отдельно.

на практике, я говорю что другая объектная модель в С++ будет смотреться очень чужеродно, так как не будет интегрироваться «по умолчанию» с другими запчастями С++: языком шаблонов

ыыы!!!

1. чувак, ты бы посмотрел на с++ для начала

шаблоны не привязаны к ооп в с++ [ и да, иногда это напрягает, например когда в template<Base x, class T> f() хочется юзать как f<derived_instance, SomeClass>() ]¹

2. ты так говорошиь, что можно подумать, будто Своя Объектная Система в чистом си будет смотреться менее чужеродно

__________________________________

¹ сейчас может мой пример и скомпилируется

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

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

а таковых че-то не видно, не?

В текущем состоянии transfrom должен быть функцией-шаблоном - для шаблонов работает attribute inference (т.к. гарантировано наличие тела функции)

пример рабочего кода, пожалуста

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

При этом твой конкретный пример очень напоминает ситуацию с const,

совершенно верно

В качестве заплатки был введён атрибут inout (http://dlang.org/function.html#inout-functions).

он выглядит довольно прилично, только не ясно, с какого хрена он применятся только к функциям — например, если я хочу накатать класс с конструктором this(inout(int)[] foo), который иницилизирует поле inout(int)[] bar этим foo, ну и несколько методов, которые тоже... в общем, inout это такой полиморфизм, а не фича исключительно функций

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

то, что ты не видишь «веских причин», уже становится традицией

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

в смысле, каждую неделю новая такая дискуссия?

а вообще да, интересно

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

Тем не менее, писать эту муть время находится и «более насущные задачи» отходят в сторону.

Я бы ещё понял, если бы ты после первого ответа начал меня игнорировать. А так логики не наблюдается вообще.

По существу, штудируйте литературу, азы профессии нужно знать.

Понятно. Прикрывшись возрастом можно уйти от ответа? Ну ок.

отладчик в студии

Жаль, что интелисенс там очень уж слабый.

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

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

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

В D, насколько я понимаю, такое случиться тоже может. Но решить получается нельзя.

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

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

Везёт тебе...

* вменяемая модульность
* CTFE
принципиально.

Не, не принципиально. «Эмулировать» модули можно имеющими средствами, просто это «менее удобно». constexpr в С++ есть и развивается.

То есть преимущество (в удобстве, в основном) есть, но принципиальным его назвать сложно.

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

В смысле? В D структура сама как-то делается идеально? Или речь просто про то, что каждый файл = отдельный модуль в отдельном неймспейсе?

В С++ определённые «стандарты организации структуры» сформировались и так. И в более-менее вменяемых проектах с этим проблем нет. Тем не менее, язык говнокодить не помешает, это да.

Кстати, ситуацию когда в проекте есть два файла с одинаковым именем можно как-то разрулить без переименования и явного задания другого имени внутри модуля («module test»)? В разные «package» разносить?

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

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

Сборщик мусора должен быть и должен быть включён по умолчанию.

А вот тут большие сомнения есть. Решение в расте больше нравится - там и оверхеда не добавили практически и безопасность сохранили.

Хотя от (более) опционального сборщика мусора не отказался бы.

Кстати, ситуацию когда в проекте есть два файла с одинаковым именем можно как-то разрулить без переименования и явного задания другого имени внутри модуля («module test»)? В разные «package» разносить?

Такая ситуация подразумевала бы наличие двух файлов с одинаковых именем в одной директории. Такое вообще бывает? :) package / module в D привязаны к структуре файловой системы.

Mono-D это плагин для Mono-Develop (он же Xamarin Studio с недавних пор) - http://mono-d.alexanderbothe.com/

«Откуда лучше качать» очень зависит от дистрибутива, т.к. разработчики Mono-Develop обожают ломать совместимость plugin API в минорных релизах и плагин работает только на совсем свежих версиях. Сам плагин доступен через внутренний add-in manager IDE.

* проверить, что код компилируется /* ограничения концепта на сигнатуру функции. пример с Ranges: auto stride(Range)(Range r, size_t n) if (isInputRange!(Unqual!Range)); если Range другой Range, OutputRange, например, код не скомпилируется. */

Конкретно это делается на трейтах итераторов. Но вообще да, концептов в С++ нет. Впрочем, их Страуструп продвигает...

* проверить, что есть определённое поле /* template hasLength(R) из std.range */

Ну нормально проверить нельзя, да. Впрочем, рефлексию времени компиляции обещают. Когда-то будет.

* static assert времени компиляции

Есть именно static_assert.

* ограничения специализации шаблонов /* в D-templates-tutorial Templates Specializations" */

Специализация есть.

Хотя пдф смотрел по диагонали (позже подробнее посмотрю), мог что-то пропустить. Поэтому остальное тоже прокомментировать не могу. Ну кроме того, что миксинов В С++ нет.

пример рабочего кода, пожалуста

http://dpaste.dzfl.pl/c78390bc (выхлоп pragma снизу)

Хотя, я, конечно же, предпочёл бы более элегантное решение в духе inout.

он выглядит довольно прилично, только не ясно, с какого хрена он применятся только к функциям — например, если я хочу накатать класс с конструктором this(inout(int)[] foo), который иницилизирует поле inout(int)[] bar этим foo, ну и несколько методов, которые тоже... в общем, inout это такой полиморфизм, а не фича исключительно функций

Если я ничего не упустил, то оно не может так работать. Между конструктором и полем класса нет строгого связывания, следовательно, код, обращающийся к полю класса, не может знать, оно в данный момент immutable, const или mutable. Для функций оно работает благодаря тому, что входные параметры и тип результата - часть одной и той же сигнатуры, следовательно компилятор может подставить тип по маске (при том, что код функции один и тот же).

профит очевиден, на мой взгляд. сравни например итераторы в плюсах и ranges в D.

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

На мой взгляд (и там эта мысль тоже неоднократно прозвучала) итераторы гибче, ренджи удобнее в «отдельных случаях» (в других «отдельных случаях» могут добавлять оверхед или неудобства). При этом в С++ есть библиотечные рейнжи (boost range) и переход от итераторов к ним и обратно тривиальный. В D из рейнджей итераторы уже не получишь. Как минус - с итераторами проще «выстрелить в ногу» (ну как обычно в С++).

то, что ты не видишь «веских причин», уже становится традицией

Да, я зануда и верю только практической необходимости :) Если бы в сообществе D реализовывали каждое разумное предложение без тех самых «веских причин», в нагромождении фич и правил уже не мог бы разобраться сам Брайт. Как бы ни была хороша идея, без подробного жизненного case study она не нужна.

Такая ситуация подразумевала бы наличие двух файлов с одинаковых именем в одной директории. Такое вообще бывает? :)

Зачем в одной? Вот есть проект с файлами:

1/test.d
2/test.d
main.d

Error: module test from file 1/test.d conflicts with another module test from file main.d
Error: module test from file 2/test.d conflicts with another module test from file main.d

Получаю закономерную ошибку:

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

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

Что, до сих пор ничего не сделано по этому вопросу, никакого

import as

eins.test.func1();
zwei.test.func1();

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

а таковых че-то не видно, не?

видно.

гитхаб сайт PDF 1 2

объектная модель — на подобие CLOS, но для Си.

COS design is tuned to provide efficient portable implementation of these concepts, specially dynamic message dispatch (x1.7-x2.3 slower than an indirect function call and about x1.2-x1.5 faster than Objective-C) as well as generic message forwarding (as fast as message dispatch and about x40-x80 faster than Objective-C). On top of these concepts, it is easy to implement high order messages, class-predicate dispatch, multiple inheritance, dynamic inheritance, dynamic classes, adaptive object model, reflection and advanced memory management. It also simplifies the programming of multi-agent systems, distributed systems or adaptive systems. COS seems to achieve the principles 1-2-3 as well as existing mainstream scripting languages (e.g. PHP, Python, Ruby, SmallTalk) while keeping principles 4-5 in the range of C. Nevertheless, COS is compliant with POSIX threads and requires a (moderately compliant) C99 compiler.

в PDFах есть сравнение по скорости с C++ и Objective-C.

принципиальная фича: first class objects классы, метаклассы, свойства метаклассов, обобщённые функции.

ещё у него на сайте есть интересные минималистичные ООП объектные системы.

ещё есть попытка формализовать, жаль, неоконченная — объектную модель C++

C++ Object Model is a long paper (see object_model.html) started years ago which I unfortunately never finished (about 25% achieved), but is enough to understand the overall. It comes with a complete example in C (see cmd_c.sh) and C++ (see cmd_cpp.sh) which describes one way to implement the C++ object model (i.e. the g++'s object model). It is addressed to advanced (and motivated ;-) C and C++ programmers who have some interest in the C++ object model, so I put it here for curiosity. It may give you some hints about the implementation complexity corresponding to the management of dynamic types within constructors and destructors (i.e. intermediate vtbl) and covariant and contravariant types in the presence of multiple and virtual inheritance (i.e. thunks). I found interesting that my naive implementation of dynamic_cast is about x3 faster than the dynamic_cast provided by g++ ;-)

при нормальном метапрограммировании в языке весь этот boilerplate должен генерироваться CTFE функциями, макросами. тогда на уровне макросов такие объектные модели и должны уметь интегрироваться между собой.

например, генерировать макросами asm naked функции в совместимом с C++ ABI виде. или совместимом с ABI «другой объектной системы» виде.

Это никак не связанные вещи. Импортировать модуль можно под любым именем (import foo = some.nested.foo.mod;), но от этого его «настоящее» имя не изменится - оно существует на уровне name mangling в объектном файле. Проблема именно в том, как корректно определить собственное имя при компиляции модуля, у которого оно (имя) явно не указано. Сейчас это просто имя файла, из-за чего и возникает проблема в примере DarkEld3r

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

«Эмулировать» модули можно имеющими средствами, просто это «менее удобно».

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

constexpr в С++ есть и развивается.

это тоже какой-то ненастоящий CTFE.

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

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

для нормального CTFE нужна нормальная же модульность и раздельная компиляция, с созданием символьной таблицы модуля во-первых; и нормальная рефлексия времени компиляции, во-вторых. как минимум, возможность перебрать все экспортированные функции/переменные модуля, узнать их типы, и т.п. typeinfo.

например, см. Blackbox Component Pascal и его GUI «интеракторы».

создаём модуль с экспортированными функциями и переменными. выбираем в меню «создать GUI» и получаем автоматически форму, где функции вызываются по нажатию соотв. кнопки, а переменные вводятся в соотв. поля (если переменная внутренняя модуля, не экспортируется — в GUI она не создаётся).

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

В смысле? В D структура сама как-то делается идеально? Или речь просто про то, что каждый файл = отдельный модуль в отдельном неймспейсе?

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

В С++ определённые «стандарты организации структуры» сформировались и так. И в более-менее вменяемых проектах с этим проблем нет.

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

Кстати, ситуацию когда в проекте есть два файла с одинаковым именем можно как-то разрулить без переименования и явного задания другого имени внутри модуля («module test»)? В разные «package» разносить?

don't do that. циклические зависимости между модулями — туда же.

Ну нормально проверить нельзя, да. Впрочем, рефлексию времени компиляции обещают. Когда-то будет.

ну ограниченно её ещё в C++98 можно было сделать, для потомков своего класса. вручную херачить раскладку полей класса, и таблицы вроде MFC/ATL-ных сообщений класса, как-то так. пример см. в ООСУБД GOODS К. Книжника, его диссер 1998 года (реализация ООБД через реализацию метаобъектного протокола в C++ через реализацию рефлексии времени компиляции через свой ручной велосипед для того чтобы метаобъектами/метаклассами задавались «аспекты», как в ООП. один аспект реализует многопоточность, другой поддержку транзакций, третий — многопользовательность, конкурентность и т.п.)

вопрос в том чтобы это «из коробки» работало для всех классов, например как typeinfo в Object в D.

без подобных извращений с полями класса и таблицами макросами.

Есть именно static_assert

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

Специализация есть.

я про это

Templates Specializations Up to now, when we write a T in a template parameter list, there is no constraint on the type that T can become during instantiation. Template specialization is a small ‘subsyntax’, restricting templates instantiations to a subset of all possible types and directing the compiler into instantiating a particular version of a template instead of another. If you’ve read [appendix-isexpression] on the is() expression, you already know how to write them. If you didn’t, please do it now, as it’s really the same syntax. These specializations are a direct inheritance from C++ templates, up to the way they are written and they existed in D from the very beginning, long before static if or templates constraints were added. The specializations are added in the template parameter list, the (T, U, V) part of the template definition. Type : OtherType restricts Type to be implicitly convertible into OtherType.

помимо typeclass T в С++ в D там может быть alias или ограничения.

и опять же, про ограничения (без них далеко не так интересно).

например, про ограничения концепта if (isInputRange!(Unqual!Range)); или проверить что есть поле типа hasLength или проверить что компилируется код, рассчитанный на определённый template mixin (если нет, специализировать по-другому)

На мой взгляд (и там эта мысль тоже неоднократно прозвучала) итераторы гибче, ренджи удобнее в «отдельных случаях» (в других «отдельных случаях» могут добавлять оверхед или неудобства). При этом в С++ есть библиотечные рейнжи (boost range) и переход от итераторов к ним и обратно тривиальный. В D из рейнджей итераторы уже не получишь. Как минус - с итераторами проще «выстрелить в ногу» (ну как обычно в С++).

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

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

И очень много тех, кто вроде бы и не против, но очень уж лень

Это тоже самое, что «не хотят»=) В плане результата. И лень им, как я думаю, не из-за того, что юнит-тестов в языке нет - это вообще не проблема, инструментов много.

Какими бы не были наивными тесты, это лучше, чем их полное отсутствие. В этом и есть простой практический смысл их включения в язык.

Я вижу лишь недостатки в плане развития возможностей юнит-тестирования и пр.

вообще на тему «нормальной модульности» см. определение «Компонентно-ориентированного программирования» Клеменса Шиперски.

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

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

ну, теоретически и на С++ возможно что-то изобразить поверх указателей на члены класса (кажется, статья была про fastest delegates available на C++).

При чем тут указатели на члены? В С++ есть вон std::function и лямбды. Но что вам нужно?

на практике, я говорю что другая объектная модель в С++ будет смотреться очень чужеродно

На Си она будет смотреться столь же чужеродно.

не будет интегрироваться «по умолчанию» с другими запчастями С++: языком шаблонов, языком «необъектный си»

Шаблоны никак не связаны с ООП в С++.

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

Какая вам нужна объектная модель? А то без примера тяжело рассуждать.

Я вижу лишь недостатки в плане развития возможностей юнит-тестирования и пр.

ну а какая по сути разница, выносить тесты в отдельный тестпакет к этому и собирать/запускать отдельной тулзой (в стиле JUnit) или писать по месту и собирать/запускать с dmd -version=unittest ?

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

алсо, видел где-то на гитхабе JUnit-style DUnit для D, так что не проблема.

Шаблоны никак не связаны с ООП в С++.

и когда там пишем в шаблонах class C, что означает что другой typename, не класса не пройдёт в подстановке — это тоже «не связаны»?

связаны же.

Какая вам нужна объектная модель? А то без примера тяжело рассуждать

гибкая же. что-то вроде CLOS/ COS, но с сахарком и с интеграцией с другими «запчастями языка».

ок, а что не выглядит как костыли?

#include <stdio.h>

или

module std [system] {
//...
    module io {
        header "stdio.h"
        export *
    }
//...
}

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

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

Ну нормально проверить нельзя, да

Можно посредством SFINAE руками.

Это фейл.

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

Что с ней не так? Данные механизмы просто не так удобно использовать, но модульность там самая настоящая.