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

алсо, чтобы два раза не вставать:

посмотри на обучалку по шаблонам в D, и скажи, вот как на С++(11/14/whatever) реализуются следующие штуки:

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

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

• * рекурсия в шаблонах через static if /* в D-templates-tutorial «Rank for Ranges» — cобственно, его весь можно подряд читать, на предмет того «а как это будет в С++» */

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

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

• * tuples для последнего аргумента шаблона

• * type tuples std.typecons

• * IFTI /* в D-templates-tutorial */

• * mixin templates

• * string mixin, как пример: Goldie parser static или Pegged — здесь во время CTFE отрабатывает сгенерированный генератором парсеров парсер. активно пользуются mixin templates, и прочими. Во время компиляции можно ругнуться и бросить static assert — не в runtime, при соблюдении некоторых условий на CTFE

D шаблоны мощнее, чем в С++ — это факт.

Напиши на constexpr трассировщик лучей и сравни %)

https://gitorious.org/metatrace

о да. сравни этот упоротый код с простым и понятным кодом на D

http://h3.gd/ctrace/

это ещё D1. на D2 было бы проще.

Note: ctrace was developed when D didn’t have Compile Time Function Evaluation and uses only the functional sub-language of template metaprogramming. Using CTFE, ctrace could be made hundreds of times faster and look like normal runtime code. But then it wouldn’t be fun anymore.

в общем, глядя в код паттерн заметен: обносим всё static if/static assert (в D2 появились ограничения концепта и прочие приятные штуки), засовываем то, что должно посчитаться в CTFE через enum/immutable/const foobar = myMegaTemplate!(all,other,parameters...) или в pragma и получаем профит — то, что должно считаться в CTFE считается именно во время компиляции, а не в рантайме.

Какой ужас. Трассировщик лучей на D тоже не отличается красотой, но там по крайней мере код на D, а не на интерпретаторе шаблонов.

о да. ctrace.zip/meta/Tuple.d

struct RecTuple(A, B = void, int depth = 0) {
...

static if (length >= 20) {
		static RecTuple opCall(typeof(val!(0)) a0, typeof(val!(1)) a1, typeof(val!(2)) a2, typeof(val!(3)) a3, typeof(val!(4)) a4, typeof(val!(5)) a5, typeof(val!(6)) a6, typeof(val!(7)) a7, typeof(val!(8)) a8, typeof(val!(9)) a9, typeof(val!(10)) a10, typeof(val!(11)) a11, typeof(val!(12)) a12, typeof(val!(13)) a13, typeof(val!(14)) a14, typeof(val!(15)) a15, typeof(val!(16)) a16, typeof(val!(17)) a17, typeof(val!(18)) a18, typeof(val!(19)) a19) {
			RecTuple res = opCall(a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14, a15, a16, a17, a18);
			res.val!(19) = a19;
			return res;
		}
	}

это прекрасно, я щитаю =)))))

хотя, это не D2, ага

«нефиг метать бисер где попало», «кому надо — тот знает»

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

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

илитота

я аж прослезилсо. внушаить !!!

Тебя не смущает то, что в данном случае ты сравниваешь работу реализации C++ (gcc, на оптимизацию которого затрачено много ресурсов) и dmd. Точно так же ты можешь сравнить gcc и clang. О самом языке это ничего не говорит.

да не, для грубых прикидок этой точности вполне достаточно:

* во-первых, он сравнивает и gdc тоже, хотя для чистоты эксперимента это должна быть одинаковая версия gcc и там, и там

* во-вторых, видно, что разница на несколько порядков, то есть за пределами погрешности измерений за счёт компилятора

* в-третьих, если пример с кодом на D поковырять: вынести инвариант из цикла, то мы видим более правдоподобное поведение, хотя тоже разница на порядки, но меньше

вывод: в случае C++ что-то оптимизируется лучше, в D (его примере) -- имеем создание объектов по нескольку раз на каждой итерации.

* в-четвёртых, если забубенить пример с мемоизацией, как я привёл, через обёртку шаблонами и eponymous trick, то видим, что объект создаётся по одному разу на каждой итерации (мемоизация же, другие повторно используются)

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

ИТОГО ВЫВОД: если криво написать CTFE на D, оно будет работать медленно. если написать нормально — будет работать нормально.

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

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

а потом вжжик — и стандарт поменялся. и опять по новой.

а потом — ещё раз поменялся. и ещё раз. и ещё раз.

в этом смысле D лучше уже хотя бы потому, что разрабатывается не design by commitee, а сообществом  — есть процессы DIP (RFC предложения типа как в питоне), есть общедоступный багтрекер.

есть официальный референс, 2 альтернативных компилятора; есть (кому надо) — велосипеды вроде Amber, SDC, D.NET, что-то своё из них при желании можно допилить проще, чем писать свой С++ компилятор, например.

сосбно, если мы собираемся как-то качественно сформулировать — то надо сформулировать требования к платформе:

- стандартный пакетный менеджер. dub в D, нихт в C++

- стандартная система сборки. Cmake(?) в C++; не нужна в D (но если очень хочется, waf, например)

- cтандартная библиотека. phobos, std2, и т.п. STL в С++

- стандартные батарейки. Boost, Qt, wxWidgets, ACE, и т.п. в C++. ХЗ что в D: (phobos, std2, DWT, D-GTK, хз что, и т.п.)

- стандартный способ тестирования. ХЗ что в C++, unittest в D (хотя, немного не дотягивает до JUnit-DUnit, например)

- стандартные IDE. Emacs/Vim/SciTE/Sublime/QtCreator/CodeBlocks/Eclipse-CDT/MS Visual Studio в С++. Emacs/Vim/SciteD/Sublime/хз.что/СodeBlocks/Eclipse-DDT/MS Visual Studio (VisualD)/MonoDevelop-D в D.

- стандартный отладчик. Visual Studio/Eclipse/DDT/gdb/windbg в C++. VisualD + конвертор PDB/Eclipse/ZeroBugs/gdb с патчами (проверить, что опять отвалилось)/windbg + конвертор PDB + деманглер в D.

- cтандартный профилятор. gprofile/valgrind/etc в C++. dmd -profile/gdc -profile/gprofile/valgrind + demangler/ etc в D.

ИТОГО:

- в C++ нет пакетного менеджера и профилятора - IDE все те же самые - ситуация с дебаггером не ясна, может работать, может нет. Настоящие программисты не используют дебаггер!!!

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

- остальные инструменты процентов на 80 те же самые.

Емакс везде тот же самый.

Батареек в смысле библиотек под С++ конечно больше, но:

* ты сравни, сколько лет оно писалось

* ты сравни, какой толпой оно писалось.

то есть, например, Qt или WebKit — сколько сотен разработчиков, сколько человеко-лет?

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

если написать нечто подобное на D, народу понадобилось бы меньше.

просто настоящих буйных пока нету. надеюсь, подтянутся.

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

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

лол. ну сравни «реальный код» на Phobos и реальный код на Boost, и время компиляции всего этого.

вот тебе реальный примерчик, да. с какой-нибудь функциональщиной на Phobos и на том же Boost.

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

Оптимизацией занимается gcc, который под D просто не заточен. То же самое с ldc. Итого нормального компилятора D сейчас нет.

а что с твоей точки зрения означает «заточенность под D», пример?

ldc и gdc это всё-таки довольно неплохой кодогенератор и оптимизатор gcc или LLVM. а не самописное нечто времён Zortech/Symantech/Digital Mars C++.

gdc и ldc оптимизируют лучше, чем dmd, но хуже, чем могли бы, ага.

но существует множество причин по которым код не представлен

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

во-первых даже с отключенной оптимизацией gdc намного медленнее g++,

потому что g++ написан на С++, а dmd всё ещё не переписан на D.

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

о да. а теперь подумай и представь себе use case, в котором эта фича

а) становится ключевой, и без нее — никак

б) не обходится никакими workaround-ами.

на ум приходит множественное наследование, которое есть зло.

и которое всё равно можно сделать workaround-ами если уж сильно приспичит.

D ничем принципиально от С++ не отличается.

* вменяемая модульность

* CTFE

принципиально.

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

ага, когда мейнстримным корпорациям делать нефиг, они яйца лижут изобретают языки под себя: вот гугл с Limbo Go, или лицокнига (а скорее, Александреску с тестировщиками и «2 часа на свои проекты») с D.

казалось бы, почему просто не использовать Си с двумя крестами: С++. хотя не, 2 креста это недостаточно круто. нужно с 4 крестами, C#, или, ещё круче — сразу с 8 крестами: С҈҉ .

вот тогда будет сразу отрада и благолепие.

О Торвальдс уже язык какой-то придумал? Расскажи. :)

вообще-то, да

Для некоторых вещей вроде миксинов множественное наследование очень круто подходит (loki, WTL/ATL). Если это парит неокрепший академический мозг, не используйте на своих проектах.

академический моск это не парит, это парит практиков-неосиляторов (см. про баттхёрт у Джоэля Сполски про «архитектурных астронавтов», про моникёры, аппартменты, WTL и прочую наследоту).

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

и хорошо бы. в конце концов, в голом С можно изобразить любую объектную модель (ObjC, C++, CLOS: COS), а в плюсах — только плюсовую.

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

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

теорема Тарского о невыразимости истины , знаете ли

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

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

исчо об этом

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

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

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

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

ты чо, ATL/WTL же.

ещё немного в Qt есть.

вопрос нужности всего этого — другое дело.

В скольких языках разработанных после С++ есть множественное наследование?

а где оно вообще есть кроме Eiffel, CLOS и C++ ?

Например, класс, который является widget-ом (наследником какого-нибудь QtWidet-а) и агентом (в терминах фреймворка SObjectizer). Такие виджеты мы использовали для прикручивания GUI к server-side приложениям.

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

ещё вопрос, какая реализация окажется лучше.

имело бы смысл прочитать «Объектно-ориентированное конструирование программных систем» Бертрана Мейера. Там только ООП, только «хардкор», никакой модной нынче функциональщины. Зато по ООП это одна из самых солидных книг.

да, книга классная. у него ещё новая версия «Почувствуй класс с Eiffel» появилась.

а фанатам функциональщины — читать Луку Карделли про ООП. «Object Calculi», про семантику ООП.

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

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

плагин вот такой для FFI — нужен. язык с поддержкой совместимости голого Си — не нужен.

а правда, eao197, вот ты же кучу языков перебрал, пока выбирал.

тот же Эйфель — почему не выбрал?

и вообще, на чём остановился (кроме С++), почему отказался от такого-то языка, что повлияло на решение?

вот еще моих мыслей на тему D, его прошлого и будущего: http://eao197.blogspot.com/2013/11/progflame-d-lor.html

Что-то из этого появилось у D за прошедшие 7 лет? Нет. Сам язык куда-то продвинулся, возможно. Но начинать на нем что-то серьезное, зная текущую ситуацию с инструментарием и прошлое этого языка? Может для каких-то задач это и оправдано. Например, для чисто вычислительных. Помнится, в списках рассылок D был некто Don Clugston, который рассказывал как он такими вещами занимался. Тут да, тут кроме языка и эффективного кодогенератора особо ничего не нужно.

появилось, да.

«официальный» пакетный менеджер dub, «официальное» место — вся активная разработка на гитхабе, в качестве IDE: VisualD (плагин к MSVS на D), MonoDevelop-D, Eclipse.DDT.

это из инструментария.

конечно, есть ещё чего допилить — но в основном, батарейки

Помнится, в списках рассылок D был некто Don Clugston, который рассказывал как он такими вещами занимался.

с DConf2013 позитивные новости были о применениях. тот же Don Clugston про «метапрограммирование в реальном мире».

ещё, откуда ветер дует с фейсбука: на DConf2013 был тестировщик из Facebook, расказывал как они применяют / собираются применять у себя D, в чем его преимущества (для тестировщика).

плюс, Александреску работает в Фейсбуке.

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

как раз в DConf2013 было 3-4 доклада про то, как фирмы успешно применяют D у себя in house.

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

так всё-таки, чем закончились твои поиски «с усугублением»?

так всё-таки, чем закончились твои поиски «с усугублением»?

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

а правда, eao197, вот ты же кучу языков перебрал, пока выбирал.

На самом деле не кучу. Плотно рассматривал и пробовал на зуб всего четыре D, Eiffel, Scala и Nice (был такой интересный язык для JVM задолго до Gosu и Ceylon-а, но был заброшен автором). Были еще какие-то языки, которые в short-list не попали, но я их уже и не вспомню.

С тем же OCaml-ом я знакомился несколько раньше, решил не связываться.

тот же Эйфель — почему не выбрал?

Самая главная причина — его цена. Не знаю как сейчас, а в 2007-м лицензия на EiffelStudio для одной платформы и одного разработчика была около $8K. Нам нужно было бы как минимум две платформы — Windows и Linux. Если добавить сюда скудость библиотек (сторонних вообще мало), да еще и некоторую многословность программ на Eiffel-е, то не понятно было, за что платить такие деньги.

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

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

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

ещё, откуда ветер дует с фейсбука: на DConf2013 был тестировщик из Facebook, расказывал как они применяют / собираются применять у себя D, в чем его преимущества (для тестировщика).

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

PS. Не знал, что VisualD все еще развивается. Думал, что разработка уже заглохла. Приятно было узнать, что ошибался.

т.е. ты кидаешь HTTPStatusException из реализации? или забиваешь на статус-код?

Вообще можно кинуть произвольный тип и сделать mapping «исключение» -> «код статуса» в обработчике. На практике мне лень и да, ошибки логики приложения заданы в терминах статусов HTTP. Тут обвинениям в нечистоплотности возражать не буду :)

гарантии дают только тесты

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

https://dev.twitter.com/docs/api/1.1/post/account/settings
...

Оверхеда не будет, если проверка чистоты параметров («это валидный UTF-8») происходит при десериализации - код метода в таком случае знает, что параметры гарантировано валидны. Если же речь идёт о проверке в более широком смысле («есть ли такой пользователь в базе»), то даже параметры по умолчанию всегда надо проверять в любом случае.

Первую проблему банально не понял :)

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

В «системном языке»? Ну ну. Сборщики(они разные бывают) полезны, но навязывать его не стоит(в этой нише).

unittest должны быть встроены в ...

Я вообще не понимаю, зачем встраивать такие вещи в язык?

в конце концов, в голом С можно изобразить любую объектную модель (ObjC, C++, CLOS: COS), а в плюсах — только плюсовую.

Это почему это? Какие возможности Си, позволяющие это, отсутствуют в С++?

В питоне, например. В Scala для trait'ов

На практике все эти ваши плагины выглядят как костыли.

транзитивность тут тоже вопрос не простой; допустим, что мне нужно код transform вызывать как с чистыми функциями (тогда он чистый), так и с нечистыми (тогда он нечистый); что делать?

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

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

При этом твой конкретный пример очень напоминает ситуацию с const, когда люди жаловались на необходимость делать шаблонными функции, которые отличаются только атрибутами параметра / типа результата. В качестве заплатки был введён атрибут inout (http://dlang.org/function.html#inout-functions). Думаю, хорошим решением было бы распространить его действие и на pure, но это решать не мне.

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

> unittest должны быть встроены в ...
Я вообще не понимаю, зачем встраивать такие вещи в язык?

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

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

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

Не знаю как сейчас, а в 2007-м лицензия на EiffelStudio для одной платформы и одного разработчика была около $8K. Нам нужно было бы как минимум две платформы — Windows и Linux. Если добавить сюда скудость библиотек (сторонних вообще мало), да еще и некоторую многословность программ на Eiffel-е, то не понятно было, за что платить такие деньги.

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

другие реализации — вроде поопенсорсней, хотя с батарейками там ещё хуже.

все платформы (+Mac и ещё какие-то замшелые юниксы, через компиляцию через Cи) там есть «из коробки». из коробки кроссплатформенность: нативный Win/Lin/Mac + .NET.

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

оправдывают тем, что в EiffelStudio всё «из коробки»: инкрементальная компиляция melted ice, тестирование по изменениям по контрактам, среда моделирования в тёплом ламповом BON вместо UML, какая-то фигня типа doxygen-а.

ещё у них с туторами и туториалами получше стало — пропаганда в виде видео, где решают какую-то конкретную задачу на конкретном примере, и агитируют за своих слонов.

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

коммерческая лицензия за 7к евро — и правда, дороговато.

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

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

вообще в принципе. если конкретно D, то alias this там позволяет эмулировать множественное наследование — с доработкой напильником, а когда (и если) реализуют множественный alias this, то и по-нормальному.

Я очень мало знаю людей, которые «не хотят» писать тесты. И очень много тех, кто вроде бы и не против, но очень уж лень :) Какими бы не были наивными тесты, это лучше, чем их полное отсутствие. В этом и есть простой практический смысл их включения в язык. D вообще чертовски не академичен и разрабатывается инженерами, которые «чистоту идеи» не очень уважают.

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

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

PS. Не знал, что VisualD все еще развивается

разработка перебралась на гитхаб, релизят регулярно

не знаю, видел ли ты такой мастер миграции с С++ (AST преобразованиями), профилёр, отладчик, другие фичи .

ещё, его в принципе не обязательно ставить в студию, голый Visual Studio Shell без языков вообще тоже подойдёт

* такой мастер миграции с С++

ссылка

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

ну кто вот он, если не тестировщик ?

Visual D другие фичи

•sources include tools to ◦convert some idl/h files of the Windows SDK to D ◦convert all idl/h files from the Visual Studio Integration SDK to D ◦convert C++ code to D (which was targeted at machine-translating the DMD front end to D, but this was abandoned) ◦convert Java code to D (which was targeted at machine-translating parts of the Eclipse plugin Descent to D, but this was abandoned)

Какие возможности Си, позволяющие это, отсутствуют в С++?

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

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

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

сдаётся, никак — и тогда С++ ничем не лучше.

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

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

но языки-то разные, поэтому какие-то обёртки всё равно нужны.

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

ну «unittest по месту» быстрее и «непосредственнее» написать, но тот же JUnit смотрится пофичастее. поэтому, ИМХО, надо и то и это — пока JUnit-подобное умеет нечто, что ещё не умеет встроенный unittest.

в D есть ещё над чем поработать. в тему Continous Integration.

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

в D со встроенным unittest — это не так, вся малина нарушается.

потом, он просто менее фичаст чем TestNG / JUnit / whatever.

хотя вот тут же как-то CI прикрутили.