Ссылку! Ссылку!

>Ну зарулил gcc в два или три раза, а окамль раз в 5-6.

Препод в вузе рассказывал про то что пока они они писали libjpeg на асме для какой-то софтины, в широкую продажу вышли компьютеры на которых разница между изначальным и оптимизированным вариантом была субъективно не видна. Технической цели они достигли - на XT с EGA монитором оно действительно было быстрее раза в три. Коммерческой - нет, тупо просрали время разработчиков.

> то советую ему попробовать cl-sql биндинг для лиспа
Я пользуюсь sql-odbc с Firebird, раньше пользовался им же для MS SQL. Да, с кодировками проблема есть, пришлось там кое-что попатчить. Да, это вызывало в своё время определённую нервозность. Но сейчас - можно сказать «почти работает». Потому что иногда какие-то глюки всё же бывают...

>И что? Это относится к быдлокоду на любом языке.

Ну не скажи. OpenMP же нашел свою нишу. И числодробильный быдлокод с его помощью вроде как допиливают.

Что за звери?

Iron Python: Python + .NET емнип.

Теперешние объемы было просто негде хранить.

Ты только задумайся: сейчас у меня разрешение 1280x1024 при глубине цвета 8 бит, что дает нам чуть больше двух мегабайт информации только на экране. А ведь научные рассчеты в свое время проводили, имея в наличии всего лишь десятки (!) килобайт (!).

А у некоторых хватает наглости утверждать, что у них «окошки медленно ресайзятся». Конечно медленно, там же перемалываются такие объемы, что нам за всю жизнь столько печатных символов не прочитать.

Там можно было вполне получить указанные результаты, если правильно выбрать, что сравнивать. Например, icc с OpenMP vs. gcc без vs. ocamlcc (вместо ocamlopt, и без распараллеливания) 8))

>Ага. Так. Теперь в какую из этих категорий относится Хаскель?

Для недогадливых я специально сделал приписку о «все вместе с эпилептичным синтаксисом впридачу». И не надо тыкать мне списком биндигов, которые ты можешь сходу нагуглить: ты ими не пользовался, чтобы об их работоспособности говорить.

>Cocoa подойдёт?

Моя ориентация не позволяет мне даже смотреть на него, но засчитаем.

Встречный вопрос: Objective-C у нас язык с динамической типизацией?

Для недогадливых я специально сделал приписку о «все вместе с эпилептичным синтаксисом впридачу».

Итого, ты считаешь, что Хаскель а) медленный, б) с недостатком библиотек, и в) с эпилептичным синтаксисом. Я правильно тебя понял?

>И при этом UI-шная логика совершенно отвратительно ложится на С и С++.

Callback он и в Африке callback, как ты его лямбдой не называй.

>И что-то там с icc было тоже далеко даже не в 1,5 раза быстрее gcc..

ЕМНИП одна директива OpenMP там наглядно показала разницу между icc и gcc.

>И, кстати, что cl-sql та ещё библиотека кажется уже всё давно знают и никто ей пользуется.

Судя по mailing листам, пользуются.

>>И при этом UI-шная логика совершенно отвратительно ложится на С и С++.

Callback он и в Африке callback, как ты его лямбдой не называй.

Там скорее матчинг по типу оконного сообщения подошел бы. И континуации для сохранения состояния между асинхронными событиями.

>Потому что иногда какие-то глюки всё же бывают...

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

> Судя по mailing листам, пользуются.
Хорошо, скажем так, не пользуются те, кто в теме. В иных рассылках такое прочитать можно (как пример в рассылке hunchentoot), что остаётся только гадать, где же прячется эта пресловутая «ацкая элита». Быдлокодеры наступают даже на CL :) Хороший знак...

>Итого, ты считаешь, что Хаскель а) медленный, б) с недостатком библиотек, и в) с эпилептичным синтаксисом. Я правильно тебя понял?

Совершенно верно.

>Например, icc с OpenMP vs. gcc без

4.2: gcc брался с OpenMP. И только дополнительные танцы с бубнами позволили получить от OpenMP выигрыш, а не проседание, как это было вначале.

vs. ocamlcc (вместо ocamlopt, и без распараллеливания)

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

И, собственно, это не мои проблемы, что многие наколенные поделки лишены вменяемых оптимизаторов и библиотек. Это, собственно, и отличает C и, прости Господи, C# от множества других «супир-мега-крутых йезыгов».

Таки где ссылка на объявленные результаты? Я напоминаю: в 2-3 раза над gcc и в 5-6 раз над окамлом.

иерархия типов != иерархия классов типов. Класс типов - это типы группа типов с реализацией предварительно декларированного интерфейса, иногда с выбором реализации функции по типу нескольких аргументов.

Классы типов это всякие Eq, Ord и т.д.? чем принципиально отличаются от миксинов?

Навкидку, если я правильно понял задачу, нужно писать что-то примерно такое такое.

Нужно не просто цикл, а выполнение кода в этом цикле, даже с сайд эффектами, плюс видимость переменных которые изменяются во внутреннем коде, плюс видимость этих переменных при их изменении. Пример

>(funcall (do* ((i 1 (1+ i)) (j i (* i 2)))
              ((>= j 15) (print "end")
               (lambda () (print j)))
           (let ((k (* j i)))
             (print (+ k i)))))

2 
10 
21 
36 
55 
78 
105 
"end" 
16 
16 ;значение формы, остальное печать - сайд эффекты.

иерархия типов != иерархия классов типов. Класс типов - это типы группа типов с реализацией предварительно декларированного интерфейса, иногда с выбором реализации функции по типу нескольких аргументов.

Классы типов это всякие Eq, Ord и т.д.? чем принципиально отличаются от миксинов?

Навкидку, если я правильно понял задачу, нужно писать что-то примерно такое такое.

Нужно не просто цикл, а выполнение кода в этом цикле, даже с сайд эффектами, плюс видимость переменных которые изменяются во внутреннем коде, плюс видимость этих переменных при их изменении. Пример

 
>(funcall (do* ((i 1 (1+ i)) (j i (* i 2)))
              ((>= j 15) (print "end")
               (lambda () (print j)))
           (let ((k (* j i)))
             (print (+ k i)))))

2 
10 
21 
36 
55 
78 
105 
"end" 
16 
16 ;значение формы, остальное печать - сайд эффекты. 

>Таки где ссылка на объявленные результаты?

Это Интернет, детка. Тебе надо, ты и ищи.

> Это Интернет, детка. Тебе надо, ты и ищи.

А, очередные «преданья старины глубокой, дела давно минувших дней». Где-то, когда-то, может быть тебе даже не приснилось... В общем, как обычно в твоём стиле — выдавать свои фантазии за факты, а при попытках получить от тебя подтверждения резко сваливать в кусты.

(потупив очи долу)
И чем же надо пользоваться?

>>Классы типов это всякие Eq, Ord и т.д.? да

чем принципиально отличаются от миксинов?

Если уж их сравнивать с миром жабы, то с интерфейсами/абстрактными классами.

выполнение кода в этом цикле,

Это есть

даже с сайд эффектами,

Эм. Это длиннее получится, потому как монады, но тоже можно. Примерно так.

s_iter:: Monad m => (a-> Bool) -> (a -> m a) -> a -> m a s_iter p t i = t i >>= \x -> if (p x) then (return x) else (s_iter p t x)

fuse_transforms:: Monad m => [a -> m a] -> a -> m a fuse_transforms [] a = return a fuse_transforms t:ts a = t a >>= fuse_transforms ts

дисклеймер a может быть таплом. Это ничего не стоит. дисклеймер два: Monad IO вы туда просунете или другую монаду - в общем, пофиг.

про видимость не понял. То, что надо видеть, таскается в составе a - проблемы нет. Или вам хочется передавать это дело нечвно ? Или вам хочется менять a из предикатов? За это обычно надо бить по рукам. Для частных случаев предикаты оборачиваются в монаду и для них строится отдельная композиция. Если очень уж надо. Но лучше не надо.

> И чем же надо пользоваться?

Ну, для Firebird-а да, больше особо нечего, но с другой стороны - зачем он нужен (я эту базу после некоторого опыта просто ненавижу :))

Если нужен ORM - то самое модное сейчас cl-perec. Я ORM не приемлю,
поэтому использую postmodern - только Postgres, но зато очень хорошо.

По работе надо работать с MS SQL, накидал за два дня для себя cl-mssql на без FreeTDS, может не шибко много, но мне больше и не надо.

Короче, основные ключевые слова: cl-perec и postmodern

Нет, ORM мне тоже не нужен. В общем, спасибо за консультацию. Файрбёрд со временем становится лучше. Сейчас уже почти можно работать.

Классы типов это всякие Eq, Ord и т.д.? чем принципиально отличаются от миксинов?

Примерно как ворон от письменного стола.

Нужно не просто цикл, а выполнение кода в этом цикле, даже с сайд эффектами, плюс видимость переменных которые изменяются во внутреннем коде, плюс видимость этих переменных при их изменении. Пример

Я тебе написал пример.

Итого, ты считаешь, что Хаскель а) медленный, б) с недостатком библиотек, и в) с эпилептичным синтаксисом. Я правильно тебя понял?

Совершенно верно.

OK. Тогда скажи, какой синтаксис более эпилептичен:

pushCommand (\body -> setVelocity body (x, y))

class physCOMMAND_SET_VELOCITY : public physCOMMAND {
public:
    physCOMMAND_SET_VELOCITY(float _a, float _b) : a(_a), b(_b) {}
    ~physCOMMAND_SET_VELOCITY() {}
    virtual void Run(physRigidBody *body){
        setVelocity(body, a, b);
    }
private:
    float a;
    float b;
};
pushCommand(new physCOMMAND_SET_VELOCITY(x, y));

>А так как Erlang более объектный, чем функциональный

Сам придумал «легенду», а теперь выдаёшь её за аксиому? Согласен, первые пару раз это было смешно/прикольно, а сейчас - тупо:)

Сам придумал «легенду», а теперь выдаёшь её за аксиому?

Не я первый придумал, не выдаю.

javascript

Интересно, почему за весь тред было только 2 упоминания о javascript?

А ведь он вполне функциональный, даже библиотека специальная есть http://osteele.com/sources/javascript/functional/ и синтаксис не сравним с лисповским.

Преймущества:

1. для тренировки достаточно браузера и текстового редактора

2. есчё долгое время будет востребован

3. давно стандартизирован как ECMAScript262

4. простой и удобный синтаксис

Недостатки:

1. мультипарадигменный

2. некоторые реализации до сих пор медлительны

Так же рекомендую попрактиковатся с ФП в python ruby erlang (clisp тут уже советовали)

PS

Haskell и OCaml не трогай (зачем нам конкуренты?)

Итак, граждане-вопрос то был-ИЗУЧЕНИЕ ФП. Изучение ФП не подразумевает создания огромных проектов, или чего то, требующего развитого набор библиотек, или языковых средств.

Первое, что подразумевает изучение ФП-это собственно изучение концепций ФП. И не важно сколько библиотек у вас вналичие или насколько быстр интерпретатор, компилируется в байт-код или нет, распространен или нет, и даже не важно то, что думает о нем Пол Грэм!

Осмелюсь предположить также, что даже и язык-абсолютно не важен. Важно лишь то, чтоб он в полной мере позволял освоить концепции ФП.

Еще важно то, что за учебники/учебные материалы в вашем распоряжении есть-что собственно будете изучать то:-)

Так что всего составляющих: 1) Язык, выбранный вашими учителями 2) Язык, позволяющий изучать концепции ФП 3) Доступность и качество интерпретатора, документации по нему

Архиважно уметь отбрасывать сомнения, и факторы, не влияющие существенно на вашу цель!

В целом хорошим выбором будет и Common Lisp (сейчас самые широко распространенные свободные реализации-CLISP, CMU CL, GCL), и Scheme (только умоляю-не обращайте внимания на эти страшные речи про R6RS... смотрите-в SICP ведь совсем мало возможностей Scheme юзается, и вам не понадобится много), и Haskell, и Oz, и Erlang, и OCaml... Все достаточно хороши для вашей цели.

Так что выбирайте учебник, темы изучения, а все остальное-само понятно станет!

Haskell и OCaml не трогай (зачем нам конкуренты?)

Вcё-таки, ты сволочь.

>В целом хорошим выбором будет и Common Lisp (сейчас самые широко распространенные свободные реализации-CLISP, CMU CL, GCL),
Для «ФП»? *штука про траву*

CMU CL, GCL

Ыыыы.
Хотя, если за CMUCL считать и SBCL...
Но вот GCL? *штука про траву*

> сейчас самые широко распространенные свободные реализации-

CLISP, CMU CL, GCL

Бугага, ели выбрался из под стола. Ну почему люди ничего не понимающие в Common Lisp начинают что-то там о нём рассуждать и даже предлагать?

Парниш, я на лиспе на 30 летнаверное дольше твоего пишу, может многое чего и не знаю-что нового сейчас...

А что собственно не так? GCL версии 2.7.0 совсем скоро будет-так что не катите бочку на него. А по поводу «оптимизирующих компиляторов», как в SBCL-это для целей изучения не нужно, и для 99% практических целей не нужно.

А вам вот я как скажу-чем вам Лисп для изучений концепций ФП плох? Давайте-конкретные только, существенные претензии выдавайте.

Я тебе написал пример.

И что я там должен был увидеть? Тела в цикле нету, тип везде интегер, причем один на всю конструкцию и т.д. Зачем там типы и чистота? Кроме как обфускацией это иначе и не назвать. Желательно пояснить в чем преимущества решения на хаскелле, на первый взгляд, там система типов ещё больше все усложняет. Это скорее аргумент против статики.

Вот написал лисповский do на лиспе, он, конечно, не очень( и не оттестирован), но для сравнения выразительности сойдёт:

(defun extr (fn forms &optional (not? nil))
  (let ((pred (if not? #'not #'identity)))
     (mapcan #'(lambda (x)
                 (if (funcall pred (cddr x))
                     (list (funcall fn x))))
             forms)))

(defmacro my-do ((&rest var-forms) (test-form &rest fms) &body body)
  (let ((iter (gensym)))
    `(let ,(extr #'(lambda (x)
                     (list (car x) (cadr x))) var-forms t)
       (labels ((,iter ,(extr #'car var-forms)
                  (cond (,test-form ,@fms)
                        (t ,@body
                           (,iter ,@(extr #'caddr var-forms))))))
         (,iter ,@(extr #'cadr var-forms))))))
       

> Парниш, я на лиспе на 30 летн аверное дольше твоего пишу,

может многое чего и не знаю-что нового сейчас...

Судя по названным реализация уже лет 15 как не пишите, ага.

А по поводу «оптимизирующих компиляторов»

Да при чём здесь оптимизирующие компиляторы, что бы не иметь проблем с библиотеками надо брать SBCL или Clozure CL, кое-что заработает и на CLISP, но будет много трабл. Да и получить сейчас помощью по CMU CL, или тем более GCL весьма проблематично, ибо никому не нужны.

Ну и зачем советовать Common Lisp для ФП, почему тогда Python не посоветовать? Вон в MIT на него переходят и ничего...

Все перечисленные мною реализации-вполне активно развиваются, и проблем с библиотеками, представляете, нет никаких совершенно! Что вам за библиотек не хватает в перечисленных мной?

> проблем с библиотеками, представляете, нет никаких совершенно!

Да что вы такое говорите? А что ж я CMUCL не могу не одного своего проекта загрузить, вечно что-нибудь отваливается, при чём не в мое коде, а в зависимых библиотеках? И SLIME постоянно вылетает, вот незадача... А GCL так вообще цирк, вообще ни одного проекта не припомню, который бы GCL официально поддерживал: если там что вдруг и заработает, то это будет чистая случайность...

Что вам за библиотек не хватает в перечисленных мной?

Библиотеки, они вообще обычно отдельно от реализаций идут, сами по себе, сюрприз?

Что вы свободного предложите кроме SBCL и почему?

>Примерно как ворон от письменного стола.

да ну. оба заявляют, какие классы функции доступны на типе, если для нашего нового типа будет своя/дополненная реализация от наследованного, то что-то вообще различий невидно.

Тела в цикле нету

А очень надо, да?

Ну вот, пажалста:

evenLoop :: Integer -> LispDo () String
evenLoop n = 
    proc () -> 
        do k <- loopVar 0 -< (\k -> k + 2) 
           stopIf -< k > n 
           let z = k^2
           returnA -< show (k + z) 

тип везде интегер, причем один на всю конструкцию

Ну посмотри повнимательнее. В testLoop переменных две.

Зачем там типы и чистота?

Можно и сайд-эффекты добавить, это же первый драфт был. Вот тебе второй:

{-# LANGUAGE Arrows, ExistentialQuantification #-}
module LispDo where
import Prelude hiding (id, (.))
import Control.Category
import Control.Arrow
import Control.Monad
data LispDo arrow x y = forall state. LispDo state (arrow (x, state) (y, Maybe state))
runLispDo :: ArrowChoice arrow => LispDo arrow x y -> arrow x y
runLispDo (LispDo init body) = proc x -> runLispDo' -< (x, init) where
    runLispDo' =
        proc (x, oldState) ->
            do (y, mbNewState) <- body -< (x, oldState)
               case mbNewState of
                 Nothing -> returnA -< y
                 Just newState -> runLispDo' -< (x, newState)
evalLispDo :: LispDo (->) () x -> x
evalLispDo lispDo = runLispDo lispDo ()
execLispDo :: Monad m => LispDo (Kleisli m) () x -> m x
execLispDo lispDo = runKleisli (runLispDo lispDo) ()
loopVar :: Arrow arrow => a -> LispDo arrow (a -> a) a
loopVar init = LispDo init (proc (f, x) -> returnA -< (x, Just $ f x))
lVar :: Arrow arrow => a -> LispDo arrow a a
lVar init = loopVar init . arr const
stopIf :: Arrow arrow => LispDo arrow Bool ()
stopIf = LispDo () (proc (b, ()) -> returnA -< ((), if b then Nothing else Just ()))
lift :: Arrow arrow => arrow x y -> LispDo arrow x y
lift a = LispDo () liftLispDo where
    liftLispDo =
        proc (x, ()) ->
            do y <- a -< x
               returnA -< (y, Just ())
instance Arrow arrow => Category (LispDo arrow) where
    id = arr id
    LispDo init2 body2 . LispDo init1 body1 = LispDo (init1, init2) lispDoCompose
        where
          lispDoCompose =
              proc (x, (oldState1, oldState2)) ->
                  do (y, mbNewState1) <- body1 -< (x, oldState1)
                     (z, mbNewState2) <- body2 -< (y, oldState2)
                     returnA -< (z, liftM2 (,) mbNewState1 mbNewState2)
instance Arrow arrow => Arrow (LispDo arrow) where
    arr h = LispDo () (proc (x, ()) -> returnA -< (h x, Just ()))
    first (LispDo init body) = LispDo init lispDoFirst
        where
          lispDoFirst =
              proc ((x, z), oldState) ->
                  do (y, mbNewState) <- body -< (x, oldState)
                     returnA -< ((y, z), mbNewState)
instance ArrowChoice arrow => ArrowChoice (LispDo arrow) where
    left (LispDo init body) = LispDo init lispDoLeft
        where
          lispDoLeft =
              proc (xOrZ, oldState) ->
                  case xOrZ of
                    Left x ->
                        do (y, mbNewState) <- body -< (x, oldState)
                           returnA -< (Left y, mbNewState)
                    Right z -> returnA -< (Right z, Just oldState)
instance ArrowLoop arrow => ArrowLoop (LispDo arrow) where
    loop (LispDo init body) = LispDo init lispDoLoop
        where
          lispDoLoop =
              proc (x, oldState) ->
                  do rec {((y, z), mbNewState) <- body -< ((x, z), oldState);}
                     returnA -< (y, mbNewState)
-- Testing:
evenLoop :: Integer -> LispDo (->) () Integer
evenLoop n =
    proc () ->
        do k <- loopVar 0 -< (\k -> k + 2)
           stopIf -< k > n
           returnA -< k
testLoop :: LispDo (->) () Integer
testLoop =
    proc () ->
        do rec {k <- lVar 0 -< k+1;}
           rec {m <- lVar 1 -< m*2;}
           stopIf -< k > 10
           returnA -< m
printLoop :: LispDo (Kleisli IO) () ()
printLoop =
    proc () ->
        do rec {k <- lVar 0 -< k+m;
                m <- lVar 1 -< m+2*k;}
           stopIf -< k > 10
           lift (Kleisli print) -< (m, k)

*LispDo> execLispDo printLoop
(1,0)
(1,1)
(3,2)
(7,5)
(17,12)

на первый взгляд, там система типов ещё больше все усложняет.

Упрощает - по сути, единственное, что реально изобретено - это тип LispDo, всё остальное пишется почти единственным образом.

Вот написал лисповский do на лиспе, он, конечно, не очень( и не оттестирован), но для сравнения выразительности сойдёт:

Ну, а я сделал без метапрограммирования, с большими возможностями (помимо упомянутого контроля за сайд-эффектами - переменные цикла можно объявлять не только в его начале, но и в середине, условий выхода может быть несколько (работает их дизъюнкциия) и они тоже объявляются в любом месте) и заработало оно с первого раза (как только скомпилилось без ворнингов). Ещё раз: КАЖДЫЙ тест заработал с первой попытки. Плюс, от первого драфта ко второму поменялся тип - а тесты продолжают работать, их переписывать не нужно. И при этом - все типы остаются согласованными.

И как ты собираешься сравнивать выразительность, если не знаешь Хаскель?

На Linux SBCL равных нет, на других платформах возможно стоит присмотреться к Clozure CL (например, под виндой есть нормальные потоки, в отличие от SBCL).

оба заявляют, какие классы функции доступны на типе

Объявляя класс, мы, фактически, а) объявляем некий новый тип, и б) показываем компилятору, что мы не собираемся (никогда) задавать значения этого типа; вместо этого, компилятор должен вывести их сам по правилам, которые мы ему дадим. Часть (б) не менее важна, чем (а).

Вот есчё одна библиотека для тренировок http://github.com/asmyczek/p4js

С ней пока не разобрался, но в общих чертах в концепцию вписывается

Честно вам скажу-я вообще ни одного крупного (более 2-3 мегабайт кода) проекта не припомню, чтоб без допиливания заработали в любой из реализаций:-) Боле того-очень много серьезных проектов были сделаны давно, и ориентированы или на устаревшие или собственнические реализации.

Так что допиливание-это нормальная практика с CL и раньше была, и сейчас есть. Всегда было несколько крупнейших реализаций, со своими особенностями, под которые было заточено большинство проектов. Такова природа Lisp сообщества.

(Не ориентированность на GCL многих проектов-так GCL же не развивался много лет. Это в последнее время за него существенно принялись.)

Вопчем, слушай сюда

Хош изучить функциональщину - изучай параллельно Хаскель и Лисп (как это делаю я). Узнаешь много нового и интересного. Натренируешь мозг. Синтаксис Хаскеля только на первый взгляд кажется ужасным, пока не поймёшь в чём тут соль :) Как только разберёшься, что и зачем тут - всё становится на свои места. Замечательная книга Practical Common Lisp довольно неплохо переведена на русский язык. REAL WORD HASKEL Есть в сетке на англицком. Вполне понятная и хорошо написанная.

Да, только в начале придётся себя малость поломать на предмет мышления.

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

Про потоки конечно тема да, хорошая, согласен. Их никогда не было «нормальных» в свободных реализациях. Но работы в этом направлении сейчас ведутся.

В этом плане Scheme очень интересна-в одном из самых ранних документов описывающих ее (MIT AIM-349, 1975) уже предполагался multithreading, хотя особенности реализации и не описывались.