Вышла новая версия компилятора языка D DMD 2.064

Я не говорил, что она не выполняет ничего. + возвращает значение, которое никак не используется. Следовательно компилятор считает, что действия нет.

О да! Тут вполне правильно написано все http://dlang.ru/Why-D-is-Better

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

«Можно использовать существующий код на С++? - Нет, выкиньте всё и пофиг, что переписать займёт кучу времени». Ну и файсбуком теперь всюду тыкать будут. Только очень сомневаюсь, что там этому совету последуют. В смысле старый код весь останется и уверен, что и дальше на С++ писать будут.

Можно, если у этого кода есть биндинги к C. Иначе с зоопарком D не работает.

ты еще в иерусалиме в центре синагоги крикни «аллах акбар!»

var funcs = {
    "echo": function (user, data) {
        return data;
    }
};

Да ладно, элементарная конструкция.

Можно, если у этого кода есть биндинги к C. Иначе с зоопарком D не работает.

Да я понимаю. И даже, в принципе, согласен с их решением. Вот только по ссылке осторожно говорится «не стоит», вместо того чтобы признать, что нельзя.

словарь анонимных функций

Что это за бред -_^

А как в Lua, например. Все функции являются объектами первого порядка и анонимны. «function f(x, y)» работает как «f = function(x, y)», то есть определяет переменную, которой эта функция присваивается как значение. Можно так же запихать их в словарь. А в Python придётся сначала объявлять именованные функции, а потом делать из них словарь.

Конкретно эта элементарная конструкция в Python еще короче.

Как только функция длиннее одной строчки, уже нет.

честгря после того как питон слил коду на Fortran IV образца 1973 года в 700 раз,
в 700 БЛЯТЬ РАЗ на современом железе типа amd opteron,
на задаче истечения плоской ламинарной струи,

О! Недобитки из РАН подтянулись. Мыльте анус скоро начнется охота на ведьм - все пойдёте дерьмо вместе с таджиками на стройках месить!

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

Му-ха-ха! Влажные мечты импотента :)

Нету в России надобности считать «задаче истечения плоской ламинарной струи». Промышленности и науки нет ==> задач таких нет. ---- В том _одном_ месте где ещё надо - на фортране и считают. Во первых потому что он и С\С++\жабу рвёт :) А во вторых - некому это правильно переделать. Все у кого мозги были давно уже далече ... ---- А есть задачи делать говносайты. Много и быстро. А ну еакидай что нить простейшее на фортране?! И вот тут то почётный импотент РАН ты узнаешь что любой школьник с питоном или рябой уделает тебя так жалкие 600 раз окажутся просто шалостями ... в общем начинай тренироваться с лопатой бомжара! :)

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

JavaScript же. Теперь можно запускать funcs[command](user, args) и радоваться, не плодя кучу лишних говноклассов.

А, я понял. Наверное, годится как одноразовое решение.

Но при чем здесь тогда анонимность? Так можно и в си, в мапе строка-указатель на функцию, наверное, делать. Примерно тот же уровень удобства)

Анонимность при том, что в неймспейсе функций нет. Для JS и прочих языков с first class функциями это очевидный синтаксис (ну кроме питона с корявыми лямбдами), в си очевиднее написать switch.

Ну на самом деле если C++ собран gcc то ограниченно можно.

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

Тогда в чем смысл писать такой код?

А в Python придётся сначала объявлять именованные функции

В питоне есть лямбды.

Можно и в си делать, в чем проблема. И зачем тут акторы?

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

В питоне есть лямбды.

Ога. Однострочные.

Но если хочется пополнить ряды конъюнктурного взаимозаменяемого говна, на выбор всегда есть C++, Java, PHP и язык 1С.

Я отмечу этот день в календаре, язык 1С поставили в один ряд с плюсами и явой :D

wxwidgets? Хотя упоминали уже, наверное.

wxwidgets

R.I.P., был актуален ровно до тех пор, пока Qt не сменил лицензию

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

ну и что это добавляет кроме +1 контекста к такому простому оператору? Любители гамаков... и нелёгких путей ёпт)

Это мне известно, я просто не вижу толкового применения.

Отступами

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

однострочными лямбдами

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

малым количеством библиотек

какой библиотеки тебе не хватило?

несовместимостью версий

приведи проблему.

встроенным в язык фашизмом

приведи пример.

и невозможностью писать в стиле

sub sm {if (^(?=[MDCLXVI])M*(C[MD]|D?C{0,3})(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$) {print $_} for @sm}[/perl]

зачем еще один перл?

Но ведь если язык задизайнен так, что реализовать многострочные лямбды сложнее, чем однострочные, то это тревожный звонок?

R.I.P., был актуален

wxWidgets 3.0.0-RC2 Released 2013-10-28

яснопонятно

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

wxWidgets 3.0.0-RC2 Released 2013-10-28
яснопонятно

да видел я эту новость и даже тыкал в этот самый RC2, как было глюкаловом, так и осталось, а добавленная поддержка cocoa и gtk3 (еще с 2.9) осталась кривая и недоделанная

из за глюков виджета и строгих ограничений версии в заказе, как то пришлось отказатся от заказа...вот так.

Ну тады ncurses || slang во все поля!) Универсально.

я уже писал - есть Qt, работает даже на большем кол-ве платформ чем wxWidgets

Любой язык, где нужно писать — не интересен

ждем python 4 со скобочками { }

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

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

О да! Тут вполне правильно написано все http://dlang.ru/Why-D-is-Better

С++ головного мозга уже не лечится.

По ссылке какое-то передергивание. Попробую объяснить, почему я так считаю.

• Какие преимущества я получу перейдя на D с С++?

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

  На практике есть уйма больших и громадных приложений написано на C++ [в качестве показательного примера http://www.stroustrup.com/applications.html]. ПО написано и решает задачи. Разве все бы ринулись писать на C++ относительно новые проекты, если создание на C++ оказалось очень сложным? На моё мнение, если язык действительно «создает больше проблем чем решает» и на нём «очень сложно писать и отлаживать код», то от него бы повально отказывались. Такого не наблюдается. Так что это скорее демагогия и словоблудие.

  Концепция ООП наложенная на C++ приводит к наследованию, делегированию и расширению количества ошибок. Это способствует «маскирующему размытию» багов, которые накапливаются по экспоненте.
  

  Пафосная фраза, рецепт дают дальше:

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

  Я считаю, что это бред быдлокодера или фанатика. «Мы не можем исправить баг, давайте всё нахрен перепишем с нуля с новой концепцией! Нет, лучше поменять платформу!». Для приличия привели бы примеры таких fatality-багов, когда пришлось в крупных продуктах менять целую концепцию или вообще платформу.

  Опыт показывает, что при переходе на D с C++ программисты экономят до 50% времени на написание и до 3-4 раз на отладку приложений.
  

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

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

  Особенно хорошо видно, что при написании продакшен кода с жесткими сроками, при наличии кучи практик и советов по написанию красивого кода, на выходе всё равно получаем быдлокод и говно. Потому что времени писать красивый код не хватает. А написать говно можно на любом языке. Опять же, пруфов у меня столько же, как у процитированного утверждения.
• Чем D лучше нового стандарта C++ 14 (C++0x)?

  Проблема в том, что на D вам придётся писать правильно
  

  Партии виднее, как правильно?

  на C++ по-прежнему можно писать как раньше
  

  Ключевое слово «можно». Между «можно» и «надо» большая разница. Партию не устраивает количество возможностей? Не обязательно их все использовать, для этого есть гайдлайны. Мы же говорим о крупных проектах, где непосредственно кодинг — только часть разработки, и есть нормальное планирование проекта, архитектуры. Да и в D без гайдлайнов не обойтись.

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

  «Современные» языки ещё под стол ходили, когда появлялись предыдущие стандарты C++. Закономерно, что с обкаткой этих современных языков (пока они не стали production-ready) появлялись и новые фичи в C++. А изначально некоторых возможностей не было, потому что тот же C++ появился в 1983, а не в 1999 (как D), так что упрекать в изначальном отсутствии некоторых фич... как бы некорректно, разве не так?

  Добавим сюда такие факты — первая стабильная версия компилятора D вышла только в 2007 (продакшн не пишут на свежевыпеченных бетах). Так что стоит отталкиваться от этой даты, если уж рассуждать об том, что некоторые фичи были давно или изначально. Значительная часть фич из стандарта C++11 (тогда C++0x) были уже доступны в gcc 4.3 и 4.4, выпуск которых был в 2008 и 2009 годах. С каждым годом всё больше и больше фич ставало доступным. Как мне кажется, несколько лет — не слишком большой период для production-ready ЯП, чтобы D мог так легкомысленно кидать камни в огород C++.

• Зачем писать на D если на С++ уже написано миллионы строк кода?

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

  Меняются ТЗ, условия эксплуатации. Хотя legacy-говна хоть жопой жуй. Они про это не в курсе?

  Каждые 5 лет мы шагаем в новые измерения и только самый прозорливый разработчик может себе позволить код, который не выкинут через 10 лет.
  

  За 10 лет не поменяются платформы, объемы задач, не произойдет смена или уточнения ТЗ, не будет эволюции в рантайме (библиотеки, ядра)? Хотя постойте, код, который не выкидывают и через 10 лет... Думаю, что у Microsoft куча прозорливых разработчиков.

  Поэтому не надо бояться использовать современные языки. Они позволяют вам реально сэкономить свое время.
  

  Аналогично: не надо бояться использовать C++11 с фичами C++14. Это современно, и позволит сэкономить своё время.
• Стоит ли мешать в одном проекте С++ и D?

  Лучшим вариантом будет использование D в новых проектах.
  

  Аналогично: лучшим вариантом будет использование C++11/C++14 в новых проектах.

  Портирование имеющегося кода с С++ на D может быть весьма трудоемко, однако это позволит сделать код более простым и легким в поддержке.
  

  Потирование имеющегося кода с C++ предыдущих стандартов на C++11/C++14 может быть _несколько_ трудоемко, однако это позволит сделать код более простым и легким в поддержке.

И вообще, интересный текст. С одной стороны говорят про код, который должен быть написан в жесткие рамки за короткое время, и D идеально подходит. С другой стороны предполагается, что потенциально этот код пишут на 10 лет наперед. Если разработчики настолько прозорливы, что планируют на 10 лет наперед, то могли бы изначально сделать всё правильно на любом языке, не? С четким ТЗ, архитектурой, документацией. Чаще происходит эволюция, и инструменты улучшаются со временем.

И да, мне припекло от статьи по ссылке, на их месте я бы лучше оставил демагогию в стороне и оперировал бы сухими фактами, примерами и какой-никакой релевантной статистикой с пруфами на методы и результаты исследований. Но они это не сделали, как и я, так что можете считать, что всё написанное мной — ЛПП.

Приведи пример кода, где нужна _именно_ лямбда, а использовать функцию - не вопрос принципа и религии.

Приведи пример кода, где нужен именно питон, а использовать ассемблер не вопрос принципа и религии. Это лишь вопрос удобства.

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

Вообще, весь сайт dlang.ru какой-то бредовый.

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

Легаси код и легко заменяемые программисты делают свое дело.

Это понятно. Но в чём же фатальный недостаток C++ (если точнее, то C++11/C++14)?

Пример можно?

Это же достаточно очевидно. Есть, например, ф-я с такой сигнатурой

void func() {

   /* ... */

   func2();
}

Это реальные распространённые баги, которые отлавливаются на стадии компиляции.

Теперь просишь другого разработчика найти и пофиксить фантомный баг (~бегло отревьювить, провести аудит). Смотрит он на реализацию type func() и аналогичные ф-ии, нигде не ясно забыли ли вернуть осмысленное значение или нет. Чтобы это понять нужно прочитывать и осмысливать код всех ф-ии.

Есть известная реализация xmpp сервера, ejabberd. Попроюуй поревьювь некоторые объёмистые ф-ии, хотя бы просто поискать точки выхода и возможные возвращаемые значения. Это довольно напряжно по сравнению с return'ми. Код в разы чаще читается людьми, чем пишется новый.

Почему-то на эрланге работают высоконагруженные кластеры и никто не жалуется.

на PHP тоже работает много «высоконагруженного» гогна и сами адепты этого действия на себя не жалуются, у них всё ок.

Далее ответ пользователю tailgunner

почему это чревато багами в строго и статически типизированном языке

нужно рассказать что такое неявное приведение типов, copy constructor и про прочие прелести ООП-подобных ЯП?

над созданием универсального кросплатформенного графического тулкита

QT форкнули? Я что-то проспал?

Quick Time?

Вот тут неплохо описано (включая комментарии) http://love5an.livejournal.com/364435.html

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

Это совсем легко, словарь анонимных ф-ий в питоне это класс.

Потом её немного рефакторят, делают ф-ю с возвращаемым значением забывая дописать конец.

Суперсложный рефакторинг, так много нюансов чтобы уследить.

Получается валидная с точки зрения языка ф-я

Нет, если только новый тип func вдруг случайно не совпал с типом func2.

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

Разве не проще тогда чтобы любая конструкция языка возвращала что-то осмысленное?

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

Не, вобще-то надо просто посмотреть на последнее выражение функции.

выплываешь аналогией с ассебмлером?) яснопонятно.

Если многострочные лямбды - вопрос удобства, то я прошу тебя привести пример этого самого удобства. Ну? Пожалуйста! Не мучай всех нас. _Покажи код_, балаболка! :)