Комментарии 17
Пример из conc либы:
За что я люблю Go и не люблю, например, JS...
Слева – перед глазами очевидный и простой код, справа – грёбаный сахар и магия под капотом.
Спасибо, но нет.
Толя, код справа на Go написан )))
Хотя понимаю, о чем ты
В любом случае спасибо за наводку, занятная библиотека, надо будет глянуть при случае что там внутри ))
Простите за наивный вопрос, но у вас в среде разработки "Go to Reference" не работает?)) Если мы пишем крупный проект, то рано или поздно , дабы не нарушить DRY нам все равно придется написать функцию обёртку и начинается велесипедо строение вместо того, чтобы просто использовать стд-шную функцию. Более того, я уверен, что после стабилизации итераторов, в стандартной библиотеке скорее всего появится похожая функция.
У вас претензия к тому, что кто-то написал содержимое функции concMap за вас и упаковал в библиотеку?
Никакого негатива не подразумеваю, просто не понял суть комметария
Не соглашусь с вами. Дробя код на функции и библотеки мы тем самым можем по отдельности их протестить.
Если все находится в одной функции, то тест существенно разрастается и становится сложным в сопровождении.
В итоге в 1968 году Дейкстра опубликовал эпохальную статью "Оператор goto считается вредным", и началась эра структурного программирования — когда программа является иерархической структурой, состоящей из блоков и подпрограмм, а goto все избегают.
Я имел в виду, что Дейкстра вынес это обсуждение в массы (что там, где много goto, там много ошибок), в результате чего люди стали писать по-другому. Т.е. это толчок к развитию, а не то, что Дейкстара писал про иерархии подпрограмм
Он писал не про это. Он писал, что отказ от инстуркций управляющих ходом алгоритма (безусловный переход) или меняющих состояние переменных (оператор присовниения) поможет автоматизировать доказательства правильности программ.
Вот только это рпдполжение было сделано для чисто теоретичсекой теоремы Бёма и Якопини и в результате он пришел к выводу, что "Тестирование выявляет только наличие, но никак не отсутствие ошибок".
Но я согласен, что все это послужило толчком к развитию.
Я, кстати, сейчас посмотрел, в статье было про плотность ошибок при использовании goto. Но это, как я понял, было примечание редактора (Вирта).
Конкретно в "Go To Statement Considered Harmful", написано именно об этом: что goto вреден, вносит хаос и так далее.
>Вот только это рпдполжение было сделано для чисто теоретичсекой теоремы Бёма и Якопини
В оригинальной статье эта теорема упоминается одной строкой в разделе "благодарности и обсуждение", в контексте "кстати вот доказали, что можно вообще без goto".
>в результате он пришел к выводу, что "Тестирование выявляет только наличие, но никак не отсутствие ошибок".
Это cовершенно другая статья, сама фраза там никакой не "вывод" а просто язвительное замечание-шутка.
Ну про закрыть канал писателем - это очевидно же.... но только если пишет один....
Безусловная фраза:
> В данном случае, кстати, лучше вообще заменить на sync.Map.
примерно в 100500 раз хуже оператора goto.
1) не совсем очевидно, как показывает практика
2) если данные прилетают из двух источников, то лучше сделать по отдельному каналу. А потом fan in.
3) чем плох sync.Map? Что там везде any? В любом случае, понятность кода может создавать оверхед. Даже, когда линейный код тупо разбивается на функции - это уже нехилый оверхед, далеко не всё инлайнится компилятором
> В данном случае, кстати, лучше вообще заменить на sync.Map.
примерно в 100500 раз хуже оператора goto.
Немного не понял. Как можно заменить sync.Map оператором `goto`?
Ну про закрыть канал писателем - это очевидно же.... но только если пишет один....
В случае многих писателей можно смело утверждать, что эти писатели тоже где-то создаются и кем-то ожидаются. Соответственно, этот кто-то ждёт пока отработают все писатели и закрывает канал, в который отправлялись данные.
Structured concurrency в языке Go