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

Все ответы на все твои вопросы уже есть в треде и/или в документации. Все твои «претензии» - домыслы не вникавшего человека. «Не читал, но осуждаю».

Продолжай, пожалуйста, мне очень интересно.

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

Устарел. Но менять его, скорее всего, не будут ибо инерция слишком велика.

А с чего вы взяли, что он устарел? Он не справляется с задачами, которые на нем решают?

Плохо справляется. Есть более совершенные инструменты.

Все ответы на все твои вопросы уже есть в треде и/или в документации.

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

Продолжай, пожалуйста, мне очень интересно.

только, если услышу вменяемый ответ

Плохо справляется.

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

Есть более совершенные инструменты.

Возможно. Но совершенство инструмента доказывается на практике. Ведь это всего-лишь инструмент. Делает-то все «мастер»=)

Продолжай, пожалуйста, мне очень интересно.

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

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

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

Возможно. Но совершенство инструмента доказывается на практике. Ведь это всего-лишь инструмент. Делает-то все «мастер»=)

Чем лучше инструмент, тем ниже потребная квалификация мастера. Программирование это просто ремесло, как и любая другая работа, а не искусство.

Это инженерная дисциплина.

Но дело не в этом

Пока я вижу, что дело в голословных утверждениях=)

Пока я вижу, что дело в голословных утверждениях=)

Считаете что С++ не нужен? :))

Есть более совершенные инструменты.

Могли бы озвучить список таковых?

Все твои «претензии» - домыслы не вникавшего человека. «Не читал, но осуждаю».

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

Правильно читать так:
Фэйсбуку некуда девать деньги и он решил платить за устранение багов в реализации языка D(чтобы меньше людей занимались полезными делами и могли конкурировать с фейсбуком).
Или так:
Фэйсбук вляпался в язык D и теперь вынужден платить за устранение багов в реализации языка D.

Почему же, нужен. Он может быть полезным инструментом. Но и чистый си тоже.

Паскали, например.

Если можно сделать на С, то зачем С++?

Согласитесь, что это суть разные веши. Одно дело, когда базовый тип умеет это, а компилятор, встречая подобную конструкцию, задействует всякие там AVX оптимизации, и другое, когда что-то подобное реализовано в библиотеках. И да, в D есть std.range и std.algorithm, но мы же не сравниваем их функциональность с базовою.

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

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

Паскали, например.

Которые еще, в отличии от C++, не устарели? ;)

Как замена C, различные варианты Паскалей, может быть и хороши. Но вот как замена C++ — смешно.

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

Если посмотрите Выше, то увидите, что я отвечал на вопрос о языке С, а не С++. Действительно, Модула или Оберон не претендуют на нишу С++, а вот на нишу С, вполне.

Они ни на что уже не претендуют.

Что значит не выгодно? Несколько Выше Вы утверждали обратное.

Возможно вы меня не так поняли.

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

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

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

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

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

Значит у меня устаревшая информация. Брайт изначально говорил о языке D как о замене C++.

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

Как это соотносится с развитием языка C++? В плюсах уже появился штатный сборщик мусора?

Кстати говоря, с развитием мобильных платформ и приложений для мобильников разговоры о вреде автоматического управления памятью не только возобновились, но и стали еще более актуальными. Т.к. мобильники не обладают ни достаточной вычислительной мощью, ни памятью для того, чтобы платформы с GC обеспечивали достаточную производительность и отзывчивость. Вот, например, Garbage collection is not available in iOS.

C++ так активно развивается благодаря изменению сознания разработчиков, которое принёс в том числе D.

И какие у вас основания так считать?

В плюсах уже появился штатный сборщик мусора?

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

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

Яву на смартфонах уже отменили или только собираются?

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

Я-то понимаю. Поэтому и спрашиваю у Vudod-а почему он так высказался.

Яву на смартфонах уже отменили или только собираются?

Скажем так, сейчас все больше высказывается недовольства производительностью приложений на смартфонах, в особенности на Android-е. И, что характерно, под iOS делаются нативные приложения на Objective-C без GC. Под новые версии WinPhone один из основных языков разработки — C++. Samsung двигает Tizen, где так же основной язык разработки C++.

Java на смартфоне, конечно, никто не отменял и не отменит. Но, в отличии от мощных серверов здесь у Java есть серьезная конкуренция (как и на десктопах).

И какие у вас основания так считать?

Потому что в C++11 и C11 был включён ряд свойств, те же bool типы, за отсутствие которых не раз критиковали в том числе разработчики D.

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

Мощности вырастут и это пройдёт.

Поэтому и спрашиваю у Vudod-а почему он так высказался.

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

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

экспериментальная поддержка модулей есть в clang, + внесено предложение для их включения в стандарт, в принципе тут нет ничего экстраординарного, насчет GC - можно ввести новый вид указателей, как это сделано, например, в C++/CLI

Во-первых, эти идеи никакой оригинальностью не обладают. О многих нововведениях я читал даже в D&E(в том или ином виде), о некоторых писал Джоссатис, о некоторых Саттер. А bool С++ очень давно есть, если что. В Си _Bool появился в C99. Во-вторых, я могу вас расстроить, но многие даже не подозревают о существовании D. Или имеют о нем весьма смутные представления. Оригинальных же идей в D вроде как нет(разве что scope(exit/success/failure)).

Вводятся другие усовершенствования, например, bool типы и потоки

Про bool смотрите выше. Потоки были взяты практически полностью из boost'а.

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

Она есть. Консервативный давно уже есть(вроде как даже какая-то из реализаций D им и пользуется, если не ошибаюсь) - Boehm GC. При поддержке компилятора и наличии специальных умных указателей, вполне можно сделать и что-то более интересное.

Мощности вырастут и это пройдёт.

Ну будем посмотреть.

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

Насколько я помню, bool был еще в стандарте C++98. std::thread бы появился в стандарте C++ и без D, поскольку это было очевидно еще до появления D на публике. Появление Java SDK доказало всему миру, что в современных условиях язык сразу должен обладать большой и унифицированной стандартной библиотекой. Другое дело, что C++11 был долгостроем еще тем.

Мощности вырастут и это пройдёт.

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

Без отказа от совместимости это невозможно, иначе это давно бы сделали.

В мобильниках ее уже сейчас некуда девать, поэтому и придумываю FullHD видео на 5" экране и прочую чепуху.

Что именно не возможно? По поводу модулей есть предложение, по поводу того, что в С++ нужно включить опциональный GC написано еще в D&E. Книга издана в 94 году, а по поводу GC Страуструп писал и ранее(в конце 80х - начале 90х).

Мне на моем Андроиде иногда не хватает 4 гигов и двух ядер. О чем вы говорите?=)

Не надо уподобляться Биллу и заявлять, что 640 килобайт должно быть достаточно для каждого.

Мало ли что и где написано, где они в стандарте?

Правда? А на что не хватает?

Возможно, скоро будут. А что?

Ну тормозит иногда что-нибудь=)

Сильно сомневаюсь. :)))

давно бы сделали

это не про С++, в нем очень неспешно внедряются новые возможности, те же модули и GC рассматривались уже для С++11, но были отложены, чтоб не затягивать новый стандарт, который и так получился весьма большим в плане нововведений, лично мой прогноз - модули будут в С++17 (если его не перенесут), а GC в следующем после С++17 стандарте

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

не-не-не, изначально речь шла о том, что с++ вообще не следует допускать к соревнованиям, из-за того, что в нем видите ли нет import-ов, а есть include (хотя импорты большей частью лучше — с этим я не спорю)

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

это так в хорошем языке; а на практике, в Д, как ты будешь выражать проверку «для любого f, названия аргументов метода f интерфейса и метода f реализации интерфейса совпадают»?

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

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

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

например, на одной странице могут быть page?action=view&foo=123&bar=baz вмете с page?action=edit&foo=123&bar=baz — это хорошо ложится именно на класс с двумя полями foo bar и двумя методами view() и edit(), а не на 2 функции view(int foo, string bar) и edit(int foo, string bar)

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

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

http://defun.co/KxZO