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

Да. Структуры - точная копия сишных, только с методами. Классы же устроены примерно как в Java.

> Да. Структуры - точная копия сишных, только с методами.

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

Запрет на наследование в структурах уже около года признан автором временной мерой. НО в структурах никогда не будет скрытых полей, в т.ч. таблиц виртуальных функций или скрытых указателей на предка. Теперь вот появилась возможность определить что-то вроде явного предка.

Именно поэтому, кстати, синтаксис отличается от классового:
class Derived : Base {}
но
struct Derived {
Base base;
alias base this;
}

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

А на Си этих способов тысячи, и что теперь?

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

Спасибо троллтеху, да.

Spectr, напомни, на каком языке невозможно написать программу неправильно.

> А на Си этих способов тысячи, и что теперь?

И потом появится масса заявлений, что D не нужен, и новая мутация намного лучше.

> И потом появится масса заявлений, что D не нужен, и новая мутация намного лучше.

Это называется "прогресс".

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

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

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

----------------------------------------------------------------

naryl>> на каком языке невозможно написать программу неправильно.

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

----------------------------------------------------------------

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

Вселенский парадокс из-за нескольких постов на LORе? Странные у тебя ожидания.

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

Это чертовски хорошая мысль, она ваша?

>> И потом появится масса заявлений, что D не нужен, и новая мутация намного лучше.

> Это называется "прогресс".

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

Настолько же моя, как и про тысячу мартышек в подвале, которые пишут на печатной машинке классику.

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

Вот вы сидите в сторонке, ждёте пока всё за вас обкатают, потом пользуетесь плодами обкатки и при всём при этом не забываете при каждом удобном случае называть обкатывающих "пионерами зелёные штанишки". :) Я не прошу присоединиться к процессу. Научитесь хотя бы уважать людей, получающих удовольствие от использования экспериментальных технологий. (в первую очеред в адрес klalafuda)

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

Почти невозможно неправильно написать на яве -- т.е. тебе кажется, что с указателями все в порядке, и на самом деле это почти что так (за исключением некоторых случаев утечки памяти, против чего НУЖЕН weak pointer).

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

Я -- уважаю. Другое дело, у меня другой взгляд чем у У.Б., какие технологии надо обкатывать.

на всякий случай -- не технологии явы

> Почти невозможно неправильно написать на яве

Мну не имел ввиду таких проколов в оригинальном посте. Кстати, я там и пример привел, в каком контексте была речь про неправильность (кстати, с кем я вел диалог - меня прекрасно понял). А речь шла про различные неочевидные возможности, в которых может быть side effect - которые будут использовать, что приведет к проблемам.

> кстати, с кем я вел диалог - меня прекрасно понял

да и я тебя понял, не беспокойся.

> потом пользуетесь плодами обкатки и при всём при этом не забываете при каждом удобном случае называть обкатывающих "пионерами зелёные штанишки".

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

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

А пока -- я буду использовать обидное слово "мутация" :-)

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

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

Можно здесь повторить холивар tailgunner'а не помню с кем на тему "что такое высокоуровневый язык?"

> Боюсь, что в языке более высокого уровня не будет понятий "структура" и "наследование".

Вероятно "структура" и "наследование" будут вводиться в стандартной библиотеке. > Можно здесь повторить холивар tailgunner'а не помню с кем на тему "что такое высокоуровневый язык?"

давай ссылку, а потом можно и повторить :-)

> Вероятно "структура" и "наследование" будут вводиться в стандартной библиотеке.

Предлагаешь определять низкоуровневые сущности через высокоуровневые?

(Нафиг ссылку. Само пошло. :])

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

Во. r vs tailgunner vs eao197: http://www.linux.org.ru/view-message.jsp?msgid=3240821

Именно так. "структура" и "наследование" будут скрыты за более высоким уровнем абстракции и ни в языке ни в библиотеках не будет в них нужды.

> будут скрыты за более высоким уровнем абстракции

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

> и ни в языке ни в библиотеках не будет в них нужды.

Не совсем понятно. Либо структуры, либо списки - или есть другой подход к организации данных?

> (Нафиг ссылку. Само пошло. :])

Ты иногда заходи на огонек, в девелопменте недавно был хороший (попал на первую страницу сайта на 2 место) флейм "зачем нужны динамические языки". Вполне возможно продолжим.

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

> Либо структуры, либо списки - или есть другой подход к организации данных?

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

А так в "обычном" языке списки должны быть. Через них надо уже определять структуры.

>> будут скрыты за более высоким уровнем абстракции

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

ммм... у меня другое обоснование. Безусловно полезную абстракцию "мне не надо заботится об указателях" можно поддерживать как в яве -- сделав принудительную сборку мусора, а можно совсем по-другому, используя например что специфику конкретной задачи. Допустим, у нас память выделяется по-немножку, но освобождается пулом. Т.е. плюсист, в отличие от явишника, может выбирать для себя способ реализации абстракции.

> Именно так. "структура" и "наследование" будут скрыты за более высоким уровнем абстракции и ни в языке ни в библиотеках не будет в них нужды.

Как конкретная цель -- это маниловщина (предложи, как это будет делаться), но как направление движения -- правильное.

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

Язык без такой привязки -- это кандидат на звание "новый язык", а не просто мутант.

> Версия 2.x поддерживается только dmd, а его нет для x86_64.

Вообще-то нормально работает под x86_64 :)

Чего тебе ещё нужно? :)

Однобуквенные языки программирования

A+
http://en.wikipedia.org/wiki/A%2B_(programming_language)

A++
http://en.wikipedia.org/wiki/A%2B%2B

B
http://en.wikipedia.org/wiki/B_(programming_language)

C--
http://en.wikipedia.org/wiki/C--

C
http://en.wikipedia.org/wiki/C_(programming_language)

C++
http://en.wikipedia.org/wiki/C%2B%2B

C#
http://en.wikipedia.org/wiki/C_Sharp_(programming_language)

D
http://en.wikipedia.org/wiki/D_(programming_language)

E
http://en.wikipedia.org/wiki/E_(programming_language)

G
http://en.wikipedia.org/wiki/LabVIEW

J
http://en.wikipedia.org/wiki/J_programming_language

J#
http://en.wikipedia.org/wiki/J_Sharp

J++
http://en.wikipedia.org/wiki/Visual_J%2B%2B

K
http://en.wikipedia.org/wiki/K_programming_language

L
http://en.wikipedia.org/wiki/L_programming_language

Q
http://en.wikipedia.org/wiki/Q_programming_language

R
http://en.wikipedia.org/wiki/R_(programming_language)

S
http://en.wikipedia.org/wiki/S_programming_language

T
http://en.wikipedia.org/wiki/T_programming_language

X++
http://en.wikipedia.org/wiki/MorphX

Y
http://en.wikipedia.org/wiki/Y_programming_language

Z
http://en.wikipedia.org/wiki/Z_(programming_language)

>А как должно быть? Брайту предлагалась очень интересная мысль - оператор opImplicitCast.

> очень интересная мысль - оператор opImplicitCast.

ссылку дай на обсуждение (если не жалко :-)

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D

Пост dsimcha, ибо, остальное один флейм.

> Во. r vs tailgunner vs eao197: http://www.linux.org.ru/view-message.jsp?msgid=3240821

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

Надо было взять что-нить попроще для примера, например работу с указателями в Си, Яве, С++. При этом надо различать

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

1. чисто синтаксические удобства, даются хотя бы макропроцессором как в С

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

3. верификацию компилятором

4. вычисления компилятором (ctfe, вычисление через шаблоны, ...)

http://www.digitalmars.com/webnews/newsgroups.php?search_txt=opImplicitCast&a....D fixed.

> Пост dsimcha, ибо, остальное один флейм.

Нашел вот это, но непонятно как там посмотреть ветку (ссылки нет!?)

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&artic le_id=86187

> Вот вы сидите в сторонке, ждёте пока всё за вас обкатают, потом пользуетесь плодами обкатки и при всём при этом не забываете при каждом удобном случае называть обкатывающих "пионерами зелёные штанишки". :) Я не прошу присоединиться к процессу. Научитесь хотя бы уважать людей, получающих удовольствие от использования экспериментальных технологий. (в первую очеред в адрес klalafuda)

В последнее время у меня усиливается впечатление, что лучшие идеи из D 2.0 (immutable и pure) придут в массы вовсе не из D. И гораздо раньше, чем D 2.0 станет стабильным и перестанет считаться экспериментальной технологией. Поскольку разработчик C# Андерс Хейсберг стал говорить о практически тех же самых проблемах (http://broadcast.oreilly.com/2009/04/an-interview-with-anders-hejls-1.html):

>...There are things that are required in our programming languages today in order for us to be able to do that properly. One of them we already have, which is the ability to pass code as parameters. As APIs get more and more complex in their capabilities, you can't just pass in flat values or data structures to the API. You've got to pass in pieces of code that the API then orchestrates and executes... ...Higher-order functions. Exactly. In order to be able to do that, you need stuff like lambdas and closures and so on. In order for you to be able to do that in a concurrent environment, you also need guarantees on whether these lambdas are pure, or do they have side effects. Could I just automatically run this in parallel, or are there side effects that would cause that not to be possible. How can I know that? Those are things that we don't have in our languages today, but we can certainly speculate about adding these. Of course, the trick is adding them in a way that doesn't constrain you too much and that doesn't break too much of your existing code. That's a big challenge.

>That is something our team thinks about daily.

Так что не ровен час, году эдак в 2011 выйдет C# 5.0 в котором будут immutable и pure. И все это с офигенным фреймворком, с IDE, с толпами евангилистов и миллионами готовых обратиться в новую религию пользователей. И все. С-шники и C++-ники останутся на своих языках (поскольку наработки не выбросишь, плюс C++0x уже будет основательно поддержан основными компиляторами). Сидящие на managed платформах получат более продвинутый C# (под оффтопиком и в виде Mono). Может и для JVM Scala аналогичным образом докрутят. Опять окажется, что экспериментальный D никому не нужен.

> Брайту предлагалась очень интересная мысль - оператор opImplicitCast. 

по мотивам того поста -- в плюсах у нас даааавно...

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

#include <iostream>

class my_float
{
    public: 
	my_float(int x): value(x) {}
	operator float () { return value/1024.0; }
    private: 
	int value;
};

void f(float x) { std::cout << x << '\n'; }

int main()
{
    my_float x(512);
    f(x);
    return 0;
}

C# уже сейчас лучше плюсов тем, что классы открыты

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

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

> http://broadcast.oreilly.com/2009/04/an-interview-with-anders-hejls-1.html

Да...

правда он говорит про 5-10 лет

> C# уже сейчас лучше плюсов тем, что классы открыты

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

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

А вот D нацеливается на нишу C++, т.к. тоже является native. Только против D работает то, что пока D допиливают энтузиасты, на C++ клепают очередной миллион строк кода (пусть временами и говнокода) в реальных проектах. И этот лишний миллион строк будет дополнительным аргументом в пользу того, чтобы и дальше работать на C++ (C++0x), а не заниматься переходом на D.

Вот и получится, что в нише native против D работает существующая кодовая база C++. А в нише managed -- такие языки, как C#, F# и Scala.

>по мотивам того поста -- в плюсах у нас даааавно...

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

class Boo
{
   public void _bar(){}
}
...
class Foo
{
   public void _foo(){}
}
class D
{
   Boo boo;
   //...
   Foo foo;

   alias boo this;
   alias foo this; 
}

void f0(boo b){}
//...
void fn(foo f){}

void main()
{
  auto d = new D;

  d._bar; 
  d._foo;

  f0(d);
  fn(d);
}