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

не нужен.

есть C++ & C.

> не нужен. есть C++ & C.

Нужен, нужен, читайте документацию. И Си тоже нужен. С++ -- сомнительно.

> С++ -- сомнительно.

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

Вот к примеру фича: "Compile time function execution" - ею можно неплохо запутать программу...

>Вот к примеру фича: "Compile time function execution" - ею можно неплохо запутать программу...

Сомнительно. Но вот alias параметр шаблона может запутать неподготовленного.

не заголовок -а стихи

> Сомнительно.

Почему же?

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

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

D вообще может запутать неподготовленного. )

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

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

>Еще немного и можно переписывать ядра...
Ога, выкинуть сборщик мусора, с ним ведро не напишешь (=

/me реквестирует D под NetBSD :)

Достаточно нормальный фреймворк сделать для C/C++ вместо стандартно-дыбильных либ и D ненужен. А так провоцируют на велосипеды.

Я в начале освоил С было в 2000 году а потом ассемблер в 2002, правда С остается любимым

> Вот к примеру фича: "Compile time function execution" - ею можно неплохо запутать программу...
Функция должна иметь один и тот же код независимо от того, выполняется она при компиляции или в рантайме. т.е. ctfe - это такой особый вид сворачивания констант.

>> Еще немного и можно переписывать ядра...
> Ога, выкинуть сборщик мусора, с ним ведро не напишешь (=

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

> Достаточно нормальный фреймворк сделать для C/C++ вместо стандартно-дыбильных либ и D ненужен.

Так напши!

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

Код, или результат работы? Странно предпологать, что _код_ может отличатся. Вот разные side-effects могли бы быть, но тут уже выше написали, что работу с внешним миром CTFE блокирует.

Последний заголовок: http://www.digitalmars.com/d/1.0/function.html

в общем то раз уже такие вещи на языке есть http://openmw.sourceforge.net/jaws/index.php/page/about/ru.html то уже не скажешь что он ненужен... надо будет посмотреть когда попритерётся...

Спасибо за ссылку. Впечатляет, по сложности на уровне C++ :)

А так-же предпоследний, в частности пункт 5.

> Ну хорошо хоть не душевного:)

Вспоминается очень оригинальный тролль: http://okante.narod.ru/D/

ну ёклмн, и поди уже патентов наполучали.

0_o

http://en.wikipedia.org/wiki/F_%28programming_language%29

http://en.wikipedia.org/wiki/J_%28programming_language%29

Ура буква H ещё свободна! H++ ну как вам? а еще лучше X--

>>Еще немного и можно переписывать ядра... > Ога, выкинуть сборщик мусора, с ним ведро не напишешь (=

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

Какой же сторонний код в ядре? :D

>http://okante.narod.ru/D/

мои глаза!!!....

Кстати а кто нить видел серьезные вёдра написанные не на C?

> а кто нить видел серьезные вёдра написанные не на C?

на асме подойдет?

Ну про Колибри и прочее я слышал, но это как то брутально очень

Сколько бы ни закапывали С и С++ ими будет пользоваться всё равно больше людей, чем всякими С-шарпами и прочими с-подобными. Причём мне кажется, это не только из-за того, что просто приходится тянуть проекты. Скорее произойдёт качественный переход на другой уровень программирования, когда С--/С/С++/Сшарп/Java просто отойдут на второй план, например, освободив дорогу Лиспам, Прологам и пр., как это в своё время сделал ассемблер, с появлением С.

>Кстати а кто нить видел серьезные вёдра написанные не на C?

A2 (бывшая Bluebottle)

http://bluebottle.ethz.ch/

http://ru.wikipedia.org/wiki/Bluebottle_OS

написана на Active Oberon

>>Надо сразу язык Z#++ его еще точно нет

>Надо Ъ++

лучше Ъ_Ъ

вот жеж бздунам счастье то привалило, хехе

может наконец избавятся от ненавистнейшего gcc

>Еще немного и можно переписывать ядра

давайте вы этим будете заниматься, а мы, как-нибудь, сями обойдёмся.

>Представляю что творится в голове человека который освоил первым ассемблер :)

ассемблер вполне простая штука, вот команды БЗ-34 и наследников интереснее.

а некоторые вообще с перфокарт начинали

>С++ -- сомнительно.

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

> В DMD 2.027 появилось неполиморфное наследование для структур. Пример из документации:

Я понял идею, но неужели это называется "неполиморфное наследование для структур" ???

И почему только для структур?

> Эх, один alias this на класс... Не доставляет.

А как должно быть?

ХЗ. Все вопросы после релиза D2. Автором неоднократно отмечалось, что фича ещё недописана. Как она будет выглядеть в готовом виде он не признаётся.

> Например с помощью структуры с одним полем (Proxy) можно красиво избавиться от необходимости выделять память под промежуточные результаты в матричных выражениях. C++ решает эту проблему (и получает пачку других) выделением классов и структур на стеке и обращением к ним по значению.

Ты лучше дай ссылку, где подробно написано.

> ХЗ. Все вопросы после релиза D2. Автором неоднократно отмечалось, что фича ещё недописана. Как она будет выглядеть в готовом виде он не признаётся.

Идея сделать (в синтаксисе плюсов) struct my_int: public int { .... }; безусловно интересная, такую вещь можно назвать неполиморфным наследованием. alias внутри меня запутал.

Описание фичи здесь: http://www.digitalmars.com/d/2.0/class.html#AliasThis

Пример про матрицы был взят из головы.

Но по-моему это "неполиморфное наследование" -- костыль. Правильно было бы с самого начала объявить int структурой (в понимании Д), и иметь структуры открытыми.

З.Ы. в Д классы открыты, как в С#, или закрыты, как в плюсах?

> В приведённом выше примере пользователь может использовать структуру S, как int с методом foo.

Вру. foo просто лежит снаружи. Вот пример поглобальнее: http://paste.dprogramming.com/dpclwyvr

Выводит:
Hello!
A - base struct

> Пример про матрицы был взят из головы.

Я не въехал, объясни подробно, где у плюсов проблемы с проксированием.

> Правильно было бы с самого начала объявить int структурой
Не уверен что понял мысль. А в чём тогда хранить собственно данные?

> в Д классы открыты, как в С#, или закрыты, как в плюсах?
Всё открыто по-умолчанию.

> Я не въехал, объясни подробно, где у плюсов проблемы с проксированием.
Нигде но из-за того, что к классам обращение происходит по значению появляются другие проблемы.

> Вот пример поглобальнее: http://paste.dprogramming.com/dpclwyvr

И чем пример поглобальнее отличается от наследования? В случае же инта мы действительно не можем от него отнаследовать.

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

Пример глобальнее наличием методов в обоих структурах.

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

Это 2 совсем разные вещи. Ты хочешь сказать, что в Д от структур нельзя наследовать без alias this?

Кстати, опасная фича. :)

struct Int {
    int a;
    alias a this;
    
    Int opAdd(int other) {
        launchNuclearMissiles();
        return Int(0); // Какая теперь разница?
    }
}

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