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

Но пользу от транзитивного конста я так и не понял (пользу immutable более-менее понимаю).

Если бы const не был транзитивен, а immutable - был, нельзя было бы определить функцию, которая принимает и mutable, и immutable данные. А это основное применение для const в D. Более того, если бы не эта необходимость, очень вероятно, что такого ключевого слова вообще бы не было.

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

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

btw, не-говноязыки мне неизвестны; с++ (субъективно) — говноязык в наименьшей степени

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

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

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

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

Мне вот кажется, что без модулей, полной статической интроспекции и pure функций язык не может быть даже допущен к соревнованию на звание «наименее говнистый язык». Discuss?

Вы можете передавать мутабельный массив immutable данных.

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

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

это будет работать?

Мне вот кажется, что без модулей, полной статической интроспекции и pure функций язык не может быть даже допущен к соревнованию на звание «наименее говнистый язык». Discuss?

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

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

модулей

что ты называешь модулями в этом контексте (или чего не хватает в плюсах)?

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

недостаток, да, но есть gcc-xml

и pure функций язык

без системы эффектов и эффект-полиморфизма ты закончишь тем, что будешь копипастить код, приделывая к нему разные квалификаторы эффектов (pure в том числе)¹; я согласен, что все это нужно

не может быть даже допущен к соревнованию на звание «наименее говнистый язык».

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

_____________________________________________________________

¹ именно этим занимаются в хаскеле, только там еще хуже — вместо копипасты и приписывания квалификаторов, там делают т.н. «монадические версии» фунций, например, map и mapM

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

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

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

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

одно другому не мешает — я вот, например, *и* ерничаю, *и* хочу узнать правду

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

«насильно загнать» - это какая-нибудь Java, где за пределы JVM - ни-ни. D не запрещает делать ничего из того, что позволяет делать C++. Он не предоставляет помощи от языка для некоторых конструкций, привычных в C++ (обсуждаемый const), но предоставляет другие. Как бы всё обсуждение идёт в контексте того «как написать так, что компилятор указывал на ошибки», а не «как написать так, чтобы работало». Для последнего не нужны ни immutable, ни const.

что ты называешь модулями в этом контексте (или чего не хватает в плюсах)?

include как языковое действие (а не препроцессорное), дающее доступ к пространству имён подключаемого модуля (а не просто копирующего forward declarations). Необходимость синтаксического/семантического разбора заголовочного файла при каждом #include (ибо он зависит от активных #define) - одна из причин очень медленной компиляции проектов на C/C++.

без системы эффектов и эффект-полиморфизма ты закончишь тем, что будешь копипастить код, приделывая к нему разные квалификаторы эффектов (pure в том числе)¹; я согласен, что все это нужно

Я не имею в виду ничего особо сильного в духе Haskell. Просто аннотация, благодаря которой компилятор возьмёт на себя рутину по проверке отсутствия побочных эффектов. Об этом ещё Кармак многократно говорил, не обязательно упарываться функциональщиной, чтобы оценить важность таких гарантий.

недостаток, да, но есть gcc-xml

Это не то, ближайшим аналогом в C++ является http://www.cplusplus.com/reference/type_traits/ - но оно может очень мало в сравнении с std.traits / __traits из D. Впрочем, D тут тоже ещё необходим важный шаг - интроспеция произвольного AST, а не только деклараций. Но это уже больше приятность, чем необходимость.

arr[] = 0.1; Я не знаю, как это сделать.

это¹ все давно сделано в библиотеках

#include <blitz/array.h>
#include <iostream>
using namespace blitz;

int main()
{
  int n=3;
  Array<float,2> u(n,n);
  u=0.1;
  u(Range(0,1),Range(1,2))=1;
  std::cout<<u;
  return 0;
}
$ g++ -Wall blitz-test.cxx
$ ./a.out 
3 x 3
[       0.1         1         1 
        0.1         1         1 
        0.1       0.1       0.1 ]

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

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

____________________________________________________________________

¹ подразумевается «для новых данных»; а нормальный язык должен был предоставлять возможности делать это и для массивов старого образца

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

Чем это плохо? Именно функциональность такого рода я активно и использую практически во всех проектах на D, чтобы

а) увеличить DRY и минимизировать количество копипасты / кода, который ничего не значит сам по себе

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

Это позволяет очень сильные вещи. Вот, например, пример использования REST-модуля для веб-фреймворка на D, там много комментариев и пояснений: https://github.com/rejectedsoftware/vibe.d/blob/master/examples/rest/source/a...

Возможности интроспекции в D позволяют сгенерировать всё это на основе обычной декларации интерфейса, не применяя никакого ручного boilerplate. Автоматически будут выведены стандартные имена для URL, определены корректные HTTP-методы, данные сериализуются в Json без вмешательства пользователя. В одну строчку можно создать RPC-клиент к этому API.

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

Used HTTP method is «GET» because function name start with «get».

отнюдь не все с этим согласятся, а я по крайней мере почувствую себя некомфортно

вот если бы там были аттрибуты, скажем как-то так:

string @function_name_is_significant getSomeInfo();

Despite this is only an interface, make sure parameter names are not omitted, those are used for serialization.

ыыы

вот этим «make sure» должен заниматься компилятор, и ide тоже должна быть в курсе происходящего

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

но если будет атрибут, то я полагаю, это будет можно сделать нормально

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

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

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

мне твои аргументы кажутся понятными, и как-то удивляет непонимание тебя в треде

пайк как-то рассказывал в своём блоге, что на Go пришли в основном питонщики и рубисты, а они ждали С++-сников.

пайк... эээ... ммм... потрясающе наивен, скажем так

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

отнюдь не все с этим согласятся, а я по крайней мере почувствую себя некомфортно

Смотрите внимательно, это всегда можно изменить явным использованием атрибута @path(«/url»). Стандартный подход к декларативному дизайну: default -> convention -> configuration. Смысл в том, чтобы максимально облегчить читаемый код за счёт удачного выбора конвенции по умолчанию.

вот этим «make sure» должен заниматься компилятор, и ide тоже должна быть в курсе происходящего

А он и занимается :) Если их таки пропустить, то будет ошибка компиляции с сообщением, почему так делать не стоит. Просто момент показался достаточно неочевидным, чтобы предупредить заранее.

если у метода, реализующего интерфейс, имена параметров будут иные

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

Недавно добавленная фишка - возможность декорировать метод произвольной функцией (@(before!funcsymbol(«paramname»)), готорая подготавливает аргумент для вызова вместо дефолтной десериализации. Такое в С++ тоже сделать довольно трудно, если вообще возможно :)

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

ыыы

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

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

тут убиваются 3 зайца:

1. проблемы с именами

2. на веб-странице обычно очень много параметров — слишком много для списка аргументов функции

3. на веб-странице-get-обработчике бывает много функций, т.е. в твоем подходе список аргументов у них окажется идентичный

Всё реализуемо.

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

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

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

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

Это можно сделать и, кажется, есть в примерах. REST-методы допускают использование любых пользовательских структур данных в качестве типов параметров. Нет никакой причины делать это обязательным поведением (сам же не любишь, когда загоняют в рамки ;)) Хотя в типичных API параметров как раз очень мало (а для обычных веб-страниц есть другие, более подходящие/удобные модули).

3. на веб-странице-get-обработчике бывает много функций, т.е. в твоем подходе список аргументов у них окажется идентичный

Не понял этого пункта.

Такое в С++ тоже сделать довольно трудно, если вообще возможно

а что надо, я не понял? *красиво* декорировать методы, или делать недефолтную десериализацию?

если у нас есть тип параметра, то привинтить к нему (к типу) недефолтную десериализацию проще простого

(а они есть? я слежу за Д, но не сильно внимательно)

Пытаемся убедить Вальтера их добавить/разрешить. Пока безуспешно. Он немного старомоден :)

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

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

Напомню, речь шла изначально о том, какой фундаментальной функциональности не хватает С++ и чего это лишает ;) Пожелания по реализации конкретного модуля можно добавлять в баг-трекер проекта и я рано или поздно до этого доберусь ;)

а что надо, я не понял? *красиво* декорировать методы, или делать недефолтную десериализацию?

Вот этот часть (Example5): https://github.com/rejectedsoftware/vibe.d/blob/master/examples/rest/source/a...

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

Так как в C++ нет атрибутов, то пришлось бы встраивать эту информацию в сам тип интерфейса, делая все методы шаблонными. Но непонятно как задавать имя вычисляемого аргумента в таком случае. В общем, какой-нибудь сильный человек должен придумать решение, но мне было бы страшно им пользоваться в production-коде. Boost::Spirit показателен :)

Так как в C++ нет атрибутов, то пришлось бы встраивать эту информацию в сам тип интерфейса

К таким вещам, вообще-то говоря, есть два подхода. Первый, который описали вы, это использование хост-языка (С++, D, Java, Ruby и т.д.) для создания встроенного DSL для какой-то предметной области. Ваш пример по преобразованию D-шного интерфейса с аннотациями в код по обработке REST-запросов как раз хорошая иллюстрация. Boost::Spirit еще одна иллюстрация.

Второй подход состоит в том, чтобы DSL-и делать внешними, используя для этого другой, более подходящий инструментарий (Antlr, Coco/R, Ragel и т.д., вплоть до языков вроде Ruby/Python/Lua).

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

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

Я не в теме REST-сервисов, но сталкивался с проблемами развития бинарных протоколов, когда приходилось расширять PDU новыми полями и обеспечивать прозрачность изменений для пользователей, которые не могли обновлять вовремя софт на своей стороне. В таких вещах практика подкидывает столько сюрпризов, что от первоначальных замыслов разработчика протокола быстро ничего не остается. Полагаю, что когда кто-то возьмет и сделает на vibe.d успешный REST-сервис, а потом будет вынужден его сопровождать, развивать, поддерживать работоспособность старых клиентов, при этом расширяя REST API, то вы быстро придете к пределу возможностей описаний с помощью D-шных аннотаций.

Второй подход обладает большей первоначальной сложностью, т.к. разработчикам придется осваивать Antlr или Coco/R, или что-то еще. Зато потом будет больше свободы и больше гибкости. А так же больше удобства пользователям внешних DSL. Хороший пример внешнего DSL — это Google Protobuf.

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

Что именно Вы пытаетесь доказать?

Что именно Вы пытаетесь доказать?

В отношении к D очень сильно проявляется WOW-эффект. Вроде: «В D есть immutable, чего не может быть в C++ в принципе!» или «В D есть type_traits и аннотации, чего в C++ нет!» и т.д. и т.п.

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

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

Так что, во-первых, очень хочется, чтобы сторонники D поуменьшили пафос в своих высказываниях. И, во-вторых, таки хочется понять, для чего нужен D в современных условиях за исключением таких причин, как «мне не нравится C++ (Java, C#,...)». Особенно когда за этим «не нравится» скрывается незнание соответствующего языка.

У D лучше синтаксис, есть модули, лучше сделаны шаблоны. Нет, пока, груза легаси. Есть и спорные моменты, но он лучше чем С++, хотя некоторые вещи я бы сделал по другому, а некоторые вовсе исключил из языка.

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

С++, объективно, устарел это признают многие разработчики.

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

При этом за 14 лет разработки всего один «стабильный» релиз, после которого язык стали делать совершенно другим.

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

Скорее это говорит о том, что на данный момент для себя я не вижу D как замену C++. Поскольку смотрю не столько на сам язык, сколько на всю экосистему вокруг.

Как замену Java или C#, или даже Go я D так же не вижу.

Может есть какая-то совсем новая и уникальная ниша для D (как для Objective-C такой является iOS/MacOS). Тогда расскажите о ней.

С++, объективно, устарел это признают многие разработчики.

Тут противоречие. Если «объективно», то не нужно апеллировать к «многим разработчикам». Если же упор делается на мнение разработчиков, то это уже не объективно.

Кроме того, сейчас не 1980-е, когда достаточно было выпустить язык без инфраструктуры и он нашел бы свое место. Времена давно изменились. Тот самый легаси, которого не смотря на 14 лет развития, нет для D и ставит его в неравное положение по сравнению с другими языками.

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

Аргументация на высоте=)

Суть в том, что на этапе декларации интерфейса можно прицепить глобальную функцию, которая будет вызываться фреймворком перед вызовом самого метода и можно сделать что угодно с HTTP контекстом и/или вычислить какой-то параметр самого REST метода, не являющийся частью API как такового.

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

При этом за 14 лет разработки всего один «стабильный» релиз, после которого язык стали делать совершенно другим.

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

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

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

Тут противоречие. Если «объективно», то не нужно апеллировать к «многим разработчикам».

Тут не противоречия. Если от С++ пытаются отказаться, значит он не устраивает разработчиков.

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

Сейчас действительно не 80-е и задача создания инфраструктуры под силу только крупной корпорации.

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

rootPathFromName
interface Example5API
{
        import vibe.http.rest : before, after;

        @before!authenticate("user") @after!addBrackets()
        string getSecret(int num, User user);
}

User authenticate(HTTPServerRequest req, HTTPServerResponse res)
{
        return User("admin", true);
}

struct User
{
        string name;
        bool authorized;
}

string addBrackets(string result, HTTPServerRequest, HTTPServerResponse)
{
        return "{" ~ result ~ "}";
}

class Example5 : Example5API
{
        string getSecret(int num, User user)
        {
                import std.conv : to;
                import std.string : format;

                if (!user.authorized)
                        return "";
                        
                return format("secret #%s for %s", num, user.name);
        }
}

лютый пиздец, и да - ты про status code вообще слышал?

ты про status code вообще слышал?

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

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

Это не нормально.

Сейчас действительно не 80-е и задача создания инфраструктуры под силу только крупной корпорации.

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

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

задача создания инфраструктуры под силу только крупной корпорации.

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

Но С++ устарел и будет постепенно заменяться другими языками

Все языки рано или поздно заменяться другими языками=) С++ достаточно активно развивается и C++11/C++14 вполне «современен» для своей ниши. Да, скорее всего С переживет С++. Но если кто-то и вытеснит С++, то это будет не D и не скоро.

когда-то я делал от нефиг делать REST-библиотеку, там данный пример выглядел бы так:

GET( secret/{num}/{user} ) ( connection& c )
{
   c.user() == "admin" ?
       c.respond( kOk, "secret" + c[ "num" ] + " for " + c[ "user" ] ) :
       c.respond( kNonAuth );
}

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

Это не нормально.

Обычное дело при проектировании сложных систем. Плохо что осознали поздно, но в данном случае лучше поздно чем никогда (как в С++).

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

А зачем? Если ставить такую задачу, то получим очередной С++. Возможности линковки с чужими библиотеками (С) вполне достаточно.

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

Это не важно, пока.

Обычное дело при проектировании сложных систем.

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

Никто не предлагает «клиентам» все переделывать.

Каким еще клиентам? :))

В данном случае - пользователям языка.

Клиенты это те кто платит. Остальным никто ничего не должен.

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

Обычное дело при проектировании сложных систем.

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

Кроме того, любая работающая сложная система является результатом эволюции простой работающей системы. Можно посмотреть на то, во что со временем превратился C#, первая версия которого не имела даже генериков.

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

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

Это не важно, пока.

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

Обращаю Ваше внимание на то, что я никого не агитирую.

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

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

Кроме того, любая работающая сложная система является результатом эволюции простой работающей системы. Можно посмотреть на то, во что со временем превратился C#, первая версия которого не имела даже генериков.

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

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

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

Но сейчас они устарели, как и С++.

Он не устарел. Даже Си не устарел.

Пока за язык не возьмется какая-либо корпорация это будет просто полигон

Печально.

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

не понимаю» == «кривой костыль» это распространённое отношение среди ретроградов

LOL, да у тебя баттхерт

Если передать контекст параметров в метод, этот класс нельзя будет использовать вне явного HTTP-контекста

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

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

я тебе пример привел - твой говнокод vs несколько строк

лютый пиздец, и да - ты про status code вообще слышал?

Слышал. `throw new HTTPStatusException(HTTPStatus.Unauthorized);`. По существу вопросов ждать не буду, так как твои дальнейшие комментарии показали, что ты ни черта не понял, зачем этот модуль спроектирован именно таким образом, а уже лезешь с идиотскими очевидными советами. Спасибо за внимание.

твой говнокод vs несколько строк

хотя они конечно не равнозначны, у меня корректно статус выставляется, а тебя нечто нерабочее, что даже не сообщает об ошибке

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

Слышал. `throw new HTTPStatusException(HTTPStatus.Unauthorized);`

LOL, еще один костыль, а ты не в курсе, что кроме статуса еще и сообщение вернуть можно?

По существу вопросов ждать не буду
повторяться ради твоих прекрасных глаз не буду
Перечитай мои ответы www_linux_org_ru

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