иногда кажется, что свои слова лучше не иллюстрировать
по-вашему, мне стоило написать в комментарии 200 строк реального кода на Haskell, где это используется?
вы же вроде не маленький и понимаете, что это пример такой чтобы читателю камента попроще было, а не потому, что ленивость используется никак иначе, как для перебора простых чисел
как правило, сленговый термин "syntax sugar" используется для обозначения тривиальных преобразований на уровне синтаксиса языка
карринг же в функциональном языке это неотъемлемое (intrinsic) свойство самой семантики языка, а не преобразование на синтаксическом уровне
>> легко реализуется перегрузкой операторов (например) со своими типами
угу, реализуйте карринг перегрузкой операторов :) это невозможно технически
>> поясните что вы имеете в виду под функцией первого класса
я имел ввиду функции, как объекты первого класса это когда в языке функция может прозрачно использоваться в качестве значения
к примеру, в сочетании с каррингом я могу создать новую функцию:
List.intersperse "\n"
и сразу же использовать её в контексте другой функции ">>>"
List.intersperse "\n" >>> concat
все это выражение имеет тип "функция от списка" и я могу применить к нему список:
(List.intersperse "\n" >>> concat) ["здесь", "был", "вася"]
>>ленивые вычисления .. не так часто это и нужно на практике.
тут как бы дело не в том, часто или редко это нужно на практике без этого невозможно написать некоторые программы так, чтобы они завершались
проверяет число на простоту
isPrime n = ...
множество всех простых чисел
primeNumbers = filter isPrime [1..]
три первых простых числа
take 3 primeNumbers
вот эта конструкция [1..] приведет к зависанию в строгом языке
ленивость в общем случае дает возможность писать обобщенно а ограничения (вроде take 3 из примера) устанавливать выше и не протаскивать их сквозь всю программу это невероятно полезно в реальных программах
>> плюс все равно, это эмулируется
а вы уверены, что не пропустили первый пример на C# из статьи? там автор как раз эмулировал функциональный код что получилось? правильно, страшилище
я уже не говорю про, что это жутко неэффективно (в императивной среде компилятор вам такой код не оптимизирует)
>>.. и давления солнечных лучей на мозг заказчика (мы же не для себя код пишем?)
так интересно-то вот что именно в функциональном языке и легче адаптировать код под нужды заказчика
потому что код наиболее близок к определению задачи, а отсутствие побочных эффектов и скрытых зависимостей в коде позволяет при рефакторинге вертеть им (кодом) как угодно и не бояться, что что-то сломается
>> и т.п. продолжу считать синтаксическим сахаром
ну если вы не отличаете синтаксис от семантики, то о чем тут можно спорить вообще
>>... к тому же в соревновании по производительности «интерпетаторы vs. компиляторы»
вы напрасно прицепились к слову «интерпретатор» в комментируемом посте
к примеру, Haskell-код можно интерпретировать, как код на C что и будет тем самым «компилятором» (кстати, рекомендую почитать работы Футамуры Futamura projections для понимания математической связи интерпретаторов, компиляторов и частичных вычислений)
для функциональных языков (и Haskell, в частности) есть сильно оптимизирующие трансляторы в императивный код (и их research до сих пор ведется), обычно используется трансляция в C с последующим скармливанием его gcc
к примеру, программы на строгом ML после трансляции в C не уступают в производительности "рукописному" C-коду даже в числодробительных задачах (ML это как C в функциональном мире)
>> не смотря на всю «оптимизацию и производительность», Eclipse тормозит, сколько бы маркетологи от Sun не рассказывали как «восхитительно эффективна Java»
Eclipse тормозит потому что он сложен включая сложность Java и библиотек на которых Eclipse построен
вот у меня Visual Studio тормозит куда сильнее эклипса, а написано оно вниимание на C++
с циклом я решаю задачу в терминах "аккумулятор, цикл, итерация, условие, etc."
а с Haskell я решаю задачу в терминах задания
>> Просто синтаксис позволяет простые случаи "свернуть"
свернуть позволяет не синтаксис, а семантика языка (функции первого класса, карринг, ленивое вычисление), в языках без этих свойств так "свернуть" не получится
и не простые случаи а любые случаи, т.к. сложные случаи разбиваются на простые
>> В данном случае он тупо создаст мап, удалит пустое, разбавит и склеит.
в данном случае он может частично-вычислить выражение и преобразовать хвостовую рекурсию в цикл получится такой же императивный код, как в примере с C#
>> Представляю себе человека, который, впав в в ступор при виде сложного (для него) кода, не обращается к документации и не спрашивает у коллег, а переписывает код на другом языке и в другой парадигме.
это не тот ступор, о котором вы подумали
>> Так что следующей больщой вещью от Microsoft видимо, будей некий Func#tional
не следующей
>> Ну и, конечно же все те бедолаги-программисты, которые volens-nolens будут вынуждены писать на этом языке "бизнес-приложения"
давайте не будем играть в футурологов
вместе с технологиями меняются и сами люди
15 лет назад мы писали на C и в ус не дули, зато вот сейчас бедолаги-программисты ну прям вынуждены писать на C#, где о, ужас есть generics, лямбды и LINQ
>> разница только в восприятии кода вами (человеков), не более того
а это неправда
разница также в восприятии кода машиной
поскольку функциональный код чётче постулирует задачу машина может более свободно интерпретировать этот код к примеру, распараллелить выполнение или частично-вычислить его или применить еще какие-нибудь продвинутые трансформации
с императивной программой у машины такой свободы нет доступные оптимизации лежат совсем в другой плоскости, на целый уровень ниже
функциональный код фундаментально проще математически
а вам почему-то кажется, что это какая-то синтаксическая надстройка
проблемы тут есть, конечно к примеру, сложно предсказать, как именно будет интерпретирован функциональный код в императивной среде исполнения во многих случаях это неприемлемо (когда требуется максимальная эффективность)
вот только многие люди склонны ставить знак равенства между императивностью и производительностью (например популярно заблуждение "C++ это быстро") а это не так
в императивной среде куда легче сделать говенный супер-неэффективный код (и делают!!!) и машина не сможет его оптимизировать
функциональная же среда намного более толерантна - в ней можно сотней способов сказать одно и то же, но в большинстве случаев все эти способы интерпретируются абсолютно одинаково
>> В отличие от самого переводчика, который повёлся на зомбирующий стиль статьи.
интересно, на что же я повелся? в отличие от вас, я хорошо знаком со всеми языками, о которых говорится в статье и с автором согласен
уровень автора, как программиста вообще никак не сказывается на интересности статьи человек взял и изучил Haskell, от чего у него случился культурный шок
он попробовал с наскоку перенести свой новообретенный опыт в C# ничего не вышло, о чём он и написал
я больше чем уверен, что такая же психологическая проблема настигнет любого с более-менее похожим проф. бэкграундом (C++/Java/C#) после осмысления FP
а вы пытаетесь что-то там увидеть между строк (зомбирующий стиль, etc), ну так давайте, раскройте нам еще одну теорию заговора :D
если переписать код из примера на LINQ то он ничем не будет отличаться от декларативных примеров из статьи, разве что синтаксис понятнее тем, кто работал с SQL
к сожалению, помимо C# мне также приходится использовать множество не-гибридных, классически императивных языков (C/C++, PHP, Java), и не думаю, что ближайшие несколько лет что-то изменится
иногда кажется, что свои слова лучше не иллюстрировать
по-вашему, мне стоило написать в комментарии 200 строк реального кода на Haskell, где это используется?
вы же вроде не маленький и понимаете, что это пример такой чтобы читателю камента попроще было, а не потому, что ленивость используется никак иначе, как для перебора простых чисел
право, смешно
разумеется, не встречали ведь в вашей практике не было Haskell
синтаксический сахар over what?
как правило, сленговый термин "syntax sugar" используется для обозначения тривиальных преобразований на уровне синтаксиса языка
карринг же в функциональном языке это неотъемлемое (intrinsic) свойство самой семантики языка, а не преобразование на синтаксическом уровне
>> легко реализуется перегрузкой операторов (например) со своими типами
угу, реализуйте карринг перегрузкой операторов :) это невозможно технически
>> поясните что вы имеете в виду под функцией первого класса
я имел ввиду функции, как объекты первого класса это когда в языке функция может прозрачно использоваться в качестве значения
к примеру, в сочетании с каррингом я могу создать новую функцию:
List.intersperse "\n"
и сразу же использовать её в контексте другой функции ">>>"
List.intersperse "\n" >>> concat
все это выражение имеет тип "функция от списка" и я могу применить к нему список:
(List.intersperse "\n" >>> concat) ["здесь", "был", "вася"]
>>ленивые вычисления .. не так часто это и нужно на практике.
тут как бы дело не в том, часто или редко это нужно на практике без этого невозможно написать некоторые программы так, чтобы они завершались
проверяет число на простоту
isPrime n = ...
множество всех простых чисел
primeNumbers = filter isPrime [1..]
три первых простых числа
take 3 primeNumbers
вот эта конструкция
[1..]приведет к зависанию в строгом языкеленивость в общем случае дает возможность писать обобщенно а ограничения (вроде
take 3из примера) устанавливать выше и не протаскивать их сквозь всю программу это невероятно полезно в реальных программах>> плюс все равно, это эмулируется
а вы уверены, что не пропустили первый пример на C# из статьи? там автор как раз эмулировал функциональный код что получилось? правильно, страшилище
я уже не говорю про, что это жутко неэффективно (в императивной среде компилятор вам такой код не оптимизирует)
>>.. и давления солнечных лучей на мозг заказчика (мы же не для себя код пишем?)
так интересно-то вот что именно в функциональном языке и легче адаптировать код под нужды заказчика
потому что код наиболее близок к определению задачи, а отсутствие побочных эффектов и скрытых зависимостей в коде позволяет при рефакторинге вертеть им (кодом) как угодно и не бояться, что что-то сломается
>> и т.п. продолжу считать синтаксическим сахаром
ну если вы не отличаете синтаксис от семантики, то о чем тут можно спорить вообще
вы напрасно прицепились к слову «интерпретатор» в комментируемом посте
к примеру, Haskell-код можно интерпретировать, как код на C что и будет тем самым «компилятором» (кстати, рекомендую почитать работы Футамуры Futamura projections для понимания математической связи интерпретаторов, компиляторов и частичных вычислений)
для функциональных языков (и Haskell, в частности) есть сильно оптимизирующие трансляторы в императивный код (и их research до сих пор ведется), обычно используется трансляция в C с последующим скармливанием его gcc
к примеру, программы на строгом ML после трансляции в C не уступают в производительности "рукописному" C-коду даже в числодробительных задачах (ML это как C в функциональном мире)
Eclipse тормозит потому что он сложен включая сложность Java и библиотек на которых Eclipse построен
вот у меня Visual Studio тормозит куда сильнее эклипса, а написано оно вниимание на C++
rotfl?
неправда ваша не тот же самый:
с циклом я решаю задачу в терминах "аккумулятор, цикл, итерация, условие, etc."
а с Haskell я решаю задачу в терминах задания
>> Просто синтаксис позволяет простые случаи "свернуть"
свернуть позволяет не синтаксис, а семантика языка (функции первого класса, карринг, ленивое вычисление), в языках без этих свойств так "свернуть" не получится
и не простые случаи а любые случаи, т.к. сложные случаи разбиваются на простые
«Perfection is finally attained not when there is no longer anything to add but when there is no longer anything to take away»
у каждого свои ассоциации
в данном случае он может частично-вычислить выражение и преобразовать хвостовую рекурсию в цикл получится такой же императивный код, как в примере с C#
это не тот ступор, о котором вы подумали
>> Так что следующей больщой вещью от Microsoft видимо, будей некий Func#tional
не следующей
>> Ну и, конечно же все те бедолаги-программисты, которые volens-nolens будут вынуждены писать на этом языке "бизнес-приложения"
давайте не будем играть в футурологов
вместе с технологиями меняются и сами люди
15 лет назад мы писали на C и в ус не дули, зато вот сейчас бедолаги-программисты ну прям вынуждены писать на C#, где о, ужас есть generics, лямбды и LINQ
эдак можно заявить, что "я оберну всю программу в функцию
doEverythingи даже заглядывать в неё не стану!"станете :)
а это неправда
разница также в восприятии кода машиной
поскольку функциональный код чётче постулирует задачу машина может более свободно интерпретировать этот код к примеру, распараллелить выполнение или частично-вычислить его или применить еще какие-нибудь продвинутые трансформации
с императивной программой у машины такой свободы нет доступные оптимизации лежат совсем в другой плоскости, на целый уровень ниже
функциональный код фундаментально проще математически
а вам почему-то кажется, что это какая-то синтаксическая надстройка
проблемы тут есть, конечно к примеру, сложно предсказать, как именно будет интерпретирован функциональный код в императивной среде исполнения во многих случаях это неприемлемо (когда требуется максимальная эффективность)
вот только многие люди склонны ставить знак равенства между императивностью и производительностью (например популярно заблуждение "C++ это быстро") а это не так
в императивной среде куда легче сделать говенный супер-неэффективный код (и делают!!!) и машина не сможет его оптимизировать
функциональная же среда намного более толерантна - в ней можно сотней способов сказать одно и то же, но в большинстве случаев все эти способы интерпретируются абсолютно одинаково
поистине нетривиальная она лишь в императивных языках
так вообще-то и в Haskell это не является синтаксисом языка ">>>" там это обычная функция
и в C++ и в C# вы никогда не повторите приведенный код на Haskell понимаете, в этих языках нет карринга (currying)
>> «практически человеческое» — это замечательный аргумент.
согласен
>> попробуете по такой методологии построить какое-нибудь сложно-составное предложение
зачем? я разобью его на несколько простых предложений
собственно, как и в любом другом языке
>> «укорачивающий» синтаксис
>>вставить в процесс хотя бы один if .. то «укорачивание» обернется против вас.
а это не синтаксис и он ничего не укорачивает в Haskell нет другого способа писать код
да, там можно сделать цикл но это сложнее чем сделать map, поскольку Haskell основан на лямбда-исчислении, а не на модели Тьюринга
советую вам всё же написать пару строк кода на Haskell или ML прежде чем комментировать код на этих языках
проблема с чтением императивного кода в том, что приходится в голове интерпретировать его выполнение
такой вот write-only код
интересно, на что же я повелся? в отличие от вас, я хорошо знаком со всеми языками, о которых говорится в статье и с автором согласен
уровень автора, как программиста вообще никак не сказывается на интересности статьи человек взял и изучил Haskell, от чего у него случился культурный шок
он попробовал с наскоку перенести свой новообретенный опыт в C# ничего не вышло, о чём он и написал
я больше чем уверен, что такая же психологическая проблема настигнет любого с более-менее похожим проф. бэкграундом (C++/Java/C#) после осмысления FP
а вы пытаетесь что-то там увидеть между строк (зомбирующий стиль, etc), ну так давайте, раскройте нам еще одну теорию заговора :D
автора оригинальной статьи, как мне кажется, просто ввели в заблуждение
у нас ведь что в учебниках написано : "инкапсуляция, наследование, полиморфизм" вот все и повторяют эту мантру как заведенные попугайчики
если переписать код из примера на LINQ то он ничем не будет отличаться от декларативных примеров из статьи, разве что синтаксис понятнее тем, кто работал с SQL
к сожалению, помимо C# мне также приходится использовать множество не-гибридных, классически императивных языков (C/C++, PHP, Java), и не думаю, что ближайшие несколько лет что-то изменится