tag:blogger.com,1999:blog-654279083390275842.post9031684066119040383..comments2024-03-19T12:22:43.654+03:00Comments on Размышлизмы eao197: [prog.flame] Почему я не использую языки D и Goeao197http://www.blogger.com/profile/17283739752119445290noreply@blogger.comBlogger65125tag:blogger.com,1999:blog-654279083390275842.post-44366931408142974602010-10-26T20:26:03.470+03:002010-10-26T20:26:03.470+03:00@Gaperton: вот мое мнение по поводу Go-шных defer,...@Gaperton: вот мое мнение по поводу Go-шных defer, panic и recover: http://eao197.blogspot.com/2010/10/progflame-go-defer-panic-recover.htmleao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-32005524924090673382010-10-26T06:55:29.075+03:002010-10-26T06:55:29.075+03:00@Gaperton:
>Или ты считаешь, что всенепременне...@Gaperton:<br /><br /><i>>Или ты считаешь, что всенепременнейше во всех темах разбираешься лучше всех, и никогда не ошибаешься?</i><br /><br />Я вот, например, не понимаю, почему для знания принципов supervisors tree в Erlang-е нужно быть экспертом по Erlang-у.<br /><br /><i>>На, полюбопытствуй, и после этого еще раз скажи, нужны ли там исключения.</i><br /><br />Конечно нужны. Но здесь и так уже слишком много сообщений понаписано, поэтому лучше я выскажусь в отдельном посте.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-75859187709937463552010-10-25T15:18:39.184+03:002010-10-25T15:18:39.184+03:00@eao197
Нет, знание, конечно, не определяется не ...@eao197<br /><br />Нет, знание, конечно, не определяется не установленным дистрибутивом. Я же сказал - что наши различия с этого факта только начинаются.<br /><br />А вот зато незнание - вполне может определяться отсутствием оного. Тот язык, который у тебя не установлен - ты не используешь. Примета такая. :)<br /><br />Так что линейку прибереги для других случаев. :) Или ты считаешь, что всенепременнейше во всех темах разбираешься лучше всех, и никогда не ошибаешься? :) Ну, тогда доставай линейку, меряться будем :).<br /><br />Кстати, перед тем, как линейкой размахивать - скажи, про такие конструкции как panic, recover, и defer в Go - слышал? :) На, полюбопытствуй, и после этого еще раз скажи, нужны ли там исключения.<br /><br />http://blog.golang.org/2010/08/defer-panic-and-recover.htmlGapertonhttps://www.blogger.com/profile/08723788281409711639noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-75736976453289301652010-10-20T18:40:37.594+03:002010-10-20T18:40:37.594+03:00>товарищу АА нужно было найти brighter писателя...<i>>товарищу АА нужно было найти brighter писателя компиляторов (злой юмор)</i><br /><br />+100500 :)))eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-13085727461219590822010-10-20T16:56:24.913+03:002010-10-20T16:56:24.913+03:00флейм пропустил.
Хотел поделиться впечатлением от...флейм пропустил. <br />Хотел поделиться впечатлением от прочтения АА, 2010. Идеи pure и организация параллельности будут кем то подхвачены а d2 - труп. Нет смысла тратить на него силы. товарищу АА нужно было найти brighter писателя компиляторов (злой юмор).<br /> <br />К сожалению отслеживая инфо по го картина печальная. Они заложились на рантайм при дизайне языка и так и не нашли в том же гугле тех бы его сделал. вместо этого они там новый гцц написали походу :)) Так что ни scalability ни safety от гонок так и не получилось. Ждать го++ ? ;) Имхо нет.<br />best regards.Miroslavhttps://www.blogger.com/profile/08682508835432008058noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-8250507775091374062010-10-18T10:18:34.435+03:002010-10-18T10:18:34.435+03:00>Разница между нами начинается с того, что тебе...<i>>Разница между нами начинается с того, что тебе, чтобы что-то посчитать, надо _качать_ эрланг, а у меня он, по странному стечению обстоятельств, уже установлен, и я могу набрать "grep" :).<br /><br />Впрочем, тебе конечно же виднее, как оно в Эрланге принято, правда? :D</i><br /><br />О да, знание принципов, которые закладывались в Erlang и которые описывались в диссертации Армстронга, определяются наличием распакованного дистрибутива. Афигительный критерий.<br /><br />Может проще сразу линейку достать? ;)eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-1645953419936367322010-10-18T10:16:42.110+03:002010-10-18T10:16:42.110+03:00>Нужно, нужно. Потому, что никакой "совсем...<i>>Нужно, нужно. Потому, что никакой "совсем другой картины" в папке erlang/lib получиться не может, и не могло.</i><br /><br />Если не делать, то не могло. А если сделать то получится, что общий объем дистрибутива otp_src_R14B_erts-5.8.1.1.tar.bz2 в распакованном виде 214Mb, из которых в lib находится 197Mb. Если из lib выдрать только непустые строки из *.erl файлов и убрать строки-комментарии то их остается всего на 51Mb в количестве 1344633 штук. В которых обнаруживается 7048 слов catch. Т.е. по одному catch на 190 строк.<br /><br />Может я чего-то не понимаю в программировании, но один catch на 190 строк -- это очень сильно непохоже на "никто не использует".eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-41478466093876762762010-10-18T03:32:35.477+03:002010-10-18T03:32:35.477+03:00>>Всего 3.5 тысячи catch-ей, на все-превсе б...>>Всего 3.5 тысячи catch-ей, на все-превсе библиотеки. Учитывая общий размер в 240 мегабайт - это ничего.<br /><br />> Не нужно мешать штуки с мегабайтами. Поскольку если выбросить оттуда все не Erlang-овое, а следом и комментарии, то получится совсем другая картина.<br /><br />Нужно, нужно. Потому, что никакой "совсем другой картины" в папке erlang/lib получиться не может, и не могло.<br /><br />>>Ну, ты о практике применения данного стиля судить не можешь, извини.<br /><br />> Это взаимно, кстати.<br /><br />Нет, это, конечно же, это не взаимно. :) Разница между нами начинается с того, что тебе, чтобы что-то посчитать, надо _качать_ эрланг, а у меня он, по странному стечению обстоятельств, уже установлен, и я могу набрать "grep" :).<br /><br />Впрочем, тебе конечно же виднее, как оно в Эрланге принято, правда? :DGapertonhttps://www.blogger.com/profile/08723788281409711639noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-71268615600104142382010-10-16T19:16:24.597+03:002010-10-16T19:16:24.597+03:00@gaperton:
>AXD301 был изначально сделан без н...@gaperton:<br /><br /><i>>AXD301 был изначально сделан без них. Это больше, чем 10 лет назад.</i><br /><br />В Java изначально generic-ов не было. Но жизнь показала, что с ними гораздо лучше, чем без оных.<br /><br />Появление исключений в Erlang-е доказывает тоже самое.<br /><br /><i>>Всего 3.5 тысячи catch-ей, на все-превсе библиотеки. Учитывая общий размер в 240 мегабайт - это ничего.</i><br /><br />Не нужно мешать штуки с мегабайтами. Поскольку если выбросить оттуда все не Erlang-овое, а следом и комментарии, то получится совсем другая картина.<br /><br /><i>>Ну, ты о практике применения данного стиля судить не можешь, извини.</i><br /><br />Это взаимно, кстати.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-88929648983438924662010-10-16T18:59:10.012+03:002010-10-16T18:59:10.012+03:00> Судя по документации это было сделано в верси...> Судя по документации это было сделано в версии 5.4, т.е. больше 10 лет назад.<br /><br />AXD301 был изначально сделан без них. Это больше, чем 10 лет назад.<br /><br />> Достаточно скачать исходники OTP, заглянуть в каталог lib и поискать catch в erl-файлах. Их там порядочно. А уж в подкаталогах test так вообще как собак.<br /><br />Всего 3.5 тысячи catch-ей, на все-превсе библиотеки. Учитывая общий размер в 240 мегабайт - это ничего.<br /><br />> На практике все оказывается далеко не так радужно.<br /><br />Ну, ты о практике применения данного стиля судить не можешь, извини.Gapertonhttps://www.blogger.com/profile/08723788281409711639noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-78958415484075097452010-10-16T13:47:22.152+03:002010-10-16T13:47:22.152+03:00@gaperton:
>В Эрланге исключения есть, но доба...@gaperton:<br /><br /><i>>В Эрланге исключения есть, но добавлены поздно,</i><br /><br />Судя по документации это было сделано в версии 5.4, т.е. больше 10 лет назад.<br /><br /><i>>и на практике применяются очень редко.</i><br /><br />Достаточно скачать исходники OTP, заглянуть в каталог lib и поискать catch в erl-файлах. Их там порядочно. А уж в подкаталогах test так вообще как собак.<br /><br /><i>>Там рулит подход let-it-crash, при котором ты вообще не пишешь обработки ошибок, и закладываешься только на успешный случай. А когда оно упадет - как бы ни упало - обрабатывается падение процесса, и все.</i><br /><br />На практике все оказывается далеко не так радужно.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-351431671705315502010-10-16T08:20:33.779+03:002010-10-16T08:20:33.779+03:00@Gaperton:
> Насчет Javascript - у него есть с...@Gaperton:<br /><br />> Насчет Javascript - у него есть свои сильные стороны. Ацки гибок благодаря динамике.<br /><br />Вот интересно узнать юз кейсы этой гибкости.<br /><br />@Left:<br /><br />с какими проблемами мы столкнемся при реализации удобных go-routines на с++ ?<br /><br />(возможно, это тянет на пост, а не на комменты)имяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-92075228280522791462010-10-16T08:13:46.968+03:002010-10-16T08:13:46.968+03:00@gaperton:
и как же будет выглядеть фрагмент того...@gaperton:<br /><br />и как же будет выглядеть фрагмент того кода с исключениями на go? в частности, что будет go-routine? <br /><br />предполагается, что функция traffic_from_line -- библиотечная; варианты ее использования различны, и она не знает, запаниковать ли после появления одной нераспарсенной строки, 10, или не менее одной в каждом файле -- поэтому она не может быть <br />единственной go-routine<br /><br />таким образом, придется форвардить неудачу как в обычном языке без исключений, и паника тут не поможет... или в go есть специальный механизм, позволяющий *однократно* задать *окончательный* обработчик паники через цепочку вызова go-routines, а не форвардить панику?имяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-69801262233697306882010-10-15T23:18:05.922+03:002010-10-15T23:18:05.922+03:00Да, подход let-it-crash получается проще исключени...Да, подход let-it-crash получается проще исключений благодаря тому, что код обработки ошибок получается полностью изолирован от функционального кода, выполняющего работу. И стратегией обработки ошибок управлять проще.Gapertonhttps://www.blogger.com/profile/08723788281409711639noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-63172138737156860462010-10-15T23:15:11.531+03:002010-10-15T23:15:11.531+03:00В Эрланге исключения есть, но добавлены поздно, и ...В Эрланге исключения есть, но добавлены поздно, и на практике применяются очень редко.<br /><br />Там рулит подход let-it-crash, при котором ты вообще не пишешь обработки ошибок, и закладываешься только на успешный случай. А когда оно упадет - как бы ни упало - обрабатывается падение процесса, и все.<br /><br />Потому, что _именно так_ - проще, а не возня с исключениями. И наличие исключений при таком подходе не первостепенно - от них, в действительности, ни жарко, ни холодно.<br /><br />Разумеется, пока ты не пробовал - тебе кажется наличие исключений существенным. Тут уж ничего нельзя поделать.<br /><br />Сильные стороны Go - это многозадачность и ортогональность системы типов. Все языки с традиционной системой типов в реальном серверном дизайне проиграют - в них проектировать сложнее.<br /><br />А со структурами данных нет особой сложности ни в одном языке. Это хорошо инкапсулируется, пишется один раз, и проблемой не является.<br /><br />Насчет Javascript - у него есть свои сильные стороны. Ацки гибок благодаря динамике.Gapertonhttps://www.blogger.com/profile/08723788281409711639noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-317870362118294232010-10-15T21:49:08.959+03:002010-10-15T21:49:08.959+03:00>Особенно, если речь идет о серверной разработк...<i>>Особенно, если речь идет о серверной разработке, и о сложной и объемной системе.</i><br /><br />В сложных системах зачастую нужны сложные структуры данных. В качестве тривиального примера -- boost::multi_index. Насколько я помню Go, создать что-то подобное на нем будет гораздо сложнее, чем на D.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-35708460005538496112010-10-15T21:45:27.638+03:002010-10-15T21:45:27.638+03:00>Насчет исключений - при наличии возможности на...<i>>Насчет исключений - при наличии возможности нарезать код на набор горутин, которые могут падать по отдельности, это проблемой не является.</i><br /><br />Само по себе нарезание того, что можно не нарезать, уже является проблемой. Даже в Erlang-е не нужно нарезать без серьезной надобности - там как раз <a href="http://www.erlang.org/doc/reference_manual/expressions.html#catch" rel="nofollow">исключения есть</a>.<br /><br /><i>>Скажем, я однозначно предпочел бы Go Javascript-у. И, вероятно, во многих случаях - С/C++. На Go элементарно приятнее писать.</i><br /><br />Я противопоставлял Go не JavaScript-у (на котором бы вообще не стал программировать по собственной воле), и даже не C++. Если выбирать между Go и D, то я бы предпочел D.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-31870370683879150702010-10-15T21:20:31.951+03:002010-10-15T21:20:31.951+03:00Особенно, если речь идет о серверной разработке, и...Особенно, если речь идет о серверной разработке, и о сложной и объемной системе.<br /><br />"Ортогональность" Go, в сочетании с поддержкой многозадачности - это очень сильные стороны.Gapertonhttps://www.blogger.com/profile/08723788281409711639noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-76077700187445304142010-10-15T21:16:49.883+03:002010-10-15T21:16:49.883+03:00Насчет исключений - при наличии возможности нареза...Насчет исключений - при наличии возможности нарезать код на набор горутин, которые могут падать по отдельности, это проблемой не является. Left про это написал. <br /><br />Такой стиль хорошо знаком программирующим на эрланге, этот паттерн обработки ошибок называется "supervision tree". И он без проблем повторяется в Go.<br /><br />Суть в том, что сложное действие иерархически бьется на дерево более мелких (посредством иерархии процессов или, для Go - горутин), каждое из которых может "упасть", и в этом случае применяется некоторая стратегия обработки ошибки.<br /><br />Понятное дело, что другим разработчикам этот стиль незнаком, ибо он крайне непрактичен при отсутствии "легкой многозадачности".<br /><br />Насчет отсутствия генериков - это, конечно, неприятно.<br /><br />Но на мой взгляд - положительных качеств у языка достаточно, чтобы это уравновесить.<br /><br />И это именно редкое сочетание выразительных возможностей и простоты.<br /><br />Скажем, я однозначно предпочел бы Go Javascript-у. И, вероятно, во многих случаях - С/C++. На Go элементарно приятнее писать.Gapertonhttps://www.blogger.com/profile/08723788281409711639noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-17194491498690060992010-10-15T07:46:47.718+03:002010-10-15T07:46:47.718+03:00@имя
Там где есть АлгТД в таком коде не будет цикл...@имя<br />Там где есть АлгТД в таком коде не будет циклов, в худшем случае будет вложенная рекурсивная функция исключение заменится обычным возвратом. А так скорее всего будет соответствующая ФВП типа take_while.<br /><br />Хотя я не против исключений, пользы от них точно больше чем вреда, при умеренном использовании конечно.Rustamhttps://www.blogger.com/profile/17746482246614094380noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-38491328529039509212010-10-14T19:54:29.866+03:002010-10-14T19:54:29.866+03:00вот цитата из ответа gaperton-a, ставящая крест на...вот цитата из ответа gaperton-a, ставящая крест на языке до тех пор, пока не сделают дженерики И НЕ ПЕРЕПИШУТ ЛИБЫ ПОД НИХ (в яве это заняло считай 10 лет):<br /><br />> Насколько там распространён "downcast" когда при компиляции есть некий абстракный object, котор<br />99;й приводится к конкретному интерфейсу?<br /><br />Настолько же, как в ранней яве. Абстрактный Object здесь является пустым интерфейсом, interface{}. Так как генериков-шаблонов _пока_ нет, даункаст будет встречаться часто. Генерики обещали добавить.имяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-25080887466943052892010-10-14T19:19:55.538+03:002010-10-14T19:19:55.538+03:00исключения нужны даже при наличии АлгТД и возможно...исключения нужны даже при наличии АлгТД и возможности возвращать АлгТД из функции<br /><br />кто поймет, смотрите 2 куска кода -- без исключений ошибку требуется форвардить изнутри наружу цикла, а с иключениями не надо (а вообще надо статью накатать)<br /><br />LogFile lf; int traffic=0; bool bad=false;<br /><br />while(lf.next_line() ) {<br /> int* i = lf.traffic_from_line();<br /> if(i){<br /> traffic+=*i;<br /> }else{<br /> bad=true; <br /> break;<br /> } <br />}<br /><br />if(bad)<br /> ...<br />}else{<br /> ...<br />}<br /><br />LogFile lf; int traffic=0;<br /><br />try{ <br /> while( lf.next_line() ){<br /> traffic += lf.traffic_from_line();<br /> }<br />}catch(ParseError){<br /> ...<br />}else{ ///это не с++, а в стиле питона<br /> ...<br />}имяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-62004688983750683022010-10-14T18:42:06.225+03:002010-10-14T18:42:06.225+03:00@Left: как в go c типами, параметризованными други...@Left: как в go c типами, параметризованными другим типом и числом? Можно ли там сделать myvector< int >, myarray< 3 > ?имяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-16494375169196809032010-10-14T17:24:49.765+03:002010-10-14T17:24:49.765+03:00>Дело в том что на гоувских каналах это в разы ...<i>>Дело в том что на гоувских каналах это в разы проще чем на с/c++-ных примитивах синхронизации.</i><br /><br />С использованием исключений этого вообще делать не придется.<br /><br /><i>>А запуск в отдельной горутине к тому же позволит всей этой "неважной" математике считаться на отдельном процессоре.</i><br /><br />Чтобы отгрести проблем с не thread-safe кодом? ;)eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-13770631005039184072010-10-14T17:23:31.490+03:002010-10-14T17:23:31.490+03:00>Скажу честно - не знаю. Скорее всего для натив...<i>>Скажу честно - не знаю. Скорее всего для нативных библиотек пишется ручками. Наверное именно поэтому сопряжение с нативным кодом в Go куда более сложное чем в том же С.</i><br /><br />Я думал, что сопряжение сложнее из-за GC, а не блокирующих операций.<br /><br />И что-то мне не верится про перевод блокирующих операций в разряд асинхронных с освобождением текущей нити для следующей goroutine. Для нативного языка это не есть гуд.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.com