Язык D доступен для FreeBSD

>> С-шники и C++-ники останутся на своих языках (поскольку наработки не выбросишь, плюс C++0x уже будет основательно поддержан основными компиляторами).

>Выход -- сделать возможность определять СВОИ атрибуты (в т.ч. immutible & pure) и проверять их компиллятором.

В С++ уже есть половинчатое решение в виде const (для деларации константных объектов и константных методов). Только вот const-методы могут изменять mutable-атрибуты и обращаться к глобальным данным. А вот если развить это дело до какого-нибудь pure const ;) Кто знает, может в каком-нибудь C++2012 так и сделают.

> Но с другой стороны alias this(множественный) - opImplicitCast + нп наследование

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

> Кто знает, может в каком-нибудь C++2012 так и сделают.

Я не хочу ждать 2012. Нужна возможность делать СВОИ атрибуты. Я уж говорил про syncronized.

> Ага, и хуже Ruby, потому что открыты не так сильно :)

поподробнее?

> Сравнение C#/Java с C++ не имеет большого смысла, поскольку это сравнение managed vs native. У них слишком разные ниши.

Я бы не назвал C# managed. Уже есть структуры, где можно расположить байты как хочешь, и возможность писать не-управляемые функции. Осталось несколько усилить систему типов, и, если речь идет не о ядре, то плюсам сильно поплохеет.

>> Кто знает, может в каком-нибудь C++2012 так и сделают.

>Я не хочу ждать 2012. Нужна возможность делать СВОИ атрибуты. Я уж говорил про syncronized.

Те, кто не хотят ждать, начинают придумывать вот такие шестиколесные велосипеды: http://www.artima.com/cppsource/codefeatures.html ;)

s/не о ядре/не о embedded/

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

хм. такие вещи обычно бывают хрупкими и крайне неудобными в обращении.

>> Ага, и хуже Ruby, потому что открыты не так сильно :)

>поподробнее?

В Ruby класс и объект можно менять в run-time :) За подробностями к Programming Ruby (http://www.ruby-doc.org/docs/ProgrammingRuby/)

>> Сравнение C#/Java с C++ не имеет большого смысла, поскольку это сравнение managed vs native. У них слишком разные ниши.

>Я бы не назвал C# managed. Уже есть структуры, где можно расположить байты как хочешь, и возможность писать не-управляемые функции. Осталось несколько усилить систему типов, и, если речь идет не о ядре, то плюсам сильно поплохеет.

Если еще и убрать из C# трансляцию в MSIL и пришитый намертво сборщик мусора :) Правда, тогда будет уже не бабушка, а дедушка ;)

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

>хм. такие вещи обычно бывают хрупкими и крайне неудобными в обращении.

Тоже самое было с лямбдами: самые нетерпеливые пользовались Boost.Lambda. Остальные спокойно (ну почти) ждут C++0x :)

>И в чем пойнт?

Для структур D это единственный способ расширить(не ограничивая в чем-то другом) их функциональность.

> В Ruby класс и объект можно менять в run-time :) За подробностями к Programming Ruby (http://www.ruby-doc.org/docs/ProgrammingRuby/)

Нееет, я не про это. В плюсах operator float() должен быть членом класса. В C# я имеено про этот оператор не знаю, но методы, которые плюсы требуют иметь внутри определения класса, можно определять ВНЕ.

> Если еще и убрать из C# трансляцию в MSIL

Это никому не мешает...

> и пришитый намертво сборщик мусора

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

>> и пришитый намертво сборщик мусора

>а это в случае современных компьютеров, возможно даже карманных, тоже никому не мешает -- никто же наверно не собирается писать ядро на С# ?

Тогда я не очень понимаю, почему вы до сих пор смотрите на C++ и D?

> Для структур D это единственный способ расширить
> (не ограничивая в чем-то другом) их функциональность. 

И это отличается чем-то по функциональности от плюсового кода?

// g++ test2.cxx && ./a.out
// output:
// 12448

#include <iostream>

struct A {
    int a;
    void aa() { std::cout << a; }
};
struct B {
    int b;
    void bb() { std::cout << b; }
};
struct C: public A, public B {};

int main()
{
    C c; 
    c.a=1; c.b=2;
    c.aa(); c.bb();
    std::cout << sizeof(A) << sizeof(B) << sizeof(c) << '\n';
    return 0;
}

> Тогда я не очень понимаю, почему вы до сих пор смотрите на C++ и D?

Потому, что *идеология* плюсов (вопреки некоторым деталям ее конкретной реализации в стандарте) мне нравится больше, чем идеология C#.

>И это отличается чем-то по функциональности от плюсового кода?

Я где-то упоминал о плюсовом коде?


>Но с другой стороны alias this(множественный) - opImplicitCast + нп наследование 

Этого как раз и не хватает в D.

> Я где-то упоминал о плюсовом коде?

я Д знаю весьма слабо, мне хочется понять, alias this это то, что в плюсах уже давно есть или действительно новая фича?

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

> alias this позволяет перенаправить все обращения к несуществующим полям и методам структуры другому символу.

Хотелось бы увидеть осмысленные примеры этого дела. А то пока это выглядит еще одним способом зашифровать программу.

> Хотелось бы увидеть осмысленные примеры этого дела. А то пока это выглядит еще одним способом зашифровать программу.

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

> я так пока что понял, что это обычное плюсовое в т.ч. множественное наследование со странным синтаксисом, но с одной полезной фичей -- наследовать можно например от int.

Не вижу ничего общего с наследованием у alias this.

> "As long as ... [Бла-бла поскипано]

Давайте начнём с того, что языки весьма условно делятся "по высоте" (я про языки общего применения). Скорее, это облако пересечений, где некоторые языки даже ортогональны основной массе. И если в таком "ортогональном" языке мы видим сущий бред, то возможно так оно и есть. В эпоху зарождения ИТ можно было позволить себе любую ахинею, вплоть до ЛИСП и Рефал. Время же отсеяло маргиналов и выделило наиболее естественные для употребления языки - Си, Сишарп, Жаба, Паскаль. Если бы не убогость возможностей, Бейсик тоже сюда вошёл бы. Поэтому нет ничего зазорного писать, например, на "ширпотребовском" Цэшарпе - это даёт гарантию будущей поддержки продукта средним (наиболее распространённом) классом программистов.

>я так пока что понял, что это неполиморфное одиночное(пока) наследование со странным синтаксисом с полезной фичей -- наследовать можно например от int.

Как-то так.

Язык Ди начинает напоминать весеннего снеговика, падающего с грязного холма - чем дальше, тем больше он облепляется всяким мусором, становится бесформенным и непонятно, где собственно морковка.
При современных требованиях к системам, куда разумнее двигаться к упрощению, подобно Смоллтоку или Objective-C и к модульности, подобно Оберону. Развитие же ООП в стиле Ди (или Сипипи) - маразм и полное извращение идей, попытка вплести "стройную идею вёсел" к покорению тундры.

Очень печально, что остаток жизни придётся провести за Цэшарпом. :(

Про странный синтаксис я уже писàл выше. (Похоже всё-таки прав Пол Грэм)

>я так пока что понял, что это неполиморфное одиночное(пока) наследование со странным синтаксисом с полезной фичей -- наследовать можно например от int.

неполиморфность проявляется в отсутствии вирт. методов? в том, что нельзя указатель на my_int неявно конвертировать в указатель на int?

> в том, что нельзя указатель на my_int неявно конвертировать в указатель на int?
Можно. Точнее, если компилятор не может в выражении использовать структуру, пытается использовать то поле, которое alias'нуто на this. Таким образом:

struct A {
int a;
alias a this;
}

void main() {
A a;
int b = a;
}

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

Под неполиморфным наследованием выше, видимо, понималось наследование без перегрузки (override) методов.

> При современных требованиях к системам, куда разумнее двигаться к упрощению, подобно Смоллтоку или Objective-C и к модульности, подобно Оберону

Причем эти древние языки к современным требованиям? Посмотри на Хаскел и Скалу - вот современные языки.

> и особенно плох разрыв _семантической_ совместимости с плюсами.

Не уверен, что это плохо.

Прогресс не исключает тукпиковые ветки, кстати.

как пияр языка D предлагаю всем посмотреть фильм:
http://www.nnm-club.ru/forum/viewtopic.php?p=745808

Хороший фильм, но ЕМНИП там ни малейшего намёка на информационные технологии нет.

> Посмотри на Хаскел и Скалу - вот современные языки.

Согласен, современные. Но кто сказал ЛУЧШИЕ? Лучшие в плане _промышленного_программинга_. Когда же вы наконец поймёте, что средний прогер НЕ МОЖЕТ разбираться в хитрожопостях чужого кода?? (да и свой со временем забывает) Сюда уже по-определению не подходят функциональщина, Скалу не знаю - надо посмотреть.

Смысл хорошего языка в мощности, но и в то же время понятности, простоте. Каждый вырваный кусок кода должен обладать максимальной автономностью и очевидностью алгоритма. Для Цэшарп это верно на 100%, но он недостаточно выразителен - много низкоуровневых операций.
Посмотрим на Скалу. А вы сами в ней разбираетесь?

10 лет - молод? C# еще только 8, а уже софта немеряно, в т.ч. под вашыми Mono

>> Посмотри на Хаскел и Скалу - вот современные языки.

> Согласен, современные. Но кто сказал ЛУЧШИЕ?

Ну да, Smalltalk и Objective C - лучшее, что есть, конечно.

> Когда же вы наконец поймёте, что средний прогер НЕ МОЖЕТ разбираться в хитрожопостях чужого кода??

Что, _уже_ не может, несмотря на наличие суперязыка C#? Ну так может надо дать "среднему прогеру" язык получше?

> Сюда уже по-определению не подходят функциональщина

Готовься сменить профессию.

>> Сюда уже по-определению не подходят функциональщина

> Готовься сменить профессию.

+ много.

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

немного троллинга:

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