LINUX.ORG.RU

Почему Go это плохо, и он вам, на самом деле, не нужен.

 ,


7

15

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

Дело в том, что Go это, на самом деле, «решение» внутренних гугловских проблем. Но отнюдь не проблем горизонтального масштабирования серверного ПО, как многие почему-то думают. Он приспособлен специально для использования в гугле вот в каком контексте.

Гугл нанимает большое количество тупых студентов, только-только после вуза или ПТУ, и заставлять их писать хоть какой-то простой код. И делать минимум ошибок, при этом. Для этого Go сделан таким тупым и упрощенным. И выкинут в паблик он только для того, чтобы вероятность, что у такого студента, только пришедшего в гугл, было хоть какое-то знание Go, была выше нуля.

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

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

Тут возникает вопрос - а почему этому тимлиду не дать в руки кодогенератор, вместо всей этой accidental complexity, возникающей из-за огромного количества строк кода, и из-за затрат на коммуникацию?

А тут надо понимать, как внутри устроены огромные корпорации типа гугла.

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

Естественно, это все отражается на качестве продуктов, и это видно как по полному прекращению инноваций в гугле, так и по постоянно мелькающим и закрывающимся высерам этой компании - hangouts, duo, google plus, google wave, и прочее и прочее, можете еще вспомнить много чего.

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

Никакой мифической простоты в отладке и в понимании кода Go не приносит. Да и сложность программных систем растет совершенно не из-за понятности/непонятности какой-то отдельной взятой строчки кода или функции. Потому, что, во-первых, понятность это понятие субъективное, во-вторых потому, что, отдельно взятая фунцкия на 5 строк понятна любому опытному программисту, будь она написана хоть на Rust, хоть на Common Lisp.

Сложность программных систем возникает из-за их размера. И Go эту проблему значительно ухудшает. Человек не может удерживать в голове слишком много вещей, даже если каждая отдельная вещь - очень простая. Количество RAM в голове ограничено.

В случае если вы не хотите выкидывать кучу денег просто так, и скорее предпочли бы нанять немного, но более-менее опытных программистов, Go будет только вреден, потому что все вменяемые люди от него, на самом деле, плюются. Он реально отталкивает опытных людей, которые способны понять сложные требования и написать, и поддерживать, более-менее сложные системы уровнем хотя бы нескольких сервисов плюс БД и MQ.

★★
Ответ на: комментарий от hateyoufeel

Тю! Ничо сложного. Немного практики и всё.

Ну так вопрос же не в том, можно ли в принципе освоить или нет. Понятно, что в большинстве случаев можно.

Просто для Scala это «немного практики» будет на 2-3-4 недели больше, чем для Java.

Ну а потом еще +N лет на то, чтобы научиться писать на Scala (или C++) так, чтобы и ты сам через 10 лет смог понять, что же тут написано. Не говоря уже про других людей :)

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

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

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

Просто для Scala это «немного практики» будет на 2-3-4 недели больше, чем для Java.

Ичо? У тебя стоит задача сделать проект руками тотальных нубов, которые программирование вчера увидели?

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

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

Да нет никакой защиты. И быть её не может. Тебе я тоже предложу посмотреть на C, в котором как и в Golang нихрена нет, но чудовищного говнокода, который непонятно что вообще делает, просто вагоны.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 4)
Ответ на: комментарий от hateyoufeel

Ичо?

То, что на Java можно начать педалить код через неделю после начала изучения Java. На Scala – через месяц.

Это если нам нужно нормальный код педалить, а не говно разводить.

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

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

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

Но к ним может добавиться еще и особенность языка программирования. Типа C++ных загадок: вот есть 3 перегрузки функции f и вызов f(0), какая из них вызовется. Или, из того, о чем читал вчера: почему от std::enable_shared_from_this нужно обязательно наследоваться публично.

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

ИМХО, конечно.

В том же C++ изрядное время на приобретения «мастерства» уходит не столько на то, чтобы освоить фичи C++, сколько на то, чтобы обходиться минимальным их количеством, не переусложняя на ровном месте. Насколько я читал критиков Scala, там подобный эффект имеет место быть.

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

Жаваскрипт не напоминает, не? Говнокод умирает, языки живут. Уж сколько говнины было написано на четвертом похапе...

Но камент был лишь о том, что «С++ за 21 день» для 2003 года это вполне нормально. И говнокод тоже ггг.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от eao197

То, что на Java можно начать педалить код через неделю после начала изучения Java. На Scala – через месяц.

Это не важно. Это делается один раз, на этапе вхождения в профессию.

Это если нам нужно нормальный код педалить, а не говно разводить.

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

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

Да, но:

  1. Не настолько.
  2. Это крайне индивидуально и относительно. Я вот без проблем хачкелл осилил, а жабу не осилил. Но говорят обычно, что жаба куда проще и легче.
  3. Всё равно вхождение в предметную область сложнее.

Но к ним может добавиться еще и особенность языка программирования. Типа C++ных загадок: вот есть 3 перегрузки функции f и вызов f(0), какая из них вызовется.

Потому что C++ – довольно всратый и убогий язычок, давай посмотрим правде в лицо. В рамках моего старого предыдущего треда, я бы хотел implicit casts нахрен вырубить из языка.

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

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

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

Говнокод умирает, языки живут. Уж сколько говнины было написано на четвертом похапе…

Эта говнина сдохла вместе с четвёртым и всеми остальными PHP. Лет 15 назад пхпшников были толпы, сейчас знаю наверное двух и обоим сильно за 30.

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

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

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

Это от человека зависит. Не знаю, как сейчас, но еще лет 10 назад толковый выпускник ВУЗа по профильной специальности уже был способен писать нормальный код (речь про плюсы, да). Больше времени уходило на то, чтобы погрузить его в предметную область и имеющуюся кодовую базу, а вот код писать учить уже не нужно было. Разве что подправлять иногда.

Потому что C++ – довольно всратый и убогий язычок, давай посмотрим правде в лицо.

Про степень убогости мне судить сложно. Но всратый, да. Хотя я все равно предпочту иметь дело с C++, чем с тем же Си, которого вокруг меня, так уж получается, немало. И с тем же Rust-ом выбор в моем случае сильно неоднозначен.

В рамках моего старого предыдущего треда, я бы хотел implicit casts нахрен вырубить из языка.

Так не вы один. Не вы один.

Нет, ты неправ.

Возможно.

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

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

но еще лет 10 назад***толковый***выпускник ВУЗа по профильной специальности уже был способен писать нормальный код (речь про плюсы, да).

Выпускник ВУЗа – это минимум два-три года опыта в профессии, а для толковых и больше. Я начал работать full time на втором курсе, например, а писать код на благо впопенсорца ещё и раньше.

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

Одинаково убогий?

Не, я не спорю, что при опыте в C и C++ на голанге писать не самый плохой код довольно просто. Но ключевое тут – опыт в C и C++.

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

Одинаково убогий?

Об этом история умалчивает. Но утверждают, что он был работающим.

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

Но то, что она есть, невозможно не признать.

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

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

Одинаково убогий?

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

Я, кстати, поэтому лавсану в первом сообщении и написал, что проектировали го умные деды, ака инженеры. В отличие от того же раста, например, который вообще не проектировали, а «чо выросло из экспериментов Грейдона»: что stdlib безблагодатное нечто, что синтаксис та ещё мазафака, что шатания во все стороны типа затаскивания асинков в синтаксис языка.

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

Dark_SavanT ★★★★★
()
Последнее исправление: Dark_SavanT (всего исправлений: 1)
Ответ на: комментарий от eao197

Я скорее подтвердить утверждение, чем объяснить.

Но это в целом уже общий подход - мне лень делать сложно. Самому же потом страдать.

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

Но это в целом уже общий подход - мне лень делать сложно.

Мне с этим гораздо проще: делать сложно мозгов не хватает :)

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

Код на го в отличие от большинства «красивых» и «любимых программистами» языков отвечает главному армейскому правилу: «безобразно, зато единообразно».

Дык, прямо как в жабе поначалу. Тоже был убогонький недоязычок, чтобы клепать однообразное говнецо. Только тогда программистов ещё заставляли костюмы носить, потому что serious business. Голанг – это такая жабка, только без объектов и виртуальной машины и с налётом старбакса.

Написать микропен^H^H^Hсервис или там простую консольную приблуду вполне пойдёт. А больше ничего на нём и не пишут.

Я так понимаю, в гугле решили его пилить, когда жабу Oracle зохавал и у гугловских в жопе засвербила паранойя по поводу судебных исков.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

Я так понимаю, в гугле решили его пилить, когда жабу Oracle зохавал и у гугловских в жопе засвербила паранойя по поводу судебных исков.

Если я правильно помню рассказы Пайка времен начала 2010-х годов, то пилить они его начали потому, что для большинства тамошных средних программистов C++ и Java оказались слишкамсложными, а Python – тормознутым и динамическим.

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

Ну и да, Java в 2007-2008-х годах была уже посложнее оной в 1995-ом.

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

Если я правильно помню рассказы Пайка времен начала 2010-х годов, то пилить они его начали потому, что для большинства тамошных средних программистов C++ и Java оказались слишкамсложными, а Python – тормознутым и динамическим.

Да, это реальная проблема была в то время: не было язычков, которые бы компилировались в нативный код, но при этом не были бы чудовищным наслоением костылей и отстрелянных ног. Ладно, были Haskell и ML, но они всегда обладали ореолом особой магии. Rust и Golang довольно неплохо дали начало заполнению этой ниши.

Хотя давай не будем забывать, что Пайк пытался давно кому-нибудь свои говноязычки типа Alef и Limbo присунуть, и наконец смог найти аудиторию. Golang и Limbo прямо очень очень похожи.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

Был D. В редакции D1 он был вот прям отличной Java for native code done right :)

Но тут, полагаю, сыграло и то, что тогда уже к разработке D подключился Александреску и уже было обещано, что когда-то в будущем будет несовместимый D2. И то, что у Пайка явно неприятие ООП на классах в стиле C++/Java. Ну и без NIH-синдрома не обошлось наверняка.

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

Был D.

Ну как был. Была какая-то непереносимая глючная хрень, от которой в итоге плевались все, кто ей пользовался. Почитай посты от разработчиков OpenMW: он изначально был на D, а потом его на C++ перенесли.

И то, что у Пайка явно неприятие ООП на классах в стиле C++/Java.

У Пайка не неприятие ООП, у Пайка мозг застрял в 70х. Он вообще ничего, что было изобретено в последние 50 лет, не приемлет. Отсюда наполненность голанга указателями на каждый чих. Только там это теперь правильные указатели.

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

Ну как был. Была какая-то непереносимая глючная хрень, от которой в итоге плевались все, кто ей пользовался. Почитай посты от разработчиков OpenMW: он изначально был на D, а потом его на C++ перенесли.

Я эпизодически пользовался D1 в 2006-2007-х годах. Проблем не встречал, но у меня и серьезных задач для него не было. Больше раздражало то, что язык все никак не мог стабилизироваться. Плюс стандартная библиотека у него была довольно куцей, а альтернатива в виде проекта Tango давало все в своем собственном виде. Та же работа с файлами в stdlib выглядела одним образом, в Tango другим. Ну и плюс все это развивалось и стабильностью не отличалось.

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

Я жабу трогал очень ограниченно, мой опыт на ней меньше 10 kloc, так что суждение такое себе, но мне жаба запомнилась как не так чтобы прям простой язык. Плюс копроративные практики написания фабрик фабрик индусами обчитавшимися GoF, которые не упрощали жизнь вообще никак.

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

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

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

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

Примерно так. Я в те годы на D пару раз пытался сделать что-то полезное, просто чтобы понять можно ли не писать на плюсах. Выводы сделал примерно те же. Только там ещё и под embedded писать было примерно как сейчас на go, только флеша было в разы меньше.

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

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

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

Ну примерно как сейчас все кубернетис ставят.

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

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

Да нет, в жабе действительно многого не хватало. Например, синглтон – это просто глобальная переменная, но так как в жабе их нет, приходится вот такое городить.

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

обмазанная потокобезопасностью, попрошу.

Это уже опционально. Некоторые не обмазывают. Тем не менее, идею ты понял.

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

Нехватка фич это действительно причина возникновения «паттернов».

Причем нехватка фич еще в крестах - GoF то про кресты написан.

Но если разбираться откуда растут ноги у этого всего, и каких фич действительно не хватало авторам то понимаешь смешное - фичи там 1 в 1 из Common Lisp Object System. Начиная там с «фабрики» (make-instance) и заканчивая чем угодно (visitor - множественная диспетчеризация, singleton - костыль ввиду отсутствия метаклассов, итд, итп).

То есть авторы тупо слизали самые базовые вещи в CLOS. Выдали это за охереть какие свои придумки, и всё. И щас макаки, которые пишут на крестах и жабках об этом даже понятия не имеют.

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

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

Так что такой себе пример.

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

Нехватка фич это действительно причина возникновения «паттернов».

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

GoF то про кресты написан.

Про смолтолк тоже, а скорее даже про ООП вообще.

Поскольку с CLOS не знаком, то про остальное мне сказать вообще нечего.

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

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

Это общие слова в вакууме. Конкретные паттерны GoF - слизаны из базовых конструкций CLOS.

Про смолтолк тоже, а скорее даже про ООП вообще.

Ну вот там пытаются в убогом single-dispatch ООП симуловского разлива, сделать какие-то вещи, которые авторам запомнились по CLOS.

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

Причина возникновения паттернов только в том, что есть повторяемые ситуации, по тем или иным причинам, которые можно как-то обобщить.

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

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

static поля - это глобальные переменные

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

Не заходи с козырей. Без этого треда скучно.

Только представь, если бы в голанге были монады и не надо было писать на каждый чих res, err := f(); if err != nil { return nil, err }

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

А что, синглтон в библиотеку вытащили?

В C++ – да, вытащили и много раз. В жабе низзя, потому что нет множественного наследования.

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

Э, не надо. Это же фишка языка. Без проверок был бы не Go. Да и монады - уши айсберга ;)

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

А при чём тут монады?

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

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

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

Хотя даже на крестах, мне было бы интересно посмотреть, как в библиотеку можно утащить Visitor, лол

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

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

По каким метрикам лучше? По количеству кода, когда тебе платят за строчку? Да, лучше. В остальном – нет, не особо.

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

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

Хотя даже на крестах, мне было бы интересно посмотреть, как в библиотеку можно утащить Visitor, лол

Я к тому, что классический способ использовать сингтон в плюсах – это отнаследоваться от него, типа class C : public Singleton<C>, .... В бусте, например, такое уже есть. Если ты хочешь не только синглтон отнаследовать, то без множественного наследования не выйдет.

Хотя даже на крестах, мне было бы интересно посмотреть, как в библиотеку можно утащить Visitor, лол

А нах он нужен в современном C++, когда появились лямбды?

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

По метрике потребления когнитивных ресурсов на единицу трансляции.

По этой метрике копипаста с if err != nil { return nil, err } просто чудовищно просасывает. От неё в глазах рябит, когда у тебя после каждого вызова функции это говно.

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

А нах он нужен в современном C++, когда появились лямбды?

При чем тут лямбды, вообще?

Visitor это про двойную диспетчеризацию. Типичный какой-нибудь пример - есть абстрактный класс Serializer, и его наследники, всякие там BinarySerializer, XMLSerializer и прочее, и есть разные объекты. Надо чтобы методы сериализации диспетчиризировались и по классам сериализуемых объектов, и по классам сериализаторов.

Можно конечно кучу if нагородить, но это говнокод очевидно, и в таком случае часто Visitor используется. Хотя у него есть недостатки, в т.ч. в том что он закрытый, т.е. не особо расширяемый извне. В C# это обходится через окостыливание всего рефлекшном, например, через который вытаскивается специального вида конструктор. Но без рефлекшна, ну типа в плюсах, это сразу копипаста.

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

Все эти проблемы в CLOS решаются из коробки не приходя в сознание - там потому что обобщенные функции.

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

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

Dark_SavanT ★★★★★
()
Ограничение на отправку комментариев: