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

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

Рефлексия когда-нибудь будет, пока есть type_traits.

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

Подобные вещи сейчас делаются руками на SFINAE и std::enable_if. Концепты тоже будут.

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

Так диапазоны применительно к С++ - это просто пара итераторов. Есть Boost.Range.

Модульность - свойство системы, а не языка.

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

Я именно это в виду и имею.

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

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

с одной стороны, я за встроенные тесты — с точки зрения single source, когда тесты и код разрабатываются в одном месте, совместно

с другой стороны, функциональность не дотягивает до того же JUnit

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

отдельных библиотек, или на базе встроенной возможности?

я так понимаю, что у отдельных библиотек типа JUnit плюсы в том, что можно произвольно определять, как будет вызываться тестовый набор из тестпакета, например: обойти всех, выдать PASS/FAIL/XFAIL/XPASS для каждого (не останавливаясь на первом assert-е FAIL-а). выдать в любом удобном машиночитаемом виде, например xml JUnit report и сравнивать потом diff, xmldiff, xml+xhtml+css и т.п.

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

и когда там пишем в шаблонах class C, что означает что другой typename, не класса не пройдёт в подстановке

Пройдет=)

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

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

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

Ок, принято. Это действительно существенно.

Пройдет=)

«Это фейл» (ц)

и когда там пишем в шаблонах class C, что означает что другой typename, не класса не пройдёт в подстановке

И да, мало того что он пройдет, так class в C++ совершенно не обязан быть связан с ООП. В STL нет ООП, но там везде class'ы=)

От структуры класс в С++ отличается только доступами по умолчанию(для классов наследование и доступ к членам по умолчанию private, а для структур - public).

Это историческое наследие. Сначала был class. Фейл там в другом месте, шаблонные шаблонные параметры должны быть объявлены как class=)

или проверить что есть поле типа hasLength

В ОО языке проверка на наличия поля в объекте не есть разумно. Разумнее проверять наличие метода. А это, вроде как, на SFINAE делалось в C++98/03.

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

Это всё решает не компилятор, а хук из druntime. Изменяемый:

http://dlang.org/changelog.html#getunittest_trait

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

Вообще-то большая. Unit-тестов может быть очень много. Для ряда из них нужно делать специальные обертки/имитаторы. Держать все это добро прямо в исходниках не очень удобно. Особенно, если разработкой и/или сопровождением Unit-тестов занимаются отдельные люди в команде (например, junior-ы или новички в процессе обучения).

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

Можно список таких библиотек в студию? Чтобы избегать таких.

Да и верится с трудом по нынешним-то временам.

Вообще-то большая. Unit-тестов может быть очень много. Для ряда из них нужно делать специальные обертки/имитаторы.

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

D пока единственный язык, где я регулярно пишу тесты как тесты.

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

Ну и мне, как профессиональному разработчику, странно читать такие вещи. Хочешь делать качественный софт — пиши тесты. По другому никак.

Что до включения кода тестов в основной код. Вот, например, сейчас в библиотеке, которую я модифицирую, около 7.5 KLOC. А тестов к ней — порядка 4.8 KLOC. Правда, там тесты посложнее чем:

x.set_y(2);
assert_equal(x.get_y, 2);

так что плохого во встроенном unittest?

так что плохого во встроенном unittest?

Не масштабируется. В случаях маленьких утилиток «на выборос» работает. В больших библиотеках и приложениях, толку от встроенного unittest мало, все равно нужно тесты оформлять отдельно с помощью дополнительных фреймворков.

Вот, например, сохраняется ли код unittest в release build?

Ну и мне, как профессиональному разработчику, странно читать такие вещи. Хочешь делать качественный софт — пиши тесты. По другому никак.

Вы меня не поняли. Я всегда пишу тесты. Но оформлять их именно как unittest стандарным образом стал только в D. Раньше я просто писал дополнительную программу на Паскале и Фортране, которая использовала и тестировала мой модуль. В Питоне я обычно делал несколько дополнительных функций тестирования, которые вызываются при условии, что это модуль main:

if __name__ == "__main__":
    test1()
    test2()

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

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

умеет проверять контракты и запускать тесты по изменениям: AutoTest

Integrated testing tools and other new features and mechanisms in EiffelStudio 6.3 include:

Tool for managing and running test cases. 
Tool for the creation of manual test cases. 
Tool for automatic creation of test cases while debugging a failure. 
Tool for automatic creation of test cases via AutoTest, which exercises a class without programmer intervention to find all possible failures. 

тесты можно сгенерировать из контрактов

раз два

Built-in metrics, profiling, and Computer Aided Software Engineering (CASE) tools to have a better overall view of your design at all stages of development. 
Amazing browsing mechanism for viewing your code and giving you information on any part of your system to develop and optimize it to its full potential. 

last, but not least: BON, особенно книжкас примерами про отличие от UML :

в отличие от UML, в BON обеспечивается обратимость (reversibility) за счёт ограничений нотации и метода.

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

презентации фичи

ещё к тому же

и вот

метрики (наверно, ближе всего к тому, о чём ты спрашивал :) )

Не масштабируется.

Справедливо.

В случаях маленьких утилиток «на выборос» работает.

Почему сразу на выброс? Задачи разные бывают.

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

Справедливо, но для ряда задач большой фреймворк бывает избыточен.

Вот, например, сохраняется ли код unittest в release build?

Нет. Во всяком случае не должен.

Вот, например, сохраняется ли код unittest в release build?

У Александреску в книжке написано, что при release все unittest выбрасываются. Я ему верю.

кратко про BON и отличия от UML

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

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

У Александреску в книжке написано, что при release все unittest выбрасываются. Я ему верю.

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

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

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

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

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

ну pdf по первой ссылке мне уже нравится.

хотя костыльно как-то:
* отображение модулей и umbrella modules это костыль ;
* неймспейсы не под контролем модулей. два костыля в одном это не баг, а фича, да

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

не думаю что это получится быстро — если некоторые и прекомпилированные хедеры ниасиливают, и на вопрос «а что такое нормальная физическая структура проекта» / «Good physical design matters also»

тупо смотрят «а чёйто? физическая структура — не, не слышал»

For a detailed coverage of physical design principles, read: Large Scale C++ Software Design, by John Lakos

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

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

«Если бы губы Муклы Ефимовны да приставить к сискам Бешайн Никитишны, да взять сколь-нибудь развязанности, какая у Памелы Дормидонтовны, да, пожалуй, прибавить к этому еще жопу Дженны Джеймсовны — то это же пиздец просто, что получится»

Модульность - свойство системы, а не языка.

В нормальном языке модули и инклуды и разделяемые библиотеки это ортогональные концепции.

Например, вот Common Lisp — нормальный язык: единица компиляции это пакет, модуль; библиотека пакетов, система — единица компоновки как «разделяемая библиотека», а инклуды это вообще ad-hoc костыль и monkey patching, который всерьёз никто не воспринимает.

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

Фейл там в другом месте, шаблонные шаблонные параметры должны быть объявлены как class=)

это уже фейл фейла =)

то что шаблоны не first class object как бы со всех щелей лезет: модули, параметры, проверка типов

ну да, SFINAE работает. хотя и костыль. просто в D механизм более универсален: через is проверить, что код, использованный в таком-то контексте вообще компилируется, и если нет — подстановка это и есть ошибка.

хук из druntime. Изменяемый:

http://dlang.org/changelog.html#getunittest_trait

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

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

и да, модули и тестпакеты — это ортогональные концепции, так что или упрощать тестпакеты для 1:1 или всё-таки разделять концепции.

в этом смысле нравится фича Amber (форк D1, который авторы Tango пилят для LLVM): настраиваемые аннотации как в .NET.

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

Если у меня в библиотеке 2/3 кода будут составлять unittest-ы и я их оставлю в release build-е, то зачем мне библиотека такого объема? А если кода тестов даже больше, чем прикладного?

Когда тесты отдельно, этой проблемы нет. Библиотека может быть 10Mb, а тестов к ней — 100Mb и ничего страшного, тесты можно вслед за библиотекой не распространять.

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

Почему не решает? Есть lib или dll/so, из которой наружу торчит какой-то API. Этот API одинаково дергается из тестов вне зависимости от того, в каком режиме скомпилирована lib/dll/so.

ну да, SFINAE работает. хотя и костыль. просто в D механизм более универсален: через is проверить, что код, использованный в таком-то контексте вообще компилируется, и если нет — подстановка это и есть ошибка.

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

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

Если у меня в библиотеке 2/3 кода будут составлять unittest-ы и я их оставлю в release build-е, то зачем мне библиотека такого объема? А если кода тестов даже больше, чем прикладного?

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

Почему не решает? Есть lib или dll/so, из которой наружу торчит какой-то API. Этот API одинаково дергается из тестов вне зависимости от того, в каком режиме скомпилирована lib/dll/so.

Вы когда-нибудь работали с системами реального времени? Иногда даже протоколирование искажает работу системы.

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

мне тоже не хватает встроенного, хотя что-то вроде метаданных/аннотаций, как @Test в JUnit вполне хватило бы

хочется видеть: название теста, название тестового набора, более подробное описание вроде PASS/FAIL/XFAIL/XPASS, независимость тестнабора от модулей.

с другой стороны у single source есть свои прелести, но на этот случай можно и грамотное программирование осилить :))

хотя, когда читаешь книгу Александреску — очень практично выглядит встроенный: dmd -version=unittest , рраз, сел и поехал

Вот, например, сохраняется ли код unittest в release build?

там, ЕМНИП, физически разные бинарники надо генерировать для -version=unittest и как обычно, то есть, почти как в питоне с __main__

BON

You have reinvented UML but worse.

Есть lib или dll/so, из которой наружу торчит какой-то API. Этот API одинаково дергается из тестов вне зависимости от того, в каком режиме скомпилирована lib/dll/so.

И языковая поддержка unit-тестирования мешает этому... как именно?

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

интересно, отловил бы его статический анализатор?

Вы когда-нибудь работали с системами реального времени? Иногда даже протоколирование искажает работу системы.

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

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

Вы когда-нибудь работали с системами реального времени? Иногда даже протоколирование искажает работу системы.

плохое, негодное протоколирование. Берёшь цифровой осциллограф, например Novena ноутбук с FPGA, пишешь логгер, и пускай себе в фоне парсит протокол куда-то в лог.

а потом отыгрываешь лог в тест вместо в систему реального времени.

с другой стороны у single source есть свои прелести, но на этот случай можно и грамотное программирование осилить :))

Да, при быстром прототипировании D-шный unittest очень привлекательная штука. Сам ей пользовался.

Но не масштабируется. Как только переходишь от прототипа к чему-то большему, нужно переходить на другой инструмент.

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

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

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

И языковая поддержка unit-тестирования мешает этому... как именно?

Боюсь, ты не того человека спрашиваешь.

Мой пойнт таков: если unittest-ы лежат прямо в коде либы, то размер либы может сильно увеличиваться, что есть плохо. Так же плохо то, что при компиляции в release режиме код unittest-ов выбрасывается. Поэтому ты не можешь быстро проверить, проходят ли unit-тесты в release-режиме.

Если держать unit-тесты отдельно, то нет ни увеличения объема либы, ни проблем с прогоном тестов в release-режиме.

плохое, негодное протоколирование. Берёшь цифровой осциллограф, например Novena ноутбук с FPGA, пишешь логгер, и пускай себе в фоне парсит протокол куда-то в лог.

Я собственно об этом и говорил. Хотя даже тут есть нюансы.