LINUX.ORG.RU

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

 , александреску, ,


0

0

Перевод статьи The Case for D, выполненный сообществом сайта http://dprogramming.ru/d/

Мы, программисты, — странный народ. Достатчно взглянуть на то, как мы выбираем любимые языки и придерживаемся этих предпочтений в дальнейшем. Ожидаемая реакция программиста, заметившего на полке книжного магазинаиздание “Язык программирования XYZ” — “Даю себе ровно 30 секунд, чтобы найти в нём что-нибудь, что мне не понравится”. Изучение языка программирования требует времени и усилий, а результаты появляются не сразу. Попытка избежать этого — проявление инстинкта выживания. Ставки высоки, вложения рискованны, так что лучше уметь принимать быстрое решение “против”.

Изучение нового языка программирования может представлять интерес только в том случае, если язык удовлетворяет принципам, которые программист высоко ценит. Любое несовпадение создаёт у программиста впечатление небрежного и небезопасного или же навязчивого и нудного языка. Язык не может одновременно устраивать всех и каждого, он должен аккуратно выбирать основные координаты, позиционируя себя среди языков программирования.

>>> Перевод (pdf)

★★★★★

Проверено: maxcom ()

D можно закапывать... Щяс Александреску туда говна наложит мощно как в C++...

Esh ★★★★
()
Ответ на: комментарий от gena2x

>Языки с gc вместо своевременной чистки моего стола просто предлагают мне в любой момент другой такой-же стол.

А есть разница? Только не надо натягивать ган^W^W выдавать случай с одним только столом за все возможные варианты или даже за их половину.

И потом, даже для таких крайних случаев есть врианты (кои в С++ нет)

>А в иначе gc поварёнок тратит вычислительный ресурс на то чтобы сообразить закончил ли я свою работу, нужны ли мне те остатки на столе


ну чтобы он не простаивал когда ты таки занят основным делом ;)

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


На всех не угодишь, а "изменяемых" языков - раз, два и обчёлся, да и далеко не все их любят ;)

yyk ★★★★★
()
Ответ на: комментарий от Esh

> D можно закапывать... Щяс Александреску туда говна наложит мощно как в C++...

Петросян, перелогиньтесь! А вообще, ждем перла о том, чего же именно в язык C++ мощно наложил Степанов.

gizzka ★★
()
Ответ на: комментарий от yyk

>http://shootout.alioth.debian.org/gp4/d.php

>на 2 теста больше =)


dmd сливает остальным компиляторам D почти на всех тестах. А gdc на генте они не осилили.

http://dbench.octarineparrot.com/ как бы говорит нам, что dmd быстро генерит медленный код, ldc и gdc - напротив, медленно генерят быстрый код.

naryl ★★★★★
() автор топика
Ответ на: комментарий от ip1981

>А C++ - тупой, поэтому хороший

хм. обкурившись книжками «Современное проектирование на C++» вышеупомянутого автора и «50 сложных задач на C++» Саттера, я понял, что C++ ни**я не тупой язык. Я не могу язык с таким количеством граблей и подводных булыжников назвать ни тупым, ни простым.

Примерно после этих книжек я начал смотреть в сторону чего-то более простого( C#, python, D ).

Dark_SavanT ★★★★★
()
Ответ на: комментарий от gena2x

>Языки с gc вместо своевременной чистки моего стола просто предлагают мне в любой момент другой такой-же стол.

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

Absurd ★★★
()
Ответ на: комментарий от scaldov

Уйди, C++ fan, пожалуйста. Уж лучше на бейсике писать чем на этой broken by design каше из парадигм с хромым синтаксисом. Писать на нем не только не «нужно», но и просто нельзя в большинстве случаев. D тоже тот еще велосипед, но это хоть какая-то попытка сделать мир лучше. А в том мире (который лучше) си++ программистам не место.

opium_inside
()
Ответ на: комментарий от RedPossum

а кто на нём пишет?

У нас часть п/о для кассового аппарата написана на D, например :)

barti_ddu
()
Ответ на: комментарий от hawai

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

жжошь!

С99 - комплексной математики быстрее не бывает.

scaldov ★★
()
Ответ на: комментарий от Absurd

Дорогой Absurd, производство столов не входит в нашу абстрактную технологическую цепочку из поварёнка и мастера-повара.

gena2x ★★★
()

Что меня удивляет... Я встретил дофига тем о том ЧТО такое D, но не хорошо написанных ответов ДЛЯ ЧЕГО/КОГО. Блин, почему Александреску именно эту тему не раскрывает? Продукт нельзя создавать не учитывая его пользователей. Я, честно говоря, практически не вижу областей применения для D. Может обсудим это?

theos ★★★
()
Ответ на: комментарий от Led

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

сам дурак.

scaldov ★★
()
Ответ на: комментарий от gizzka

> ждем перла о том, чего же именно в язык C++ мощно наложил Степанов.

STL. Искренне надеюсь, что за это Степанов оправится в адЪ.

tailgunner ★★★★★
()
Ответ на: комментарий от gena2x

>Дорогой Absurd, производство столов не входит в нашу абстрактную технологическую цепочку из поварёнка и мастера-повара.

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

Absurd ★★★
()
Ответ на: комментарий от opium_inside

пример годной юзабельной известной программы на Д в студию.

а так - это пустой трёп. то лучше, сё лучше.

scaldov ★★
()
Ответ на: комментарий от tailgunner

>> ждем перла о том, чего же именно в язык C++ мощно наложил Степанов.

STL. Искренне надеюсь, что за это Степанов оправится в адЪ.

Я так и не дождался вменяемого ответа в чем же такая фатальная роль STL.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Я так и не дождался вменяемого ответа в чем же такая фатальная роль STL.

Насчет «фатальной» я ничего не говорил. А плоха STL тем, что привела к сильному усложнению и без того сложного языка.

tailgunner ★★★★★
()
Ответ на: комментарий от scaldov

Просто и удобно говоришь? Приведи пожалуйста простой пример, как сделать свой istream который бы читал свои данные не из файла-строчки, а используя заданную тебе функцию my_mega_read_function (выглядит как fread).

theos ★★★
()
Ответ на: комментарий от scaldov

Ну и про то, что hash_map<string, string> сливает HashMap<String, String> в 10 (прописью, десять) раз я уже писал. Да, СТЛ это мощь.

theos ★★★
()
Ответ на: комментарий от theos

* HashMap<String, String> - это джавовская стандарнтная хэштаблица.

theos ★★★
()
Ответ на: комментарий от Absurd

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

Задача получения и освобождения ресурса релевантна проблеме его использования.

gena2x ★★★
()
Ответ на: комментарий от tailgunner

>А плоха STL тем, что привела к сильному усложнению и без того сложного языка.

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

Absurd ★★★
()
Ответ на: комментарий от Sun-ch

> В явке это достигается за счет большого числа библиотек. И хороших библиотек, которые охватывают практически весь спектр прикладных задач.

Большого количества - да. Хороших библиотек - как повезёт. Саныч, хочешь поговорить про программирование на Java? Слова типа Swing, JMF, JAIN-SIP тебе знакомы не по наслышке, или просто читал что такое есть? Брр, не напоминайте мне...

Casus ★★★★★
()
Ответ на: комментарий от gena2x

>Задача получения и освобождения ресурса релевантна проблеме его использования.

Да нифига - получить что-то и пользоваться этим это разные проблемы. Отсюда растут уши семейства порождающих паттернов типа AbstractFactory или Builder.

Absurd ★★★
()
Ответ на: комментарий от scaldov

> STL это мощь. просто и удобно.

Не пробовал в gdb поотлаживать конструкции из STL? Да хоть тот же vector, уж куда проще объект. Например, по корке понять, что же лежало в a[i]?

Casus ★★★★★
()
Ответ на: комментарий от Absurd

>> STL. Искренне надеюсь, что за это Степанов оправится в адЪ.

Я так и не дождался вменяемого ответа в чем же такая фатальная роль STL.

И не дождешься ))) Ибо большинство оппонентов это кто не осилил stl, у кого «он непредсказуемо течёт», «тяжёл в отладке» и т.д. Хорошо еще если они тихо сами с собой начинают писать свои стринги, мапы и вектора. Хуже если они становятся начальниками и начинают напрягать на эту тему тех у кого stl лёгок в отладке и не течёт )))

Alesh
()
Ответ на: комментарий от Alesh

>И не дождешься ))) Ибо большинство оппонентов это кто не осилил stl, у кого «он непредсказуемо течёт», «тяжёл в отладке» и т.д.

Слушайся старших и годик не пиши ничего на С++ - попросись на багфиксинг.

Absurd ★★★
()
Ответ на: комментарий от tailgunner

> STL. Искренне надеюсь, что за это Степанов оправится в адЪ.

меня всегда удивляло это твое отношение к степанову и STL

www_linux_org_ru ★★★★★
()

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

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

на счет приемственности (legacy). пока в C++/Java будет популярно использование каких-то специфичных библиотек, которые обходят проблемы самого языка, вроде ACE, boost, apache-..., для такого кода D вряд ли хорошо, только если больше делать нечего :) для нового кода, почему бы и не попробовать…

p.s. «The Case for D» лучше переводить как «Аргументы в пользу D», а «дварф» — это просто «карлик» :)

zeroreturn
()
Ответ на: комментарий от tailgunner

> А плоха STL тем, что привела к сильному усложнению и без того сложного языка.

Язык общего назначения был и будет сложным.

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

Ну и писать свои малоабстрактные (прикладные) библиотечки, юзая 15% языка.

______________________

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>> А плоха STL тем, что привела к сильному усложнению и без того сложного языка.

Язык общего назначения был и будет сложным.

Особенно если он включает в себя второй язык общего назначения как подмножество.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Особенно если он включает в себя второй язык общего назначения как подмножество.

что фактически доказывает неортогональность его концепций, см. выше

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Absurd

> Я так и не дождался вменяемого ответа в чем же такая фатальная роль STL.

Почитай перевод.

naryl ★★★★★
() автор топика
Ответ на: комментарий от Casus

>> STL это мощь. просто и удобно.

Не пробовал в gdb поотлаживать конструкции из STL? Да хоть тот же vector, уж куда проще объект. Например, по корке понять, что же лежало в a[i]?

Дай угадаю! Ты намутил трехэтажную конструкцию серьезно «разруливающую туда-сюда» память и т.п. Но надо было их еще и в массив ... И тут ты вспомнил про Степанова ))) В этом случае действительно лучше намутить свой вектор. )))

Alesh
()
Ответ на: комментарий от theos

Приведи пожалуйста простой пример, как сделать свой istream который бы читал свои данные не из файла-строчки, а используя заданную тебе функцию my_mega_read_function

Вот пример для дескриптора, можно вместо read (fd, ) поставить my_mega_read_function

http://www.josuttis.com/cppcode/fdstream.html

class fdinbuf : public std::streambuf {
  protected:
    int fd;    // file descriptor
  protected:
    static const int pbSize = 4;        // size of putback area
    static const int bufSize = 1024;    // size of the data buffer
    char buffer[bufSize+pbSize];        // data buffer

  public:
    fdinbuf (int _fd) : fd(_fd) {
        setg (buffer+pbSize,     // beginning of putback area
              buffer+pbSize,     // read position
              buffer+pbSize);    // end position
    }

  protected:
    virtual int_type underflow () {
        if (gptr() < egptr()) {
            return traits_type::to_int_type(*gptr());
        }

        int numPutback;
        numPutback = gptr() - eback();
        if (numPutback > pbSize) {
            numPutback = pbSize;
        }

        memmove (buffer+(pbSize-numPutback), gptr()-numPutback,
                numPutback);

        int num;
        num = read (fd, buffer+pbSize, bufSize); //Изменить эту строку
        if (num <= 0) {
            return EOF;
        }

        setg (buffer+(pbSize-numPutback),
              buffer+pbSize,
              buffer+pbSize+num);

        return traits_type::to_int_type(*gptr());
    }
};

class fdistream : public std::istream {
  protected:
    fdinbuf buf;
  public:
    fdistream (int fd) : std::istream(0), buf(fd) {
        rdbuf(&buf);
    }
};
HexGhost
()
Ответ на: комментарий от Absurd

>> И не дождешься ))) Ибо большинство оппонентов это кто не осилил stl, у кого «он непредсказуемо течёт», «тяжёл в отладке» и т.д.

Слушайся старших и годик не пиши ничего на С++ - попросись на багфиксинг.

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

Alesh
()
Ответ на: комментарий от scaldov

По-твоему как только придумали C++ на нем сразу появилась куча годных программ? Был ли он калом до того как на нем было написано первое коммерческое приложение? Что изменилось после этой переломной точки в самом языке?

opium_inside
()
Ответ на: комментарий от Absurd

> По моему только Александреску в конце концов приблизился к тому чтобы соорудить из изначально бесполезных шаблонов что-то стоящее наподобие языка спецификации проектирования

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

Так что тут неверна изначальная задумка.

Какая задумка - параметризованные типы?

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

> А можно перевести конструкцию static const на русский? Для новичка.

Это единственное, что смущает уважаемого анонимуса )))

Alesh
()
Ответ на: комментарий от anonymous

А можно перевести конструкцию static const на русский? Для новичка.


static - переменная располагаеться в дата сегменте
const - любые обращения к переменной не смогут ее изменить

hk
()
Ответ на: комментарий от anonymous

> А можно перевести конструкцию static const на русский?

const - константа, после инициализации изменить нельзя (если хаком, то иногда можно).

static - поле/метод класса, а не объекта. Т.е. оно одно на все объекты данного класса, а не в каждом классе своё.

Т.е. static const - это константа класса. А вообще, Страуструп вам в помощь.

HexGhost
()
Ответ на: комментарий от hk

Ужос. Спасибо за разъяснения всем :)

anonymous
()
Ответ на: комментарий от anonymous

> Потому что можно в разных объектах одного класса инициализировать константу разными значениями (в конструкторе).

HexGhost
()
Ответ на: комментарий от anonymous

> Ну как бы да :) Зачем static для объекта с модификатором const?

Понятен твой сарказм ))) Это из раздела мифологии языка, как про Геракла, Зевса )))

Alesh
()
Ответ на: комментарий от anonymous

Ну как бы да :) Зачем static для объекта с модификатором const?


ты еще спроси в чем разница между static const и const static :)))

hk
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.