Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, alex_public, Вы писали:
_>>О, кстати, интересно... А кто-нибудь использует haskell в качестве серверных скриптов? По идее там многие недостатки будут скрыты за допустим fastcgi интерфейсом или чем-то подобным...
К>А зачем это надо, если есть тот же warp, например? К>(ссылка немного старовата уже правда)
Собственно я что-то типа этого и спрашивал. Спасибо. ) А на практике кто-нибудь это использовал? Или может есть известные проекты на этой базе?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, MigMit, Вы писали:
MM>>Ясно, спасибо. Да, в питоне компрехеншены спижжены именно из Хаскеля.
_>Хы, а Питон не раньше его появился на свет случаем? )))
Компрехеншены появились, если википедия не врёт, в Python 2.4, это 2004 год. Стандарт Хаскеля (уже содержащий компрехеншены) — 1998 год.
MM>>Не понял. Как техника отката относится к паттерн-матчингу?
_>Как это какое? Это как раз основное преимущество Пролога в этой области.
В какой области? Особенно учитывая, что это вообще основа Пролога в целом.
_>Ну на самом деле это просто у меня были завышенные ожидания к Хаскелю, что типа там собрали всё лучшее
Разумеется, нет. Хаскель — это новое изообретение, а не коллекция старых трюков.
MM>>Во-вторых, можешь. Хаскельный FFI позволяет объявить внешнюю функцию как чистую. Другой вопрос, что если она таки нечистая, то ты поимеешь проблем (от непредсказуемости порядка вычислений, например).
_>Хм. Интересно. Я так понимаю что по умолчанию все системные функции объявлены как нечистые и подобные действия — это типа нарушения практик?
По умолчанию системные функции не объявлены. Хаскель — кроссплатформенный инструмент, и на одну конкретную версию системного API не завязан.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, alex_public, Вы писали:
_>>>О, кстати, интересно... А кто-нибудь использует haskell в качестве серверных скриптов? По идее там многие недостатки будут скрыты за допустим fastcgi интерфейсом или чем-то подобным...
К>>А зачем это надо, если есть тот же warp, например? К>>(ссылка немного старовата уже правда)
_>Собственно я что-то типа этого и спрашивал. Спасибо. ) А на практике кто-нибудь это использовал? Или может есть известные проекты на этой базе?
Ну вот скоро сдаём проект в том числе и на этом деле.
Из проектов вспоминается с ходу только http://www.haskellers.com/ на йесоде, исходники его (haskellers) были толи у сноймана толи в аккаунте yesodweb на гитхабе.
Re[5]: Мифический Haskell
От:
Аноним
Дата:
16.02.12 19:57
Оценка:
Здравствуйте, alex_public, Вы писали:
А>> Вот именно, что универсальный. А задача-то узкоспециализированная.
_>GUI — это явно не ускоспециализорованная задача. )))
Да куда уж узкоспециализированнее? Там своя, отличная от всего остального семантика предметной области. ГУЙ на XAML или Tcl/Tk делать надо, на специальных DSL-ях, а не на языках общего назначения.
_> Ну разве что если вы программируете микроконтролёры и т.п... )))
Никогда не программировал микроконтроллеры.
А>> Какие такие "функциональные практики"? Там полноценной лямбды нет. Закопать!
_>Хыхы, а какие тогда на ваш взгляд есть языки с нормальной поддержкой функционального программирования? )
Те, где нет разницы между expression и statement (то есть, у каждого выражения есть значение), где есть полноценные лямбды и лексические замыкания. Питон не пройдет.
А>> Тем более что на кой хрен надо делать гуй на том же языке, что и логику? Все нормальные люди гуй и логику всегда разделяют.
_>Разделять (логически) — это одно. А использовать для них разные инструменты (и плюс неизбежные переходники делать) — это только от бедности используемых инструментов.
Причем тут "бедность"? Это единственный вменяемый подход. Логика отдельно, отрываемые разные ГУЙни к ней — отдельно, другим процессом, с текстовым тупым протоколом между гуем и логикой. Unix way, однако.
_> К счастью у моих команд в руках инструменты позволяющие и просто создавать быстрый системный код с логикой и быстро создавать красивые интерфейсы.
Это C++-то? Не поверю. C++ для логики шикарен, да. Но гуй на нем деланный выглядит тошно (имею в виду код). Особенно если это какая-либо пакость вроде Qt.
Здравствуйте, jazzer, Вы писали:
J>А что такое ПП? И, чтоб 2 раза не вставать уже — что такое "(a ~ b) => ..."?
ПП — это пистолет-пулемёт. А `~' — это волночка. Означает, что типы в контексте должы совпадать. Например, если функция имеет сигнатуру (a ~ b) => a -> b -> c, это значит, что она будет работать с любыми a и b, но они должны совпадать. Полезно это, если есть какие-нибудь функции над типами. Тогда, например можно писать (F a ~ b) => .. что означает, что должны совпадать b и результат применения F к а.
Здравствуйте, MigMit, Вы писали:
_>>Хм. Интересно. Я так понимаю что по умолчанию все системные функции объявлены как нечистые и подобные действия — это типа нарушения практик?
MM>По умолчанию системные функции не объявлены. Хаскель — кроссплатформенный инструмент, и на одну конкретную версию системного API не завязан.
Мммм ну их просто вызывают из соответствующих функций runtime library. Как я понимаю все родные функции оборачивающие OS API (типа работы с файлами и т.д.) тоже нечистые, да? И это как бы обосновано?
Здравствуйте, MigMit, Вы писали:
_>>Но вот то что Lisp императивный — это довольно неожиданная новость.
MM>Он не только императивный, он ещё и перехваленный.
А я и не говорю что Лисп очень хорош. Но вот на счёт императивности... Это как-то слишком. )))
Здравствуйте, Аноним, Вы писали:
А> Да куда уж узкоспециализированнее? Там своя, отличная от всего остального семантика предметной области. ГУЙ на XAML или Tcl/Tk делать надо, на специальных DSL-ях, а не на языках общего назначения.
Ну конечно. ))) Может ещё ресурсы (*.rc) от MS были хорошим решением? )))
_>>Хыхы, а какие тогда на ваш взгляд есть языки с нормальной поддержкой функционального программирования? )
А> Те, где нет разницы между expression и statement (то есть, у каждого выражения есть значение), где есть полноценные лямбды и лексические замыкания. Питон не пройдет.
Вообще то это не ответ на мой вопрос — я предложил перечислить подходящие языки. )
А> Причем тут "бедность"? Это единственный вменяемый подход. Логика отдельно, отрываемые разные ГУЙни к ней — отдельно, другим процессом, с текстовым тупым протоколом между гуем и логикой. Unix way, однако.
Да, да, идеология завоевавшая целый 1% рынка — это самый достойный образец для подражания. )))
А> Это C++-то? Не поверю. C++ для логики шикарен, да. Но гуй на нем деланный выглядит тошно (имею в виду код). Особенно если это какая-либо пакость вроде Qt.
Мне как бы пофиг как он там внутри выглядит — его генерит графический редактор, в котором контролы таскают мышкой. )))
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Похоже Хаскель действительно "affect the way you think about programming", и, похоже, действительно это недоступно ни в одном другом из перечисленных языков. Рекомендую почитать здесь http://www.paulgraham.com/avg.html про "Blub Paradox". Там про Лисп, но суть феномена отражена верно.
После изучения лиспа я очень быстро наигрался в конс-пары и виртуальные машины и прекратил это.
Адский ад был — придуманный мной курсовой проект по созданию смолтолка из лиспа поверх dBase III
А вот после изучения хаскелла уже который год практикую list comprehensions всюду где можно (и за это очень люблю питон с его ленивостью (!)).
Здравствуйте, alex_public, Вы писали:
_>Возможно стоит ещё посмотреть это. Есть какие-нибудь интересные примеры "правильного" кода, но при этом не из абстрактной области, а из реальных приложений?
Конечно, есть! Вот пожалуйста: http://habrahabr.ru/blogs/Haskell/129235/ Там и ссылку на код найдете, и всю предысторию. Код работает ежемесячно, никаких нареканий нет, без этой утилиты теперь жизнь не представляем.
_>А я и не говорю что Лисп очень хорош. Но вот на счёт императивности... Это как-то слишком. )))
Ну функциональный стиль больше поощряется в scheme, в лиспе за всю историю старались развивать императивные возможности (за ради практической пользы).
Здравствуйте, MigMit, Вы писали:
MM>Есть неполноценная имитация — шаблоны. Когда функция для каждого типа пишется отдельно, но макросистема (т.е., шаблоны) позволяет один раз показать, как оно должно выглядеть, а дальше компилятор пишет их сам.
И что? Вопросы реализации. Причём позволяющие использовать низкоуровневую оптимизацию, применительно к конкретному фактическому типу. inbox -- не всегда достоинство.
Здравствуйте, MigMit, Вы писали:
J>>Если в текстовом — то это шаблоны. J>>А если в бинарном — то это type erasure уже (void* в экстремальном случае)... MM>В бинарном. MM>Аргумент про type erasure не понятен для языков, компилирующихся в натив. В ассемблерном коде типов всё равно нет.
Ну void* же, не?
J>>Я посмотрел твой пост про скалярное произведение, мало что понял, если честно — если длина известна во время компиляции, то есть более простые способы ее проверить безо всяких консов...
MM>А она неизвестна. Известно, что она ОДИНАКОВАЯ.
Тогда что надо проверять, если уже все известно?
можешь привести пример пользовательского кода, который либо должен компилироваться, либо нет?
типа вот тут мы одинаковые вектора подаем — все компилируется.
А тут — разные, и не компилируется.
J>>Есть какая-нть задача, которая решается только ПП и другого более прямого решения на С++ нету? MM>Оксюморончик получился.
В смысле, что можно пытаться городить арифметику Пеано, а можно просто воспользоваться тем фактом, что в С++ числа — это числа, которые можно умножать/делить/складывать напрямую, и никакие пеаны для этого не нужны. Это я имею в виду под "более прямым".
Здравствуйте, alexlz, Вы писали:
A>Здравствуйте, MigMit, Вы писали:
MM>>Есть неполноценная имитация — шаблоны. Когда функция для каждого типа пишется отдельно, но макросистема (т.е., шаблоны) позволяет один раз показать, как оно должно выглядеть, а дальше компилятор пишет их сам. A>И что? Вопросы реализации. Причём позволяющие использовать низкоуровневую оптимизацию, применительно к конкретному фактическому типу. inbox -- не всегда достоинство.
Нет. Про бесконечное развёртывание шаблонов не забыл?
Здравствуйте, jazzer, Вы писали:
J>можешь привести пример пользовательского кода, который либо должен компилироваться, либо нет? J>типа вот тут мы одинаковые вектора подаем — все компилируется. J>А тут — разные, и не компилируется.
В том ЖЖ-шном посте есть.
J>В смысле, что можно пытаться городить арифметику Пеано, а можно просто воспользоваться тем фактом, что в С++ числа — это числа, которые можно умножать/делить/складывать напрямую, и никакие пеаны для этого не нужны. Это я имею в виду под "более прямым".
А теперь вспоминаем, что эти числа должны быть известны при компиляции. Не тот факт, что они равны, а они сами.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Здравствуйте, jazzer, Вы писали:
J>>А что такое ПП? И, чтоб 2 раза не вставать уже — что такое "(a ~ b) => ..."?
ПМ>ПП — это пистолет-пулемёт. А `~' — это волночка. Означает, что типы в контексте должы совпадать. Например, если функция имеет сигнатуру (a ~ b) => a -> b -> c, это значит, что она будет работать с любыми a и b, но они должны совпадать. Полезно это, если есть какие-нибудь функции над типами. Тогда, например можно писать (F a ~ b) => .. что означает, что должны совпадать b и результат применения F к а.
Можешь дать пример или ссылку на пример?
А то пока что непонятно, почему бы просто не написать a -> а -> c вместо (a ~ b) => a -> b -> c.
Перекуём баги на фичи!
