> Начни с осиливания навания.

Ну Clojure. Легче? Непривычное слово.

EvilBlueBeaver (26.02.2010 16:22:45)

> Почему на лиспе нельзя портабельно разбирать argv / канпелировать в
> ELF / юзать треды / юзать ассемблерные вставки / эффективно работать
> с памятью / whatever?

Ну это всё просто неправда. Можно. Только это делается библиотеками, а не зашито в реализации. Кстати, не напомните в стандарте С функции для работы с тредами?

> Что же мы видим? Набор костылей - воркараундов вокруг
> несовместимости имплементаций

Гы, вы вообще когда-нибудь исходники на С видели?

archimag (26.02.2010 16:32:31)

http://thesz.livejournal.com/ -- вот один из хаскелистов. AFAIK, зарабытывает как раз Haskell-ем -- моделирует железо в какой-то московской фирме. Правда тихим его назвать сложно, т.к. категоричность его суждений, имхо, временами выходит за рамки разумного.

Так же, по моим наблюдениям, из функциональщиков, которые много флудят на форумах и пишут статьи в журналах, очень не многие действительно ведут разработку на ФЯ.

eao197 (26.02.2010 16:37:39)

> Ну Clojure. Легче? Непривычное слово.

Конечно легче. Осталось только осилить сам язык, а он совсем не сложный.

> Конечно легче. Осталось только осилить сам язык, а он совсем не сложный.

То, что он не особо сложный я догадываюсь. но во-первых, не вижу для себя ни практической ни теоретической выгоды, а во-вторых (буду неоригинален), меня пугает обилие скобочек.

EvilBlueBeaver (26.02.2010 16:40:20)

Ваш пример - он символизирует :)

#if BOOST_WORKAROUND( __IBMCPP__, <= 600 )
#  define BOOST_GRAPH_NO_OPTIONAL
#endif

#if defined(__GNUC__) || !defined(BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS)
#define BOOST_CRC_DUMMY_PARM_TYPE
#define BOOST_CRC_DUMMY_INIT
#define BOOST_ACRC_DUMMY_PARM_TYPE
#define BOOST_ACRC_DUMMY_INIT
#else
namespace boost { namespace detail {
    template < std::size_t Bits, BOOST_CRC_PARM_TYPE TruncPoly,
     BOOST_CRC_PARM_TYPE InitRem, BOOST_CRC_PARM_TYPE FinalXor,
     bool ReflectIn, bool ReflectRem >
    struct dummy_crc_argument  { };
} }
#define BOOST_CRC_DUMMY_PARM_TYPE   , detail::dummy_crc_argument<Bits, \
 TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem> *p_
#define BOOST_CRC_DUMMY_INIT        BOOST_CRC_DUMMY_PARM_TYPE = 0
#define BOOST_ACRC_DUMMY_PARM_TYPE  , detail::dummy_crc_argument<Bits, \
 TruncPoly, 0, 0, false, false> *p_
#define BOOST_ACRC_DUMMY_INIT       BOOST_ACRC_DUMMY_PARM_TYPE = 0
#endif

Ой!

impfp (26.02.2010 16:42:55)

> наверное так и не осилю - порог вхождения высоковат

Начни с простого. Сделай аналог (пусть кривой) того, что умеешь делать на другом языке. Знание приходит с опытом.

mv (26.02.2010 17:02:06)

> Начни с простого. Сделай аналог (пусть кривой) того, что умеешь делать на другом языке. Знание приходит с опытом.

Шелдон? То была ирония))

EvilBlueBeaver (26.02.2010 17:20:28)

> Так же, по моим наблюдениям, из функциональщиков, которые много флудят на форумах и пишут статьи в журналах, очень не многие действительно ведут разработку на ФЯ.

Это относится в равной мере и к императивщикам. И вообще, не только к программистам и работникам IT ;)

Уже 4 страницы! Пожалуй можно нас осчастливить :)

По моим наблюдениям, подавляющее большинство императивщиков таки используют в своей работе именно императивные языки. В отличие от.

eao197 (26.02.2010 18:17:49)

> Какая-то околоакадемическая бодяга для очкариков.

> Будьте проще, пожалуйста! Хотите чтобы вас за красноглазых очкариков не считали, рассказывайте о нужных и практических вещах.

В следующем номере:

- Как реальному пацану подобрать правильную качалку?
- На каких тачках не позорно ездить?
- Где тусуются самые сисястые тёлки в районе?

И многое другое!

Читатйте журнал "Практика функционального програ.. че-э-э-эго-о-о?

LamerOk (26.02.2010 18:21:54)

> По моим наблюдениям, подавляющее большинство императивщиков таки используют в своей работе именно императивные языки. В отличие от.

А подавляющее большинство англичан говорит на английском и что? Не забываем, что в большинстве случаев функциональщики это бывшие императивщики. И если им по ходу работы приходится писать императивно, то ничего удивительного в этом нет. Многие и хотели бы писать функционально, да засилье императива не позволяет (попробуйте спеть в итальянской опере на японском. в теории возможно, на практике вряд ли ;) )

Но есть и исключения http://www.haskell.org/haskellwiki/Haskell_in_industry

И как показывает развитие событий, функционалка пользуется все большим спросом (особенно онтересно было посмотреть на соревнования языков на благо ВМФ США)

( ⋅ (( ⋅ ) ⋅ ( ⋅ ) ⋅ ( ⋅ ))) ⋅ ( ⋅ ) ⋅ ( ⋅ ) ⋅ ( ⋅ ) ⋅ ( ⋅ )

Сиськи, много сисек.

> В следующем номере:

> - Как реальному пацану подобрать правильную качалку? > - На каких тачках не позорно ездить? > - Где тусуются самые сисястые тёлки в районе?

> И многое другое!

> Читатйте журнал "Практика функционального програ.. че-э-э-эго-о-о?

Уполз под стол! :)))))))

У лиспа c хаскалем не порог вхождения, а водопад вхождения!

Ну и зачем тогда агитировать за Haskell и при этом самому его не использовать (зато выпячивать это самое ЧСВ)? Что, ждём пока другие (которых пытаемся агитировать) изменять ситуации в индустрии, что бы наконец сами агитаторы смогли писать на нём?

archimag (26.02.2010 18:47:32)

> Ну и зачем тогда агитировать за Haskell и при этом самому его не использовать (зато выпячивать это самое ЧСВ)? Что, ждём пока другие (которых пытаемся агитировать) изменять ситуации в индустрии, что бы наконец сами агитаторы смогли писать на нём?

Тогда и LISP не нужен.

ТС'у требовалось избежать коредампов - я написал как. Какая тема - такой и ответ.

> У лиспа c хаскалем не порог вхождения

Да не, порог это. Низенький такой. Просто под этот порог кто-то нагадил, и потому брезгливые люди переступать через него не решаются. Только всякие копрофилы и лезут.

> Тогда и LISP не нужен.

Не понял логики. И я ведь не сказал, что Haskell не нужен. Я просто говорю, что если кто-то агитирует за язык (тем более, если агитирует агрессивно, утверждая что это делает его лучшим программистом), то необходимо демонстрировать как агитатор использует этот язык на практике. А наши хаскелисты-теоретики только о "возвышенном" могут писать, а всякие земные вещи, типа реальной разработки, это как бы и не для них.

archimag (26.02.2010 19:13:14)

> попробуйте спеть в итальянской опере на японском. в теории возможно, на практике вряд ли ;)

Ололо!!

man Madama Butterfly

LamerOk (26.02.2010 19:16:08)

> тем более, если агитирует агрессивно, утверждая что это делает его лучшим программистом

ЛучшИм или лучшЕ? Последнее полностю верно.

> А наши хаскелисты-теоретики только о "возвышенном" могут писать, а всякие земные вещи, типа реальной разработки, это как бы и не для них.

Ага, например, вот это команда теоретиков http://www.galois.com/

Чтобы учить других готовить омлет, не обязательно самому нести яйца. Мне кажется, что именно изучение теории программирования расширяет кругозор и повышает квалификацию программиста. А всякие земные вещи может лучше делать на perl в одном случае, и на java в другом. Программист должен быть универсалом и выбор конкретного языка, или набора языков должно определяться спецификой проекта.

Sun-ch (26.02.2010 19:35:23)

> показывается, что по сравнению с С++ в лиспе все делается через жопу

Ага, а через что же тогда работает код в стиле Александркску? Шаблонное мнтапрограммирование мало того, что на 100% функуионально, так и ещё и крайне мм... извёрнуто.

Я не против С++, некий элемент brainfuck'а в нём, "это не баг, это фича", но завираться то не стОит.

> некий элемент brainfuck'а в нём, "это не баг, это фича", но завираться то не стОит.

я разве писал, что в С++ все идеально? там точно так же есть свои "жопы"

lester (26.02.2010 19:38:49)

[quote]Многие и хотели бы писать функционально, да засилье императива не позволяет[/quote]

Собственно в этом и поинт: в реальности функциональщине до широкого использования еще пилить и пилить. Но пилить влом, лучше зарабатывать деньги на Java/C#, а статейки писать про Haskell и трындеть о всеобщем функциональном щасте в будущем.

А приличное удаление функциональщины от мейнстрима может объясняться еще и тем, что для многих насущных задач функциональщина как из пушки по воробьям. Нахера изучать мономорфизм и экзистенциональные типы, если нужно просто проверить длину пришедших откуда-то данных перед их сохранением в БД?

eao197 (26.02.2010 20:00:31)

> Собственно в этом и поинт: в реальности функциональщине до широкого использования еще пилить и пилить

Зачем? Если бы в широком применении был бы хоть какой смысл от функциональщины, она бы давно была допилена и перепилена.

Но её в практическом, прикладном программировании просто нет, не было и не предвидится. И это доказывает, что она просто банально не нужна. В реальности нет ни одной задачи, которую стоило бы решать с применением функциональщины.

Программисты на эрланге с тобой не согласятся. Полно задач, для которых он подходит лучше других.

Sun-ch (26.02.2010 20:09:00)

> если нужно просто проверить длину пришедших откуда-то данных перед их сохранением в БД?

а написание самой СУБД и даже такая мелочь как передача данных - это что не практические задачи? или СУБД для функциональщины - это тоже "воробей"?

lester (26.02.2010 20:09:45)

И с каких это пор эрланг - функциональщина?

Эрланг занимал бы точно ту же самую нишу, даже если бы в нём ни единой функциональной фичи не было. Его прикол в concurrency, и пишут на нём преимущественно императивный код.

Вы много знаете проектов, под которые писались бы собственные СУБД и средства IPC?

Среднестатический разработчик использует стороннюю СУБД и чужую библиотеку для обмена данными. Его задача -- выполнение некоторых обычных операций. Но даже на это временами ума не хватает.

eao197 (26.02.2010 20:14:47)

Интересно было бы посмотреть на императивный код на Erlang-е.

eao197 (26.02.2010 20:15:45)

> Cреднестатический разработчик использует стороннюю СУБД и чужую библиотеку для обмена данными. Его задача -- выполнение некоторых обычных операций. Но даже на это временами ума не хватает.

я не спрашивал про "среднестатического разработчика", я спрашивал - раз функциональщина такое волшебное колдунство, то где, например, те же СУБД на ней? или у функциональщиков "ума не хватает" (с)?

lester (26.02.2010 20:22:14)

Да кстати, мне тоже было бы интересно. А то как то не видел еще 'императивного' кода на Эрланге.

kristall (26.02.2010 20:23:23)

> Зачем? Если бы в широком применении был бы хоть какой смысл от функциональщины, она бы давно была допилена и перепилена.

> Но её в практическом, прикладном программировании просто нет, не было и не предвидится. И это доказывает, что она просто банально не нужна. В реальности нет ни одной задачи, которую стоило бы решать с применением функциональщины.

Вот, раскудахтались. См. F#.

dave (26.02.2010 20:24:23)

Сюда же можете LINQ добавить, который тоже весь функциональный.

dave (26.02.2010 20:25:58)

И чё смотреть то? Его на практике никто не применяет. И делает его та же контора что и хацекель. Для таких же окомемиков.

> то где, например, те же СУБД на ней? или у функциональщиков "ума не хватает" (с)?

Функциональщина говно. А на Лиспе СУБД есть. Например, Itasca, широко известная в узких около-CADовых кругах.

Это вам нужно не у меня, а у адептов функциональщины спрашивать.

Сам-то я большой скептик. Мое имхо -- наиболее попсовые и удобные для массового обывателя фишки ФЯ (имутабельность, лямбды, алгебраические типы, сопоставление с образцом, вывод типов) оперативно перекочуют в императивный мейнстрим. И будут широко востребованны обычными программистами вроде меня. А хардкорные функциональщики продолжат экспериментировать с разными зависимыми типами и прочей теорией.

Собственно, все это можно наблюдать на примере развития Scala, D, C#, да того же C++.

eao197 (26.02.2010 20:28:37)

> я не спрашивал про "среднестатического разработчика", я спрашивал - раз функциональщина такое волшебное колдунство, то где, например, те же СУБД на ней? или у функциональщиков "ума не хватает" (с)?

Не знаю, как в функциональщине, а на лиспе есть как минимум Allegro Cache

Добавь и Лисп в этот список. Это императивный язык, позаимствовавший несколько фичей из функциональщины. Но он был бы хорош и без единой функциональной фичи.

> А на Лиспе СУБД есть. Например, Itasca, широко известная в узких около-CADовых кругах.

значит осиливают :) хотя гугль говорит - что оно мертвое и даже SQL не поддерживает

lester (26.02.2010 20:35:35)

> Чтобы учить других готовить омлет, не обязательно самому нести яйца.

Да, но у меня вызывает подозрение, что человек, который пытается учить меня готовить омлет и утверждает что это самая вкусная еда на свете, сам его не готовит, с чего бы это?

> Мне кажется, что именно изучение теории программирования расширяет
> кругозор и повышает квалификацию программиста.

Ерунда, изучать надо не теорию, а хорошие успешные проекты.

> А всякие земные вещи может лучше делать на perl в одном случае,
> и на java в другом.

Ну т.е. вы подтверждаете мнение, что говорить о практическом применении ФП нелепо?

archimag (26.02.2010 20:38:44)

> это сделать immutable symbols или переменные - вот это да, сложно. Первое сделали в Lisp, а второе - в Haskell и Clojure

Ты просто отстал от жизни. Узнай, какие языки программирования входят в стандартный набор Visual Studio 2010.

dave (26.02.2010 20:50:26)

> это сделать immutable symbols или переменные - вот это да, сложно. Первое сделали в Lisp, а второе - в Haskell и Clojure

Вы знаете, как обойти setq в лиспе?

Во первых, VS2010 еще даже не вышла официально. Так что на практике ею никто не пользуется. Она только на поиграться. Во вторых, да, конечно же окодемегам тоже надо Visual Studio впаривать. Пусть грантиками своими копеечными с MS поделятся. На практике никто F# использовать не будет все равно, он только для окодемегов.

> Боюсь, что будут трудности с практическом материалом, ведь никто не пишет на CL в функциональном стиле Угу. Попробовал я использовать этот монстр. Утверждалось, что CL столь гибок, что позволяет программировать в любом стиле. Однако выяснилось, что в дизайне языка сделано все, что бы функциональное программирование в нем было неудобно. Конечно, потрахавшись пару часов, я сделал DSL, на котором можно писать функционально. Но все равно остается ощущение, что там все делается через задний проход. А еще выяснилось, что далеко не все реализации хвостовые вызовы оптимизирут. Ну как так можно жить?

Динамические, параллельные, распределённый языки без всякой функцирнальщины писали, например Obliq. Но используют почему-то Erlang.