Здравствуйте, matumba, Вы писали:
M>Не совсем злости — скорее, этакая досада, что есть море очевидного говнокода на говноязыке, которое по-хорошему давно надо выпилить как зло и заменить намного более удобными/безопасными языками, но т.к. существуют "профессоры" типа вас, адвокатирующие за продолжение сипиписной вакханалии, у руководящих людей создаётся ложное впечатление, что "достаточно взять пару толковых С++ ребят" и все проблемы решены. На деле дуроломство не имеет границ и С++ только подливает масла в огонь, предлагая неокрепшим умам поиграть со своими лезвиями. Цепная реакция даёт ещё больше говнопроектов, которые худо-бедно живут, но при этом не дают развиваться другим языкам, которые, вероятно, могли бы быть в два раза более производительны и надёжны. А время идёт и ждать, пока каждый говнопроект не сдохнет в шаблонно-указательных муках, нет никакого желания. Теперь вы осознаёте, что такое "невинное" существование С++ всё равно гадит в отрасль, не давая ей развиваться с другими, более достойными языками? Даже пример дам — Линукс. Я подобную халтуру не поставлю даже в бортовую радиолу,
Если из-за досады ты линукс в бортовую радиолу не поставишь (сюрприз! в бортовых радиолах линукс уже используется), то это не досада, а злость.
M>Не воспринимайте всё так уж лично, просто посмотрите на ситуацию сверху — С++ объективно опасный и бестолковый язык, в мэйнстриме это язык-урод, не отвечающий главным требованиям. Ну а кто хочет на нём писать, пусть пишут — тянуть за рукав не будем.
Не путай свои требования и главные требования.
У С++ есть два плюса: мультипарадигменность и поддержка наследия. Он и в будущее смотрит, и прошлое не забывает.
Сколько стоит перенести гору уже существующего кода с C++ на D? А без тотального переписывания?
Новые проекты — пожалуйста, начинай хоть на D, хоть на окамле.
Кстати, не на тот язык звереешь. Фортран — вот где ад.
Между прочим, до сих пор используется. Те же промышленные библиотеки линейной алгебры — Intel MKL, AMD ACML — изначально сделаны для фортрана, с переходниками для си.
Здравствуйте, Кодт, Вы писали:
К>Не путай свои требования и главные требования.
Где они спутаны? Цитату в студию или трепло.
К>У С++ есть два плюса: мультипарадигменность и поддержка наследия.
Мульти... чо??? Этот ассемблер с классами? Родной, это не "мультипарадигменность", а БАРДАК — так будет точнее.
Наследие? Ну и что с того? Раньше и на PL/1 писали, он что, стал от этого полезнее или правильнее? Его заслуженно забыли, потому что вовремя осознали — не нужен.
К>Сколько стоит перенести гору уже существующего кода с C++ на D?
С чего вы решили, что вообще нужно переносить этот хлам??? Ди — не просто повторение "Си с классами", а практически новая методология! Ну или сильно улучшенная, как нравится. Т.е. переносить старые костыли нет никакого смысла, Ди предлагает куда более интересные вещи (CTFE, mixins, ranges, RTTI), под которые надо ЗАНОВО писать код. Кроме того, "легаси" зачастую грешит полным отсутствием вменяемой архитектуры, шаблонов, да и просто устаревшими приёмами. Пример — GCC, вот уж точно кого следует зазиповать и закопать.
Ты сам-то их читал? А понял о чём речь? Походу, нет.
Если кто-то (под воздействием дебильного пузыря "HTML5+JS") стал писать приложения на абсолютно непригодном, тормозном убожестве и при этом получил такие же отстойные приложения, как это соотносится с тем, что 1.5GHz процессор МОЖЕТ И ДОЛЖЕН исполнять всё быстро? Ты вообще в курсе, что первые "окна" работали на 40MHz i386, причём без ускорителя? Это в 37 раз медленнее, чем современный ARM-чип, и это только одно ядро ARM!
Вот как раз если бы писали под смартфоны на Ди, можно было бы вообще забыть про "тормоза". Вся надежда на D+LLVM.
А можешь книги по Д посоветовать? Просто туториалов/вики как-то мало, хочется более подробного разбора фич. Смущает, что "The D Programming Language" аж в 2010 году издана, по идее, в языке немало изменений было. Или книга всё-таки актуальна?
Здравствуйте, matumba, Вы писали:
M>Ты сам-то их читал? А понял о чём речь? Походу, нет.
Читал, понял о чем речь. И вам мой юный друг почитать рекомендую и не разводить демагогию не ознакомившись с материалом.
M>Если кто-то (под воздействием дебильного пузыря "HTML5+JS") стал писать приложения на абсолютно непригодном, тормозном убожестве и при этом получил такие же отстойные приложения, как это соотносится с тем, что 1.5GHz процессор МОЖЕТ И ДОЛЖЕН исполнять всё быстро? Ты вообще в курсе, что первые "окна" работали на 40MHz i386, причём без ускорителя? Это в 37 раз медленнее, чем современный ARM-чип, и это только одно ядро ARM!
Вас что-то понесло в другую сторону.
M>Вот как раз если бы писали под смартфоны на Ди, можно было бы вообще забыть про "тормоза". Вся надежда на D+LLVM.
Вы отчего не поймете простую вещь — на данный момент D c GC это бледная копия C#. D без GC это бледная копия С++. Проблема D на данный момент что никому не нужна бледная копия если можно использовать более эффективный продукт который имеет более высокую производительность, backword compatibility c с ранними версиями, отточенный FCL и прекрасные инструменты.
Здравствуйте, DarkEld3r, Вы писали:
DE>А можешь книги по Д посоветовать? Просто туториалов/вики как-то мало, хочется более подробного разбора фич. Смущает, что "The D Programming Language" аж в 2010 году издана, по идее, в языке немало изменений было. Или книга всё-таки актуальна?
Вполне актуальна. Т.е. лучше всего изучать по ней, а потом быстро глянуть, что изменилось, там не так много.
Из открытых источников стоит отметить такой: http://ddili.org/ders/d.en/
Еще надавно начали делать tutorial: http://qznc.github.io/d-tut/
Здравствуйте, D. Mon, Вы писали:
EP>>>А в D спокойно могут пожертвовать производительностью ради других целей (об этом говорил A.A.). EP>><b>например</b> DM>В монологе с этой позиции Ал-ку говорит совершенно другое. Что они начинают отталкиваться не от угла треугольника эффективность-удобство-безопасность, а от середины,
Он сказал, что начинают с середины и пытаются завоевать столько территории сколько возможно.
DM>и в некотором смысле опровергают CAP-теорему для такого треугольника, т.е. дотягиваются до _всех_ его углов.
Он не говорил что получилось дотянуться до всех углов
Здравствуйте, matumba, Вы писали:
M>DrDobbs обрадовал небольшой заметкой про использование языка D в таком крупном проекте, как Facebook.
Моё видение ситуации такое: Александреску умный мужик и прекрасный инженер с мировым именем. Фэйсбуку прощу потерпеть пять килобайт D-рьма в репозитории, чем расставаться с таким инженером, раз уж у него такой pet language. Будь у него личной игрушкой Malbolge, было бы сейчас в Facebook пять килограмм кода на Malbolge.
Здравствуйте, D. Mon, Вы писали:
EP>>void sort(RandomAccessRange &x) EP>>void sort(BidirectionalRange &x) EP>>Это шаблоны функций, перегрузка между которыми происходит автоматом. Требования каждой концепции разбиваются компилятором на атомы, и производится тест вложенности множеств и т.п.
DM>Перегрузка таких шаблонов в D есть,
По примитивному static if? Такой уровень есть и в C++98, через enable_if.
DM>но, насколько я помню, без такого теста вложенности, последовательная,
Что значит последовательная? В порядке объявления?
DM>т.к. в условиях может выполняться почти произвольный код, они намного больше всего могут тестировать,
enable_if тоже много чего может тестировать.
DM>поэтому такую проверку "вложенности множеств" провести нереально, она возможна лишь для сильно примитивных условий, которые и обещают в С++.
Не-примитивные условия а-ля static if/enable_if есть уже давно. Дело как раз в удобстве автоматической перегрузки.
DM>Вот такой пример на С++ как записывается? DM>http://thedeemon.livejournal.com/53900.html
Эти has_member доступны начиная с C++98, через SFINAE.
А вот что доступно C++14:
template<typename T>
concept bool Equality_comparable()
{
return requires(T a, T b)
{
bool = {a == b};
bool = {a != b};
};
}
Причём проверки такого вида были доступны и в C++11, через decltype, только в более нагромождённой форме.
DM>(проверка переданного шаблона на выполнение аксиом функтора в категории)
Я не увидел там никаких аксиом, только синтаксические проверки. Вообще "проверка выполнения аксиом" — звучит крайне дико
EP>>Итераторы C++ обеспечивают эффективную композицию. Если у нас есть 4 итератора, то из них можно получить 6 range бесплатно, без runtime penalty — просто выбери нужную пару итераторов. DM>Хороший пример, спасибо.
Есть ещё другой момент — безопасность реализации алгоритмов работающих с random access.
Итератор это и индекс и "accessor". В то время как D Range используют просто целые индексы которые не знают откуда они пришли, и по факту являются "обрезанными" итераторами.
Здравствуйте, matumba, Вы писали:
M>DrDobbs обрадовал небольшой заметкой про использование языка D в таком крупном проекте, как Facebook. 5K LOC — как говорил Семёныч, выходя из пивной: "Маленький шажок человека, но большой шаг для человечества!". Действительно, ну не может же хороший язык быть вечным мальчиком для битья всякими язвительными сипиписниками — "разум когда-нибудь победит" (ц) Смысловые Галлюцинации.
Facebook на три часа оказался недоступен по всему миру
Пользователи Facebook по всему миру жаловались на невозможность опубликовать статус и обновить ленту новостей. При попытке захода в соцсеть отображалось сообщение о закрытии сервиса на временные технические работы
Как сообщили официальные представители Facebook в России, ошибка была вызвана техническим сбоем сети.
"Сегодня утром во время технического обслуживания сети произошла ошибка, не позволявшая некоторым пользователям публиковать статусы и комментировать на Facebook в течение короткого периода времени. Мы быстро решили вопрос и снова работаем на 100%. Приносим извинения за любые неудобства, вызванные сбоем."
В справке Facebook поясняется, что такие проблемы обычно наблюдаются у пользователей, чей аккаунт хранится в базе данных, улучшением которой в данный момент занимается компания.
Не лично ли Александреску занимался этим улучшением?
Здравствуйте, FR, Вы писали:
EP>>В следующем году будут концепции — большой шаг вперёд. А что тут может предложить D? duck-typing? FR>D может предложить намного более полный и мощный контроль в compile-time, тот же static if FR>дополненный foreach как по типам (работающим в compile time) так и по значениям и гораздо
Такой foreach есть в C++98: boost::fusion::for_each. Не хватает только полиморфной лямбды (нужно вручную делать function object), которую скоро добавят.
FR>Да static if с одной стороны конечно вещь гораздо более низкоуровневая чем концепты, но это FR>не только минус но и плюс, мощность у нее гораздо выше.
Какой именно static if? В D он может применяться в нескольких разных контекстах.
FR>Ну и плюс такой сахар как Template Constraints позволяет писать в стиле контрактов нового С++, хотя конечно с более примитивным матчингом.
Это же и есть один из вариантов static if, аналог которого есть в C++98 — enable_if.
Здравствуйте, FR, Вы писали:
EP>>Итераторы C++ обеспечивают эффективную композицию. Если у нас есть 4 итератора, то из них можно получить 6 range бесплатно, без runtime penalty — просто выбери нужную пару итераторов. FR>Да все так, но плата за эффективность внутри как раз практически невозможность композиции на итераторах снаружи, FR>цепочку из функций работающих с парами независимых итераторов делать практически невозможно. Понятно что тот же FR>boost::range все исправляет, но похоже что лучше иметь в стандартной библиотеке (как в C++ так и в D) и итераторы FR>и range.
В C++ добавят range'ы (которые пара итераторов) — afaik для этого есть целая study group.
FR>Ну и кстати написать для D итераторы ничего не мешает, и эффективность у них будет такой же как и в C++, так что FR>к недостаткам языка их отсутствие никак нельзя отнести.
Во-первых что-то для range'ей уже встроено непосредственно в язык, тот же foreach или slice'ы.
Во-вторых я показал range'ы как пример того, что авторы жертвуют производительностью ради других преимуществ.
В-третьих я сомневаюсь что итераторы теперь встроят в стандартную библиотеку D, без поддержки которой они вряд ли будут распространёнными.
EP>>Чтобы вернуть вменяемый результат, параллельно "рабочему" range'у приходится передёргивать дополнительный range result. В то время как в STL, нет этих лишних телодвижений — возвращается итератор, который практически бесплатно определяет два range'а. FR>Тут кстати еще в профайлер надо смотреть, эти лишние телодвижения по сути в машинном коде добавят пару FR>лишних инкрементов, это будет заметно только в очень вырожденных случаях.
Пара лишних инкремнтов будут на простейших range'ах, а если там что-то более сложное?
Мой поинт в том, что если абстракция порождает не-эффективный код by-design — то это изначально плохая абстракция.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
DM>>Вот такой пример на С++ как записывается? DM>>http://thedeemon.livejournal.com/53900.html
EP>Эти has_member доступны начиная с C++98, через SFINAE.
Речь не о них. Читай дальше, внимательнее, не спеши с ответом.
EP>А вот что доступно C++14: EP>
EP>template<typename T>
EP>concept bool Equality_comparable()
EP>{
EP> return requires(T a, T b)
EP> {
EP> bool = {a == b};
EP> bool = {a != b};
EP> };
EP>}
EP>
EP>Причём проверки такого вида были доступны и в C++11, через decltype, только в более нагромождённой форме.
В С++ это только обещают, в D это давно есть. Но не только это, а выполнение почти произвольного кода. Прочитать файл, отсортировать, распарсить, посчитать... Проверить компилируемость выражения, опять же, и в зависимости от результата делать осмысленные вещи.
DM>>(проверка переданного шаблона на выполнение аксиом функтора в категории)
EP>Я не увидел там никаких аксиом, только синтаксические проверки.
Внимательнее посмотри. Там описываются шаблонные функции и вызываются, результат вычислений используется в static if'e. Вычисления могут быть весьма нетривиальными.
EP> Вообще "проверка выполнения аксиом" — звучит крайне дико
Если тебе нужно реализовать, например, класс кольца или группы, то в тестах нужно проверить, что выполнены аксиомы кольца/группы. Это просто математика. Не нравится такое слово, можно говорить о "законах", каковое слово и было в посте.
Здравствуйте, DarkEld3r, Вы писали:
DE>А можешь книги по Д посоветовать? Просто туториалов/вики как-то мало, хочется более подробного разбора фич. Смущает, что "The D Programming Language" аж в 2010 году издана, по идее, в языке немало изменений было. Или книга всё-таки актуальна?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Он не говорил что получилось дотянуться до всех углов
Если насчет угла отвечающего за производительность, то ничего кроме плохого оптимизатора
в оригинальной версии dmd не мешает. На D вполне можно писать в стиле си или си с шаблонами
полностью отказавшись от GC.
EP>Такой foreach есть в C++98: boost::fusion::for_each. Не хватает только полиморфной лямбды (нужно вручную делать function object), которую скоро добавят.
Ну реально же страшно по сравнению с D. И не дай бог мелкую ошибку допустить и получим
километровое сообщение, и чуть начни более менее интенсивно такое применять, даже на мелких
проектах будет компиляция несколько минут минимум.
В D же все прозрачно, просто, одинаково что в компил что в ран тайм и без "синтаксического оверхеда"
наконец.
EP>Какой именно static if? В D он может применяться в нескольких разных контекстах.
static if вообще не разделяя на подвиды, и плюс CTFE конечно.
FR>>Ну и плюс такой сахар как Template Constraints позволяет писать в стиле контрактов нового С++, хотя конечно с более примитивным матчингом.
EP>Это же и есть один из вариантов static if, аналог которого есть в C++98 — enable_if.
Это да, я и писал про сахар, но это только одно мелкое применение, ну и опять удобней и проще.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В C++ добавят range'ы (которые пара итераторов) — afaik для этого есть целая study group.
Уже в 14 ?
FR>>Ну и кстати написать для D итераторы ничего не мешает, и эффективность у них будет такой же как и в C++, так что FR>>к недостаткам языка их отсутствие никак нельзя отнести.
EP>Во-первых что-то для range'ей уже встроено непосредственно в язык, тот же foreach или slice'ы.
EP>Во-вторых я показал range'ы как пример того, что авторы жертвуют производительностью ради других преимуществ.
С этим согласен, но согласись жертва невелика и никто ни мешает сделать свои итераторы.
EP>В-третьих я сомневаюсь что итераторы теперь встроят в стандартную библиотеку D, без поддержки которой они вряд ли будут распространёнными.
Это да, зря Александреску свою знаменитую статью писал
EP>Пара лишних инкремнтов будут на простейших range'ах, а если там что-то более сложное?
А что может быть еще сложнее? Что-то функций с десятком итераторов я не видел.
И опять таки скажем даже тот же std::transform (первое что пришло в голову с кучей итераторов)
переведется на range без всякой потери производительности.
В результате как я и говорил все сведется к достаточно узким случаям.
EP>Мой поинт в том, что если абстракция порождает не-эффективный код by-design — то это изначально плохая абстракция.
Здравствуйте, matumba, Вы писали:
К>>Не путай свои требования и главные требования. M>Где они спутаны? Цитату в студию или трепло.
У тебя в голове спутаны. Откуда твоя уверенность, что промышленности позарез нужно именно выкинуть си и взять ди?
Задумайся на досуге о том, что промышленность так и не выкинула си. Неспроста, наверное.
А за "или трепло" сам знаешь, куда тебе пойти.
К>>У С++ есть два плюса: мультипарадигменность и поддержка наследия.
M>Мульти... чо??? Этот ассемблер с классами? Родной, это не "мультипарадигменность", а БАРДАК — так будет точнее. M>Наследие? Ну и что с того? Раньше и на PL/1 писали, он что, стал от этого полезнее или правильнее? Его заслуженно забыли, потому что вовремя осознали — не нужен.
Вот так взяли и вовремя осознали? Да просто DEC не стал портировать PL/1 на PDP, а потом все дождались, когда IBM370 сдохнет.
Найди нишу, в которой D будет доминировать в силу личного предпочтения основателей, и доживи до светлого момента, когда ниша C/C++ закроется.
Только искать и ждать придётся долго: места расхватаны.
К>>Сколько стоит перенести гору уже существующего кода с C++ на D?
M>С чего вы решили, что вообще нужно переносить этот хлам??? Ди — не просто повторение "Си с классами", а практически новая методология! Ну или сильно улучшенная, как нравится. Т.е. переносить старые костыли нет никакого смысла, Ди предлагает куда более интересные вещи (CTFE, mixins, ranges, RTTI), под которые надо ЗАНОВО писать код. Кроме того, "легаси" зачастую грешит полным отсутствием вменяемой архитектуры, шаблонов, да и просто устаревшими приёмами. Пример — GCC, вот уж точно кого следует зазиповать и закопать.
Вот-вот, надо заново писать код. Кто будет платить кодерам?
Народ вовсю фортраном пользуется, чтобы адский матан не переписывать на модные академические языки.
Перекуём баги на фичи!
