Вышла первая версия компилятора D, написанная на D

Всё уже продемонстрировано: http://stackoverflow.com/a/24000041/2935339

Вообще-то я просил строку сгенерировать, не «Convert a number to a string literal with constexpr», это во-первых. А во-вторых, я просил не через жопень. А то уродство, ссылку на которое ты привёл, иначе как «жопажопа» назвать нельзя :-) Вот что я хочу. Пусть есть функция:

template<class Args...>
Result get(Args... args);

Хочу, чтобы во время вызова

auto r = get("ivan", "ivanov", 25);

// сгенерировалось выражение
// SELECT * FROM table
// WHERE fname = $1 AND lname = $2 AND age = $3
// во время компиляции.

Да, была ещё тема перспектив D.

Проходишь по второй ссылке отсюда http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4236.html на гитхаб, забираешь оттуда удобную реализацию basic_string_literal и делаешь с её помощью всё не через зад, как ты выразился. Только твой пример ущербный ибо не понятно откуда get должно придумывать fname, lname и age.

Проходишь по второй ссылке отсюда http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4236.html

Обалдеть, для конкатенации строчки во время компиляции нужно написать почти 600 строк нечитаемого говна на цепепе, и для пущей важности оформить целый документ с серьёзным названием - N4236 :-) А всего то надо - сгенерировать строчку. Это стиль цепепе :-) Вот ведь где потеха настоящая, а ещё говорят лисперы... :-)

Только твой пример ущербный ибо не понятно откуда get должно придумывать fname, lname и age.

Пусть тебя это не волнует, откуда get придумает :-)

А всего то надо - сгенерировать строчку

Этот basic_string_literal и есть всего-то аналог std::basic_string для константных строк.

Пусть тебя это не волнует, откуда get придумает :-)

Он не может это придумать, если это не известно программисту.

Речь о неадекватно больших усилиях,

Ну блин, не учите, ктож заставляет-то? Где не нужно думать о производительности, там уже давно Java/C# и Python-ы с Ruby-ями, не говоря уже про JavaScript.

Где нужно думать о потреблении ресурсов, там либо C с goto cleanup, либо C++.

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

Профессионалу ничего этого и даром не надо. Многократно доказано, что для написания реально полезного программного продукта достаточно возможностей C.

Ну да, ну да. Школьники, может быть, вам и поверят.

Да, потому что смешивать mutable и immutable в таком виде - поиск приключений на свою голову. Добавлять поддержку откровенно дурного стиля программирования да ещё и ценой большего усложнения системы типов (т.к. нужно отслеживать квалификаторы для каждого уровня отдельно)? Нет уж, лучше передавайте мутабельный объект-аггрегатор.

Ребята D-шники, вы все там такие прихлопнутые на голову? Или вам религия не позволяет смотреть на проблемы concurrency без навязанных Александреску стереотипов?

Почему в C++ я могу без проблем широковещательно разослать объект вида:

struct change_log_stream_notify {
  log_stream & new_log_stream;
};

void notify_handler(const change_log_stream_notify & msg ) {
  m_log_stream = msg.new_log_stream;
}

void notify_handler(change_log_stream_notify msg) {
  msg.new_log_stream = new my_stream();
}

Зашибись, блин, язык, спроектированный в XXI-м веке.

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

А вот это ближе к истине. И таких мест в С++ полно. В общем, не нужно выдавать нужду за добродетель.

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

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

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

В рамках данной темы важно то, что D не является заменой C++. В том числе и в плане простоты языка.

Ну да, ну да. Школьники, может быть, вам и поверят.

Да тот же git написан на C. Тот же Postgres - тоже на C. Та же Mathematica - опять C. Рантайм Racket - снова C. Библиотеки для обработки изображений, а-ля GraphicsMagick - C. Какие исключения? Какие шаблоны? Чего дурью маиться и тратить время на всякое это говно типа классов и наследования с виртуальными базовыми классами и прочим дерьмом, если для всего и вся сгодится простой язык C? :-)

Чего дурью маиться и тратить время на всякое это говно типа классов и наследования с виртуальными базовыми классами и прочим дерьмом, если для всего и вся сгодится простой язык C? :-)

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

Я просто попрошу вас объяснить прелести plain old C людям вроде адептов D из этого топика. Не говоря уже про Брайта с Александреску. Вот ведь где, исходя из ваших посылов, совсем неумные люди: создают язык, где и исключения, и классы, и шаблоны в полный рост.

Все вокруг дебилы, только один упоротый Обероном аноним со смайликами лучше всех знает на чем нужно писать софт.

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

Перечисляй, не перечисляй, мне пофиг. Я говорю о том, что отличное знание небольшого по размеру языка C, который целиком и полностью укладывается в мою человеческую память, и виртуозное владение им, открывает любые возможности для решения практических задач. Зная C, я даже банальную функцию для Postgres напишу в лёкгую, а дебильный цепепе придётся оборачивать дебильным extern «C» {...}, избегать использования исключений и т.д. и т.п.

Все вокруг дебилы, только один упоротый Обероном аноним со смайликами лучше всех знает на чем нужно писать софт.

Ну почему же, не все. :-) Те, кто способен писать рабочий код на C, не обременяя свой мозг ненужным говном вроде ООП-моделей - не дебилы :-)

В коде вида

void notify_handler(const change_log_stream_notify & msg ) {
  m_log_stream = msg.new_log_stream;
}

m_log_stream в дальнейшем нельзя обрабатывать одновременно без блокировок, т.к. new_log_stream может обрабатываться (и изменяться) в этом же время в другом потоке. То есть на самом деле это обычный мутабельный объект, а мнимое предотвращение ошибок вида `msg.new_log_stream = new my_stream()` - популярные среди разработчиков С++ миф, которому я пока что не видел практического подтверждения.

Поэтому ..

Почему в C++ я могу без проблем

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

Да, была ещё тема перспектив D.

Нет, это не ко мне.

m_log_stream в дальнейшем нельзя обрабатывать одновременно без блокировок

К иммутабельности объекта change_log_stream_notify это вообще не имеет никакого отношения.

предлагаю на этом обсуждение и закончить.

Ну правильно, как только D-шникам указывают на проблему в дизайне их любимого языка, так сразу «предлагаю закончить». А проблема в том, что в языке не различаются случаи когда у нас есть иммутабельная struct A{int v;} и иммутабельная же struct A{int * p;}.

Для ряда кейсов отсутствие различия между этими случаями в D приходится отказываться от иммутабельности и язык оказывается даже хуже C++.

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

Зная C, я даже банальную функцию для Postgres напишу в лёкгую

Да, для банальных функций Си отлично подходит. А как пытаешься сделать что-то чуть менее банальное - получаешь linux/list.h. И согревает только то, что знание Си укладывается в память поехавшего на Обероне анонимуса.

Зная C, я даже банальную функцию для Postgres напишу в лёкгую, а дебильный цепепе придётся оборачивать дебильным extern «C» {...}, избегать использования исключений и т.д. и т.п.

Так все ваши беды от неосиляторства? Как предсказуемо.

Ну почему же, не все. :-) Те, кто способен писать рабочий код на C, не обременяя свой мозг ненужным говном вроде ООП-моделей - не дебилы :-)

Ну а те, кому нужен D, они-то, они-то кто?

Да, для банальных функций Си отлично подходит.

C, в отличии от цепепе, D, от всяких Go, C#, от тех же Perl, Java отлично подходит для всего. Абсолютно. :-)

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

А что написано на Обероне и зачем мне он дался, как если только не читать книжку Никлауса Вирта? :-)

Так все ваши беды от неосиляторства? Как предсказуемо.

Неосиляторство - это скорее всеми силами избегать писать на самом естественном для сегодняшних машин языке - C. :-) То, что ты не осилил C - очевидно. :-)

C, в отличии от цепепе, D, от всяких Go, C#, от тех же Perl, Java отлично подходит для всего. Абсолютно. :-)

Добавь побольше смайликов, а то кто-нибудь не поймет, что ты поехал.

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

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

То, что ты не осилил C - очевидно. :-)

От использования C я сознательно отказался где-то в 1992-м, когда ни D, ни Go, ни C#, ни Java не было. Да и C++ в моем распоряжении был совсем не такой, как сейчас, а без шаблонов, исключений, пространств имен, STL-я и прочих современных плюшек. И даже тогда было понятно, что для очень большого числа задач C++ намного лучше C, т.к. позволяет обходиться гораздо меньшим количеством усилий.

Но вам нужно выйти за рамки, обозначенные вам Виртом в Обероне, может тогда что-нибудь поймете.

А вы не стесняйтесь. Можете назвать меня как угодно, но попробуйте объяснить, в чем смысл того, что в C++ может быть константный объект A с неконстантной ссылкой на объект B внутри. И это широко используется в многопоточном программировании.

А вот в D такого не может быть. Ну т.е. вообще. При этом D декларирует поддержку многопоточности.

Какой за этим практический смысл?

Особенно при том, что в C++ элементарно делается и D-шная модель: достаточно внутри A хранить константную ссылку на B. И все.

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

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

Но вам нужно выйти за рамки, обозначенные вам Виртом в Обероне, может тогда что-нибудь поймете.

В общем все понятно, кроме С++ ты ничего не можешь, старый уже и ленивый.

Кстати, а чего ты Оберон-то пинаешь, причем здесь он?

Кстати, а чего ты Оберон-то пинаешь, причем здесь он?

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

Аноним со смайликами просто типичный представитель секты Оберона.

От использования C я сознательно отказался где-то в 1992-м

Хм, я вот от цепепе сознательно отказался в пользу C. И дело было не так давно - пару лет назад. :-)

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

Это откровенная брехня :-)

Хм, я вот от цепепе сознательно отказался в пользу C.

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

Тем не менее, если вы так любите C, то что вы делаете в теме про D? Это язык ничуть не проще C++.

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

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

Аноним со смайликами просто типичный представитель секты Оберона.

Попей водички :-) Анониму со смайликами Оберон ни каким боком не упал. Тебе по-русски говорят - C. Значит C. :-)

Ты сам подумай, фонатеть от 1350 страниц нечитаемого бреда

Мозги включите. Есть разница между «фонатеть» и не видеть в D достойной альтернативы C++. Как раз отметившиеся здесь C++ники как раз не прочь иметь язык более удобный и безопасный, чем C++. Но нет такого пока, к сожалению. И D, к сожалению, таким не стал.

придерживаясь всяких там паттернов и канонов ООП по Страуструпу

Вы что-то путаете, каноны ООП — это к Бертрану Мейеру, а паттерны — это к банде четырех. Если бы вы читали Страуструпа, то знали бы, что он догматизмом не страдает и не страдал никогда.

как правильно писать закорючки на цепепе

Еще раз: покажите адекватную замену C++.

И да, язык C для многих задач такой заменой не является.

Тем не менее, если вы так любите C, то что вы делаете в теме про D? Это язык ничуть не проще C++.

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

Еще раз: покажите адекватную замену C++.

Ещё разок - C. :-)

Еще раз: покажите адекватную замену C++.

Единственно, для чего нужен цепепе - это кодирование с помощью Qt - единственного более-менее ценного достижения на цепепе. :-)

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

Думается, что больше всего он страдает икотой :-)

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

И вы еще кого-то здесь обвиняете в фанатизме?

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

Вы сами-то хоть поняли, что сейчас написали?

PS. Прежде чем говорить «надежде получить больший результат с меньшими усилиями», попробуйте реализовать Boost.MultiIndex на чистом C. Может поймете, что речь вовсе не о «надежде».

попробуйте реализовать Boost.MultiIndex на чистом C

А попробуй-ка на цепепе компилятор для своего DSL простенький написать :-) Я на Лиспе - как с куста. А ты на цепепе задолбишься :-)

И вы еще кого-то здесь обвиняете в фанатизме?

Так это не фонатизм, а реальная практическая необходимость. Любой профессиональный программист обязан отлично знать C. Если таких знаний нет - это не профессиональный программист, а ваятель жалких скриптов, бесконечно зависимый от фреймворков бедолага, вечно шныряющий по кругу в поисках волшебных технологий. Опыт, и никакого фонатизма :-)

А попробуй-ка на цепепе компилятор для своего DSL простенький написать

Для этих целей есть Ruby. Для более сложных вещей, вроде IDL или чего-то еще более сложного — генераторы парсеров.

Я на Лиспе - как с куста.

Вы уж определитесь, C или Лисп. А то в показаниях путаетесь.

Любой профессиональный программист обязан отлично знать C.

2015-тый год заканчивается, пора бы уже выйти из криптокамеры. Plain old C сейчас нужен разве что махровым системщикам и разработчикам встраиваемого софта для совсем уж маломощных устройств. Причем не факт, что с точки зрения карьерных перспектив и размеров заработка, работа на plain C выгоднее какого-нибудь JavaScript-а.

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

Да, да, да, расскажите нам еще про свои влажные фантазии...

Опыт, и никакого фонатизма

Опыт?

Для этих целей есть Ruby. Для более сложных вещей, вроде IDL или чего-то еще более сложного — генераторы парсеров.

Я говорю компилятор, подразумевая генерацию машинного кода, а не жалкое тормозное интерпретационное говно :-) И Лисп здесь подходит лучше, чем что-либо другое. :-)

Вы уж определитесь, C или Лисп.

Лисп, который Common Lisp - такой же огромный монстр, как и цепепе. Только ещё сложнее, и в этом его главная проблема. И без Лиспа обойтись можно, как и без цепепе. А вот без C - никак. :-) Поэтому и выводы всегда в пользу C. :-)

Plain old C сейчас нужен разве что махровым системщикам и разработчикам встраиваемого софта для совсем уж маломощных устройств.

Опять брехня. :-) Хоть посмотри на Tiobe - второй по популярности язык.

Да, да, да, расскажите нам еще про свои влажные фантазии...

Для малограмотных и ленивых фантазии всегда остаются фантазиями. А для квалифицированных сишников нет ничего невозможного :-)

Опыт?

Сын ошибок. :-)

И Лисп здесь подходит лучше, чем что-либо другое. :-)
Поэтому и выводы всегда в пользу C. :-)

Совсем вы что-то заврались, батенька.

PS. DSL-ли на Ruby делаются влет, а на выходе получается C++ный код, который транслируется в машинный.

Опять брехня. :-)

Попробуйте опровергнуть.

Хоть посмотри на Tiobe - второй по популярности язык.

Уровень аргументации потрясающий.

Совсем вы что-то заврались, батенька.

Чего мне врать? Всё правда. :-)

PS. DSL-ли на Ruby делаются влет, а на выходе получается C++ный код, который транслируется в машинный.

По сравнению с Лиспом - говно технология. Хотя бы по одной простой причине - компилятор Лиспа доступен в рантайме и код генерируется на лету :-)

Попробуйте опровергнуть.

См. Tiobe :-) Посмотри вакансии даже на самом захудалом HR-сайте :-)

Уровень аргументации потрясающий.

Так я тебе перечислил пачку реально широкоиспользуемого ПО, написанного на C. Ты же игноришь, ибо упорот :-)

Чего мне врать? Всё правда. :-)

Правда то, что знать нужно C, а пользоваться Лиспом?

Вы уж как-то определитесь, либо С рулит, либо Лисп.

См. Tiobe :-)

Нормальные люди Tiobe в качестве аргумента не приводят.

Посмотри вакансии даже на самом захудалом HR-сайте :-)

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

Так я тебе перечислил пачку реально широкоиспользуемого ПО, написанного на C. Ты же игноришь, ибо упорот :-)

На это уже отвечал.

Нормальные люди Tiobe в качестве аргумента не приводят.

Приводят. :-)

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

Да пожалуйста Разработчик ядра PostgreSQL. :-)

Приводят

У нас разные представления о нормальности, по видимому.

Да пожалуйста Разработчик ядра PostgreSQL.

В мое время разработка ядер СУБД, как и разработка компиляторов, так же относилась к категории «системного ПО». Так что не зачет.

Где еще примеры вакансий?

И вы не ответили на самое главное:

Правда то, что знать нужно C, а пользоваться Лиспом?
Вы уж как-то определитесь, либо С рулит, либо Лисп.

У нас разные представления о нормальности, по видимому.

Не волнует :-)

В мое время разработка ядер СУБД, как и разработка компиляторов, так же относилась к категории «системного ПО».

Не волнует :-)

Так что не зачет.

Не волнует :-)

Где еще примеры вакансий?

Не HR-агент :-)

И вы не ответили на самое главное:

Всё уже сказано :-)

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

Производительности можно добиться и на джаве, если правильно писать, и позаменять «плохие» типы из стандартной библиотеки на свои собственные (Mechanical Sympathy). И еще можно воспользоваться Azul машиной.

То, о чем пишете вы, относится к типам late majority и laggards (может отчасти и для eary majority)

Я пишу о стандартной практике в любой конторе. Никто не будет закладываться на не вполне понятные риски, пока (хотя-бы!) не появятся основания эти риски прикинуть.

Одним из первых в каком городе? Где-то на просторах СНГ? Поскольку вне СНГ Питон в эти годы был вполне себе раскрученным и востребованным языком.

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

но ПОЧЕМУ уже в эти годы в Европе было «раскрученное питоновское сообщество»? Только из свойств языка? Или исходя из практического опыта (и соответствующей раскрутке) использования в образовании?

Язык D был достойной заменой C++у в 2006-2007-м

перестаньте воспринимать D именно как ЗАМЕНУ C++, и всё встанет на свои места.

Но вот D настолько себя дискредитировал за все эти годы, что таковой быть не может. По определению :)

Не вопрос. Предложите другую.