там вы декларативно (а не императивно) описываете интерактивность что позволяет с легкостью реализовать это в любом функциональном языке
кстати, WPF/XAML в .NET 3 живой пример этому (Bindings в XAML это FRP), ведь XAML это вполне себе декларативный язык, многое можно сделать в нём даже без императивного code behind
>> Вы опять подходите из того, что в начале инструмент - потом архитектура программы.
для меня в начале инструмент, а уже потом всё остальное, т.к. я не сторонник RUP и подобных дисциплин "сначала всё-всё проектируем на бумажках, потом рендерим наши мега-blueprint'ы любым подходящим инструментом"
когда работаешь над постоянно меняющимся прототипом гибкость инструмента неоценима, с плохим инструментом просто пропадает мотивация и желание что-то делать
я вам вполне понятным языком ответил, почему "C++ это не быстро" и как применяется ленивость
поинтересуюсь, кстати: у вас есть опыт разработки софта на C++ или вы про него только слышали?
>> с учетом «код из своих проектов я выкладывать в public domain не собираюсь»
ну, охуенная аргументация вообще: "покажи код нет да тебе стыдно!"
детский сад
>> мне в ответ начали гнать
«не хами, парниша»
от вас я еще не услышал ни одного вопроса или ответа по существу, кроме повторяющихся из поста в пост выпадов в сторону личности собеседника перечитайте еще раз свои посты, это типичный приём троллей
можете и дальше продолжать "плакать, колоться и лезть на кактус", как те ежики из анекдота адекватные люди меня услышали, с вами же мне говорить не о чем
код из своих проектов я выкладывать в public domain не собираюсь
но охотно расскажу, как именно ленивость применяется в реальном коде
представьте себе работу с очень большой или вообще бесконечной (ну например граф с циклами) структурой данных
в моей практике типичный паттерн с ними был такой как-то обработать и отфильтровать (выборка)
в императивном языке обычно делают так — для выборки используется «паттерн» визитор, в визитор передается функция, которая обрабатывает
то есть, получается IoC (inversion of control) а это жуня, т.к. приходится выворачивать flow кода наизнанку, а вместе с ним и мозг (когда читаешь такой код)
в Haskell же ленивость позволяет обойтись без IoC в коде (фактически, ленивость это такой power abstraction над IoC) что пишешь, то и получаешь, и не паришься о том, что структура данных может быть гигантской или бесконечной
пример, который я привел именно это и показывает, просто вы не хотите это видеть, вы видите в нём не содержание, а форму (множество простых чисел, бла-бла-бла) :/
>> что все их «достоинства» лежат строго в вашем воображении?
по-моему, они очевидны такой код хорошо пишется, хорошо читается и хорошо компилируется
разве можно желать бОльшего?
и это не серебряная пуля (никто не называл это так) просто потому, что это классическая дырявая абстракция (по Джоэлу)!
>> изучая теорию «функционального программирования»
теория ФП (а точнее, теоретическая основа) это лямбда-исчисление
>> что очень много программировал на «функциональном языке» ECMAScript, он же JavaScript
это из-за того что вы путаете intrinsically functional язык (Haskell, ML-семейство) и императивный язык, позволяющий программировать функционально (коим являются JavaScript, Python и еще много разных)
их интерпретаторы совсем разные, они по-разному видят программу (Haskell - это синтаксический сахар над типизированым лямбда-исчислением, JavaScript - это в разы более сложный в математическом смысле язык, и за ним не стоит никакого строгого математического фундамента, это просто ad-hoc каша неудивительно, что это толком никак не оптимизируется)
строго говоря, JavaScript - даже близко не функциональный язык, несмотря на то, что он выглядит местами, как функциональный
>> и расскажите поподробнее про заблуждение «С++ — это быстро», я хочу чтобы у меня открылись глаза :)
да чего стоит только забыть поставить "&" и передать аргумент по значению, а не по ссылке
я уже не говорю про чудовищный менеджмент памяти (new/delete), который при наивном использовании STL или любых других RAII-объектов вам зафрагментирует кучу так, что потом и два байта не выделить (в особо запущенных случаях)
только не надо сейчас загибать пальцы и рассказывать про то, что руки должны расти из правильного места C++ это язык не для людей, а для мутантов с многолетним опытом наступания на грабли в этом самом C++, вроде меня и, знаете, я этим совсем не горжусь; мне жалко, что я убил несколько лет жизни на ковыряние в говне.
>> к тому же map — это цикл «в один конец», в нем невозможно сделать break, любой if внутри map превращает код в нечитаемый кошмар
map это не цикл, и в нем не требуется делать "break" и "if"
и какой такой нечитаемый кошмар? не будьте голословны приведите пример, где вы увидели нечитаемый кошмар
вы сейчас пытаетесь проецировать свой опыт программирования в императивных языках так ничего не выйдет
там программируют по-другому
объяснять здесь, как именно я не собираюсь, почитайте SICP или какой-нибудь "Yet Another Haskell Tutorial", на худой конец; напишите какую-нибудь несложную софтину на Haskell, и тогда можно будет о чем-то конструктивно говорить, а сейчас наша дискуссия по сути бессмысленный флейм
это что-то вроде интро
пример кода был дан чтобы показать мощь pattern matching для декомпозиции структур данных / мульти-диспатча на Erlang только так и программируют
посмотрите, к примеру, Functional Reactive Programming есть даже JavaScript-фреймворк в этой парадигме (FLAPJAX)
там вы декларативно (а не императивно) описываете интерактивность что позволяет с легкостью реализовать это в любом функциональном языке
кстати, WPF/XAML в .NET 3 живой пример этому (Bindings в XAML это FRP), ведь XAML это вполне себе декларативный язык, многое можно сделать в нём даже без императивного code behind
пальцы мешают в двери офиса проходить, наверное
кому-то приходится разрабатывать проекты с нуля — здесь эффективность прототипирования имеет решающее значение
>> Дескать так и так, мне пофиг что я пишу, для кого я пишу, зачем я пишу и правильно ли я пишу
вы не дружите с логикой
просто виндоус уродует их хинтингом для чёткости, при этом теряется оригинальная форма
контроверсия ключ к успеху
без этого хороший пост не написать
плюсов вам не избежать
P.S. я "стартапер" и немного обижен тем, как вы подвели всех под одну гребёнку
для меня в начале инструмент, а уже потом всё остальное, т.к. я не сторонник RUP и подобных дисциплин "сначала всё-всё проектируем на бумажках, потом рендерим наши мега-blueprint'ы любым подходящим инструментом"
когда работаешь над постоянно меняющимся прототипом гибкость инструмента неоценима, с плохим инструментом просто пропадает мотивация и желание что-то делать
а вообще я удивлен, что в ВУЗах уже преподают Haskell прогресс, не иначе
поинтересуюсь, кстати: у вас есть опыт разработки софта на C++ или вы про него только слышали?
>> с учетом «код из своих проектов я выкладывать в public domain не собираюсь»
ну, охуенная аргументация вообще: "покажи код нет да тебе стыдно!"
детский сад
>> мне в ответ начали гнать
«не хами, парниша»
от вас я еще не услышал ни одного вопроса или ответа по существу, кроме повторяющихся из поста в пост выпадов в сторону личности собеседника перечитайте еще раз свои посты, это типичный приём троллей
можете и дальше продолжать "плакать, колоться и лезть на кактус", как те ежики из анекдота адекватные люди меня услышали, с вами же мне говорить не о чем
заблуждение в чем? сдается мне, вы заблуждаетесь в том, что я заблуждаюсь
я ведь не утверждал, что какой-то конкретный интерпретатор умеет делать какое-то конкретное преобразование кода
так что советую вам отбросить ваши необоснованные домыслы насчет того, что есть что в моём представлении
я люблю C он почти совершенен (семантически), хоть синтаксис там и корявоватый местами
а вот C++ это уродливое говно "ни о чём" хоть оно может быть очень удобным, если правильно его готовить
но говно оно исключительно потому, что его очень сложно научиться готовить, это прямое следствие из корявости языка
в терминах Сполски, это на порядки более дырявая абстракция, чем Haskell слишком легко написать код с непредсказуемым поведением
но охотно расскажу, как именно ленивость применяется в реальном коде
представьте себе работу с очень большой или вообще бесконечной (ну например граф с циклами) структурой данных
в моей практике типичный паттерн с ними был такой как-то обработать и отфильтровать (выборка)
в императивном языке обычно делают так — для выборки используется «паттерн» визитор, в визитор передается функция, которая обрабатывает
то есть, получается IoC (inversion of control) а это жуня, т.к. приходится выворачивать flow кода наизнанку, а вместе с ним и мозг (когда читаешь такой код)
в Haskell же ленивость позволяет обойтись без IoC в коде (фактически, ленивость это такой power abstraction над IoC) что пишешь, то и получаешь, и не паришься о том, что структура данных может быть гигантской или бесконечной
пример, который я привел именно это и показывает, просто вы не хотите это видеть, вы видите в нём не содержание, а форму (множество простых чисел, бла-бла-бла) :/
>> что все их «достоинства» лежат строго в вашем воображении?
по-моему, они очевидны такой код хорошо пишется, хорошо читается и хорошо компилируется
разве можно желать бОльшего?
и это не серебряная пуля (никто не называл это так) просто потому, что это классическая дырявая абстракция (по Джоэлу)!
теория ФП (а точнее, теоретическая основа) это лямбда-исчисление
>> что очень много программировал на «функциональном языке» ECMAScript, он же JavaScript
это из-за того что вы путаете intrinsically functional язык (Haskell, ML-семейство) и императивный язык, позволяющий программировать функционально (коим являются JavaScript, Python и еще много разных)
их интерпретаторы совсем разные, они по-разному видят программу (Haskell - это синтаксический сахар над типизированым лямбда-исчислением, JavaScript - это в разы более сложный в математическом смысле язык, и за ним не стоит никакого строгого математического фундамента, это просто ad-hoc каша неудивительно, что это толком никак не оптимизируется)
строго говоря, JavaScript - даже близко не функциональный язык, несмотря на то, что он выглядит местами, как функциональный
>> и расскажите поподробнее про заблуждение «С++ — это быстро», я хочу чтобы у меня открылись глаза :)
да чего стоит только забыть поставить "&" и передать аргумент по значению, а не по ссылке
я уже не говорю про чудовищный менеджмент памяти (new/delete), который при наивном использовании STL или любых других RAII-объектов вам зафрагментирует кучу так, что потом и два байта не выделить (в особо запущенных случаях)
только не надо сейчас загибать пальцы и рассказывать про то, что руки должны расти из правильного места C++ это язык не для людей, а для мутантов с многолетним опытом наступания на грабли в этом самом C++, вроде меня и, знаете, я этим совсем не горжусь; мне жалко, что я убил несколько лет жизни на ковыряние в говне.
>> к тому же map — это цикл «в один конец», в нем невозможно сделать break, любой if внутри map превращает код в нечитаемый кошмар
map это не цикл, и в нем не требуется делать "break" и "if"
и какой такой нечитаемый кошмар? не будьте голословны приведите пример, где вы увидели нечитаемый кошмар
вы сейчас пытаетесь проецировать свой опыт программирования в императивных языках так ничего не выйдет
там программируют по-другому
объяснять здесь, как именно я не собираюсь, почитайте SICP или какой-нибудь "Yet Another Haskell Tutorial", на худой конец; напишите какую-нибудь несложную софтину на Haskell, и тогда можно будет о чем-то конструктивно говорить, а сейчас наша дискуссия по сути бессмысленный флейм
смотреть надо проще :)