«Обсуждать» и рассказывать месяц за месяцем, как вам не нравится то, чем вы не пользуетесь — это разные вещи.
Обсуждение ценно, когда собеседник знает предмет обсуждения.
Однако это, епрст, не отменяет моего другого ощущения: «wtf???»
Ну это проходит, когда вы встречаетесь с кодом на эксепшенах, где ошибки вообще не обрабатываются как следует, просто потому что им не уделяют должное внимание, полагаясь на «механизмы языка». Это как раз причина, по которой исключения не используются в Google даже в С++.
Вот вы справедливо заметили про «такая ситуация возникает очень редко». «Груда повторяющегося кода» — это признак плохого кода. Про циклическую сложность слышали? В Go есть даже линтер, которые показывает функции, в циклической сложностью больше 10. Если у вас 3 или 4 вызова, в котором вам нужно проверить ошибку — ничего тут страшного нет, зато любой, кто будет читать код после вас, сразу будет видеть, как идет flow и что происходит в результате ошибки.
Итак, вы взяли почти синтетический пример из одной статьи, на который придумали модификацию в этой статье, и который вы теперь подаёте как «демонстрацию неэффективности языка», и просите меня написать за вас код, как будто это изменит ваше непробиваемое желание доказать, насколько плох язык, который вы даже не знаете. Вопрос о практичности примера пока оставим в стороне.
Раз уж вы так хотите использовать в повторяющихся вызовах write() какие-то функции в качестве параметров, но не хотите, чтобы они вызывались в случае ошибки — сделайте так, чтобы они в этом случае не вызывались! Это же просто. Функции это такие же значения, и во write можно передавать саму функцию, а не ее результат, и запускать функцию после проверки на err. Кроме того, если вы уже настолько синтетически придумали пример, в котором лучше всего напрашивается выбрасывание «исключения» — используйте panic/recover! Go не запрещает это делать, он специально для этого в языке, чтобы использовать тогда, когда это действительно необходимо и оправданно.
Но тем не менее, ответа на вопрос «что делать с кучей повторяющихся `if err != nil { return err }`.
Есть же ответ. Есть это действительно «куча повторяющихся» — сделайте то же, чтобы вы делали с «кучей повторяющихся» кода, если бы речь шла не про ошибки. В этом главная суть.
что код ошибки должен быть вторым значением
Это не код ошибки, вы упускаете фундаментальную разницу.
Это не отвечает на вопрос «если в строке ew.write(getAB()) возникает ошибка, то почему выполняются getCD() и getEF(), когда в их результирующих значениях смысла нет?»
Представьте, что речь не про ошибки, и ответьте сами на этот вопрос :)
Пример в статье был подан не как «вот вам специальный IIf, чтобы хендлить вот такой случай», а как пример того, как смотреть на ошибки. Если понять посыл статьи, то всё становится намного проще.
В аналогиях важно видеть не только схожее, но и различное.
Ну, Go — это вот как Оберон в начале этого лета, кажется, помните?
Ну, если не выглядывать за пределы комментариев Хабра, то, наверное две статьи про Оберон таки похожи. Ну ладно, раз это профессиональное, то вы ответили на мой вопрос.
Пользуясь случаем, спрошу — а зачем вы, раз не любите Go, ходите во все посты про Go и доказываете, какой он плохой?
Я вот просто не могу представить на себе, что должно мной двигать, чтобы мне захотелось ходить в посты про языки, которые мне не нравится и оставлять там комментарии, что-то кому-то доказывая про то, что я не люблю и не знаю.
Проясните эту загадку? )
Ясно. Желаю вам найти других собеседников, разделяющих ваше убеждение, что Go придумывали идиоты, а вы знаете как надо было, потому что в Java и C# не так. Мне не интересно на такое «общение» время тратить.
Если вы примете тот факт, что авторы Go занимаются кое-чем другим, чем желанием запудрить вам мозг, мне будет проще отвечать на ваши многочисленные комментарии.
Вы предлагает убрать вообще указатели? Очень круто. Давайте посмотрим — в Go при передаче параметров, всегда происходит копирование. Всегда. Даже если это указатель — он копируется, но поскольку это всего лишь информация об адресе в памяти, то код, работающий с переданным указателем, имеет доступ к нужному объекту. Давайте, по вашему мудрому наставлению, «уберем вообще это и не будем пудрить мозг». Как теперь изменять значения, переданные в функции? Отказываться от подхода «все копируется» и переделывать дизайн языка и компилятора?
Если бы здесь была простота, то не было бы вообще разделения на значение и указатели
Ну это вам так кажется. Но даже в статье это написано, что в языке важен баланс между необходимыми фичами и простотой, а не «простота любой ценой».
":=" не совместим с полями структур
Дело не в «несовместимости с полями структур», а с тем, что ":=" создает и инициализирует переменную, а поле структуры уже проинициализированно всегда. Описанный момент иногда бывает да, но я не берусь утверждать, что знаю, как сделать лучше.
Обсуждение ценно, когда собеседник знает предмет обсуждения.
Это модифицированный пример из поста, который я переводил.
Ну это проходит, когда вы встречаетесь с кодом на эксепшенах, где ошибки вообще не обрабатываются как следует, просто потому что им не уделяют должное внимание, полагаясь на «механизмы языка». Это как раз причина, по которой исключения не используются в Google даже в С++.
В Google исключения не используются нигде, в том числе в С++, именно по озвученной вами причине.
Итак, вы взяли почти синтетический пример из одной статьи, на который придумали модификацию в этой статье, и который вы теперь подаёте как «демонстрацию неэффективности языка», и просите меня написать за вас код, как будто это изменит ваше непробиваемое желание доказать, насколько плох язык, который вы даже не знаете. Вопрос о практичности примера пока оставим в стороне.
Раз уж вы так хотите использовать в повторяющихся вызовах write() какие-то функции в качестве параметров, но не хотите, чтобы они вызывались в случае ошибки — сделайте так, чтобы они в этом случае не вызывались! Это же просто. Функции это такие же значения, и во write можно передавать саму функцию, а не ее результат, и запускать функцию после проверки на err. Кроме того, если вы уже настолько синтетически придумали пример, в котором лучше всего напрашивается выбрасывание «исключения» — используйте panic/recover! Go не запрещает это делать, он специально для этого в языке, чтобы использовать тогда, когда это действительно необходимо и оправданно.
Этот пример демонстрирует подход к проблеме и ход мыслей. Остальное — надуманное вами лично.
Есть же ответ. Есть это действительно «куча повторяющихся» — сделайте то же, чтобы вы делали с «кучей повторяющихся» кода, если бы речь шла не про ошибки. В этом главная суть.
Это не код ошибки, вы упускаете фундаментальную разницу.
Вы же не притворяетесь, правда?
Код в статье был примером, служащим для демонстрации подхода.
Продолжайте вашу борьбу с мельницами дальше :)
Представьте, что речь не про ошибки, и ответьте сами на этот вопрос :)
В аналогиях важно видеть не только схожее, но и различное.
Ну, если не выглядывать за пределы комментариев Хабра, то, наверное две статьи про Оберон таки похожи. Ну ладно, раз это профессиональное, то вы ответили на мой вопрос.
Я вот просто не могу представить на себе, что должно мной двигать, чтобы мне захотелось ходить в посты про языки, которые мне не нравится и оставлять там комментарии, что-то кому-то доказывая про то, что я не люблю и не знаю.
Проясните эту загадку? )
Ясно. Желаю вам найти других собеседников, разделяющих ваше убеждение, что Go придумывали идиоты, а вы знаете как надо было, потому что в Java и C# не так. Мне не интересно на такое «общение» время тратить.
Если вы примете тот факт, что авторы Go занимаются кое-чем другим, чем желанием запудрить вам мозг, мне будет проще отвечать на ваши многочисленные комментарии.
Вы предлагает убрать вообще указатели? Очень круто. Давайте посмотрим — в Go при передаче параметров, всегда происходит копирование. Всегда. Даже если это указатель — он копируется, но поскольку это всего лишь информация об адресе в памяти, то код, работающий с переданным указателем, имеет доступ к нужному объекту. Давайте, по вашему мудрому наставлению, «уберем вообще это и не будем пудрить мозг». Как теперь изменять значения, переданные в функции? Отказываться от подхода «все копируется» и переделывать дизайн языка и компилятора?
Ну это вам так кажется. Но даже в статье это написано, что в языке важен баланс между необходимыми фичами и простотой, а не «простота любой ценой».
Дело не в «несовместимости с полями структур», а с тем, что ":=" создает и инициализирует переменную, а поле структуры уже проинициализированно всегда. Описанный момент иногда бывает да, но я не берусь утверждать, что знаю, как сделать лучше.
Так вот статья именно об этом.
Ну и если бы все было «ожиданным», то ничего нового и не появлялось.
«Просто использовать» != «просто набирать на клавиатуре»