Андрей Александреску, The Case for D

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

Навскидку. Не только. В ряде случаев (и ядро тому пример) нет возможности использовать ряд возможностей С++. Кроме того, ряд средств именно С, например макросы, являются спасением. Например, тот же printk, который заменяет собой printf для случая работы в ядре — макрос.

Отношение к макросам в С++ хорошо известно. Для того, чтобы от них уйти изначально предложены были inline-функции. А это «немного» другое, чем макросы, хотя по своей идее механизмы сходны.

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

Кроме того. Как пример другого подхода — ядро на С++ и что из этого вышло, рекомендую посмотреть на Symbian. Да. Изначально это С++. Но при прикручивании того же Апача http://opensource.nokia.com/projects/mobile-web-server/ , Nokia пришлось реализовывать библиотеки POSIX -> http://www.forum.nokia.com/main/resources/technologies/open_c/

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

ну с тех пор уже много воды утекло, gcc стал гораздо лучше с тех пор :)

>Я хочу сказать, что D - умный язык, слишком умный.

> А C++ - тупой, поэтому хороший. Забыли умную Винду?

Не умничай! (или не юродствуй?) Твой хороший язык, не смотря на то, что позволяет строить "абстрактные абстракции", заставляет всё время помнить о том, что "муку сначала надо просеивать, а стол надо протирать и до и после" и т.п. Это работа "поварёнка" - раз убедившись, что он нормально работает, я не хочу даже вспоминать об этих мелочах. Но ни буст с stl-м, ни (язык не поворачивается их так назвать) сишные макры не дают полной свободы.

О, знаток D детектед, это хорошо :) Возник вопрос по существу статьи. Конструкция вида

alias getGadget this;

скорее похожа на операцию приведения типа, причем тут множественное наследование?

А так есть конечно интересные моменты, но отладка вот такого например кода:

foreach ( f ; take(50, recurrence!( «a[n−1] + a[n−2]» ) (0,1)))

представляется нереально геморройной, мне пока не понятно как можно вставить breakpoint внутрь текстовой строки. А если эта текстовая строка еще и отпарсится не совсем так как ожидал автор? В общем могу только пожелать удачи программистам решившим забабахать действительно большой распределенный проект (с кучей кода генерящегося во время исполнения) в деле разбора багрепортов от ошеломленных пользюков.

ПыСы Программист это не тот кто пишет программы а тот кто их отлаживает. (С) Народная мудрость.

и какой такой свободы Вам не дают STL с Boost-ом ?

> На C++ можно забабахать такую комплексную алгебру, какую вы хотите, сохранив совместимость со всем миром

когда я хотел узнать причину быстрой комплексной математики в D, то обнаружил, что они имеют хороший профит от определения действительной и мнимой частей объектами разных типов - это снижает количество элементарных операций при операциях над самими векторами. это по большому счёту не совсем совместимо со всеми подряд. зато работает. переписать можно, но зачем? я же не переписываю STL и Boost каждый раз, когда хочу их использовать

Предсказываю over 9000 комментов и первое место в Top 10.

>и какой такой свободы Вам не дают STL с Boost-ом ?

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

я уж и не буду вспоминать контекстно-зависимый синтаксис

>Господи, просто 3.14здецкие идиоты сидели и шлифовали алгоритмы того же ядра Linux

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

И «потоки» как таковые были сразу

Ага, это IBM залила весь код. Иначе не было бы скандала со SCO.

Такое ощущение что авторы D дети, не понимающие сути. Что бы все кинулись переписывать что-то на новом языке, нужна просто гигантская мотивация(и возможности языка стоят абсолютно не на первом месте). И фразы типа - это круто потому что тут есть такой крутой эксепшин по своей сути глупейшие. Как правильно написал кто-то с ЛОРа - я знаю больше языков программирования чем хороших программ.

Нафиг это компилируемый питон. Хочу компилируемый Smalltalk!

Вообще я считаю, основываясь на собственном опыте, «путь хакера» в смысле Эрика Раймонда, я бы сейчас сформулировал так.

Java -> Common Lisp -> Haskell.

Изучать все остальное, уже зависит от специализации. Конечно системным прогерам без С и ассемблера не обойтись.

>а начём писать - дело десятое. умный пишет на Си(++), т.к. это работает быстро и кросплатформенно.

Глупый заявляет на ЛОРе про то, что «умный пишет на Си(++), т.к. это работает быстро и кросплатформенно».

Ничего не поделаешь: недостаток образования и самообразования ничем не компенсируешь :(

>но пока что ничего лучше нету C/C++

«Ну, кому и кобыла - невеста»

>Java -> Common Lisp -> Haskell.

Джаву ты приплёл только из-за своего ника. Нафиг не нужно её изучать.

Вспомнил про свободную реализацию Morrowind на D, зашёл на сайт и...

We're switching to C++ It's now official: OpenMW is changing development language from D to C++. The reasons for this are threefold:

* Very few people know D, lots of people know C++

* Nobody has a D compiler, and setting one up is difficult on most platforms except for 32 bit Linux

* Maintaining a mixed D/C++ code base is too much work, mostly because the compiler and tools don't work well together in this scenario (especially on Windows.)

...

16 November 2009

Подробнее http://openmw.sourceforge.net/jaws/

> Нафиг это компилируемый питон. Хочу компилируемый Smalltalk!

Вперед же, кто мешает!

>похапе детектед.
NO U

>полуркай «индусский код»
Незачем так далеко ходить, ващето. :)

>И "потоки" как таковые были сразу а не появились в результате шлифовки алгоритмов по порождению процессов?

Ух ты. Что прямо шлифовали-шлифовали, и вдруг потоки появились как побочный эффект? Потоки - это отдельная идея и ее заимплементили.

>Ндааа... И только прости, Господи, просто 3.14здецкие идиоты сидели и шлифовали алгоритмы того же ядра Linux

Выбрать алгоритм и его заимплементить - это 10 % времени разработки - дай бог. Вот что я хотел сказать. Еще есть разработка архитектуры, проектирование, а потом еще оптимизация и отладка. А потом еще расширение и кастомизация с саппортом бывают. И если ты сделал херовую архитектуру, то мега алгоритм ее не спасет, ты зарастешь костылями и успех пройдет мимо. (не повезло, не фортануло)
А возможность не зарости костылями частично определяется наличием средств абстракции. Короче, идите и пишите АЛГОРИТМЫ! А я пойду свое говно дебажить, пока не уволил :)

п.с. Конечно, алгоритмы очень важны. Но писать что все гавно, главное - алгоритмы - это имхо дилетантство.

А давайте все перейдём на Эсперанто!!!

> Выбрать алгоритм и его заимплементить - это 10 % времени разработки - дай бог. Вот что я хотел сказать. Еще есть разработка архитектуры, проектирование, а потом еще оптимизация и отладка

Да, и хавчик приготовить, выспаться, принять душ, выгулять собаку, ...

Разработка не простое дело.

> Был уже промышленный Unix, даже исходники были доступны. Осталось только повторить.

Неправда Ваша, боярин... Неистину глаголете... Бога не боитесь! :)))) Тот же стек TCP/IP, который уж кто только не реализовывал... Даже в вянде не почурались «стибрить» изо FreeBSD, а вот подиж ты... В линуксе самописный.

Доказать просто — для вянды и фряхи, в случае написания сниффера, например, потребны либы winpcap или libpcap соответственно. А в линуксе карточка может быть благополучно переведена в promisc. режим куда как проще. Это доказывает то, что сама по себе работа данной части ядра не «заимствована» ни откуда, а была честно написана.

С другой стороны, есть ещё масса вещей, которые создавались «с нуля» и работают весьма и весьма не плохо. Например, те же pthreads. Был более старый вариант «LinuxThreads», сейчас заменён на NPTL. Оба варианта базировались на системном вызове clone(), но NPTL победил. Как-то по-лучше работает. LT ушёл в прошлое. Алгоритм изменили? Или так... «косметически»? Кстати, именно по причине того, что используется вызов clone() и все нити порождаются в одной группе, в Linux используется «странный» TID. Но это уже другое. Не столь суть.

Я НЕ спорю с тем, что писать код «в вакууме», не опираясь на какие-то ранее существующие решения это НЕ правильно. Но и смотреть надо что и как реализуется.

A-234

представляется нереально геморройной, мне пока не понятно как можно вставить breakpoint внутрь текстовой строки

Гг, а как отлаживать что-то продвинутое на шаблонах в плюсах? Ну даже ещё не на уровне Boost и даже Loki, но уже и не на уровне пресловутого hello world.

А ещё есть восхитительный препроцессор C/C++, он кааак нагенерирует кода - хоть заотлаживайся.

К слову, Decent умеет compile-time view (http://www.youtube.com/watch?v=oAhrFQVnsrY), ставь брейкпоинты и отлаживайся, сколько душе угодно. А вообще в таких случаях полезно головой думать в процессе написания.

> «муку сначала надо просеивать, а стол надо протирать и до и после»

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

> А давайте все перейдём на Эсперанто!!!

Ага, это будет круто, только вдумайтесь, где ещё в мире троллят про Линукс (и не только) на эсперанто!

> К слову, Decent умеет compile-time view

* Descent, конечно же

Только почему-то scope(failure) никак для C++ не сделают, хотя пытались. Да и время компиляции с рекурсивными шаблонами никуда не деть. Никто не спорит, что на C++ можно сделать всё. Всё можно писать и на ассемблере, но нужно ли?

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

Это ты сейчас про SQL? Или про Prolog? Нет? Может про Хаскель? Или про любой язык с GC?

Продолжая кривые аналогии: если известно, что я в 16-00 приду что-то месить, и к этому времени мой стол не будет готов - это DoS, хорошо если без "кернелпаника" :) А большее меня и волновать-то не должно - кто, когда и чем помыл стол и помыл ли вообще

void main!!!11

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

Никто не будет ничего переписывать. Но будут начинать новые проекты. Вон, питон - говно говном (и с си не совместим, как c++), однако новых проектов на нём (к сожалению) over 9000.

> Доказать просто — для вянды и фряхи, в случае написания сниффера, например, потребны либы winpcap или libpcap соответственно. А в линуксе карточка может быть благополучно переведена в promisc. режим куда как проще. Это доказывает то, что сама по себе работа данной части ядра не «заимствована» ни откуда, а была честно написана.

Ув. коллега, вы в корне неправы. А точнее, не знаете ни хрена ни про снифферы, ни тем более про TCP/IP стек в разных ОС.

Причем тут ник? Для начинающих очень важно видеть результаты в виде работающих программ. В явке это достигается за счет большого числа библиотек. И хороших библиотек, которые охватывают практически весь спектр прикладных задач.

Вот так, с помощью нехитрых приспособлений буханку белого (или черного) ХЛЕБА можно превратить в троллейбус... НО ЗАЧЕМ?!

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

Автору часто предлагали помощь, но никто не хотел пошевелить пальцем и установить DMD. Автору пришлось ради своего проекта пойти навстречу фанатикам. От них в разработке польза неоценима.

> А давайте все перейдём на Эсперанто!!!

Почему бы и нет? Только родной язык (C++) забывать не нужжно. ;)

Но если вдруг все заговорят на простом, логичном и фичастом Эсперанто, всем будет только лучше.

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

> Ув. коллега, вы в корне неправы.

Ээээ... Кхммм... «Коллега», примеры сами в состоянии найти? С удовольствием посмотрю на Ваш сниффер без того же bpf... И сравните его использование в исходном коде для FreeBSD с, например, таким вариантом для Linux:

ifr.ifr_flags |= IFF_PROMISC; s=ioctl(fd, SIOCSIFFLAGS, &ifr); if(s < 0) { perror(«promisc. mode failed»); } return fd;

Думаю, что Вы мне явно не коллега... :)))

Если Вы подумали что я зачем-то пишу про сниффер протокола, то я Вас уверяю — здесь не про это.

maxcom, а куда дели ссылку на dvi?

Та же статья в православном формате: http://verypositive.com/files/d2.dvi

Присоединяюсь! Только переходить лучше не на Эсперанто (новодел, как-никак). Лучше переходить на санскрит. То же логически созданный язык, насколько я слышал...

Потроллить на санскрите о Linux... Это просто праздник какой-то... :)))

Тесты тоже еще никто не отменял.

функциональщики и до них доберутся. как сказал мне один товарищ "уравнения не падают"

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

Алсо предвижу что в будущем D имеет все шансы занять место Жабы и Cи-решетка

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

Батенька, право, не стоит говорить за всех. Это, как минимум, неуместно. Особенно, не видя кода человека. В конце-концов кто-то же портировал тот же GIMP под Windows. И оно, как ни странно, работает именно так, как и описано. Быстро и кроссплатформенно. И Апач с тем же постгресом. То же портированы. Претензии к скорости или кроссплатформенности есть?

Если Ваш проект куда как больше и энтерпрайзовее, то я просто снимаю шапку...

Увы (или не увы?) не имеет. Совершенно разные философии за языками стоят.

>“Даю себе ровно 30 секунд, чтобы найти в нём что-нибудь, что мне не понравится”

char*, <>.

Так и не понял, чего нового в мир принесли изобретатели языка D?

Сборку кучи?
Конструкторы/деструкторы?
Многопоточность?
Ексепшены ввода/вывода?
Классы?

Что нового? Чем D круче, хотя бы Оберона, которому сто лет в обед?

>Потому-что метод «быстро и кросплатформенно» (а на самом деле быстро и грязно) для больших энтерпрайз проектах не работает.

А как же Oracle? Или SAP? Просто изначально надо закладываться под другие платформы и технологии. Показательный пример - 1С как было изначально в клиенте все заточено под венду, так все и осталось. И про линакс с ней можно забыть.

Алсо предвижу что в будущем D имеет все шансы занять место Жабы и Cи-решетка

Бугага
Шутку понял. Смешно :)