tag:blogger.com,1999:blog-654279083390275842.post349570436338980283..comments2024-03-19T12:22:43.654+03:00Comments on Размышлизмы eao197: [prog] Презентация Мартина Одерски State of Scala с конференции Scala Days 2011eao197http://www.blogger.com/profile/17283739752119445290noreply@blogger.comBlogger47125tag:blogger.com,1999:blog-654279083390275842.post-1883844797874542192011-09-24T07:24:46.265+03:002011-09-24T07:24:46.265+03:00@Евгений Охотников
И если от п.1 никуда не денешь...@Евгений Охотников<br /><br /><i>И если от п.1 никуда не денешься (даже переход с C на Питон этого требует и происходит не сразу), то вот по поводу п.2 я уверен в том, что будь и флагманских ФЯ более привычный синтаксис, то мало потеряв в "выразительности", они бы больше приобрели в популярности</i><br /><br />По моему это или никак, или очень мало влияет на популярность, что и показывают например Scala, Немерле и Dylan.<br />Просто на фоне первого пункта второй требует на порядок меньше усилий на освоение.Rustamhttps://www.blogger.com/profile/17746482246614094380noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-65490911574333129902011-09-23T15:44:53.045+03:002011-09-23T15:44:53.045+03:00я надеюсь, что скоро они выложат его...я надеюсь, что скоро они выложат его...Alex Otthttps://www.blogger.com/profile/13001951608173211050noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-54547173779479576592011-09-23T15:42:44.813+03:002011-09-23T15:42:44.813+03:00@Alex Ott:
>Мой опыт (включая наблюдение за ра...@Alex Ott:<br /><br /><i>>Мой опыт (включая наблюдение за разными людьми) показывает, что изучение новых языков (точнее подходов к программированию), всегда себя оправдывало с точки зрения производительности разработчика - более ясного кода, меньше багов и т.д.</i><br /><br />Поднял эту тему в отдельной заметке: http://eao197.blogspot.com/2011/09/progflame.html<br /><br /><i>P.S. на YaC2011 был хороший доклад Алексея Воинова (мы вместе работали когда-то) на эту тему - посмотрите</i><br /><br />Пока не нашел этого выступления. Ни видео, ни текста :(eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-48577685026817123482011-09-23T13:03:14.379+03:002011-09-23T13:03:14.379+03:00> А зачем? Чем не устраивает генерация кода из ...<i> > А зачем? Чем не устраивает генерация кода из структуры БД?<br /><br />ыыыы! прочти тред еще раз</i><br /><br />Там, в основном, бред. Что именно надо почитать? А лучше просто скажи, чем не устраивает генерация кода из БД?<br /><br /><i>> а для чего в гуе рефлексия и атрибуты?<br /><br />нда... <br /><br />чтобы делать гуй программно</i><br /><br />Даже не могу себе представить, как это выглядит. Это можно использовать для загрузки гуя из описания, но при чем тут программный гуй?<br /><br /><i>тааак... значит, там на сишарпе писали не только гуй?</i><br /><br />Дак на нем среду разработки делают (создание/редактирование проектов, интеграция с компиляторами/симулятором/отладчиком). <br /><br /><i>так или иначе, сишарпа должно хватать для гуя даже с небольшой логикой</i><br /><br />Вот только на это его и хватает.<br /><br /><i>я не очень уверен, но по-моему ты неправ, активно различая персистентные структуры данных и отсутствие побочных эффектов</i><br /><br />Из 2-го следует первое, но не наоборот.<br /><br /><i>если их следует различать, приведи пример</i><br /><br />DiffArray.<br /><br /><i> > Этот DDC пилят уже достаточно давно, но вроде как он до сих пор сырой и экспериментальный.<br /><br />из чего не надо делать вывод про системы эффектов</i><br /><br />А я и не делал никаких выводов. Просто оно пока еще слишком сыро и узко, чтобы вставлять.<br /><br /><i>то, что монада ИО, призванная защищать от неверных действий, не дает выполнить верные -- с моей точки зрения приговор для хаскеля;</i><br /><br />Верные -- это какие?<br /><br /><i>если у нас есть алгоритм, в императивной форме юзающий побочный эффект в Х, то мы можем сделать его чистым, если Х будем передавать доп. параметром туда, кому побочный эффект нужен, и сделаем Х персистентным для тех, кому видеть побочный эффект не надо</i><br /><br />Передавать параметром эффект? Что-то не понял<br /><br /><i>система эффектов -- это must have современного языка</i><br /><br />А можно пример такой системы эффектов?Vladimir Shabanovhttps://www.blogger.com/profile/14322574042735481057noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-74051648593966047992011-09-23T10:35:06.040+03:002011-09-23T10:35:06.040+03:00@Rustam:
Особенности синтаксиса есть везде. Речь ...@Rustam:<br /><br />Особенности синтаксиса есть везде. Речь о другом. Если человеку, который знает, скажем, Паскаль, дать кусок алгоритма, реализованного на C++ или C#, то паскалист хотя бы в общих чертах будет понимать, какие действия выполняются в этом куске -- циклы, вызовы функций и пр.<br /><br />Поэтому то переходы с Паскаля на С, затем на C++, после чего на Java/C# -- это лишь уточнение и привыкание к некоторым деталям.<br /><br />Переход же с какой-нибудь Java на функциональный язык (из ML семейства) требует намного больших училий из-за двух вещей:<br />1. Думать нужно по другому (но чтобы научиться думать по другому требуется много времени).<br />2. Привыкнуть к синтаксису.<br /><br />И если от п.1 никуда не денешься (даже переход с C на Питон этого требует и происходит не сразу), то вот по поводу п.2 я уверен в том, что будь и флагманских ФЯ более привычный синтаксис, то мало потеряв в "выразительности", они бы больше приобрели в популярности.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-5788674214779871482011-09-23T09:56:15.543+03:002011-09-23T09:56:15.543+03:00@Евгений Охотников
В питоне сразу проявляются бло...@Евгений Охотников<br /><br />В питоне сразу проявляются блоки кода и утиная типизация, и очень быстро сильно отличная от тех же С++/C# объектная система.Rustamhttps://www.blogger.com/profile/17746482246614094380noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-88911697192451941752011-09-23T09:53:21.914+03:002011-09-23T09:53:21.914+03:00@Евгений Охотников
Ну вот, для тех кто уже в теме...@Евгений Охотников<br /><br /><i>Ну вот, для тех кто уже в теме f a b = (f a) b. А для начинающих это постоянное выяснение -- "f(a, b)", "(f(a))(b)", "f(a(b))", f().a().b() и т.д.<br /><br />В ФП и так заморочек хватает, а тут еще и синтаксис к которому привыкать нужно. В общем, нужно сильно хотеть, чтобы сквозь это все продираться при обучении.</i><br /><br />В ML образных это не просто синтаксис а одна из базовых вещей которые необходимо изучать в первую очередь.<br /> <br />В сишном синтаксисе не говоря уже о C++, тоже кстати заморочек хватает, взять хотя бы такую тоже вполне базовую вещь как объявление не тривиальных типов указателей.Rustamhttps://www.blogger.com/profile/17746482246614094380noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-498990754397065122011-09-23T09:51:17.606+03:002011-09-23T09:51:17.606+03:00@Rustam:
>Ну есть же пример того же питона тож...@Rustam:<br /><br /><i>>Ну есть же пример того же питона тоже с весьма своеобразными блоками и видимостью, который сишники осваивают без проблем и быстро.</i><br /><br />Может потому, что эти своеобразные правила не сразу проявляются? Что-то я не припомню, чтобы в простых программах на Питоне были заморочки по поводу объявления переменных.<br /><br />Ну и Питон - все-таки больше императивный язык :)eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-560632333606067282011-09-23T09:46:11.418+03:002011-09-23T09:46:11.418+03:00Насчет Прототип гуя был сделан на хаскеле за 3-4 м...Насчет <i>Прототип гуя был сделан на хаскеле за 3-4 месяца. Аналогичного функционала на C# потом не могли добиться где-то 1.5 года (бОльшим кол-вом народа).</i> это нормально, даже если прототип и релиз на одном и том же языке. Если прототип по трудоемкости не отличается на порядок в более легкую сторону от релиза это уже не прототип по моему.Rustamhttps://www.blogger.com/profile/17746482246614094380noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-91017002519695291752011-09-23T09:42:09.113+03:002011-09-23T09:42:09.113+03:00@Евгений Охотников
Поскольку замшелый императивщ...@Евгений Охотников <br /><br /><i>Поскольку замшелый императивщик может привыкнуть, скажем, к OCaml-овским let x = y in ...<br />Только понять почему это должно настолько сильно отличаться от C-шного стиля декларирования сущностей внутри блока не сможет.</i><br /><br />Ну есть же пример того же питона тоже с весьма своеобразными блоками и видимостью, который сишники осваивают без проблем и быстро.Rustamhttps://www.blogger.com/profile/17746482246614094380noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-16264549641178203952011-09-23T03:26:58.445+03:002011-09-23T03:26:58.445+03:00> Этот DDC пилят уже достаточно давно, но вроде...> Этот DDC пилят уже достаточно давно, но вроде как он до сих пор сырой и экспериментальный.<br /><br />из чего не надо делать вывод про системы эффектов<br /><br />этот DDC пилят настолько редко, что я не нашел там человеческого (а не обзорного) описания их системы эффектов<br /><br />то, что монада ИО, призванная защищать от неверных действий, не дает выполнить верные -- с моей точки зрения приговор для хаскеля; я однозначно ему предпочту с++, который, хотя и не защищает в ряде случаев, все же дает возможность сделать правильно, когда это надо<br /><br />система эффектов -- это must have современного языкаимяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-59093057119394571602011-09-23T03:14:17.509+03:002011-09-23T03:14:17.509+03:00я не очень уверен, но по-моему ты неправ, активно ...я не очень уверен, но по-моему ты неправ, активно различая персистентные структуры данных и отсутствие побочных эффектов<br /><br />если их следует различать, приведи пример<br /><br />если у нас есть алгоритм, в императивной форме юзающий побочный эффект в Х, то мы можем сделать его чистым, если Х будем передавать доп. параметром туда, кому побочный эффект нужен, и сделаем Х персистентным для тех, кому видеть побочный эффект не надо<br /><br />обатное утверждение, кмк, тоже верно, хотя я и не уверенимяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-26700899046316745252011-09-23T02:50:29.989+03:002011-09-23T02:50:29.989+03:00> А зачем? Чем не устраивает генерация кода из ...> А зачем? Чем не устраивает генерация кода из структуры БД?<br /><br />ыыыы! прочти тред еще раз<br /><br />> а для чего в гуе рефлексия и атрибуты?<br /><br />нда... <br /><br />чтобы делать гуй программно<br /><br />>Действительно, квалификация была ниже, <br /><br />вот и выплывают настоящие причины<br /><br />>да еще и нужно было использовать упомянутую выше ООБД.<br /><br />весело там у вас<br /><br /><br />> а вот логику писать там долго<br /><br />тааак... значит, там на сишарпе писали не только гуй?<br /><br />так или иначе, сишарпа должно хватать для гуя даже с небольшой логикой<br /><br />> грубая сила / тупая работа занимают время.<br /><br />но зачастую это быстрее или даже выгоднее, учитывая квалификацию разрабов<br /><br />часто тупая работа решает, например нажать 100 раз на клавишу вместо того, чтобы выяснить, как записать макрос, записать клавиатурный макрос вместо программирования функции, ... вплоть до твоих случаев<br /><br />я не говорю, что так должно продолжаться и дальше, но это реальностьимяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-47107608564911782202011-09-23T00:01:17.320+03:002011-09-23T00:01:17.320+03:001. см. чуть выше; я например считаю, что персистен...<i>1. см. чуть выше; я например считаю, что персистентностью надо управлять не только компилятору, но и программисту -- он может затребовать, сколько thunk-ов может висеть в памяти и т.п., а еще может даже написать свой оптимизированный вариант персистентной коллекции *специально* для данного юз кейса</i><br /><br />Вообще, в хаскеле есть strictness annotation-ы и форсирование вычислений, а также переменные. Т.е. не хочешь thunk-ов и персистентости -- пожалуйста.<br /><br /><i>дальше -- вообще все то, что в планах у одерски :-)</i><br /><br />А что, например? Я мельком просмотрел презентацию -- многое из того, что там только в планах или только-только появилось, в хаскеле есть уже достаточно давно.<br /><br /><i>вот например стандарный прокол хаскеля из-за отсутствия системы эффектов: http://www.haskell.org/haskellwiki/DDC/EffectSystem</i><br /><br />Системы эффектов -- очень экспериментальная вещь. Есть отдельные языки с эффектами, но в них обычно кроме эффектов ничего толком нет. Этот DDC пилят уже достаточно давно, но вроде как он до сих пор сырой и экспериментальный. <br /><br />В хаскеле еще много чего нет (тех же зависимых типов, например), но не стоит называть это проколом. Хаскелл все-таки очень практичный язык, и туда стараются добавлять только то, что действительно облегчит жизнь большому кол-ву людей (хотя многие штуки достаточно экспериментальные).<br /><br /><i>короче: основной профит ФП это персистентность</i><br /><br />это профит чистых структур данных, для которых фп необязателен.<br /><br /><i>опять-таки, вовсе не всегда именно персистентность нужна для распараллеливания;</i><br /><br />Для распараллеливания хорошо отсутствие побочных эффектов, из-за которых становится важным порядок выполнения.<br /><br /><i>например, откат транзакции может делаться через (персистентно) сохраненившуюся копию, а может делаться через алгебраически обратную операцию -- и тут ваш хаскель кмк спасует</i><br /><br />Почему-же спасует? Ничто не мешает сделать обратную операцию.<br /><br /><i>> Аналогичного функционала на C# потом не могли добиться где-то 1.5 года (бОльшим кол-вом народа).<br /><br />не поверю, что причина в языке -- скорее, в существенно низшей квалификации разрабов</i><br /><br />Действительно, квалификация была ниже, да еще и нужно было использовать упомянутую выше ООБД. Однако, кроме гуя, там хватает логики (делается IDE с симулятором/отладчиком и пр.), а вот логику писать там долго (да и с гуем большие проблемы из-за того, что народ очень любит гуй в дизайнере делать, а не программно).<br /><br /><i>да и не нужно нихрена вообще для лепки интерфейсов, кроме рефлексии и атрибутов</i><br /><br />а для чего в гуе рефлексия и атрибуты?<br /><br /><i>да, могут быть идеи, которые в сишарпе не выражаются (точнее, сишарп их верифицировать не сможет), но при лепке интерфейсов это преодолевается грубой силой / тупой работой</i><br /><br />грубая сила / тупая работа занимают время.<br /><br /><i>вот ты лучше скажи, как сделать аналоги аннотаций в хаскеле: http://www.linux.org.ru/forum/development/4550090</i><br /><br />А зачем? Чем не устраивает генерация кода из структуры БД?Vladimir Shabanovhttps://www.blogger.com/profile/14322574042735481057noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-35677062433005964132011-09-22T20:14:11.705+03:002011-09-22T20:14:11.705+03:00s/(в т.ч. языков)/(в т.ч. языковых)/s/(в т.ч. языков)/(в т.ч. языковых)/имяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-22342149181005084022011-09-22T20:11:35.194+03:002011-09-22T20:11:35.194+03:00> Аналогичного функционала на C# потом не могли...> Аналогичного функционала на C# потом не могли добиться где-то 1.5 года (бОльшим кол-вом народа).<br /><br />не поверю, что причина в языке -- скорее, в существенно низшей квалификации разрабов<br /><br />в сишарпе достаточно возможностей (в т.ч. языков), чтобы лепить интерфейсы; да и не нужно нихрена вообще для лепки интерфейсов, кроме рефлексии и атрибутов<br /><br />да, могут быть идеи, которые в сишарпе не выражаются (точнее, сишарп их верифицировать не сможет), но при лепке интерфейсов это преодолевается грубой силой / тупой работой<br /><br />вот ты лучше скажи, как сделать аналоги аннотаций в хаскеле: http://www.linux.org.ru/forum/development/4550090имяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-51607766812938618152011-09-22T19:55:03.083+03:002011-09-22T19:55:03.083+03:00опять-таки, вовсе не всегда именно персистентность...опять-таки, вовсе не всегда именно персистентность нужна для распараллеливания; например, откат транзакции может делаться через (персистентно) сохраненившуюся копию, а может делаться через алгебраически обратную операцию -- и тут ваш хаскель кмк спасуетимяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-22282320356817146842011-09-22T19:50:35.480+03:002011-09-22T19:50:35.480+03:00@Alex Ott:
изучение новых подходов -- да, весьма ...@Alex Ott:<br /><br />изучение новых подходов -- да, весьма оправдано, но не для обычного разработчика, а скорее для разработчика ЯП<br /><br />когда и если будет сделан язык, позволящий в рамках привычного синтаксиса выражать новые подходы, эти подходы будет оправдано изучать обычным разработчикам<br /><br />(это я не к тому, чтобы поменьше писать в блогах о пользе новых подходов -- как раз об этом писать надо побольше)<br /><br />@dsorokin<br /><br />> Вот, возможность повторно использовать существующие значения и есть это самое. Если бы не было иммутабельности, то такой возможности бы не было.<br /><br />такая возможность есть и без иммутабельности (через коллекции с поддержкой персистентности), и именно в этом я вижу реалистичную и перспективную идею одерского<br /><br />@Vladimir Shabanov<br /><br />> Интересно. А что там надо серьезно переделывать?<br /><br />1. см. чуть выше; я например считаю, что персистентностью надо управлять не только компилятору, но и программисту -- он может затребовать, сколько thunk-ов может висеть в памяти и т.п., а еще может даже написать свой оптимизированный вариант персистентной коллекции *специально* для данного юз кейса<br /><br />дальше -- вообще все то, что в планах у одерски :-)<br /><br />вот например стандарный прокол хаскеля из-за отсутствия системы эффектов: http://www.haskell.org/haskellwiki/DDC/EffectSystem<br /><br />короче: основной профит ФП это персистентность, но она нужна не всегда, а управляемоимяhttps://www.blogger.com/profile/17115793398497396330noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-50289975973625034252011-09-22T13:10:15.429+03:002011-09-22T13:10:15.429+03:00@Vladimir Shabanov:
>В общем типичный real wor...@Vladimir Shabanov:<br /><br /><i>>В общем типичный real world</i><br /><br />Так в том-то все и дело. Что из-за real world все упирается либо в отсутствие людей, либо в наличие уже существующих наработок, либо в специфику предметной области (из-за которой конкретный язык либо вообще не имеет значения, либо есть выбор только из одного) и т.д.<br /><br />Посему знание, скажем, Haskell-я может быть как Феррари в деревенском сарае -- красиво, но ездить не где.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-12116846804943258002011-09-22T12:33:18.230+03:002011-09-22T12:33:18.230+03:00Но GUI пишут не на хаскеле, а на C# -- таки битие ...<i>Но GUI пишут не на хаскеле, а на C# -- таки битие определяет сознание.</i><br /><br />Это продавленное свыше решение. Прототип гуя был сделан на хаскеле за 3-4 месяца. Аналогичного функционала на C# потом не могли добиться где-то 1.5 года (бОльшим кол-вом народа).<br /><br />У нас в проекте две большие части -- моделирование и рисование схем. Рисование схем делает отдельная команда на C#. По-этому, пришлось и остальную часть гуя делать на C# для однородности.<br /><br />Не стоит радоваться тому, что "вона хаскелисты тоже на C# пишут". Это вынужденная мера. Использование C# всячески ограничивается до уровня "тупой интерпретатор того, что скажет хаскель". И, в целом, C# реально очень сильно тормозит проект.<br /><br />Хотя, кроме C# у нас еще ООБД есть, которая нафиг не нужна, но это идея генерального, так что также вынуждены использовать. Есть часть на java -- VHDL-транслятор, который ужаснейшее глюкало, но его разработчик абсолютно уверен, что java это отличный инструмент. У команды схемного редактора есть еще проблемы с видением/процессами.<br /><br />В общем типичный real world, который может кому-то кажется нормальным, но для меня это местами прямо дикость какая-то. Хотя потихоньку какой-то результат получается, но ооочень потихоньку (с точки зрения хаскелиста).Vladimir Shabanovhttps://www.blogger.com/profile/14322574042735481057noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-71331017192589943512011-09-22T11:54:10.342+03:002011-09-22T11:54:10.342+03:00@Alex Ott:
Ну значит я пример такой обезъяны, кот...@Alex Ott:<br /><br />Ну значит я пример такой обезъяны, которая, тем не менее, успешно устроилась в индустрии и ест хлеб с маслом.<br /><br />Поскольку не могу понять, ни причин использования именно такого вида деклараций переменных/констант в C, ни аналогичных причин для Pascal, ни аналогичных для OCaml. Да и пофигу, если честно. Только вот декларации в C и Pascal оказываются понятнее и привыкать к ним даже не приходится -- раз и все. В отличии от.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-30011958610894415772011-09-22T11:47:23.276+03:002011-09-22T11:47:23.276+03:00Если программист не может понять, то он не програм...Если программист не может понять, то он не программист, а обезьянка, которая делает строго по образцу...<br />В мире куча непривычного - разные культуры и т.п.Alex Otthttps://www.blogger.com/profile/13001951608173211050noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-5491358612528101862011-09-22T11:36:02.441+03:002011-09-22T11:36:02.441+03:00@Alex Ott:
Похоже, тему эту нужно раскрыть в отде...@Alex Ott:<br /><br />Похоже, тему эту нужно раскрыть в отдельной заметке. Поскольку здесь у нас точки зрения, вероятно, довольно сильно отличаются.<br /><br />Но исходный мой посыл остается таковым: если бы в языках, ведущих родословную от ML, применялся более привычный большинству программистов синтаксис, то это сделало бы процесс изучения языка чуть-чуть, но проще. А значит и сами языки были бы привлекательнее.<br /><br />Поскольку замшелый императивщик может привыкнуть, скажем, к OCaml-овским let x = y in ...<br />Только понять почему это должно настолько сильно отличаться от C-шного стиля декларирования сущностей внутри блока не сможет.<br /><br />Большой плюс Scala в этом смысле то, что они у себя этих ML-ных корней не используют настолько сильно. Хотя бы объекты объявляются привычным образом.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-51339439060842154012011-09-22T11:18:23.712+03:002011-09-22T11:18:23.712+03:00Erlang реализует один из подходов к ФП, Хаскель - ...Erlang реализует один из подходов к ФП, Хаскель - другой, и т.д. И в знании обоих нет ничего плохого.<br /><br />Я тоже пишу часть времени на С++, но от того, что я часто применяю приемы из разных ФЯ, код часто короче, ошибок сильно меньше и т.д.Alex Otthttps://www.blogger.com/profile/13001951608173211050noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-70732891037570906662011-09-22T11:06:00.161+03:002011-09-22T11:06:00.161+03:00@Alex Ott:
Вот именно, подходов. C ФП можно позна...@Alex Ott:<br /><br />Вот именно, подходов. C ФП можно познакомиться и на примере Erlang-а с нормальным синтаксисом.<br /><br />Кроме того, сами хаскелисты не могут использовать хаскель для всего. Если не ошибаюсь, Шабанов и Зефиров сейчас в одной конторе работают. Но GUI пишут не на хаскеле, а на C# -- таки битие определяет сознание. И если нужно забивать гвозди, то изучать микроскоп не обязательно :)eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.com