ГовноGo зохавает не все, а нишу замены С++

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

И именно потому что Google > Mozilla и Go готов сейчас. Будь Rust хоть во всем круче.

Go готов именно потому, что это довольно средненький язык по сегодняшним меркам.

Именно...

... так.

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

И при реализации мы должны либо удостовериться что возвоащено корректное значение, либо, если оно нам неважно, сказать (void).

Например, man 3 printf. ;)

И при реализации мы должны либо удостовериться что возвоащено корректное значение, либо, если оно нам неважно, сказать (void)

Нет.

А здесь...

... я не соглашусь.

Не всегда, например, ф-ции из стандартной библиотеки могут быть выполнены. И лучше (если есть сомнения) подстраховаться, проверив сколько напечатано (опять-таки например) символов. Либо просто сказать (void)printf(...); или просто забить. Это простейший пример. В реале всё несколько сложнее.

С другой стороны, при использовании splint на постоянной основе, такие «мелочи» очень быстро становятся привычными. Если проанализировать мат splint'а, а не забивать на него.

... я не соглашусь.

Твое право. Но если в Си ставить void везде, где игнорируется значение выражения, это дойдет до маразма _очень_ быстро. Например:

(void)(x++);
(void)(c = 1);

это дойдет до маразма _очень_ быстро

Наоборот плюс, поощрение написания кода без сайдэффектов.

без сайдэффектов.

ЩИТО

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

С другой стороны в си в функциональном стиле особо не попишешь.

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

У тебя какое-то свое, глубоко личное, определение сайд-эффектов.

In computer science, a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions of the outside world.

Присваивание помимо возвращаемого значения также изменяет состояние, по википедии вполне себе сайдэффект.

Не...

... ну понятно что в каждое поле тыкать не нужно (void)... ))) Особенно, в случае с совсем уж очевидными вещами.

Присваивание помимо возвращаемого значения также изменяет состояние, по википедии вполне себе сайдэффект.

int fourtytwo() { return 42; }

// функция с сайд-эффектом
void f1() { int x = fourtytwo(); }

// функция без сайд-эффекта!111
void f2() { fourtytwo(); }

... ну понятно что в каждое поле тыкать не нужно (void)... )))

Понятно?

anonymous> мы должны либо удостовериться что возвоащено корректное значение, либо, если оно нам неважно, сказать (void)

Не вижу здесь исключений.

в случае с совсем уж очевидными вещами.

В случае с неочевидными вещами^W^Wаллокаторами лучше иметь атрибут warn_unused_result.

Честно сказать затрахали пиарщики языка D. Причем пиар неумелый и только во вред языку. D интересный язык, при прочих равных он лучше плюсов, но прочие как раз не равные и поэтому на убийцу плюсов он пока не тянет. Но сообщество у языка сильное и очень профессиональное - на официальном сайте не то, что быдлокодеров нет, а пару раз люди признались, что порой им не хватает знаний вникать в поднимаемые темы, хотя в своем городе/стране они выше среднего - в общем, некая академичность, но не оторванная от жизни присутствует. Вот русская версия сайта уже попахивает. DQuick я бы вообще не стал рекламировать, только вредить людям. Которые четко сказали что будут пилить его для своих нужд и вообще выкладывать его не хотели и они никогда не позиционировали его так громко как в первом посте этой темы. Вообще не понимаю, почему его упомянули.

Фейсбук - ну и что? Сколько можно это мусолить? Расширение функциональности Фобоса - вот про аллокаторы бы стоило упомянуть как раз, а тут тишина. На днях Александреску предложил сообществу модуль std.allocator, который реализует нетипизированные аллокаторы. Очень мощный функционал, после принятия в Фобос D реально позволить отказаться от сборщика мусора где нужно (правда еще Фобос нужно будет переписать в той части, в которой используется гц). Для плюсистов это будет хороший знак. После аллокаторов допилят контейнеры (их текущая реализация имеет ряд недостатков, которые ждут как раз аллокаторов, они не критичны, но не красят язык это точно). Лично я бы позициронировал язык как более удобный и дружелюбный чем плюсы - одни шаблоны чего стоят. Кто внутрь Boost'а глядел, понимают, как это классно, когда ты можешь посмотреть код и понять его не будучи гуру в шаблонах - в D дело обстоит именно так. Там никому в голову не придет избегать либы с тяжелым использованием шаблонов, как это с Boost'ом обстоит. При этом по возможностям/недостаткам D чаще превосходит плюсы, чем плюсы его - в чистом виде, как язык без инфраструктуры. Самый главный недостаток у D для меня на данный момент это отсутствие библиотек, но вопрос решаемый за счет совместимости с сишными либами, да и народ по маленьку пишет. С гуями определенное неудобство - гтк работает, но под виндой все-таки не родной, есть порт SWT работает кроссплатформенно и использует нативный гуй, но только 32 бита - в общем вроде все есть и есть даже выбор небольшой, но присмотришься, то здесь, то там чего-то нехватает.

Очень интересный подход к concurrency в виде message passing плюс immutable data плюс TLS - все поддерживается на уровне языка, писать код в функциональном стиле очень эффективно - быстро и просто, при этом perfomance drawback не очень большой и в большинстве случаев им можно пренебречь, насчет потребления памяти - кого это волнует при текущих ценах на нее? Правда многие, как я посмотрел, пытаются на Ди писать в привычном стиле со всеми вытекающими - менталитет, хрен ли. Но признаю, эта часть фобоса не доведена до завершения - с простыми встроенными типами работает на ура, с пользовательскими приходится иногда использовать workaround'ы, что раздражает. Пару раз язык вызывал у меня приступы откровенного бешенства - из-за того что кое-чего важного не хватало и что есть, например, в плюсах, и при все при этом мысли переписать все на плюсах никогда не возникала, лично для меня альтернативы нет, благо есть возможность.

Сейчас идет работа над разделяемыми библиотеками, одна крупная контора (не ФБ) выразила желание использовать D в продакшене, если будет нормальная поддержка динамических либ, по этому поводу хотели их еще в 2.063 допилить, но не шмогли, сейчас обещают в 2.064 сделать все в никсах, про винду и макось промолчали. По-маленьку пилят код для армов, поддержку андроида, но это не мейнстрим пока. Кричать, что язык супер и кто не перешел на Ди тот лох я бы точно не стал. Пишите на том языке на котором пишите. Есть время и интерес изучить что-то новое - попробуйте написать для души небольшой проект. Уверен, некоторым понравится. В ньюсгруппе признавались некоторые, что пишут прототипы своих проектов на ди, потом переписывают на плюсах и пускают в продакшн - говорят так быстрее, чем сразу писать на плюсах. Вроде все сказал, что на языке было.

Хммм...

...

С другой стороны в си в функциональном стиле особо не попишешь.

С одной стороны — а надо ли? Ведь изначально (согласно той же википедии http://en.wikipedia.org/wiki/Functional_programming), ЯФП несколько менее эффективны в ряде случаев. В частности я говорю о:

Functional programming languages are typically less efficient in their use of CPU and memory than imperative languages such as C and Pascal.[49]

Почему так, там дальше написано, не столь суть. С другой стороны, были и есть разного рода эксперименты, например:

- http://lucabolognese.wordpress.com/2013/01/04/functional-programming-in-c/

- http://bartoszmilewski.com/2011/07/11/monads-in-c/ (оговорюсь — здесь «кресты», но при изрядной доле желания, до С допилить можно, но вот нужно ли?).

- некоторые фичи замыканий можно симитировать посредством callback-функций и в С, например — http://en.wikipedia.org/wiki/Closure_(computer_science)

Можно ещё нарыть (был ещё проект старый по прямо closures in C, забыл где видел, я его давненько смотрел), не в том суть. В С Вы в принципе ограничены разве что своими желаниями/потребностями. Навряд ли кто-то будет ваять чистый вариант ЯФП в С только для того, чтобы сказать что С это ЯФП. Смысла нет. Сишники, как правило, более прагматичны. )))

Конечно не увидите...

... здесь исключений. Я всё-таки исхожу из того, что программист не является хроническим идиотом (к пыхерам это не относится, впрочем, как и «программирование» в общем и целом). По крайней мере, если возвращаемое значение тривиально, то лучше не баловаться. Хотя, если добавить в .vimrc аббревиатуру для (v вида (void), для файлов C, то можно даже не запариваться по данному поводу. )))

Это не так. Выравнивание отступов от начала строки сохраняется

There’s More Than One Way To Do It

Perl же, ну!

void f1() { int x = fourtytwo(); }

Это не присваивание, это инициализация, так что сайд-эффекта тут нет.

void f1() { int x = fourtytwo(); }

Это не присваивание, это инициализация, так что сайд-эффекта тут нет.

Ахпростите.

// функция с сайд-эффектом
 void f1() { int x = 0; x = fourtytwo(); }

Нормально? Есть сайд-эффект?

Так что в результате они либо упустят время и говноGo всё зохавает, либо они выпустят незавершенный язык.

Да ладно. Go как-то вообще не впечатляет, а начнут к нему фичи массово прикручивать - может монстр не хуже С++ получится.

К тому же вон D «готов» давно уже, а толку? А за растом хотя бы мозилла. Плюс, вроде, самсунг поддержать их в этом хотел?

Go как-то вообще не впечатляет

Да. Но, с другой стороны, Ява тоже не впечатляла в свое время.

Go поднимается на крыло. И в rust-dev@ о нем говорят достаточно часто.

Насчет Samsung ничего не слышал с момента анонса Servo.

изначально предназначенного для решения специфичных для «телекома» задач, его тянут куда ни попадя.

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

Самый главный недостаток у D для меня на данный момент это отсутствие библиотек, но вопрос решаемый за счет совместимости с сишными либами

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

Будь Rust хоть во всем круче.

Он уже не очень.

чесгря после питона мне любой язык

Там есть статическая типизация?

Да. Но, с другой стороны, Ява тоже не впечатляла в свое время.

А что тут вообще сравнивать, когда Ява уже 10 лет назад стала майнстримом промышленной разработки ПО, при этом обеспечив фантастические по своей доступности и возможности средсва разработки. Я видел работы школьников 8-11 классов, сделанных на javafx - очень впечатляет.

где есть ключевое слово new

А как ты относишься к языкам где есть malloc/free?

Напишу сервачок с верой в глазах что green threads спасут отца русской демократии и посмотрю сколько сожрет памяти на 10к активных соединениях, думаю будет хорошей оценкой влияния реализации стеков

А TCO в данной нише не критичен

Почему бы просто не взять эрланг?

А почему просто взять и не взять ерланг?

Да. Но, с другой стороны, Ява тоже не впечатляла в свое время.

Ну так и сейчас тоже? Впечатляет разве что «большей кросплатформенностью», а в плане фич от своего «конкурента» (С#) сильно отстаёт. Ну и количество библиотек, наверное.

Go поднимается на крыло. И в rust-dev@ о нем говорят достаточно часто.

Ну может быть, не сильно слежу за его развитием.

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

(void)(x++);
(void)(c = 1);

что любопытно — ты так сам ответил на свой вопрос «почему return последнего значения это плохо» (я его буду называть неявный return)

допустим, прогер пишет код, и временно *бросает* его на стадии, где последним оказывается одно из этих выражений; если разрешен неявный return, то вернувшись сюда через час, прогер легко не сможет узнать, бросил он код, или завершил

тут можно возразить, что подобного рода выражения можно запретить, и заставить скажем писать

c=1;
c;

c x++ это уже не проходит, и есть еще проблема: допустим, у нас есть printf, который в случае неудачи кидает исключение, а обычно возвращает число отпечатанных символов, которое в 90% никому не нужно, и игнорируется — тут опять не различишь, хотелось ли выдать из функции результат printf, или чуть дописать еще

на самом деле это конечно не разбор до полной глубины, но пусть будет так

еще добавлю, что where типа как в хаскеле куда нагляднее неявного return-а (если оно применимо)

вместо

if( a>0 ) {
  int x=f(1, 2);
  x+=g(x, 3);
  h(x, y, 4);                      // подразумевается return h(x, y, 4);
}

пишем:

if( a>0 ) {
  return h(x, y, 4) where { int x=f(1, 2); x+=g(x, 3); }
}

допустим, прогер пишет код, и временно *бросает* его на стадии,

Ну а если «прогер» напишет такое:

bool foo()
{
    // TODO!!!
    return true;
}

С принтом пример тоже так себе - это будет «проблемой» только если возвращаемое значение схожего типа.

Хотя лично я проблемы в явном ретурне не вижу вообще.

Фейсбук - ну и что? Сколько можно это мусолить?

где-то я видел мнение (с которым соглашусь), что фейсбуку легче потерпеть у себя 5клок абсолютно любого кода, пусть даже на брейнфаке, чем уволить александреску

Расширение функциональности Фобоса - вот про аллокаторы бы стоило упомянуть как раз, а тут тишина. На днях Александреску предложил сообществу модуль std.allocator, который реализует нетипизированные аллокаторы.

кинь ссылочку плиз

И при этом тип совпал?

Что тут удивительного/особенного? Часто для retrun типа используют int и bool, совпадение достаточно вероятно даже если запретить неявные преобразования.

Ну, если уж придумывать сценарии ошибки, то пусть будет такой: при рефакторинге просто дописали return перед последним оператором.

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

я тебя не понял до конца

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

вообще мне не нравится читать код с неявным return-ом, хотя писать его возможно удобнее в таком ide — впрочем, ide может вполне подставлять и return /* TODO */ в соответствующие блоки

Ну а если «прогер» напишет такое:

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

Очень верно сказано. Многие так называемые «пиарщики» в русскоязычном сегменте сети на самом деле сами имеют достаточно смутное представление о том, что рекламируют и постоянно передёргивают факты. Я вообще не рекомендовал бы верить ничему кроме официального англоязычного newsgroup и #d @ irc.freenode.net

Впрочем, не то что бы на LOR когда-то пытались серьёзно вникать в тему, главное лишь бы был повод для холиваров :)

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

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

кинь ссылочку плиз

http://forum.dlang.org/post/l4btsk$5u8$1@digitalmars.com

я тебя не понял до конца

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

вообще мне не нравится читать код с неявным return-ом

Да мне, если честно, пофиг. Реальных преимуществ ведь нет. В смысле и так и так устраивает. С ретурном, наверное, для большинства привычнее. Писать тоже не намного больше.

то с большей вероятностью баг вылезет сразу на тестировании по сравнению с ф-ий потенциально возвращающей множество значений.

Ну я думал мы всё-таки о статически типиззированных языках говорим.

И соответственно «сильно много» значений вернуть не удастся. То есть проблема только с самыми простыми случайми типа инта/була вылезать будет.

И соответственно «сильно много» значений вернуть не удастся.

И не нужно. Фантомный баг легко можно сделать даже на булевом типе. Если, например, статистически в >99 % будет возвращать true, а в остатке false (или наоборот). Потому случай со 100 % true (или false, т.е. с константным значением) в заглушке значительно выгоднее возврата значения из последнего выражения, т.к. он не оставляет неопределённости.

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

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

статическая типизация

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

malloc/free

это функции. и не отношусь. каджому - свое

Ну, пока всё традиционно, «обсуждается вкус ананасов». Противопоставление C++/Go, / D забавляет (понятно, человек, скорее всего, не дал себе труда плотно разобраться ни в одном из обсуждаемых предметов).

Однако, общий интерес радует. Из стадии «предмет не замечают», плавно перетекли в стадию агрессивного неприятия. До «я всегда говорил, это вещь!», осталось совсем чуть-чуть :)

Жду норм поддержку для iOS и Android. А пока не нужно. Хотя сам язык мне очень понравился...

допустим, прогер пишет код, и временно *бросает* его на стадии, где последним оказывается одно из этих выражений; если разрешен неявный return, то вернувшись сюда через час, прогер легко не сможет узнать, бросил он код, или завершил

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

тут можно возразить

Самое лучшее возражение здесь - NOTABUG WONTFIX.

на самом деле это конечно не разбор до полной глубины

На самом деле это придумывание проблем на ровном месте - и тобой, и mashina. Альтернативно, это Си/Си++/D головного мозга.

D-Quick - A GUI library written in D

• C 84.7%
• Shell 7.1%
• C++ 2.8%
• Objective-C 2.6%
• D 2.0%
• Other 0.8%

Я б не сказал... :)