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

Проблема в том, что ты не прав. В C++ так можно. Пример:

template <typename T>
class A {
public:

    virtual T v(const T a) = 0;
};

template <typename T>
class B : public A<T> {
public:

    virtual T v(const T a) { return a + 1; } ;
};

int main() {
    B<int> b;
    A<int>* pb = &b;
    pb->v(4);
}

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

И как там у вас, в параллельной вселенной? Отрасль растет и развивается, о каком развале речь?

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

Проверка корректности тела шаблона, очевидно. Если ты пишешь в С++ template T, это значит, что какой-то тип в будущем может удовлетворить телу шаблона.

Если ты пишешь в Racket (All (T) ...), то это значит, что тело шаблона должно возвращать корректный результат (с точки зрения типов) для любого типа T.

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

У меня в примере шаблонный параметр T виртуальной функции «virtual T v(const T a);»

Впрочем, в ракете вроде готового хватает.

Если честно, маловато. Не хватает крупных библиотек. Например, тот же XML. Есть просто парсинг и генерация. Причём в стиле DOM. Ничего похожего на XPath, XSLT, валидацию нет и в ближайшее время не предвидится.

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

Если ты пишешь в Racket (All (T) ...), то это значит, что тело шаблона должно возвращать корректный результат (с точки зрения типов) для любого типа T.

Да, что-то я ступил. В общем, это как «generics» в C#?

В общем, это как «generics» в C#

В принципе ближе, но цели всё равно другие. Хотя можно использовать и именно так.

(define: (T) (typed-box (x : T)) : (Values (-> T) (T -> Void))
  (define: x1 : T x)
  (values (lambda: () x1) (lambda: ([y : T]) (set! x1 y))))

> (define-values (getter setter) (typed-box 3))

> (setter 10)
> (getter)
- : Integer
10

Но зачем. FORTRAN и так идеален.

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

Но зачем. C++ и так идеален.

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

Посмотри на ATS.

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

И этот язык для некоторой части математиков наверное подойдёт. Не знаю, не математик сам.

у С++ нет «ломки», которой очень страдает D;

Поэтому каждый год полно комментов о том что «так сейчас на C++ никто не пишет, сейчас пишут так»... и далее по тексту. А ему другие отвечают, что во всех проектах которые им попадались пишут как в 2008 году потому что visual studio.

D перенял такую особенность. Walter Bright писатель компиляторов, а не разработчик языков. Появился в проекте Александреску и решили забацать уже прям язык, отовсюду понемножку. Сборщик мусора в D, насколько понимаю, это всё та же библиотека для C++/C которую используют для отладки программы перед релизом.

Единственное новшество в D это модульность. Остальное просто косметика.

Дoстигли уровня TurboPascal 90-x и Object Pascal(Delphi) 2005 года.

И ради чего?

Поэтому каждый год полно комментов о том что «так сейчас на C++ никто не пишет, сейчас пишут так»... и далее по тексту. А ему другие отвечают, что во всех проектах которые им попадались пишут как в 2008 году потому что visual studio.

это не «ломка», в С++ из-за новых «фич» или моды твой старый код не превратится в тыкву

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

Невозможно латать дыры С++ до бесконечности

абсолютно согласен, это еще не считая кол-во откровенного «хлама» в той же стандартной библиотеке, которого прибавилось с С++11

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

и тут не спорю, но лично мне D не кажется достойным преемником, так что буду ждать Rust

Поэтому каждый год полно комментов о том что «так сейчас на C++ никто не пишет, сейчас пишут так»...

Так ведь это разные вещи.

На С++ «так не пишут» (на самом деле, пишут по всякому) потому что (с какого-то времени) можно удобнее. А на D «по старому» писать просто становится нельзя.

и тут не спорю, но лично мне D не кажется достойным преемником, так что буду ждать Rust

Лично мне бы хотелось, чтобы «просто» повыкидывали из С++ весь устаревший мусор и прочую ерунду оставленную ради совместимости. Плюс нормальноe метапрограммирование, чтобы не нужны были извраты на шаблонах. К сожалению, все «преемники» фичи урезают, пусть и такие «бесполезные» как множественное наследование и перегрузка функций и т.д.

Множественное наследование не нужно. Необходимость перегрузки операторов тоже спорна.

Множественное наследование не нужно.

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

Необходимость перегрузки операторов тоже спорна.

Да понятно, что без почти любой фичи можно обойтись.

Множественное наследование не нужно.

Множественное наследование - нужно.

мне бы хотелось, чтобы «просто» повыкидывали из С++ весь устаревший мусор и прочую ерунду оставленную ради совместимости

Совместимости с Си? :)

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

В Rust для этого есть трейты.

Лично мне бы хотелось, чтобы «просто» повыкидывали из С++ весь устаревший мусор и прочую ерунду оставленную ради совместимости

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

Совместимости с Си? :)

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

Но я вообще немного о другом. Скажем, как пишет Страуструп в своё FAQ про С++11 о «Uniform initialization syntax and semantics». Что местами приходится использовать присваивание, местами круглые скобки. И давайте сделаем один общий способ с фигурными скобками. Удобно, но старые способа никуда не деваются, что «хорошо» и естественно, но в итоге новички столкнуться с кучей вариантов, что затруднит изучение языка (и заодно парсинг кода).

Или всякие мелочи для безопасности и удобства неплохо было бы иметь. Например, конструкторы классов по умолчанию explicit, с необходимостью писать implicit, если надо. Дефолтный break в свитче и т.д.

В Rust для этого есть трейты.

С растом очень поверхностно знаком. Представим такую ситуацию: есть иерархия классов window со своими методами типа show и т.д. И никак не связанная другая иерархия с базовым классом, например, object. Могу ли я в rust написать класс, который можно передавать в существующие функции требующие обьекты как из первой иерархии, так и из второй (отдельно).

Если да, то пожалуй соглашусь, что «не нужно». Если нет, то останусь при своём мнении.

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

Почему?

Отказываться от использования С библиотек, конечно, не надо. Это по моему вообще везде есть. А возможность напрямую код включать... такая ли это большая потеря?

Ответил слишком рано :/

Совместимости с Си? :)

«Совместимость» на уровне исходного кода?

На уровне исходного кода тоже, но тут скорее речь о туманном «идейном» уровне.

есть иерархия классов window со своими методами типа show и т.д. И никак не связанная другая иерархия с базовым классом, например, object. Могу ли я в rust написать класс, который можно передавать в существующие функции требующие обьекты как из первой иерархии, так и из второй (отдельно).

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

Почему?

потому-что это будет чем-то вроде D, но только хуже

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

А мне не нравится. Идеология множественного наследования ущербна и требует изобретения лишних сущностей.

Идеология множественного наследования ущербна и требует изобретения лишних сущностей.

Для некоторых вещей вроде миксинов множественное наследование очень круто подходит (loki, WTL/ATL). Если это парит неокрепший академический мозг, не используйте на своих проектах.

Для некоторых вещей вроде миксинов множественное наследование очень круто подходит

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

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

Чего это? Таким макаром надо на C написать, все остальные средства которые можно иногда успешно применить (классы, шаблоны и другая ерунда) не место в языке общего назначения.

Чего это? Таким макаром надо на C написать, все остальные средства которые можно иногда успешно применить (классы, шаблоны и другая ерунда) не место в языке общего назначения.

Не передергивайте.

На уровне исходного кода тоже, но тут скорее речь о туманном «идейном» уровне.

Не понимаю. Вот скажем, у D есть такая «совместимость на идейном уровне» (и заодно в расте где «совместимости на уровне исходников» можно сказать, что нет)? Куски С кода можно просто копировать и использовать как D код. Разработчики обещают, что «если скомпилится, то будет так же работать». А если нет, то придётся подправить, да.

Достаточно ли такой совместимости? С++ компилятором ведь тоже не любой С код соберётся. Опять же, если в свитче брейк по дефолту будет (в D, кстати, нечто отдалённо похожее есть), то совместимости как бы нет. Но проблемы не вижу. Или как другой пример - сейчас можно использовать тайпдефы или using для одной цели. using позиционируется как более удобный способ. Почему бы (в гипотетичском новом языке) не оставить только один. Кстати, в D тайпдефы тоже несколько другое делают.

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

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

потому-что это будет чем-то вроде D, но только хуже

Дык, в расте этой «совместимости» ещё меньше, но тебе же язык интересен?

А мне не нравится. Идеология множественного наследования ущербна и требует изобретения лишних сущностей.

Это каких же?

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

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

Но почему?

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

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

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

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

Например есть утюг и кофемолка, вы предлагаете ввести класс «приборы включаемые в розетку»? А если в них есть Wifi, то ввести класс Wifi-устройство? Считаете что наследование тут уместно?

Интерфейсы лучше отражают окружающую дейтсвительность и не порождают сильной связности, в отличие от наследования.

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

Вот скажем, у D есть такая «совместимость на идейном уровне» (и заодно в расте где «совместимости на уровне исходников» можно сказать, что нет)? Куски С кода можно просто копировать и использовать как D код.

Оба несовместимы. Идея Си - «прогер должен обо всем заботиться сам». Это было практично 30-40 лет назад, с небольшими программами и примитивными по сегодняшним меркам компиляторами. Сейчас практично сделать навороченный компилятор и пожертвовать 5% производительности программы за гарантии безопасности. И Rust, и D дают такие гарантии (при определенных условиях, конечно).

Достаточно ли такой совместимости?

Смотря для чего. По-моему, это просто неудачный кивок в сторону Си.

С++ компилятором ведь тоже не любой С код соберётся.

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

интересно возможна ли ситуация когда растовских трейтов не хватит для чего-то.

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

Дык, в расте этой «совместимости» ещё меньше, но тебе же язык интересен?

ты не зря добавил кавычки к «совместимости», а Rust мне да, более интересен, т.к. во-первых я не считаю, что D мне сильно облегчит жизнь по сравнению с C++11/14, плюс я еще ничего толком не читал про Rust и не пробовал на нем писать

Проблемы ромба нет?

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

Мне такие примеры не известны, кроме книжных.

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

Например есть утюг и кофемолка, вы предлагаете ввести класс «приборы включаемые в розетку»?

Нет, не предлагаю.

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

В скольких языках разработанных после С++ есть множественное наследование?

Таких не так уж мало (Perl, Python, OCaml).

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

Думаете это спроста?

Нет. Жертвуют фичами ради простоты или безопасности. Вероятно, в ряде случаев это оправдано. Просто лично мне не нравится такой подход для языка «наследника С++».

Идея Си - «прогер должен обо всем заботиться сам».

Тогда и С++ местами «не совместим» с такой идеей. Другое дело (и это, на мой взгляд, гораздо важнее и является «идеей С++») - возможность не использовать «высокоуровневые средства» и не получать лишнего оверхеда («не платишь за то, что не используеешь»).

Си++ собирал практически полный Си89

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

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

Ну так и я о том же. Потому и хотелось бы обменять часть соместимости на дополнительное удобство/простоту. Не пойму только твоего отношения - нужна ли дополнительная «корявость» ради «совместимости».

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

Если честно, то итоговый ответ так и не понял.

ты не зря добавил кавычки к «совместимости»

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

а Rust мне да, более интересен, т.к. во-первых я не считаю, что D мне сильно облегчит жизнь по сравнению с C++11/14, плюс я еще ничего толком не читал про Rust и не пробовал на нем писать

Аналогично.

Но как я вижу, представление об «идеальном наследнике С++» у каждого своё. (:

Дело в том, что в Racket число типов несчётно (в математичексом смысле), а в С++ конечно.

В С++ я не могу сделать тип «число от 0 до 1000».

По ходу С++ вы не знаете...

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

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

Perl, Python, OCaml :)))))

Множественное наследование это не фича, это баг!

Множественное наследование это не фича, это баг!

То есть по существу возразить нечего.

Пример множественного наследования будет?

Пример множественного наследования будет?

Например, класс, который является widget-ом (наследником какого-нибудь QtWidet-а) и агентом (в терминах фреймворка SObjectizer). Такие виджеты мы использовали для прикручивания GUI к server-side приложениям. Виджетная часть отвечала за отображение информации (мониторинговой) и получение воздействий пользователя. А агентная часть — за взаимодействия с другими агентами в приложении (получение той самой мониторинговой информации, управление другими агентами и т.д.). Причем остальные агенты работают на своих собственных рабочих нитях, а такой гибридный widget-агент работает на главной нити приложения, что позволяет widget-агенту при получении сообщения сразу же изменять свое визуальное состояние.

Вообще, такое скрещивание объектов из разных фреймворков является не такой уж редкой практикой.

Идеология множественного наследования ущербна

Одиночное наследование - частный случай множественного. Или разрешать наследование классов или нет(оставляя только наследование интерфейсов/треитов и пр.).