Если б D'шный компилятор ещё понимал бы Сишные хедеры (не С++ хедеры конечно же), цены бы D не было.

http://www.digitalmars.com/d/2.0/htomodule.html

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

А я смотрел htomodle. Она же во-первых не автоматически это делает. Т.е. руками пилить придется. Во-вторых это всё равно придется делать для КАЖДОЙ платформы, при КАЖДОМ изменении.

Та, другая программа тоже проблемы имеет и давно не поддерживается (у народа были пробемы с её компиляцией).

Ещё раз — тулзы для однократной, путь и автоматической конвертации сишных хедеров в Дишные модули недостаточно. При компиляции программа на Д должна использовать актуальные хедеры из текущего окружения (целевой платформы). Для программиста это должно быть абсолютно прозрачно, иначе есть шанс наступить на неприятные грабли, когда что-то изменится в целевой платформе.

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

>>> Во как молдаванин спетросянил!

Andrei Alexandrescu este un programator român если чо :)

Андрей Александровский - эстет, написал роман про программатор.

++

А вообще, - кто не в курсе, - что молдавский, что румынский - одна шняга: У молдован даже родной язык теперь называется «Румынский»

4.2

>У молдован даже родной язык теперь называется «Румынский»

Статья 13, пункт 1 конституции: «Государственным языком Республики Молдова является молдавский язык...»

Сколько неосиляторов C++. Стыдно должно быть.

Ещё раз — тулзы для однократной, путь и автоматической конвертации сишных хедеров в Дишные модули недостаточно. При компиляции программа на Д должна использовать актуальные хедеры из текущего окружения (целевой платформы). Для программиста это должно быть абсолютно прозрачно, иначе есть шанс наступить на неприятные грабли, когда что-то изменится в целевой платформе.

А в описанной модели, если что-то изменится в h-файле - программа просто не скомпилируется? Ненамного лучше.

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

Может Александреску рассказал, где и как он применяет D у себя в Facebook? А то над языком уже больше 10 лет работают (сам Александреску уже года три как), очень активно его меняют, много о нем говорят... Но никогда не доводилось слышать, чтобы на D сделали какую-нибудь промышленную разработку. Да, энтузиасты пилят какие-то библиотеки, кто-то какие-то игровые движки пытается делать, да и все.

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

> И не понимаю, чего так создатели STL и D так на итераторы дрочат? Может быть им стоит объясниь что все прогерссивное человечество пользуется функциями высших порядков?

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

>> Ещё раз — тулзы для однократной, путь и автоматической конвертации сишных хедеров в Дишные модули недостаточно. При компиляции программа на Д должна использовать актуальные хедеры из текущего окружения (целевой платформы). Для программиста это должно быть абсолютно прозрачно, иначе есть шанс наступить на неприятные грабли, когда что-то изменится в целевой платформе.

А в описанной модели, если что-то изменится в h-файле - программа просто не скомпилируется? Ненамного лучше.

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

Значительно хуже, если скомпилируется, но будет работать не так, как надо.

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

Таковой тулзы. То что есть, не умеет делать полноценный враппер в полностью автоматическом режиме. Ни одна из двух.

И сделать это не так тривиально как тебе кажется.

Никто не говорил, что тривиально. У htod на страничке, кстати, написано английским по белому, почему именно нетривиально.

Т.о. D мог бы стать приемником C/C++, если бы умел сишные хедеры.

То есть в итоге осталось запилить одну тулзу (пусть сложно, но реально) - и наступит полное щастье?

> Статическая строгая типизация, Роб Пайк и Кен Томпсон, конкурренси изкаропки. Что еще нужно для счастья?

как минимум — отсутствие необходимости в даункастах

а она в го наличествует

вообще, го это что-то типа явы *до* дженериков

>> Т.о. D мог бы стать приемником C/C++, если бы умел сишные хедеры.

То есть в итоге осталось запилить одну тулзу (пусть сложно, но реально) - и наступит полное щастье?

Как я понимаю, как минимум на D посмотрят существенно большее количество людей, чем без нее.

Тут я с анонимусом полностью согласен.

Это необходимое условие но не достаточное. :-)

Но в принципе, да. Если бы такая (вменяемая) тулза существовала, то в некоторых (возможно многих) проектах можно было бы уже использовать D.

Особенно если бы это совпало с введением компилятора D в состав gcc.

> Статья 13, пункт 1 конституции: «Государственным языком Республики Молдова является молдавский язык...»

Статья 13, пункт 2: клеить обои без пузырей!
гыгы :)

> Вот если бы Александреску рассказал, что они в Facebook переписали...

Т.е. возможностей языка вам недостаточно? Это простительно начинающим, тогда смотрите примеры из конференции - там промелькивают интересные варианты. Повторюсь, Вальтер только собрал лучшее в одном месте, всё это уже было в других языках.

Я думаю, что «суперкрутых» примеров нет, потому что выйгрыш можно ощутить только на сложных проектах, а таковые вряд ли опенсорсны. Но даже чуть поработав фантазией можно догадаться, сколько интересного можно сваять на тех же mixin'ах.

Т.е. возможностей языка вам недостаточно?

Возможностей языка мне было достаточно еще в D1, особенно, когда Брайт туда добавил mixin-ы. Тогда же я стал применять D в качестве инструмента для мелких утилит (класса сделал-запустил-выбросил). Но для перехода в серьезное использование языку нужна стабильность. И после анонса D2 стало понятно, что стабильность D не грозит в ближайшие несколько лет.

Развитие D — это наглядная демонстрация принципа «лучшее враг хорошего». В погоне за реализацией своих идей Брайт и Александреску забывают, что язык программирования — это инструмент, который должен быть здесь и сейчас, для решения практических задач. Тогда хочешь, не хочешь, но полет фантазии где-то нужно будет остановить и пойти на какой-то компромис. Они же не останавливаются уже много лет подряд.

Я думаю, что «суперкрутых» примеров нет, потому что выйгрыш можно ощутить только на сложных проектах, а таковые вряд ли опенсорсны

По поводу крутых проектов. Когда-то один очень хороший разработчик написал библиотеку Harmonia на D и даже сделал на ее основе какой-то проект (http://www.rsdn.ru/forum/philosophy/1152810.aspx). Но потом его самого задолбала ситуация с нестабильностью D и он плюнул на язык и свернул Harmonia в пользу HTMLayout-а.

Да там забавного много. Вчера вот на коленке наваял такую штуку:

catchAll in myfunct() + 2;

эквивалентно try { myfunc(); } catch (Exception e) {};

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

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

По-моему, их полет фантазии остановился год-два назад (к сожалению, так и не дойдя до приличного pattern matching).

D1 полностью стабилен, вообще-то. Больше того - D2 на данный момент также стабилизирован. Возможно, будет добавлено несколько фич, но с полным сохранением обратной совместимости. Другое дело, что баги там ещё править... Например, сейчас aliasThis может быть только одно в структуре или классе, хотя обещают, что будет неограниченное количество, или сейчас у property нельзя больше двух аргументов сделать - а иногда удобно, чтобы там был tuple.

Опять же - старый синтаксис функций пока не убрали (это когда можно сделать

void myFunc(int x) {
   writeln(x);
}

void main() {
   myFunc = 5; //prints 5
}

В новом синтаксисе такая функция долюна быть с атрибутом @property.

@property - точно более поздняя идея. И таких красивых я не видел - в частности, их можно перегружать. Например,

import std.conv;
struct XXX {
    string _myString;
    @property {
        string myString(string src) {
            _myString = src;
            return _myString;
        }
        string myString(int src) {
            _myString = to!string(src);
            return _myString;
        }
        string myString() {
                return _myString;
        }
    }
}

void main() {
    XXX x;
    x.myString = "qwerty";
    x.myString = 123;
}

@property - точно более поздняя идея. И таких красивых я не видел - в частности, их можно перегружать. Например,

import std.conv;
struct XXX {
    string _myString;
    @property {
        string myString(string src) {
            _myString = src;
            return _myString;
        }
        string myString(int src) {
            _myString = to!string(src);
            return _myString;
        }
        string myString() {
                return _myString;
        }
    }
}

void main() { XXX x; x.myString = «qwerty»; x.myString = 123; }

D1 полностью стабилен, вообще-то.

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

А в чем проблема? D1 поддерживается (и будет поддерживаться). D2 - это, фактически, новый язык, со своими достоинствами и недостатками. Первую версию он никак не отменяет. Хотя лично мне она не нравится - примитивная слишком.

4.2

>Статья 13, пункт 2: клеить обои без пузырей!

опять 4.2 это в трудовом кодексе написано)))

P.S. переписывал бота как-то с питона на D. Понравилось, язык понятный, без неожиданностей и можно писать высокоуровнево. правда работало медленней питона xD

Как умудрилось так медленно? Если остался код - не похвалитесь? Я так понимаю, это следствие «дословного перевода» - было бы интересно выяснить, в чём дело.

>Как умудрилось так медленно?

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

>> По-моему, их полет фантазии остановился год-два назад

@property - точно более поздняя идея.

Реализации @property в ченджлоге я почему-то не нашел, но они есть уже в книге Александреску. Так что им не менее года.

Но явно меньше двух, судя по рассылке. Примерно в июле 2009 там ещё шли бурные дебаты на эту тему

THELANDOFLISP!

А зачем в D добавили хэшмэп прямо в язык? uint[string] foo;

Почему это не в библиотеке?

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

Потому что это дает возможность использовать хэшмапы там,где требуется статическая инициализация

В данной презентации английским по белому сказано (стр.42, слайд #34):

Associative arrays were built in, now library

Так кому из вас верить?

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