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

Кстати говоря, в Qt уже давно есть интеграция с STL-ными вещами. И те же QtString могут получать в конструкторе ссылки на std::string.

Ещё добавлю, что Qt-шные контейнеры имеют stl совместимыe интерфейсы, так что их можно в стандартных алгоритмах использовать.

Причём это не только Qt касается. Если заглянуть скажем в wxWidgets, то там их контейнеры тоже имеют стандартные интерфейсы (бегин/енд, поддержка итераторов и т.д.).

* или же сопровождает старый-старый код.

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

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

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

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

Не очень понял вашу мысль. Вы предлагаете клиентам писать на D самим? Уверяю вас, они не будут писать даже на питоне.

Ведь успех QML же отсюда растет - дизайнер может обойтись без программиста

Дизайнер - не клиент. И таки да, дизайнер не должен иметь никакого отношения к программисту. Но они оба работают над результатом, который нужен клиенту.

Вангую дальнейшее размытие понятия программист

История говорит нам, что при развитии отраслей, наоборот, усиливается специализация.

Там был конкретный ответ на заявление о том, что C++ развивается под влиянием D =) Так что ваши рассуждения не в тему.

Слушайте, у D вообще стандарта нет=)

Где это в стандарте?

Что именно?

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

Насчёт поддержки ГЦ можно глянуть тут (в разделе «Garbage collector support»).

Про наличие реализаций уже упоминали. Да, не в стандарте, а в качестве сторонней библиотеки. И что? Речь то шла про принципиальную невозможность.

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

Есть стандарт де факто.

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

Может хватит эту мантру повторять? Я уже сто раз сказал, что некоторый интерес есть и изучаю язык глубже. Это не мешает в спорах участвовать и замечать минусы (как и плюсы).

А то у вас смешно получается. Постоянные утверждения какой замечательный язык Д, но как только выясняется, что что-то криво или чего не хватает, то сразу начинается обвинения в необъективности и желании найти «грязь» и прочие фантазии.

Может не надо за меня решать, что мне надо? Сеанс «телепатии по интернету» не заказывал. Тем более, что я отвечал вообще на вам.

В любом случае, по существу есть что сказать? В смысле ответить на процитированный вопрос. Я даже напомню его - «что В D есть такого, чего не было нигде до этого?».

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

Из нескольких известных мне людей, пишущих сугубо прикладные программы на C++ (не только из университетской среды, но и из промышленности), все используют передачу по указателям, ручное вычисление адресов и явное освобождение памяти.
Этому он учит студентов и использование других средств карает, а стандарт C99 для него «никому не известная фигня».

По моему опыту, студентов всегда приходится «переучивать». И если в конторе практикуется кодеревью, то таких ужасов в коде нет. Хотя может мне просто везло.

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

За время разговоров о модулях в С++, у меня уже дети успели вырасти. Интересно, ко времени появления внуков модули в С++ появятся? :))

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

Не стыдно задавать такие вопросы в 21 веке?

А то у вас смешно получается. Постоянные утверждения какой замечательный язык Д, но как только выясняется, что что-то криво или чего не хватает, то сразу начинается обвинения в необъективности и желании найти «грязь» и прочие фантазии.

Смешно получается у вас. «Я изучаю язык глубже» - а сами даже не читаете спеки. При этом постоянно показываете, что это вам не нравится в языке, это вам не нравится в языке. Так вас никто и не уговаривает. Не нравится не ешьте, повторяю еще раз. Когда человек испытывает реальный интерес, то он испытывает интерес к тому, что ему интересно, простите за тавтологию. А когда человек испытывает интерес к языку, в котором ему ничего не нравится и в котором он находит постоянно одни минусы - я с трудом назову это интересом к языку. В группу новостей же никто из присутствующих не зашел и не задал интересующий его вопрос - какой это интерес к языку? Это всего лишь интерес именно в этом топике показать, что D это говно, а я умный. Ну, или наоборот, что я умный, а D это говно.

Рассказать каждому, чем язык D может быть полезен именно для него - простите, я даже не собирался этого делать. У каждого свои задачи. И не всем D подойдет. Но это не значит что D плохой и т.д. Еще раз объясняю - не нравится язык, не используйте. Интересен язык - милости просим в нг. Там смело задавайте вопросы и на них исчерпывающе ответят. Все очень просто.

За время разговоров о модулях в С++, у меня уже дети успели вырасти. Интересно, ко времени появления внуков модули в С++ появятся? :))

Одно дело «разговоры», другое - обсуждение комитетом. Но всё-таки речь не об этом шла. А о принципиальной возможности. Так ведь даже реализация есть, пусть и «экспериментальная».

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

Не стыдно задавать такие вопросы в 21 веке?

Ну просвяти меня тёмного. Языками с модулями пользоваться приходилось (хотя бы С#), но видимо не понимаю что я теряю в C++. Самое раздражающее - это замедление компиляции. А ещё?

Вам сколько лет, если не секрет?

Ну просвяти меня тёмного. Языками с модулями пользоваться приходилось (хотя бы С#), но видимо не понимаю что я теряю в C++. Самое раздражающее - это замедление компиляции. А ещё?

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

Нет.

«Я изучаю язык глубже» - а сами даже не читаете спеки.

Пока по книге продвигаюсь. С++ изучать по стандарту тоже не самая лучшая идея. Или под спеками D что-то другое подразумевается?

При этом постоянно показываете, что это вам не нравится в языке

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

Так вас никто и не уговаривает.

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

В группу новостей же никто из присутствующих не зашел и не задал интересующий его вопрос - какой это интерес к языку?

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

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

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

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

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

Это был очень плохой код=)

Нужно рассказывать что модульный принцип держит код в более

сухом и чистом виде?

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

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

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

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

А тут не совсем понял. Чем в С++ хендер + спп файл в этом плане не «модуль»? Тем, что автоматически в отдельный неймспейс не попадает?

Вам сколько лет, если не секрет?

Не секрет - 27. Ну и чисто ради интереса ваш тоже было бы интересно узнать.

Ну и ответ по существу получить всё-таки надеюсь.

46

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

«Я изучаю язык глубже» - а сами даже не читаете спеки.

а где, кстати, спеки?

Все понятно, что модули удобнее. Именно поэтому их и собираются добавлять. Но это не мешает следовать принципам модульность в С++.

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

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

Это всего лишь интерес именно в этом топике показать, что D это говно, а я умный. Ну, или наоборот, что я умный, а D это говно.

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

умный человек всегда будет _*критически*_ оценивать что-то (в данном случае Д), что ему предлагают на замену тому, чем он сейчас пользуется (в данном случае с++)

и критическая оценка совсем не отменяет *интерес* к чему-то новому

Все понятно, что модули удобнее. Именно поэтому их и собираются добавлять. Но это не мешает следовать принципам модульность в С++.

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

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

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

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

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

После этого позволю себе высказаться резко. Когда D начинают рекламировать люди с такими воззрениями на профессию программиста, мне становится намного спокойнее за будущее не только C++, но и других замшелых мейнстримовых языков, включая Java и COBOL. Ну а D, пока вокруг него толпятся и размахивают руками такие сторонники, ничего не светит.

Для меня уже давно медицинский факт в том, что до стабильного релиза и нормального развития с оглядкой на коммьюнити и совместимость D не дойдет.

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

по этой теме: я считаю, что спроектировать язык так, чтобы он, оставаясь стабильным, мог все же подвергаться развитию (!) — это весьма сложная, но решаемая задача; однако, если она в *явном* виде не поставлена на *1-м месте* — то и решения ожидать не стоит, через N лет из нового языка получится тот же бурелом, то же нагромождение плохо совместимых пластов, как из современного с++

так что даже если и дойдет до стабильного релиза, через N лет получится все равно что-то вроде современного с++

Вы это расскажите программирующим пользователям по классификации glebiao - к которым отношу себя и я. Я не являюсь программистом в моем понимания, потому что я решаю свою задачу с помощью программирования потому что другого способа нет. Но у меня задача главнее чем программирование. Мне деньги платят за решение задачи, а как я ее решу это другой вопрос. И вот для таких практикующих программистов, а их хватает, дружелюбность языка играет заметную роль. Как я уже приводил пример питона в среде научных сотрудников. Посмотрите на тему ГИС - там очень много людей далеких от программирования во многих смыслах осваивают питон. И реально на нем пишут. Посмотрите на ту же QGIS, хотя сама она на Qt основана, многие модули к ней написаны на питоне именно программирующими пользователями, а не программистами. Да, она тормознутая на мой взгляд, многие вещи сделаны неоптимально, глюки выскакивают и т.д. Но это реальный тренд - увеличение количества людей, которые пишут код не являясь программистами. Вы можете отрицать это, не соглашаться, но это объективная реальность.

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

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

Это я у себя в блоге писал.

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

Конечно. Можно было бы посмотреть на развитие Turbo Pascal и Delphi. А затем и C#.

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

Абсолютно согласен!

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

facepalm.jpg

доказательства какие-то будут?

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

я? говном исходить? даже не начинал :-) ты не знаешь лор :-)

польза от человека может быть 2 *несовместимых* типов:

1. задавать ему вопросы *о языке* (возможно с подколкой) и слушать ответы *о языке*

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

выбирай

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

доказательства какие-то будут?

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

выбирай

Ну надо же. Прямо выбор мне предоставили. Да не нужен мне ваш выбор. Просто не нужен и даже смотреть ничего не буду. :)

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

Типа одолжение мне делаете? :D Я свой выбор уже давно сделал, а насчет зубы поскалить я это делаю с удовольствием и умеючи. Но нет у меня такой цели. Считаете меня п.1 - ваше право. Бороться за звание быть п.2 в ваших глазах - вот посмешили. :) Даже пальцем не пошевельну.

Почему я должен тратить на это время?

По-моему вам никто не мешает пройти мимо=)

Можно, я именно так сейчас и делаю. Для этого у исключений и есть поле msg.

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

исчезнут гарантии синхронизации имён

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

Как родные опциональные параметры методов D.

тут сразу несколько проблем, возьмем за пример:

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

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

REST не подразумевает никакого влияния на логику по определению

а я и не говорил про влияние

Можно было бы посмотреть на развитие Turbo Pascal и Delphi. А затем и C#.

Это история успеха или наоборот?

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

Их всегда было много. Раньше, возможно, их было даже больше. Программированием занимались математики и физики. Да даже биологи(Докинз, например) =)

Сейчас, наоборот, большая специализация.

Понятное дело, что это только часть заказчиков

Это не заказчики. Это работники.

Это история успеха или наоборот?

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

А в отношении C# это, полагаю, еще и история успеха.

Вот это верное замечание.

Это история успеха или наоборот?

C#, скорее, видимо история успеха — ты вот сможешь так взять и сходу накидать несовместимостей между пластами в C#, подобных

class Base { .... };
class Derived: public Base { .... };
Derived array[10];
Base* ptr1 = &(array[1]);
Base* ptr2 = ptr1+1;

Я слабо с ним знаком.

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

Собственно, это уже резко сужает нишу.

Во-первых, вам явно не приходится сталкиваться с особенностями командной разработки.

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

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

Так что при всем уважении к вашим разработкам и опыту, я могу предполагать, что вы находитесь далеко от индустрии разработки ПО, в которой в силу множества причин востребованы Java, C#, Perl, Python, Ruby и еще с пару-тройку десятков языков, включая C++.

Слушайте, у D вообще стандарта нет=)

У Питона тоже нет :) И, кстати, примерно 15 лет его считали маргинальным поделием, ни на что не годным вследствие тормознутости, странного синтаксиса, отсутствия стандарта, непрерывно вносимых изменений (помним, что в той же ветке 2.x объявленные в 2.x устаревшими свойства удалялись в 2.x+2). А когда они, не добившись ещё полной тотальной популярности в 2007 году решили всё сломать и сделать Python 3K, народ вообще за голову схватился.

TL;DR = «pure без системы эффектов малополезно, а то и бесполезно»

Ключевым фактором тут является то, что f тоже должно быть чистой функцией. Или необходимость транизитивности для pure тоже вызывает сомнения?

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

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

float[] transform( const float[] src, float function(float) pure f ) pure {
  float[] dst = new float[src.length];
  for (int i=0; i < src.length; ++i) {
    dst[i] = f(src[i]);
  }
  return dst;
}
float[] transformМ( const float[] src, float function(float) f ) {
  float[] dst = new float[src.length];
  for (int i=0; i < src.length; ++i) {
    dst[i] = f(src[i]);
  }
  return dst;
}

собственно, имеем те же проблемы, как и в хаскеле вместо языка программирования — монады вместо эффектов

предположим, что есть две функции f1 и f2, которые, хотя и не являются чистыми, коммутируют:

int var1=0;
int var2=0;

float f1(float x) { ++var1; return 1*x; }
float f2(float x) { ++var2; return 2*x; }

человеку очевидно, что код

	float[] input = [ 1.0, 2.0, 3.0 ];	
	float[] out1 = transformМ(input, &f1);
	float[] out2 = transformМ(input, &f2);

	float[] input = [ 1.0, 2.0, 3.0 ];	
	float[] out2 = transformМ(input, &f2);
	float[] out1 = transformМ(input, &f1);

но как насчет компилятора? пусть ему видны оба определения f1 и f2 (или даже они inline), но не видно тело transformМ, а только виден его прототип

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

Не будет, конечно.

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

поэтому, мне кажется, ты не прав

кстати, интересно было бы забенчить несколько «массивных» операций Д и аналогичных в с++, *специально* не юзающих стандартную библиотеку

чуть дополню свой коммент Facebook платит за устранение багов в реализации языка программирования D (комментарий)

Q: почему бы не обойтись одной transformM?

A: потому что pure вирусна, и где-то потребуется именно transform, которая pure

Q: почему нельзя переставлять 2 функции transformM?

A: потому что компилятор не знает, может, у transformM ключевая строка выглядит так:

     dst[i]=f(src[i])+var1;

Это так и есть. Это исследовательский язык.

это какой-то детский сад, а не исследование

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

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

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

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

• Преимущество разделяемых данных при обмене между потоками мнимое, поскольку современные процессоры имеют большой раздельный кеш для каждого ядра. Поэтому будем копировать данные между потоками. Отсюда, в частности, immutable.
• Явная работа с указателями есть зло всегда, кроме особо системных случаев. Поэтому синтаксис должен быть построен так, чтобы обычный несистемный программист указателей не видел.
• Шаблоны должны быть простыми и понятными, иначе ими никто не станет пользоваться, кроме некоторых любителей и сильно матёрых гуру. Но этих людей мало. Если же многие не станут пользоваться шаблонами, будет свалка.
• У большинства базовых вариантов: массивов, ассоциативных массивов (словарей), кортежей, строк и прочих комплексных чисел должна быть одна стандартная реализация. Её отсутствие или недостаточная проработанность ведёт к зоопарку (что мы уже видели даже на примере самого D1 с двумя «стандартными» библиотеками).
• Сборщик мусора должен быть и должен быть включён по умолчанию. Если вы такой джедай, что он вам не нужен, вы его выключаете и работаете, как хотите. При этом на вас смотрят либо как на прокажённого, либо как на святого (иногда эти понятия пересекаются). Потому что иначе память будет течь (все мы грешны). Это не значит, что сборщик мусора не может ошибаться, но исправить 1 сборщик мусора всегда проще/лучше, чем править 100500 написанных без него программ.
• unittest должны быть встроены в те модули, где написан сам тестируемый код, иначе они теряются и на них все забивают. Их включение/исключение из проекта регулируется ключом компиляции...

Это, конечно, неполный список. Я не претендую на всеведение.

и что мы видим - тормозные компиляторы для D и никакого CTFE

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

вот быстрый пример:

import std.stdio;

template Fib(T)
{
	//100 max 
	T[100] fib_memoized = [];
	//eponymous trick
	T Fib(T n) { 

				
			if (fib_memoized[n] == 0)
			{  scope F = _Fib(n);
				fib_memoized[n] = F.value();
			}	
				return fib_memoized[n];
		    }			
			
  struct _Fib {
	  private:
		T _value;
	  public:
		this(T n) { _value = n; }
	  	T /*int*/  value() {
			if (_value <=2) return 1;
			T f2 = Fib(_value-2);
			T f1 = Fib(_value-1);
			return 	f1 + f2;
		}	
  }	//_Fib
} //Fib

int main()
{
        for (int i = 0; i < 10; i++)
        {
        // вместо
        //         scope const Fib x = Fib(40);
	auto x = Fib!(int)(40);
                writefln("n=%d", x);
        }
        return 0;
}

вот быстрый пример:

LOL, и это предлагается вместо варианта на С++? С++ и до С++11 мог на шаблонах посчитать в compile time

ну посчитай мемоизацию на шаблонах в плюсах, а я посмотрю =)

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

вообще, в чём смысл теста? померять, насколько быстро могут создаваться вложенные объекты?

это ежу понятно, что в случае D + gc + typeinfo будет немного помедленнее, чем в С++ и объекты в стеке

твои примеры на C++ и на D не эквивалентны — в случае C++ constexpr конструктор как бы говорит нам, что объект меняться после создания не будет. и компилятор скорее всего соптимизирует разные инстансы внутри цикла в один.

в случае D — это не так. это надо дополнительно обеспечивать. намекнуть, что объект константен.

или, как в моём примере: обёртка шаблонами кода на объектах. или шаблонами + концептами.

твой тест меряет время создания инстансов объектов, ничего более.

даже если так, то, value() константен  — в С++ задаётся руками, в D CTFE может вывести (при соблюдении некоторых условий)

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