Говнокод #21732 — Java — Говнокод.ру

Java / Говнокод #21732

−51
1. 1
2. 2
3. 3
```
public void read(InputStream is) throws Exception {
        ...
    }
```
Когда человек совсем не уверен в себе

Запостил: krokozyabr, 27 Ноября 2016

Tweet
Комментарии (209) RSS
- rotretS 27.11.2016 13:19 # −1
  
  Быть может, программист хотел обработать исключение в этом методе.
  И вообще, что за манера, кидать одну строчку кода!
  Ответить
- Hanazono-Satoshi 28.11.2016 21:44 # −1
  
  Как минимум InputStream бросает IOException. Фиг знает что еще содержится в этом методе.
  Ответить
  - bormand 28.11.2016 21:48 # 0
    
    > Фиг знает что
    Вот именно! А клиенту метода теперь придётся ловить (или прокидывать дальше) этот сраный экцепшен, с которым он ничего путнего сделать не сможет.
    Ответить
    - barop 28.11.2016 21:51 # −1
      
      Как жаль что никто на свете не умеет в чекд эксепшены
      Ответить
      
      bormand 28.11.2016 22:03 # −1
      
      Да их даже сами разрабы жабы не осилили.
      Ответить
      
      barop 28.11.2016 22:08 # −1
      
      не все. В некоторых местах (стримы, parseInt) они почти в тему
      Ответить
      
      bormand 28.11.2016 22:13 # −1
      
      Ага, и в этих стримах они сами из-за них и обосрались (с RuntimeException не возникло бы желания задавить исключение в close).
      
      http://govnokod.ru/14254
      Ответить
      
      barop 28.11.2016 22:15 # −1
      
      да, в клозе обосрались, не спорю)))
      В апаче коммнос даже closeSilently завезли
      
      но ты и сам контракт нарушил: зачем ты клозишь стрим после IOException?
      Ответить
      
      bormand 28.11.2016 22:17 # −1
      
      > контракт нарушил
      Ткни носом, где. Разве что flush() не позвал перед close(). Но кто ж знал, что close() у FilterOutputStream молча жрёт исключения (хоть и throws IOException)...
      Ответить
      
      barop 28.11.2016 22:24 # −1
      
      обосрался
      Ответить
      
      bormand 28.11.2016 22:26 # −1
      
      Лол, они таки пофиксили! Это из какой версии JDK? Восьмёрка поди?
      Ответить
      
      barop 28.11.2016 22:28 # −1
      
      ровно то, что ты написал, только в синтаксе восьмой джавы)
      
      Это не ты контракт нарушил, а джависты: нельзя ничего делать со стримом после того что он кинул exception.
      
      Ну и пидары-же
      -------
      или не пидары?
      
      из close полетит excception?
      Ответить
      
      bormand 28.11.2016 22:30 # 0
      
      Хуй с ним, с close(), код из восьмой хотя бы исключение от flush не жрёт... По крайней мере не получится молча проебать хвост файла как в 6-7. Так что в восьмёрке тот баг таки пофиксали.
      Ответить
      
      barop 28.11.2016 22:33 # −1
      
      Именно что НЕ жрет.
      
      Сам попробуй
      
      // write your code here FileInputStream s = new FileInputStream("c:\\HaxLogs.txt"); try (FileInputStream s2 = s) { throw new IOException("SD"); } }
      
      А раз нежрет то и проблемы нет. Ща проверю была-ли она в седьмой
      ------
      
      Да, в седьмой именно так)
      
      Ну ок, значит стримы научились юзать только к восьмой джаве
      Ответить
      
      bormand 28.11.2016 22:35 # −1
      
      6-7 жаба сожрала экцепшн, проверь.
      Ответить
      
      barop 28.11.2016 22:35 # −1
      
      жрало, ты прав)
      
      Выходит что в 6-7 джаве джависты сами насрали на свой контракт
      Ответить
      
      Hanazono-Satoshi 28.11.2016 22:24 # −1
      
      нельзя обосраться.... но мы обосрались..))
      Ответить
      
      guest 28.11.2016 23:04 # 0
      
      Это были лихие девяностые и мы обсирались как могли.
      Ответить
      
      Hanazono-Satoshi 28.11.2016 23:08 # −1
      
      У бомбы два провода - красный и синий. Не тот перегрыз и не станет России. А цыферки к нолику ближе и ближе. Во взмокшей ладони дрожат пассатижи. Застыла отчизна в погибельном трансе, Осталась секунда последнего шанса, Простая секунда, ничтожная малость. Нельзя обосраться, нельзя обосраться... И мы обосрались...
      Ответить
      
      barop 28.11.2016 23:10 # −1
      
      Красная армия сильная армия.
      Смелая армия просто геройская.
      Непобедимейшее войско.
      В самом жестоком бою.
      
      Припев:
      А я обосрался в строю!
      
      Все коммунисты и все комсомольцы.
      Нужно подохнуть вперед добровольцы.
      С песнями рота идет.
      Только вот я не пою.
      
      Припев:
      Я обосрался в строю!
      
      Родина мама спи не ворочайся.
      Сыны твои гордо на стреме стоят.
      Дали мне тоже большой автомат.
      Стой говорят я стою.
      
      Но вот обосрался в строю
      Ответить
      
      Hanazono-Satoshi 28.11.2016 23:17 # −1
      
      х*й на всё на это и в небо по трубе))
      Ответить
      
      barop 28.11.2016 23:22 # −1
      
      перевести на черно-белый режим
      и убивать
      убивать
      Ответить
      
      roman-kashitsyn 29.11.2016 00:14 # −1
      
      > Да их даже сами разрабы жабы не осилили.
      
      Вообще говоря, чекед-эксепшены -- принципиально унылое говно и попоболь. Их невозможно готовить правильно, нету языковых средств.
      
      Вот хочешь ты, к примеру, написать функцию высшего порядка, в которую коллбэк передается. Какое исключение должна кидать эта функция высшего порядка? Это зависит от того, что кидает коллбэк. Как в языке выразить мысль, что метод кидает то же самое исключение, что кидает его функция-параметр? Никак.
      
      Разве джависты пишут функции высшего порядка, спросите вы? Конечно пишут, только не знают об этом. Особенно, теперь, когда им лямбды с потоками подарили.
      
      Помню как-то визитор по простенькому "AST" запилил. Какое исключение нужно бросать из visit у объекта? А хрен его знает. Зависит от того, что бросает визитор.
      Захотел сконвертить дерево в JSON или распечатать в поток -- пиши унылые обёртки, которые конвертируют IOException во какой-нибудь специальный RuntimeExeption, и обёртку, которая достаёт родное исключение обратно.
      
      Лютое количество бойлерплейта для простой, казалось бы, задачи.
      Ответить
      
      barop 29.11.2016 00:22 # −1
      
      Смысл чекдов был в том, что метод может в рантайме понять что не может выполнить свою работу, и должен тебе как-то об этом сигнальнуть. Понятно что можно сделать это вручную:
      
      1) выйти из метода
      
      2) вернуть null или передать ссылку на результат (ах да, в жабе так нельзя), но это не заставит тебя проверить результат и можно легко проебать ошибку, да и писать 10 ретурнов не всегда комильфо.
      
      Если в рантайме у тебя отвалился диск или удаленный сокет или от пользователя пришел мусор, то эксепшен будет ебать мозг пока его либо его ЯВНО не поймают, либо он угандошит весь тред (ну или весь реквест в случае серверов), и это очень круто, просто у этого есть одно узкое применение.
      
      Джависты пишут функции (особенно с тех пор как туда завезли лямбды), но вот именно там чекдэксепшены красиво не заюзать, увы. Это проёб.
      
      Рантайм эксепшены вообще нужны для совсем другого, они просто случайно "так же называются" и сигнализируют о нарушении контракта. Их не надо ловить (разве что если они летят из плагина) а надо пиздить программиста по голове. В идеале они вообще не должны быть Exception, а должны быть Error
      Ответить
      
      roman-kashitsyn 29.11.2016 00:32 # −1
      
      Можно подумать, я не знаю, для чего джависты придумали чекед-исключения. Сказка про иерархию исключений в жабе у любого зелёного джуниора от зубов должна отскакивать.
      
      Проблем от них гораздо больше, чем пользы, вот в чём поинт. Нормальные пацаны не выпендриваются, не плодят лишные сущности и энкодят ожидаемые ошибки в типе возвращаемого значения.
      Ответить
      
      barop 29.11.2016 00:37 # −1
      
      >>энкодят ожидаемые ошибки в типе возвращаемого значения.
      
      Тогда нужно на выбор
      1) везде вертать туплу (Pair<Result, Error>)
      2) в классе Object сделать поле lastError (щтоб он автоматом везде был)
      3) научиться принимать указатель на объект чтобы заполнять его ошибкой.
      
      Третий пункт очень любят яблочники в Objc:
      
      NSError error; NSFooBarBuz(42, &error); if (error) { //обосратушки }
      
      Какой из этих вариантов тебе менее противен? Ну или предложи свой
      Ответить
      
      roman-kashitsyn 29.11.2016 00:48 # −1
      
      Говорю же, в типе возвращаемого значения указывать
      
      StatusOr<T>
      
      https://github.com/google/lmctfy/blob/master/util/task/statusor.h
      Or_error в Ocaml, MonadError в Haskell.
      
      Подход Go тоже вполне сносен.
      Ответить
      
      barop 29.11.2016 00:53 # −1
      
      StatusOr<T> -- по сути это мой вариант с туплой, просто более красивый, и в отличии от туплы у него есть отличный getValueOrDie, то-есть если там ошибка то всё упадет. Мне нравится.
      
      Я подумаю еще до чего доебаться)
      Ответить
      
      roman-kashitsyn 29.11.2016 01:02 # −1
      
      В Folly тоже похожий класс есть
      
      https://github.com/facebook/folly/blob/master/folly/Try.h
      Александреску про него как-то рассказывал
      https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C
      Ответить
      
      barop 29.11.2016 01:14 # −1
      
      >>2012
      
      Ох, сколько же времени прошло прежде чем люди поняли как правильно хендлить ошибки, да?
      
      Тернист путь от errno/GetLastError
      Ответить
      
      wvxvw 05.12.2016 19:37 # +1
      
      Ты просто наверное только факториал написал на Го.
      Ну в Го вообще ничего хорошего нет, кроме горутин. Но ошибки там - это вообще эпический пиздец. Это так плохо, что даже Вижуал Басик покажется нормальным языком.
      С другой стороны, на Го пишут либо дети которые хотят (хотели) прославится на Гитхабе, либо люди, которые повелись на красивую рекламу, и теперь не знают, как от этого говна избавиться. Все без исключения библиотеки на Го такого хуёвого качества, что даже Нода и ПХП на их фоне выглядят надежными и провереными временем.
      Посмотреть на код того же Докера, etcd, Тераформ. О, Тераформ, это отдельный пиздец, который даже в горячечном бреду невозможно представить. Так можно в кровавых слезах утонуть. И не в последнюю очередь изза "работы с ошибками".
      
      Начнем с того, что, если по-честному, в Го нет ошибок, как концепции. Есть какая-то хуйня под названием error, которя никого ни к чему не обязывает. И есть убогий механизм для работы с крешами програмы, который даже до уровня trap в Баше не дотягивает. И это, блять, при активно использующейся многопоточности и отсутствующем отладчике.
      Изза того, что механизма бросания ошибок нет, нет и стектрейсов, и каждая библиотека дрочит как хочет, но в 90% случаев стектрейсов просто не будет. А в остальных 10% они будут указывать в произвольные места в програме.
      Изза отстутсвия каких либо средств для работы с языком, однострочники в Го разрастаются в полотна бессвязных if err != nil { return err }. Статистика по моему проекту:
      
      $ find ./src -type f -name '*.go' -exec grep 'if err != nil' {} + | wc -l 9292 $ find ./src -type f -name '*.go' | wc -l 543
      
      А вот билт-ин говно:
      
      $ find /usr/local/go/src -type f -name '*.go' -exec grep 'err != nil' {} + | wc -l 8049 $ find ./src -type f -name '*.go' | wc -l 2498
      
      Из нашего отдела люди готовы уходить с понижением зарплаты туда, где пишут на Питоне, лишь бы только это говно не видеть.
      Ответить
      
      bayan 05.12.2016 19:38 # +2
      
      Я не спец в го, но если он не нравится wvxvw , то его стоит попробовать.
      
      >>Из нашего отдела люди готовы уходить с понижением зарплаты туда,
      Когда я работал программистом в маленькой психиатрической больнице (С)
      Ответить
      
      roman-kashitsyn 05.12.2016 19:56 # +3
      
      > Ты просто наверное только факториал написал на Го
      
      Вообще говоря, нет, не факториал. Веб-приложение -- аналог https://kapeli.com/dash, которое индексирует локальные доки (либу для парсинга я писал на сишке, в го использовал FFI) и позволяет делать fuzzy-поиск (на биграммах) по документации с динамической подгрузкой результатов. Честно говоря, я в основном упирался в тормознутость стандартных структур данных из-за отсутствия нормальных шаблонов. Ручной инлайнинг ускорил тогда мой поиск в 8 раз.
      
      В последнее время я мало пишу на Го (в основном на C++), но воспоминания в основном положительные. В плане обработки ошибок подход у нас аналогичный.
      
      > нет и стектрейсов
      
      Это большая проблема, очень серьёзная. В C++ тоже стектрейсов нет из коробки. Можно сбоку прикрутить при большом желании, но большинство этим не занимается.
      
      Когда пишешь асинхронный код, стектрейсы вообще бесполезны -- коллбэки дёргаются из реактора, интересного в них ничего не увидишь.
      
      > где пишут на Питоне
      
      О да, больше всего на свете я "люблю" программы на питоне, которые в любой непонятной ситуации кидают в меня Key/Value/WhateverError. Возможно, стектрейс поможет разработчику ткнуть пользователя в нужную строчку документации или понять, где он накосячил в типах, но никак не поможет ему побороть свою неспособность нормально обрабатывать ошибки. Пользователю они скорее мешают.
      
      Универсальное средство обработки ошибок -- это миф, исключения им не являются.
      Ответить
      
      bayan 05.12.2016 20:05 # 0
      
      Хорошие программы на python выдают хорошие сообщения об ошибках.
      
      А плохие программы (в случае мусора на входе) дают говно.
      
      Нативная программа дает General Protection Fault.
      
      Программа на питоне дает KeyError.
      
      Жаба дает NPE и 150 строк маловразумительных трейсов
      
      Итд
      Ответить
      
      roman-kashitsyn 05.12.2016 20:07 # +2
      
      > Хорошие программы на python выдают хорошие сообщения об ошибках.
      
      Охотно верю. Жаль, что мне такие практически не попадались.
      Ответить
      
      bayan 05.12.2016 20:15 # 0
      
      Питона много в дроппобксе. Ты хоть раз видел KeyError на сайте дропбокса?
      Ответить
      
      bormand 05.12.2016 21:13 # 0
      
      > Ты хоть раз видел KeyError
      Да ты их даже в пыхе не увидишь, если сервер правильно настроен... Кто в 2016 году ошибки в браузер срёт?
      Ответить
      
      roman-kashitsyn 05.12.2016 21:54 # +2
      
      > Кто в 2016 году ошибки в браузер срёт?
      Яндекс.Музыка
      Ответить
      
      inkanus-gray 06.12.2016 00:00 # 0
      
      Не всегда. Иногда Яндекс.Музыка не играет, ничего не сообщая пользователю.
      Ответить
      
      bayan 05.12.2016 21:58 # 0
      
      https://www.google.ru/search?q=warnong+invalid+argument+suppli ed+for
      
      отак с ходу
      https://toster.ru/q/61278
      Ответить
      
      1024-- 05.12.2016 20:18 # 0
      
      Неясно, что вообще писать в случае ошибки программиста.
      Это задача того же уровня, что и построение полного (совсем полного) списка уязвимостей системы.
      Ответить
      
      roman-kashitsyn 05.12.2016 20:22 # 0
      
      > в случае ошибки программиста
      
      Я уже говорил, что не против исключений в случае ошибок программиста (в go для этого есть panic).
      Правда, в C++ для этого полезней крэшится -- можно потом в core-дампе как следует поковыряться, ибо стэк-трейс зачастую не содержит информации, которая поможет исправить ошибку.
      Ответить
      
      bayan 05.12.2016 20:26 # 0
      
      >>что вообще писать в случае ошибки программиста.
      "программа содержит ошибку и будет закрыта, напишите программисту"
      Ответить
      
      roman-kashitsyn 05.12.2016 20:20 # 0
      
      > А плохие программы (в случае мусора на входе) дают говно.
      
      Go сам по себе программистов не исправит. Тот, чья стратегия обработки ошибок заключалась в ловле всего что можно в main и печати в stdout, так и будет писать при любом удобном случае if err != nil { return err } и ругать Go. Иногда return err -- это именно то, что нужно. Часто имеет смысл вернуть новую ошибку, с описанием того, что пытались сделать, с какими аргументами, и почему не получилось. "Exception translation", только с менее громоздким синтаксисом и более полезными для пользователя сообщениями.
      
      https://blog.golang.org/errors-are-values
      Ответить
      
      wvxvw 05.12.2016 20:29 # 0
      
      Лол. В С++ тоже нет стектрейсов? Да ну? Сравнил говно с поносом. Какя разница, что там есть в С++.
      
      А про асинхронный код: да, насмешил. Бесполезные говоришь. А что ошибки никогда искать и исправлять не приходилось? Просто потому, что в Го этого практически нереально добиться, не переписав рантайм с нуля - тебе просто в голову не прийдет, что это вообще возможно. А оно ведь все тут, рядом, и существует уже много лет.
      
      А ты не подумал, что над разработкой програмы, и над чтением ее стектрейсов вызваных некорректным поведением програмист проводит 99% от рабочего времени? И что без этой информации, програма вообще никогда не попадет к твоему чисто теоретическому заказчику?
      В соседнем отделе, продукт, аналогичный нашему писало два человека на Питоне. (В моем отделении нас было шестеро, но двое уволились, и еще двое перешли в другие отделы). Они все сдали и уехали в Аргентину на месяц курить гашиш, а у нас что ни неделя, то добалвяется 100-200 if err != nil. Потому, что билт-ин библиотека - говно. Чужие библиотеки - говно. В своем коде невозможно проследить логику выполнения изза того, что приходится бороться с некорректной работой всего остального.
      
      Я молюсь чтобы меня перевели либо на Питон, либо на Руби. Я бы даже на Яве писал, лишь бы это говно больше никогда не видеть.
      Ответить
      
      bayan 05.12.2016 20:39 # +2
      
      --Language1 лучше чем Language2
      --Докажи
      --Ну у нас на Language1 программу написали быстрее, чем на Language2.
      
      У Сёмы достойный конкурент
      Ответить
      
      3_14dar 05.12.2016 22:41 # +1
      
      Бароп, снова ты на связи, дегенерат?
      
      >--Ну у нас на Language1 программу написали быстрее, чем на Language2.
      Значит она им дешевле вышла, понимаешь? ДЕНЕШКИ. В мире апинсорса такого нет.
      Ответить
      
      bayan 05.12.2016 22:43 # +2
      
      Ну да, это вполне же твоя логика.
      
      --ахахаха openssl не используют в серьезных конторах
      --докажи
      --ну я слышал что в amazon его не используют
      
      --хахаха l2tp не настроить в линуксе
      --докажи
      --ну я чатился с долбоебом который не осилил l2tp в freebsd
      
      Вы с wvwvwcwv два сапога пара
      Ответить
      
      3_14dar 05.12.2016 22:52 # 0
      
      >-хахаха l2tp не настроить в линуксе
      >--докажи
      >--ну я чатился с долбоебом который не осилил l2tp в freebsd
      Сама додумала, обезьянка? Где я это утверждал?
      
      >--ахахаха openssl не используют в серьезных конторах
      >--докажи
      Хром. Существование форков.
      Ответить
      
      bayan 05.12.2016 22:57 # +1
      
      >>Где я это утверждал?
      http://govnokod.ru/21736#comment360570
      
      >>Хром. Существование форков.
      Cryptography Functions из Windows не используются в Chrome под Mac OS X. Следовательно, Windows Crypto API не используется в серьезных проектах.
      Бугага.
      Ответить
      
      3_14dar 06.12.2016 02:38 # 0
      
      Потому что он не кроссплатформенный, дурачок. Алсо завези туда какой-нибудь гост.
      
      >http://govnokod.ru/21736#comment360570
      Где ты там прощел "l2tp не настроить в линуксе" и "l2tp в freebsd"? Конкретно эти цитаты приведи, питушок косоглазый.
      Ответить
      
      barop 06.12.2016 02:48 # +3
      
      Вся твоя школолошная говнопаста, которую ты сюда зачем-то припер, состояла из описаний страданий петушка, который не мог в линуксе и то и сё.
      
      В том числе он не мог в L2TP. Когда я попыталася рассказать тебе о прелестях L2TP на винде, ты начал нести нелепые отмазки про какого-то неосилятора, который не смог L2TP во фрибзд.
      
      Тут дело даже не в том, что FreeBSD не имеет отношения к линуксу (незнание этого факта я тебе прощаю, ты и более простые вещи не знаешь), а в том что для доказательства утверждения "Foo это сложно" ты приводишь аргумент "питушок не смог Foo".
      
      Это характеризует только петушка. Ну и тебя, как человека который с ним общается.
      Ответить
      
      guest 06.12.2016 03:19 # +1
      
      С возвращением, Ваше Высочество. Так их, анскилябр этих.
      Ответить
      
      bayan 05.12.2016 22:46 # 0
      
      >>Значит она им дешевле вышла, понимаешь?
      Мне даже лениво объяснять насколько не в тему тут это твое глупое замечание.
      Ответить
      
      3_14dar 05.12.2016 22:53 # +1
      
      >ДЕНЕШКИ. В мире апинсорса такого нет.
      Ясно.
      Ответить
      
      bayan 05.12.2016 23:38 # +3
      
      Подобные представления об опенсорсе я слышал в 1999-м году от троллей, а с тех пор уже и не слышал.
      
      Наверное нужно последние 15 лет прожить в пузыре, чтобы всерьез думать что в линуксах драйверы компилируют вручную, а опенсурсные разработчики не получают зарплату.
      
      Люди в RedHat, Apple и Google, разработчики Android, Darwin, llvm -- им всем ужасно приятно будет узнать что они не получают зарплату.
      Ответить
      
      bormand 05.12.2016 22:54 # +1
      
      > программу написали быстрее
      > значит она им дешевле вышла
      Ахуенная логика.
      Ответить
      
      3_14dar 05.12.2016 22:56 # 0
      
      Мням, что не так?
      Ответить
      
      bormand 05.12.2016 22:58 # 0
      
      > что не так
      В выводе, достойном британских учёных - "если программу написали быстрее, то она им дешевле вышла".
      Ответить
      
      3_14dar 05.12.2016 23:01 # 0
      
      То есть про то что время программистов оплачивается, причем по постоянной ставке, ты не слышал?
      Ответить
      
      bayan 05.12.2016 23:02 # 0
      
      Сём, если ты когда-нить в жизни будешь работать программистом ты узнаешь еще что бывает поддержка программ, и она тоже не бесплатна.
      
      И что программисты в мире опенсурса тоже получают зарплату.
      
      А потом ты научишься читать, почитаешь первоначальный высер своего брата по разуму, и узнаешь что деньги и скорость написания тут вообще не причем
      Ответить
      
      bormand 05.12.2016 23:05 # +1
      
      > тоже получают зарплату
      И что зарплата у разных программистов, внезапно, разная... И что сложность программ могла отличаться...
      
      > она тоже не бесплатна
      Скупой платит джважды ;)
      Ответить
      
      3_14dar 06.12.2016 02:42 # 0
      
      >бывает поддержка программ, и она тоже не бесплатна.
      Как на это влияет ЯП? Я имел в виду написать ту же программу с тем же качеством. Если ее можно написать быстрее, то почему нет?
      Ответить
      
      bormand 05.12.2016 23:09 # +1
      
      > причем по постоянной ставке
      Т.е. премий и повышений у вас там не бывает? :) Грустно как-то...
      Ответить
      
      guest 06.12.2016 16:05 # 0
      
      У меня не бывает премий! И повышений не предвидится! Хнык :'(
      Ответить
      
      defecate-plusplus 06.12.2016 17:05 # +2
      
      работаешь плохо?
      Ответить
      
      guest 06.12.2016 17:13 # 0
      
      Говено работаю, да. Хотя мне кажется, что это не моя вина.
      Ответить
      
      roman-kashitsyn 06.12.2016 17:17 # +3
      
      > Хотя мне кажется, что это не моя вина.
      
      Go виноват?
      Ответить
      
      guest 06.12.2016 17:21 # +1
      
      Начальство. Задач нет, не дают проявить себя на поприще разработки ПО.
      Ответить
      
      defecate-plusplus 06.12.2016 17:25 # +1
      
      не такая и редкая ситуация
      
      но я бы не сказал, что сейчас на рынке труда всё плохо
      Ответить
      
      bayan 06.12.2016 21:17 # 0
      
      попробуй сменить контору
      Ответить
      
      guest 06.12.2016 21:28 # 0
      
      Если бы знал хорошие варианты, уже сменил бы. Не хочется пересаживаться с пик точеных на хуи дроченые.
      Ответить
      
      bayan 06.12.2016 23:12 # +2
      
      Странная логика.
      
      Ну поищи контору которая тебе нравится, узнай что ей надо и выучи.
      
      А то вот так люди страдают до тридцати пяти лет, а потом оказывается что лет им уже много, а кроме просиженных штанов опыта и нет.
      Ответить
      
      guestinho 07.12.2016 01:46 # 0
      
      А хуй знает, что им надо. Я тут собеседовался в одну симпатичную контору. Поспрашивали баяны про сортировку и т.п., я поотвечал. Перезванивать не стали. Хнык, в общем.
      Ответить
      
      3_14dar 07.12.2016 04:38 # 0
      
      Что за магическое число - 35?
      Ответить
      
      barop 07.12.2016 04:40 # 0
      
      От балды взятое.
      Можно сказать 42 или 29.
      Ответить
      
      AnalniyTerzatel 07.12.2016 05:11 # −1
      
      Надел твою кишку на свою балду, проверь.
      Ответить
      
      O____O 07.12.2016 13:36 # −1
      
      ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ, БЛЯ!
      Ответить
      
      1024-- 06.12.2016 01:47 # 0
      
      А как правильно языки сравнивать?
      
      По количеству фич? По количеству программистов? По количеству проектов? По математической каноничности? По строчкам кода для решения эталонной задачи? По количеству правил грамматики?
      
      Тут хотя бы человек публикует данные, каким-то образом относящиеся к реальности.
      Ответить
      
      barop 06.12.2016 02:29 # +1
      
      >>По количеству фич?
      да
      >>По количеству программистов?
      нет
      >>По количеству проектов?
      да
      >>По математической каноничности?
      не очень
      >> По строчкам кода для решения эталонной задачи?
      да
      >> По количеству правил грамматики?
      не очень
      
      >>каким-то образом относящиеся к реальности.
      Один мой знакомый ходил в синей кепке, и его сбила машина.
      А другой ходил в красной и его не сбила.
      
      Отсюда я делаю вывод что синие кепки носить опаснее.
      Ответить
      
      roman-kashitsyn 05.12.2016 20:40 # +3
      
      > А что ошибки никогда искать и исправлять не приходилось?
      
      Собственно, это основная часть моей работы -- чинить нетривиальные ошибки. Когда люди нормально обрабатывают ошибки, ты либо сразу понимаешь, в чём проблема (даже не открывая сорцов), либо вставляешь кусок текста ошибки в git grep/code search и практически сразу находишь нужное место.
      
      Кстати, ты может раньше не замачал... Твои доводы на 96% состоят из эмоций и не содержат информации для размышления.
      Ответить
      
      subaru 05.12.2016 21:33 # 0
      
      Так ты там на багфиксе сидишь? Лол.
      Ответить
      
      bayan 05.12.2016 21:51 # +1
      
      Конечно. В гугле есть специальные отделы багинтродьюсеров и багфиксеров.
      Багинтродьюсеры делают баги, а багфиксеры их правят.
      так и живут.
      Ответить
      
      subaru 05.12.2016 21:53 # −1
      
      как всегда, ты сарказмируешь не в тему а в лужу
      Ответить
      
      bayan 05.12.2016 21:55 # 0
      
      Просто было трудно удержаться увидев такой наивный высер
      Ответить
      
      subaru 05.12.2016 21:59 # −1
      
      Что в нем наивного, бароп? Для тебя сикрет, что многим программистам задачи спускает начальство, и иногда это только баги, которые надо пофиксить?
      Ответить
      
      bayan 05.12.2016 22:01 # +1
      
      Если одни программисты занимаются исключительно багфиксом, то логично предположить что другие занимаются исключительно багмейкерством. Так-ли это, хуесто?
      Ответить
      
      subaru 05.12.2016 22:02 # −1
      
      Нет, просто у тебя с логикой проблемы (тоже не в первый раз замечаю).
      Ответить
      
      bayan 05.12.2016 22:04 # 0
      
      Зато с логикой отлично у тебя. Из того факта что Кашицин фиксит баги ты сделал вывод о том, что "задачи спускает начальство, и иногда это только баги".
      
      Видимо ты пытаешься перенести свое доширачерство на галерах на гугл.
      Этакий обратный карго-культ.
      Ответить
      
      roman-kashitsyn 05.12.2016 22:29 # +1
      
      > Так ты там на багфиксе сидишь? Лол.
      
      Я каждое утро прихожу на работу, открываю логи сервиса, и создаю баги на все крэши и ERROR записи, которые считаю ошибкой. Часть назначаю на ответственных, часть чиню сам.
      Мне вообще стрёмно писать новый код, пока старый делает хрен пойми что.
      
      Ты так не делаешь, @subaru?
      Ответить
      
      bormand 05.12.2016 22:32 # +4
      
      > Каждое утро я прихожу на работу, открываю логи сервиса, и создаю баги на все крэши и ERROR записи, которые считаю ошибкой.
      Прям начало копипасты о Воване.
      Ответить
      
      guest 05.12.2016 23:14 # 0
      
      Не делаю. У меня и так полный бэклог унылых багов, от которых уже тошнит. Но ты молодец.
      Ответить
      
      wvxvw 06.12.2016 13:54 # 0
      
      Да ну? "нормально обрабатывают ошибки" - это не эмоциональный аргумент, чтоли? Это просто пиздежь бессмысленный. Который порисходит от самолюбования и непонимания предмета разговора.
      
      По поводу метрик, и почему раньше сделаный продукт в соседнем отделе - это показательно.
      Потому, что, как я уже говорил, продукт аналогичный. Наш отдел пишет инфраструктуру для тестов, другой отдел пишет инфраструктуру для самой системы. Под инфраструктурой понимается установка, настройка, отладка, аггрегация статистики и первичный анализ.
      Наши задачи очень похожи, и по объему и по назначению.
      
      Код написаный на Питоне вызывает минимум проблем: за последние три месяца в ночных сборках + тестах этот код проявил себя всего два раза (один раз забыли добавить какую-то программу в системный путь, и другой раз поменялся механизм раздачи SSH ключей в кластере, который они не предусмотрели).
      
      Код написаный на Го вызывает проблемы раз в два-три дня. С банальными ошибками, которые прошли мимо код-ревью потому, что на Го можно писать только говнопортянки, и просто нету достаточно человек, чтобы уделить достаточно внимания чтению этого бреда. Ошибки типа: после парсинга Ясона забыли проверить длину массива. Перепутали местами строчку с сообщением об ошибке и строчку, где предполагается, что ошибка уже обработана. Ну, и иногда билт-ин АПИ подсыпает всяких крашей в абсолютно безобидных местах. Типа "попытка закрыть уже закрытый канал, блять" - очень серьезная ошибка изза которой програма закрывается без строчки логов.
      Ответить
      
      roman-kashitsyn 06.12.2016 14:15 # +1
      
      > "нормально обрабатывают ошибки" - это не эмоциональный аргумент, чтоли?
      
      Нет, я же написал, что понимаю под нормальной обработкой ошибок -- внятное семантическое описание проблемы, понятное пользователю, вместо унылых стектресов. Например, довелось мне как-то запускать чей-то питонокод, обучающий классификатор. Через пару минут работы обучателя вываливался невнятный стэктрейс из глубин skikit-learn с сообщением ValueError: 1 < 2. Оказалось, что обучающий набор был кривой и содержал только примеры с одной меткой. Нормальной обработкой ошибок я бы назвал сообщение "Your training set contains only 1 label, the classifier expects at least 2. Check your data." Это сообщение бы мгновенно указало мне на мою проблему, и мне не пришлось бы пару часов изучать кишки skikit, чтобы понять, как я пришёл к 1 < 2.
      
      > это показательно.
      
      Это было бы показательно, если одни и те же люди, имеющие одинаковую экспертизу в обоих языках, писали одно и тоже. Откуда мне знать, какие вы там профессианалы, если вы каналы по два раза закрываете.
      
      > парсинга Ясона забыли проверить длину массива
      
      В питоне такую ошибку, несомненно, невозможно допустить.
      
      > Перепутали местами строчку с сообщением об ошибке и строчку, где предполагается, что ошибка уже обработана.
      
      Исключения, очевидно, решают эту проблему.
      
      > безобидных местах. Типа "попытка закрыть уже закрытый канал
      
      Это в основном показывает, что вы не умеете в понятие "владение ресурсом". И да, это означает ошибку программиста.
      
      > програма закрывается без строчки логов.
      
      Чего? Паника происходит. Если вы не печатаете её в лог -- это ваша проблема.
      panic: close of closed channel
      Ответить
      
      wvxvw 06.12.2016 15:25 # 0
      
      Та ладно, ты не знаешь, что слово "семантически" значит. Просто умного из себя строишь. А по сути просто хуйню какую-то пишешь. У тебя, блять, был стек трейс, по которому ты мог найти неработающий код, и попробовать использовать то место куда ты кушаешь для того, чтобы понять, что там случилось. Вот когда у тебя в коде 20% ошибок выглядят так: io.EOF, без стек трейсов. Вот тогда ты понимаешь, зачем нужны стек трейсы.
      
      Тебе о профессионализме не судить, если ты думаешь, что это очень нужный краш при повторном закрытии канала. Краш всей программы, Карл! Нахуй нужен такой close() в высокоуровневном языке с потоками и селектами? Просто у этих долбоебов "так получилось", вот поэтому так и работает. Они не планировали, не думали о том, как лучше сделать. Налабали какой-то хуйни и в продакшн. Благо, все, что они делают - для внутреннего пользования, а там видимо инженерам нечем руки занять, вот и тестируют. Вот и пишут ёба-недоинерпретаторы Питона на Яве для сборок своих проектов и подобную хуету.
      
      Я же говорю, что в Го эти тривиальные ошибки тяжело найти изза того, что код размазан на 100500 строк бессмысленной повторяющейся хуйни. Ревьюер не в состоянии читать одно и то же, и не ошибаться никогда.
      
      Да чего там дальше объяснять... Ну, вот, продукт "известной" компании. Типа хай-энд продукт. Семинары, платные специалисты, все дела:
      https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-apiserver/app/server.go#L80
      Твои же братья-долбоебы написали. У меня просто руки опускаются, когда мне говорят, что мне нужно это говно использовать в своем проекте. Они, блять, ошибки все одного типа возвращают, принтэфами. Без стак трейсво. Полотно из функций на 200 строк. Пидарасы. Уебаны. Слов нет.
      Ответить
      
      subaru 06.12.2016 15:35 # 0
      
      > Полотно из функций на 200 строк.
      Мне бы твои проблемы. У меня тут функции по 2к строк очень плохого спагетти. Хнык :'(
      Ответить
      
      guest 06.12.2016 15:38 # +3
      
      А давайте попросим страйкера сделать отдельный раздел, где мы будем ныть про наши галеры?
      Ответить
      
      bayan 06.12.2016 16:02 # +1
      
      >>что это очень нужный краш при повторном закрытии канала. Краш всей программы, Карл!
      
      Попробуй PHP, серьезно. Там можно и файлы 2 раза закрывать, и к неинициализированным переменным обращаться.
      
      Главное собачку поставить в начале.
      
      Вообще управление ресурсами и памятью это скучно. Лучше всегда рандомно выделять память и освобождать её, захватывать ресурсы и отпускать. Пусть ЯП и его рантайм сам обо всем позаботятся
      Ответить
      
      roman-kashitsyn 06.12.2016 16:04 # +2
      
      > Просто умного из себя строишь.
      
      Ну ок, давай посмотрим глазами трезвого человека на то, что ты написал.
      
      В соседнем отделе люди пишут на питоне, и не ноют, и вообще всё давно сделали. У вас много детских ошибок: потерянные проверки, перепутанные местами педали строки, не знаете, кто владеет каналами, не печатаете паники в лог. Вы ноете и хотите уволиться. И виноват в этом, разумеется, Go. Потому что там писать много надо.
      
      Нет, ну всякое бывает, я тоже раз в год continue в каком-нибудь цикле забываю в чейнджлисте на 100 строк, и ревьюер этого не замечает, но язык-то тут причём.
      
      > повторном закрытии канала
      
      Повторное закрытие канала в "в высокоуровневном языке с потоками и селектами" это потенциальный рейс кондишен. Вероятно, две горутины конкурентно гадят в один канал, и не знают, кто его должен закрыть. Лучше просигналить эту ошибку сразу, чем ждать, пока через полгода что-нибудь закрэшится при попытке записи в закрытый канал.
      Если ты так не считаешь, то вам следовало писать на PHP: там можно делить на нуль и игнорить ворнинги.
      
      > ошибки все одного типа возвращают
      
      И чем тебе помогут ошибки разных типов в этом случае? Ты напишешь код, который сам будет устанавливать отсутствующий сертификат, если получит MissingCertificateError? Видимо, тут все ошибки unrecoverable, код не сможет починить сам себя, требуется внимания программиста. На первый взгляд ничего откровенно плохого не вижу. В пистоне была бы такая же портянка, только отовсюду летел бы какой-нибудь KubernetesError или, ещё хуже, ValueError.
      Ответить
      
      bormand 06.12.2016 19:09 # 0
      
      > тривиальные ошибки тяжело найти
      > ревьюер не в состоянии читать одно и то же
      Ну х.з. У нас вот тоже код с ручной обработкой ошибок (+RAII для всех ресурсов). Если кто-то где-то забывает обработать ошибку - на ревью это прям режет глаза, т.к. выбивается из общего стиля и нарушает однородность ;)
      Ответить
      
      DypHuu_niBEHb 12.01.2023 00:37 # 0
      
      >По поводу метрик, и почему раньше сделаный продукт в соседнем отделе - это показательно.
      
      сивоконь конечно редкостный апиздабол
      Ответить
      
      inkanus_gray 12.01.2023 03:14 # 0
      
      ну как, показался?
      Ответить
      
      bormand 05.12.2016 21:19 # +3
      
      > Потому, что билт-ин библиотека - говно
      > Чужие библиотеки - говно
      A bad workman blames his tools.
      Ответить
      
      subaru 05.12.2016 21:32 # +1
      
      Я его понимаю. Когда какой-то плавающий баг раз в месяц роняет программу в кору, а стектрейс ведет в какие-то бустовые кишки, то у меня лично в такие моменты накатывает депрессия. А при попытке разобраться в сорцах этих бустовых кишков вообще повеситься хочется.
      Как ты справляешься с такими ситуациями, борманд?
      Ответить
      
      bormand 05.12.2016 21:47 # +1
      
      > в кору
      > стектрейс
      У тебя есть стектрейс и дампы. Мне бы твои проблемы...
      
      > Как ты справляешься
      Культурой кода - проверки указателей, ассёрты, RAII и т.п. Больше, походу, никак.
      
      З.Ы. Хотя, после проезда по памяти, все эти коры и бектрейсы - просто бесполезный мусор, показывающий на какой-нибудь невинный код...
      Ответить
      
      bayan 05.12.2016 21:50 # 0
      
      Лол, а у тебя нет?
      Ты под ios пишешь чтоли? Это когда твоя программа упала у Васи и всё что ты знаешь это "твоя программа упала"?
      Ответить
      
      subaru 05.12.2016 21:56 # 0
      
      > Культурой кода
      Ну это не очень полезный совет. "Чтобы программа не падала, надо просто не писать баги."
      Ответить
      
      bormand 05.12.2016 22:00 # 0
      
      > не очень полезный совет
      Ну раз не хочешь ему следовать - пиши хуйню @ читай крешдампы до утра. Пока не обретёшь просветление.
      Ответить
      
      CHayT 06.12.2016 18:14 # 0
      
      > пиши хуйню @ читай крешдампы до утра.
      Use Erlang @ Let it crash
      Ответить
      
      guest 06.12.2016 18:22 # 0
      
      Да уж, хорошо что там ФП и вообще порог вхождения высокий, а то был бы идеальный язык для говнокодеров.
      Ответить
      
      CHayT 06.12.2016 18:26 # +2
      
      > и вообще порог вхождения высокий
      
      Я вас умоляю. У нас две недели даётся на изучение с нуля вместе со всем ФП. Потом, конечно, некоторое время на гк наблюдаются "фирменные ревью от Снаута".
      Ответить
      
      bormand 06.12.2016 18:30 # +1
      
      > Let it crash
      У меня на прошлой работе гуйня для терминала так работала - сегфолтилась, супервизор её перезапускал, прога подтягивала стейт с сервака, обрабатывала кнопочки-датчики, отправляла стейт на сервак, рисовала новый фрейм, сегфолтилась... Сегфолт каждый кадр, но по ощущениям вполне нормально работало, просто трафика много на сервер. Заметил не сразу :)
      Ответить
      
      CHayT 06.12.2016 18:37 # 0
      
      А надо было разумный restart intensity и period в супервизоре установить!
      Ответить
      
      bormand 06.12.2016 18:39 # 0
      
      > разумный restart intensity и period
      Тогда вообще бы не заметил?
      
      З.Ы. Супервизором там был тупой sh скрипт с бесконечным циклом :)
      Ответить
      
      CHayT 06.12.2016 18:46 # +2
      
      > Тогда вообще бы не заметил?
      Наоборот, через некоторое время супервизор отправил бы чайлда мыться под струю сам бы покрешился, ибо поддерживать сервис -- это хорошо, но поддерживать _неправильно_ работающий сервис -- немного другое.
      > Супервизором там был тупой sh скрипт с бесконечным циклом :)
      Это тогда не надзиратель, а сообщник.
      Ответить
      
      bormand 06.12.2016 18:52 # 0
      
      > сам бы покрешился
      Т.е. в итоге самый главный супервизор понимает, что жизнь - тлен. И делает харакири себе и всем оставшимся в живых?
      Ответить
      
      CHayT 06.12.2016 19:15 # +1
      
      > И делает харакири себе и всем оставшимся в живых?
      
      Именно. Если не помогает даже, скажем, рестарт на уровне кластера, главный супервизор говорит, мол, "вызывайте этих говнокодеров из отпусков, выходных и заказывайте им ведро вазелина, а я отправляю трафик в другой дц и ухожу в спячку".
      Ответить
      
      wvxvw 06.12.2016 14:06 # 0
      
      Ну да, потому что проще всегда перейти на личности и сказать "ты мудак" потому что тебе что-то не нравиться.
      
      По-поводу чужих библиотек. Ну, взять тот же парсер для Ямла на Го. Это уебищная копи-паста из сишного кода, без понимания того, что происходит в оригинале. Он примеры с оф. сайта в половине случаев не может распарсить. А когда может - выбрасывает нужную информацию. Ну и кроме всего прочего - не потокобезопасный.
      Есть, например генерилки для Трифта / Сваггера. Код сгенерированый для Трифта ни один линтер не пройдет, а кроме того, в сгенерированом коде не просто невозможна многопоточность, он вообще больше одного запроса одновременно обработать не может. В Сваггере сгенерированом полно string.ToUpper("POST") и т.п. хуйни. Они наверное вообще ни разу не смотрели на то, что генерировали. А до запуска дело вообще не дошло.
      
      Из гугловского говна: реализация SFTP, но без сжатия. Зато они туда нахуярили асинхронную сборку и чтение файлов. Типа, можно читать файл одновременно с разных отступов. Но интерфейс у этого говна все-равно последовательный. Т.е. если попытаться патч написать для этого бесполезного говна, на это уйдет несколько месяцев.
      
      А вообще, на говнокоде просто места не хватит рассказывать про всю уебищность библиотек на Го. Выше - только промиля из всего, что там творится.
      Ответить
      
      bormand 06.12.2016 18:37 # 0
      
      Ну т.е. виноват не язык, а просто инфраструктура сырая (что вполне нормально для молодого и развивающегося языка).
      Ответить
      
      bormand 06.12.2016 18:44 # 0
      
      З.Ы. К слову, тому же питону 25(!) лет.
      Ответить
      
      3_14dar 06.12.2016 19:12 # 0
      
      А он сишные либы не умеет юзать что ли?
      Ответить
      
      guestinho 07.12.2016 01:52 # +1
      
      Умеет, но вроде через гланды. Я сам не гошник, но в каком-то докладе слышал, что там FFI вызовы через три пезды в отдельном потоке выполняются.
      У гошников явный тренд писать все снуля на го. У них даже собственная реализация tls на го вместо опенссл.
      Ответить
      
      bayan 07.12.2016 01:56 # +1
      
      тсс
      никому не рассказывай что у жабы и дотнета тоже есть такой тренд.
      Ответить
      
      guest6 12.01.2023 04:33 # 0
      
      > У них даже собственная реализация tls
      
      ого, вот это реально стращно
      Ответить
      
      bayan 06.12.2016 21:04 # 0
      
      А почему C#.NET моложе пыха, а при этом там и фреймворк и язык в тыщу раз лучше?
      Ответить
      
      bormand 06.12.2016 21:06 # 0
      
      > моложе пыха
      Всего года на 3, если верить вики :)
      
      А насчёт того, что фреймворк лучше - только последние. Второй тем ещё говном был. А первый - имхо, даже хуже жабы.
      Ответить
      
      bayan 06.12.2016 21:12 # 0
      
      Второй был не хуже шестой жабы, а то и лучше (генерики в рантайме).
      И уж конечно он в тысячу раз лучше пхп
      Ответить
      
      3_14dar 07.12.2016 04:37 # 0
      
      >генерики в рантайме
      Зачем они нужны?
      Ответить
      
      bayan 07.12.2016 16:45 # 0
      
      Ты не поверишь: чтобы чекать тайпы в рантайме, чтобы не ловить ClassCastException, чтобы кастовать в Array без бойлерплейта
      Ответить
      
      AnalniyTerzatel 08.12.2016 14:10 # 0
      
      Поцелуй меня в зад.
      Ответить
      
      O____O 08.12.2016 14:53 # 0
      
      Поцелуй меня в ад.
      Ответить
      
      guest 29.11.2016 00:38 # −1
      
      Кстати, а ты же там без исключений пишешь? Расскажи, как работается спустя пару месяцев. Как без стл живется? Как процесс разработки устроен? Слей инсайдов про борг и спаннер.
      Ответить
      
      barop 29.11.2016 00:39 # −1
      
      спорим, хуесто, он тебе ничего не расскажет?
      
      В корпорации добра такие NDA что папа не горюй
      Ответить
      
      guest 29.11.2016 00:40 # −1
      
      Ну а вдруг) Хотя он и в прошлый раз неохотно рассказывал.
      Ответить
      
      barop 29.11.2016 00:46 # −1
      
      ну вдруг, да) Послушаем)
      
      Я вот слыхал что там до такой степени своя атмосфера, что даже кодстайлы у них не всегда совпадают с оф. рекомендациями (типа питонячьего pep8)
      Ответить
      
      guest 29.11.2016 02:44 # −1
      
      Таки проигнорил похоже :-\
      Ответить
      
      roman-kashitsyn 29.11.2016 13:26 # −1
      
      > Таки проигнорил похоже :-\
      
      Не совсем понятно, что ты ожидаешь услышать. Всё, что я могу рассказать, уже давно и так опубликовано и широко известно (собственно, поэтому я и могу это рассказать).
      
      Borg: http://research.google.com/pubs/pub43438.html Spanner: http://research.google.com/pubs/archive/44915.pdf Flume: http://research.google.com/pubs/pub35650.html Bazel: https://bazel.build/ C++ Guildeline: https://google.github.io/styleguide/cppguide.html Python Guildeline: https://google.github.io/styleguide/pyguide.html
      
      > Как без стл живется?
      Кто сказал, что без стл? Либы тут отличные, кстати.
      
      > Как процесс разработки устроен?
      http://agileconsortium.pbworks.com/w/page/f/XR7+mstriebeck-ShtAddingProcess.pdf
      Ответить
      
      guest 29.11.2016 13:34 # −1
      
      Ну естественно я ожидал что-то, чего нет в этих статьях, каких-то охуительных историй и личных впечатлений. Та же статья про спанер вышла 4 года назад, с тех пор наверняка много поменялось.
      Ну я в общем не настаиваю. Если нет охуительных историй, то и не надо.
      Ответить
      
      guest 29.11.2016 14:17 # −1
      
      А ты небочь пишешь на пхп за доширак в маленькой вебстудии, и по ночам мечтаешь о Гугле?
      Ответить
      
      guest 29.11.2016 14:44 # −1
      
      бароп, плиз
      Ответить
      
      guest 29.11.2016 15:57 # −1
      
      плиз иди на хуй, я хотел сказать
      Ответить
      
      barop 29.11.2016 15:46 # −1
      
      >> With the help of an experienced agile leader (scrum
      >> master, XP coach…) it was possible to carefully
      >> introduce agile practices into Google
      
      Круто:) Я единожды видел скрам в аутсорсе. Продуктовые компании редко его умеют. Гугл молодец
      Ответить
      
      CHayT 29.11.2016 16:06 # −1
      
      А я видел, как в продуктовой компании аджайл юзает... IT саппорт. Заставь дурака богу молиться.
      Ответить
      
      barop 29.11.2016 16:07 # −1
      
      страшно представить какой у них размер спринта
      Ответить
      
      CHayT 29.11.2016 16:10 # −1
      
      Три недели, всё по взрослому. Вот это называется менеджерская шиза.
      Ответить
      
      barop 29.11.2016 16:11 # −1
      
      --у меня сломалась мышь
      --добавили в беклог, попробуем впихнуть в следующий спринт на планировании
      
      Пленниг покер: сколько времени займет замена мыши?
      Ответить
      
      CHayT 29.11.2016 16:13 # −1
      
      Ну там речь была не про мыши, а про обслуживание/аппаратную перенастройку серверов в лабе, но суть ты понял . Людей спасала только система знакомств ^___~
      Ответить
      
      barop 29.11.2016 16:26 # −1
      
      но я видел и обратные случаи, где требования к софту были у программиста в голове, потому что их озвучили сегодня вечером по скайпу. И где программист выкладывал наживой сервер по FTP нетестированные патчи
      Ответить
      
      bormand 29.11.2016 06:40 # −1
      
      Ну я вот тоже без исключений пишу. Как-будто это что-то редкое и необычное.
      Ответить
      
      guest 29.11.2016 11:35 # −1
      
      довольно сложно это делать, когда стандартная библиотека и буст дизайнились с исключениями в уме (да, я знаю, что в гцц можно выключить, и стл начнет абортиться вместо исключений, но это сомнительный костыль).
      Ответить
      
      roman-kashitsyn 29.11.2016 13:14 # −1
      
      > стандартная библиотека
      > с исключениями в уме
      
      Лол, в каком месте? Весь STL exception-agnostic, iostreams вообще унылое говно на флажках.
      Ответить
      
      bormand 29.11.2016 17:35 # −1
      
      > Лол, в каком месте?
      Все контейнеры stl, которые никак не могут просигналить об out of memory. Разве что тупо abort()'ом.
      Ответить
      
      guest 29.11.2016 17:40 # −1
      
      Ну как раз bad_alloc вменяемо обрабатывать только ембедщики и умеют кажется. А вот всякие at() можно было бы и без исключений сделать.
      Ответить
      
      bormand 29.11.2016 17:54 # 0
      
      > bad_alloc вменяемо обрабатывать
      А на линупсе оно вообще редко прилетает... Скорее OOM киллер кого-то убьёт в подворотне, чем ядро признается в недостатке памяти.
      Ответить
      
      dxd 29.11.2016 18:19 # −1
      
      Наш научный код падает по bad_alloc примерно в трети случаев. В остальных - oom_killer приходит, да.
      Ответить
      
      roman-kashitsyn 29.11.2016 17:42 # −1
      
      > которые никак не могут просигналить об out of memory
      
      std::set_new_handler
      Ответить
      
      bormand 29.11.2016 17:43 # −1
      
      Туда что-то осмысленное можно засунуть кроме лога и/или аборта? :)
      Ответить
      
      guest 29.11.2016 17:45 # +3
      
      запуск сборщика мусора
      Ответить
      
      roman-kashitsyn 29.11.2016 17:49 # +1
      
      > Туда что-то осмысленное можно засунуть кроме лога и/или аборта? :)
      
      Вызов Borg, который перезапустит бинарник на машине с большим кол-вом RAM.
      Ответить
      
      bormand 29.11.2016 17:52 # −1
      
      Ну можно ещё подёргать какие-нибудь коллбеки у других подсистем, чтобы они поделились памятью.
      Ответить
      
      barop 29.11.2016 18:48 # −1
      
      https://developer.apple.com/reference/uikit/uiviewcontroller/1621409-didreceivememorywarning?language=objc :)
      Ответить
      
      guest 29.11.2016 17:42 # −1
      
      Стандартная библиотека - это не только стл. Там дохуя кто эксепшоны бросает. Вот тебе чиста для примера, чтобы ты понял, о чем я: http://ru.cppreference.com/w/cpp/string/basic_string/stol
      Ответить
      
      roman-kashitsyn 29.11.2016 17:48 # 0
      
      Ок, допустим, stol кидает исключение. Я бы сказал, что он такой просто нафиг не нужен.
      
      Какова вероятность, что некая строка является валидным числом? Небольшая. Значит, ошибка в этой функции вполне ожидаема. Если ошибка ожидаема, какое-же это тогда "исключение"?
      
      Разумеется, для этого есть вменяемые эквиваленты, возвращающие StatusOr<T>.
      Ответить
      
      guest 29.11.2016 17:52 # −1
      
      Напомню, что тут речь не про идеальный способ работы с ошибками, а про то, что со стандартной библиотекой жить без исключений скорее нельзя, чем можно.
      Ответить
      
      roman-kashitsyn 29.11.2016 17:58 # −1
      
      > что со стандартной библиотекой жить без исключений скорее нельзя, чем можно.
      
      Ну ок, ты нашёл пару функций в стандартной библиотеке, которые зачем-то кидают исключения.
      
      Я всё же утверждаю, что большая часть кода там exception-agnostic (контейнеры, алгоритмы, стримы, сишные легаси, етц). А то, что не агностик -- не нужно.
      
      От bad_alloc никуда не денешься, но там можно просто крэшится, большинство приложений не могут обработать эту ошибку.
      Ответить
      
      guest 29.11.2016 18:47 # −1
      
      ¯\_(ツ)_/¯
      А я утверждаю, что такой хуйни там навалом. А еще есть буст.
      Ответить
      
      roman-kashitsyn 29.11.2016 19:30 # −1
      
      > А я утверждаю, что такой хуйни там навалом
      
      Ок, продолжай утверждать.
      А я и дальше буду юзать умные указатели, *map, vector, string, подмножество буста, етц.
      https://google.github.io/styleguide/cppguide.html#Boost
      Ответить
      
      bormand 29.11.2016 19:32 # −1
      
      Обидно, что property tree без исключений неюзабельно: Callers of throw_exception are allowed to assume that the function never returns; therefore, if the user-defined throw_exception returns, the behavior is undefined.
      Ответить
      
      roman-kashitsyn 29.11.2016 19:40 # −1
      
      > property tree
      
      Нам оно без надобности, у нас тут свои эпичные конфиги.
      Ответить
      
      guest 29.11.2016 19:45 # −1
      
      А я и дальше буду юзать все, что мне понадобится из стандартной библиотеки и буста. Потому что я не в гугле. По этой же причине я не буду следовать этому стайлгайду.
      
      > string
      http://en.cppreference.com/w/cpp/string/basic_string/at
      http://en.cppreference.com/w/cpp/string/basic_string/insert
      http://en.cppreference.com/w/cpp/string/basic_string/erase
      http://en.cppreference.com/w/cpp/string/basic_string/append
      en.cppreference.com/w/cpp/string/basic_string/replace
      http://en.cppreference.com/w/cpp/string/basic_string/substr
      http://en.cppreference.com/w/cpp/string/basic_string/copy
      Ответить
      
      defecate-plusplus 29.11.2016 21:57 # −2
      
      > Потому что я не в гугле
      так ты хвалишься или жалуешься?
      Ответить
      
      guest 29.11.2016 22:34 # −1
      
      Я объясняю тов. Кашицыну, почему я использую библиотеки, кидающие исключения.
      Касательно моей оценки ситуации:
      - Исключения - говно. Я бы хотел, чтобы в плюсах их не было.
      - Гугл - заебись. Это плохо, что я не работаю там CTO.
      Ответить
      
      AnalniyTerzatel 29.11.2016 22:45 # −1
      
      А между тем, в Яунде двадцать градусов тепла.
      Ответить
      
      roman-kashitsyn 29.11.2016 23:09 # −1
      
      > http://en.cppreference.com/w/cpp/string/basic_string/at
      
      Все перечисленные методы кидают правильные исключения (в отличие от stol). Причина выбрасывания этих исключений -- халатность программиста. Перечисленные методы можно спокойно вызывать в любом гугловом коде, просто ошибка в коде приведёт к std::abort().
      
      > По этой же причине я не буду следовать этому стайлгайду.
      
      Можно подумать, тебя кто-то заставляет.
      Ответить
      
      barop 29.11.2016 23:10 # −1
      
      То-есть ты не против исключений в случае нарушения контракта, да?
      
      Исключений в том смысле, в каком они используются в Objc например, или в смысле "RuntimeException / AssertError" в жабе?
      
      Ну например сказано "не передавать сюда NULL", а его передали и получили исключение?
      Ответить
      
      AnalniyTerzatel 29.11.2016 23:19 # −1
      
      А между тем, в Яунде двадцать градусов тепла.
      Ответить
      
      roman-kashitsyn 29.11.2016 23:24 # +1
      
      > То-есть ты не против исключений в случае нарушения контракта, да?
      
      Нет, не против. Суть в том, чтобы отличать ожидаемые ошибки от исключительных ситуаций.
      Проблемы с I/O при записи в файл -- ожидаемая ошибка, которую можно и нужно предусмотреть заранее и обработать.
      Выход за границе массива -- это ошибка в программе, которую нельзя предусмотреть и правильно обработать.
      OutOfMemory означает, что программист неправильно оценил ресурсы, которые требуются для корректной работы программы, с этим в большинстве случаев ничего не сделаешь.
      Ответить
      
      AnalniyTerzatel 29.11.2016 23:31 # −1
      
      А между тем, в Яунде двадцать градусов тепла.
      Ответить
      
      guest0 30.11.2016 00:30 # −1
      
      Все ясно, ты о своем. Мне без разницы, по делу исключение или нет. Речь шла о том, чтобы их не было вообще. Я не хочу, чтобы эти пидоры летали по моему коду рандомно меняя поток выполнения. Если код выполз за приделы массива, то пускай падает сразу, а в остальное время я хочу видеть по коду, что творит функция.
      И да, я не считаю, что at() у мапы должен кидать исключение или крашить программу. Из-за такого at'а я использую find и ебу итераторы (хорошо хоть auto завезли).
      Ответить
      
      barop 30.11.2016 00:34 # −1
      
      >>рандомно меняя поток выполнения
      
      а можно подробнее?
      Ответить
      
      guest0 30.11.2016 00:42 # −1
      
      Ну читаешь ты чей-то код. Циклы там, ифы, функции какие-то вызываются, вроде все понятно. А хуй там плавал! Каждая строчка может быть последней, а где потом окажется выполнение - пойди проссы еще.
      Ответить
      
      barop 30.11.2016 00:43 # −1
      
      Ну если представить что ЕДИНСТВЕННАЯ реакция на Exception это "немедленно сдохнуть" то какая разница как это реализовано технически?
      Сдыхает он срязу там, или наверху колстека?
      Ответить
      
      guest0 30.11.2016 00:49 # −1
      
      Ну если представить, то да. Только в реальности это не так :)
      Ответить
      
      roman-kashitsyn 30.11.2016 00:59 # −1
      
      > какая разница
      
      Деструкторы же
      Ответить
      
      barop 30.11.2016 01:08 # −1
      
      финалайзеры в джаве, м?)
      Ответить
      
      roman-kashitsyn 30.11.2016 01:15 # −1
      
      финалайзеры finally-блоки.
      Ответить
      
      barop 30.11.2016 01:23 # −1
      
      >> finally-блоки.
      да, я о них, финалайзеры это вообще атавизм он тут не при делах
      Ответить
      
      roman-kashitsyn 30.11.2016 00:48 # −1
      
      > я не считаю, что at() у мапы должен кидать исключение
      
      Используй вместо него operator[], нет?
      Ответить
      
      guest0 30.11.2016 01:06 # −1
      
      Чтобы он мне какой-то хуиты в мапу навставлял?)
      Ответить
      
      barop 30.11.2016 00:35 # −1
      
      А между тем, в Яу^W^W
      
      тогда зачем городить иерархию таких исключений?
      
      И зачем механизм их отлова?
      
      -------------
      Воепрос тебе на засыпку: Для тупого веблога является ли недоступность СУБД ожидаемой или это исключительное?
      Ответить
      
      roman-kashitsyn 30.11.2016 00:47 # −1
      
      > Для тупого веблога является ли недоступность СУБД ожидаемой или это исключительное?
      
      Недоступность любого внешнего процесса является ожидаемой. Проектировщики апи клиента СУБД не знают, где он будет использоваться -- в веблоге или нет.
      Ответить
      
      barop 30.11.2016 01:15 # −1
      
      Ну вот из глубин ORM летит наверх SQLException.
      Автор серьезного софта его ловит и обрабатывает.
      Автор веблога ловит ВСЕ exceptions, пишет пользователю "temporary down", текст эксепшена (toString()) пишет в лог, и шлет письмо админу.
      Админ видит текст эксепшена и все фиксит.
      
      Все. Одинаково хендлятся ВСЕ эксепшены, буде-то место кончилось на БД или коннекшен упал.
      
      В твоем же случае StatusOr<T> придется тащить буквально везде, до самого верху чтобы записать его в лог и сделать тоже самое.
      
      А если метод одновременно подключается к СУБД и REST API удаленного сервиса?
      Там будет уже две ошибки.
      
      Представь как засрется API, нет?
      Ответить
      
      roman-kashitsyn 30.11.2016 02:06 # −1
      
      > Автор веблога ловит ВСЕ exceptions, пишет пользователю "temporary down", текст эксепшена (toString()) пишет в лог, и шлет письмо админу.
      
      Очевидно, автор этого веблога пишет на PHP и вообще живёт счастливо без всяких исключений, connect() or die(), вот это всё.
      Посмотрим, как админу понравится получать письмо каждый раз, когда KeyError какой-нибудь случится.
      Ответить
      
      AnalniyTerzatel 30.11.2016 02:44 # −1
      
      А между тем, в Яунде двадцать градусов тепла.
      Ответить
      
      barop 30.11.2016 02:53 # −1
      
      Ну а если он пишет на java?
      
      KeyError это одноразовая ошибка, а no space left on device явно волнует админа, разве нет?
      Ответить
      
      AnalniyTerzatel 30.11.2016 03:00 # −1
      
      А между тем, в Яунде двадцать градусов тепла.
      Ответить
      
      barop 30.11.2016 01:24 # −1
      
      Другой пример: у меня есть интерфейс за которым стоит удаленный сервис.
      Ремоутинг, значит.
      
      Ты правда будешь пихать в КАЖДЫЙ (даже войд, лол!) метод status?
      Ответить
      
      guest0 30.11.2016 01:55 # −1
      
      В го так и делают. А в типичном расте вообще половину кода .unwrap() занимают.
      Ответить
      
      barop 30.11.2016 03:02 # −1
      
      Разве не говно?
      
      А с другой стороны проблема напоминает nullify.
      В современных ЯП принято иметь для Nullable и notnull разные типы, и заставлять юзера явно проверять что значение не null.
      
      Kotlin e.g.
      
      Тут почти тоже самое
      Ответить
      
      guest0 30.11.2016 03:20 # −1
      
      Мне в го нормально было. В плюсах с optional тоже было бы ок.
      Ответить
      
      barop 30.11.2016 03:24 # −1
      
      Потому что на C++ редко пишут веббложики, нет?
      Ответить
      
      AnalniyTerzatel 30.11.2016 05:18 # −1
      
      А между тем, в Яунде двадцать градусов тепла.
      Ответить
      
      roman-kashitsyn 30.11.2016 01:55 # 0
      
      > Ты правда будешь пихать в КАЖДЫЙ (даже войд, лол!) метод status?
      
      А в чём, собственно, проблема? Идея относится к удалённому сервису так, будто он ничем не отличается от локального -- уже плохая. Даже жабисты это поняли на заре RMI, поэтому чекед RemoteException кидается из каждого прокси.
      Ответить
      
      barop 30.11.2016 02:52 # −1
      
      RMI давно проклят и забыт. Спринг так не делает, например.
      Другой пример это прокси-классы на SOAP.
      
      >>Не отличается от локального -- уже плохая
      Во ты сейчас просто взял, и насрал на целый пласт архитектуры, понимаешь?
      
      А если у меня есть алогритм который должен быть агностик на тему того локальный он или удаленный?
      
      Конечно, удаленный будет работать в 38 раз медленее, но и пофиг. Это ентерпрайз, он асинхронно обрабатывает заказ, и мне не важно что он занимает не 15 секунд а 15 минут.
      Почему я должен его менять?
      Ответить
      
      bormand 30.11.2016 06:28 # 0
      
      > агностик на тему того локальный он или удаленный
      Ну вот и пусть всегда считает, что он удалённый, даже если исполняется локально ;)
      Ответить
      
      AnalniyTerzatel 30.11.2016 06:52 # −1
      
      А между тем, в Яунде двадцать градусов тепла.
      Ответить
      
      guest 29.11.2016 13:16 # −1
      
      Я сочиняю роман
      Кашицын всей моей жизни
      Иду по вечному кругу
      Ответить
      
      guest 06.12.2016 19:12 # 0
      
      >>Иду по вечному кругу
      Ебут тебя во все дыры, да? )
      Ответить
      
      barop 29.11.2016 00:34 # −1
      
      PS: >>Как в языке выразить мысль, что метод кидает то же самое исключение, что кидает его функция-параметр? Никак.
      
      Вот это кстати хуйня полная. Это же элементарно было бы сделать. Так почему не сделали?
      
      Пусть функция, чей формальный параметр есть другая функция с эксепшеном E явно говорит (ну или при вызове ее явно указывается): "я прокину E" либо "я обязуюсь поймать и обработать E".
      
      А знаешь почему эта, казалось бы элементарная, мысль не пришла никому в голову?
      Потому что никто не умеет checked exceptions, даже в Oracle:) Все думают что это "говно какое-то и всё равно его никто не юзаеот"
      Ответить
Добавить комментарий
Ошибка компиляции комментария:

Гости могут высказаться только в понедельник, среду, четверг или воскресение
Где здесь C++, guest?!

А не использовать ли нам bbcode?

[b]жирный[/b] — жирный

[i]курсив[/i] — курсив

[u]подчеркнутый[/u] — подчеркнутый

[s]перечеркнутый[/s] — перечеркнутый

[blink]мигающий[/blink] — мигающий

[color=red]цвет[/color] — цвет (подробнее)

[size=20]размер[/size] — размер (подробнее)

[code=<language>]some code[/code] (подробнее)

Проверочный код: *

Говнокод: по колено в коде.

Java / Говнокод #21732

Комментарии (209) RSS

Добавить комментарий