LambdaVM

ничо не понял

/me с нетерпением ждёт результатов.

Мощь haskell + обширные библиотеки Java - взрывоопасное сочетание.

высер?

А как оно соотносится с Jaskell? http://jaskell.codehaus.org/

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

Ну что-ж... "...Если звёзды светят, значит кому-то это нужно..." (с) где-то. А вообще посмотрим на производительность этого гибрида ужа с ежом (никого не хочу обидеть: ни фанатов Haskell, ни фанатов Java)...

Видимо, это проект профессора В.С.Л., который на деле хочет доказать, что JVM, неоптимизированная под хвостовую рекурсию, не подходит для реализации функциональных языков

>А вообще посмотрим на производительность этого гибрида ужа с ежом (никого не хочу обидеть: ни фанатов Haskell

Типа, Хаскелл - тормоз? Я тоже так думал :) Но на http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&... по совокупности смотрится неплохо. А если ещё учесть память и объём кода - http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&... то уже совсем интересно :)

jaskell - это не haskell, это так "скриптовый язык по мотивам".

> Видимо, это проект профессора В.С.Л., который на деле хочет доказать, что JVM, неоптимизированная под хвостовую рекурсию, не подходит для реализации функциональных языков

Объясните, зачем в ОО языках нужна хвостовая рекурсия? Желательно с примером из реальной жизни который можно использовать в бизнес приложениях

В OO-языках - не нужна. Но JVM то позиционируется как общая платформа, а не как запускалка для ОО-язычка для даунов.

И решение отказаться от поддержки фичи, которой будет пользоваться 0.1% разработчиков, было весьма идиотским. Поскольку это - лучшие из лучших. Это те самые 0.1% разработчиков, кто мог бы делать тулзы для 99.9% оставшихся, тех самых, кому не нужна хвостовая рекурсия, кто готов жрать ОО-языки и не давиться.

она не нужна, но если она есть, то это хорошо.

> Объясните, зачем в ОО языках нужна хвостовая рекурсия?

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

зачем такие страшные слова?

Любопытно..

http://ru.wikibooks.org/wiki/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B_%D1%84%D1%8... ? Ну а также в wikipedia по haskell смотри

> Объясните, зачем в ОО языках нужна хвостовая рекурсия? Желательно с примером из реальной жизни который можно использовать в бизнес приложениях

Отличный танкист из тебя выйдет чувак!

А кто сказал что JVM не поддерживает хвостовую рекурсию?

Оптимизация под неё это удел компилятьра а не JVM

+1

s/компилятьра/JIT/

Хвостовая рекурсия нужна чтобы простые алгоритмы сложно и нечитабельно написанные в высоком функциональном стиле работали не намного хуже чем двухстрочечные прозрачные реализации с применением быдлоцыклов.

>Объясните, зачем в ОО языках нужна хвостовая рекурсия? Желательно с примером из реальной жизни который можно использовать в бизнес приложениях

Какой вопрос - такой ответ. Рекурсия нужна для работы с рекурсивными структурами данных. А хвостовая - для работы со структурами произвольной глубины.

XML - рекурсивная структура данных.

В ООП для эти целей используются Visitor/Composite

Полноценно работать с рекурсивной структурой данных (список/дерево/s-выражение) без применения рекурсии (пусть и не явной!) невозможно.

Что Вы, я ведь нигде не писал, что Haskell - тормоз. А за ссылки - спасибо, просветился...

>Типа, Хаскелл - тормоз? Я тоже так думал :) Но на http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&...... по совокупности смотрится неплохо.

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

Ну, GHC сам по себе довольно быстр.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&...

> Ну, GHC сам по себе довольно быстр.

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

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

Напиши функцию Аккермана на быдлоциклах, умник. Посмеёмся.

Напиши банальный обход дерева на быдлоциклах, умник. Посмеёмся.

>Напиши банальный обход дерева на быдлоциклах, умник. Посмеёмся. Банальный обход обычно уже давно реализован - только функтор подставить.

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

>Полноценно работать с рекурсивной структурой данных (список/дерево/s-выражение) без применения рекурсии (пусть и не явной!) невозможно.

До сих пор ни один человек не привел, даже банального, примера где в Жабе нужна ХВОСТОВАЯ рекурсия. Про обычный обход дерева рассказывать не надо - стековой рекурсии достаточно.

Тут один гений программирования жаловался на ограниченный размер метода в жаве - руки надо отрывать таким умельцам, которые пишут многостраничные методы.

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

конструктивисты уже доперли, что в реальном мире объекты имеют-таки свойства создаваться, существовать, занимать чужое пространство, и наконец дохнуть. вполне обычное явление -- последовательность разрушающих присваиваний (x <- 1; x <- 2) -- вещь, которая понятна даже детям, -- в этом языке превратилась в постоянную головоломку.

монады это, конечно, прикольно (в смысле -- весело), только делают-ли программирование проще? нет. в топку все это...

> не понимаю, нафиг вообще этот хаскель нужен?

Для практики. То, что на C++ или Java будет стоить 100 человеколет, с Хаскеллем делается за 100 человекомесяцев. Только человеки, конечно же, нужны более умные и качественные, а не такой бракованный материал, как ты.

> Для практики. То, что на C++ или Java будет стоить 100 человеколет, с Хаскеллем делается за 100 человекомесяцев.

врёшь. посмотри стандартную библиотеку ghc -- куча всяких монад-комбинаторов и прочих медитаций над абсртакциями, и до сих пор нет _полноценных_ биндингов к Xlib (с тем, с чем столкнулся в реальной жизни). в принципе та же самая тенденция наблюдается и в отношении к прочим привычным вещам: поддержке rdbms, ipc, и т.п. если для хаскела такие тривиальные задачи до сих пор не решены, почему реальные проекты должны писаться быстрее?

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

> последовательность разрушающих присваиваний (x <- 1; x <- 2) -- вещь, которая понятна даже детям

Вот этого не надо! :) Когда я в 7 лет впервые увидел в книжке про БЕЙСИК конструкцию "x = x + 1", я испытал тяжелейшее душевное потрясение. Во-первых, из-за того, что для оператора разрушающего присваивания какой-то идиот додумался использовать символ равенства, который я тогда вполне знал и понимал. "Это как такое может быть, чтобы x = x + 1, когда x != x + 1?! А точнее, x < x + 1". Во-вторых, из-за того, что тут неявно вводится понятие времени. То есть, в момент времени t1 x у нас был равен, например, 1, а в момент времени t2 > t1 этот x равен уже 2. Я же привык думать, что все математические выражения постоянны и незыблемы. В самом деле, если значение одного и того же выражения сегодня уже не такое, как вчера, да и вообще, может меняться в самый неподходящий момент, то это блин чистейшая шиза. Вот что примерно я ощутил, познакомившись впервые с деструктивным присваиванием.

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

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

Зри сюда: http://www.linux.org.ru/jump-message.jsp?msgid=1439200#1439417

Мы ведь любим и чтим русскую литературу? =)

>То, что на C++ или Java будет стоить 100 человеколет, с Хаскеллем делается за 100 человекомесяцев.

Мягко выражаясь - это гипотеза, которую никто не проверял на практике не станет.

Бессмысленное злобствование некоторых по поводу Java с одной стороны забавляет, но с другой стороны показывает усиливающийся упадок культуры народа под действием демократии, реформ, телевидения, пепси-колы и подобной дряни.

>То, что на C++ или Java будет стоить 100 человеколет, с Хаскеллем делается за 100 человекомесяцев.

Мягко выражаясь - это гипотеза, которую никто не проверял на практике и не станет.

Бессмысленное злобствование некоторых по поводу Java с одной стороны забавляет, но с другой стороны показывает усиливающийся упадок культуры народа под действием демократии, реформ, телевидения, пепси-колы и подобной дряни.

> и до сих пор нет _полноценных_ биндингов к Xlib

А вот это не надо. Для xmonad уже все дописали. Нужно будет, еще сделают -- это всего лишь ffi

> поддержке rdbms

hdbc, hdbc-odbc

> ipc

System.Posix.Signals

> хаскель это вещь в себе, как любая абстрактная теория. его основная проблема в том, что он пытается как-то по своему интерпретировать законы реального мира.

реального мира, да? фиговая такая быдлокодерская реальность у нас :-)

Читайте вот этого перца http://thesz.livejournal.com/tag/%D0%A5%D0%B0%D1%81%D0%BA%D0%B5%D0%BB%D1%8C интересные вещи пишет

> А вот это не надо. Для xmonad уже все дописали.

Коли речь зашла о xmonad. Если такие умные, подскажите реализацию ffi для XGetClassHint() . В библиотеке ее нет. К python биндинг сочинился нараз, а для этой шняги (хаскел) черт ногу сломит. =)

> Мягко выражаясь - это гипотеза, которую никто не проверял на практике и не станет.

Проверяли, уже как минимум пять разных независимых экспериментов было. Java и C++ везде сливали.

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

ты был каким-то неправильным ребенком. ) в действительности, шиза у математиков. в природе все меняется. "нельзя войти в одну и ту же реку дважды". поэтому абстрактные теории классической математики хреново интерпретируются в контексте реального мира. реальные данные могут теряться, программы -- глючить, память -- ограничена, актуальность информации -- зависит от времени, ... это -- данность, наш мир (скорее всего) таков. и вот эти, кажется, уже просекли фишку: http://ru.wikipedia.org/wiki/Конструктивная_математика ;)

> Коли речь зашла о xmonad. Если такие умные, подскажите реализацию ffi для XGetClassHint() . В библиотеке ее нет. К python биндинг сочинился нараз, а для этой шняги (хаскел) черт ногу сломит. =)

Сейчас посмотрел в сорсы Graphics.X11.Xlib.Extras, тут все совершенно очевидно. Даже без знания хаскеля все пишется по аналогии :-)

Кстати, насчет xmonad -- сам давно хочу его как следует попилить. Если будет что-то интересное, с радостью помогу.

> Сейчас посмотрел в сорсы Graphics.X11.Xlib.Extras, тут все совершенно очевидно. Даже без знания хаскеля все пишется по аналогии :-)

Нужен именно полнофункциональный (каламбур'с) пример очевидного кода, чтобы засунуть в Graphics.X11.Xlib.Extras . Либо покажи рабочий код, либо иди лесом дальше корить JVM отсутствием хвостовой рекурсии, вместе с прочими бестолковыми теоретиками. ;)

Может, я чего-то не прокупил в этой статье, и вы мне убогому сейчас откроете глаза, но как я понял, "эволюция объектов" в этой конструктивной математике понимается в смысле марковских нормальных алгорифмов. Имхо они ближе, всё-таки, к функциональщине и лямбда-исчислению, ну да ладно, за эволюцию и зависимость от времени с грехом пополам сойдут. НО ГДЕ ТАМ Профессором проклятое ДЕСТРУКТИВНОЕ ПРИСВАИВАНИЕ? =)

Да пожалуйста. 15 минут

Код совершенно очевиден, если понимать что такое ffi

import Foreign.C.String

....

data ClassHint = ClassHint {
  resName :: CString,
  resClass :: CString
}

instance Storable ClassHint where
    alignment _ = alignment (undefined :: CInt)
    sizeOf _ = #{size XClassHint}
    peek p = return ClassHint
                `ap` (#{peek XClassHint, res_name                } p)
                `ap` (#{peek XClassHint, res_class               } p)
    poke p ch = do
        #{poke XClassHint, res_name } p $ resName ch
        #{poke XClassHint, res_class } p $ resClass ch

foreign import ccall unsafe "XlibExtras.h XGetClassHint"
    xGetClassHint :: Display -> Window -> Ptr ClassHint -> IO ()
    
getClassHint :: Display -> Window -> IO ClassHint 
getClassHint d w = do 
    alloca $ \ch_return -> do
        xGetClassHint d w ch_return 
	p <- peek ch_return
	xFree ch_return
	return p

Ах да, это не просто так, это патч к Graphics.X11.Xlib.Extras

за код -- респект! если теперь сможешь еще и внятно объяснить, что каждая конструкция обозначает, в этом "очевидом коде", будешь вообще молодец. больше всего не понятно слово `ap`.

зы: не работает. :(

мой интуитивный быдловариант выглядит так:

data ClassHint = ClassHint { resName :: String , resClass :: String }

instance Storable ClassHint where sizeOf _ = #{size XClassHint}

alignment _ = alignment (undefined :: CInt)

peek p = do p_res_name <- (#{peek XClassHint, res_name} p) :: IO CString p_res_class <- (#{peek XClassHint, res_class} p) :: IO CString res_name <- peekCString p_res_name res_class <- peekCString p_res_class xFree p_res_name xFree p_res_class return $ ClassHint res_name res_class

getClassHint :: Display -> Window -> IO ClassHint getClassHint d w = alloca $ \ p -> do xGetClassHint d w p peek p

foreign import ccall unsafe "XlibExtras.h XGetClassHint" xGetClassHint :: Display -> Window -> Ptr ClassHint -> IO Status

и даже каким-то магическим образом функционирует, но я понимаю лишь 10% этого кода :(

за код -- респект! если теперь сможешь еще и внятно объяснить, что 
каждая конструкция обозначает, в этом "очевидом коде", будешь вообще 
молодец. больше всего не понятно слово `ap`.

зы: не работает. :(

мой интуитивный быдловариант выглядит так:

data ClassHint = ClassHint
                        { resName  :: String
                        , resClass :: String
                        }

instance Storable ClassHint where
    sizeOf _ = #{size XClassHint}

    alignment _ = alignment (undefined :: CInt)

    peek p = do 
    	p_res_name  <- (#{peek XClassHint, res_name}   p) :: IO CString
    	p_res_class <- (#{peek XClassHint, res_class}  p) :: IO CString
	res_name    <- peekCString p_res_name
	res_class   <- peekCString p_res_class
	xFree p_res_name
	xFree p_res_class
        return $ ClassHint res_name res_class

getClassHint :: Display -> Window -> IO ClassHint
getClassHint d w 
	=  alloca $ \ p -> do
		xGetClassHint d w p
		peek p

foreign import ccall unsafe "XlibExtras.h XGetClassHint"
    xGetClassHint :: Display -> Window -> Ptr ClassHint -> IO Status

и даже каким-то магическим образом функционирует, но я понимаю лишь 10% этого кода :(

Я, видать, зря сделал xFree.

В доках по Control.Monad :

---

ap :: Monad m => m (a -> b) -> m a -> m b

In many situations, the liftM operations can be replaced by uses of ap, which promotes function application.

return f `ap` x1 `ap` ... `ap` xn

is equivalent to

liftMn f x1 x2 ... xn

---

Может, я бы сам такое и не сообразил бы написать, но в X11-extras такой стиль является стандартом :-)

Твой код вобще правильнее, потому что я даже из СString сделать String поленился :-)

> ГДЕ ТАМ Профессором проклятое ДЕСТРУКТИВНОЕ ПРИСВАИВАНИЕ? =)

может и я что-то не так понял. просто хотел подчеркнуть мысль: математики -- ушлый народ. они уже давно разрабатывают свои чудесные теории в отрыве от реальности. и ужасно гордятся их абстрактной красотой и стройностью.

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

мир таков, что память ограничена, объекты имеют свойства эволюционировать, появляться и исчезать. в реальности даже 2 + 2 = 4 только в том случае, если отыщется свободное место для этих 4, и ничего не сглючит из-за перепада напряжения и т.п. иначе может быть совсем другой результат (при котором тоже нужно как-то действовать, на что математика ответов не даёт).

вот и хотят математики виртуальную машину, где объекты существуют вечно, память -- бесконечна и т.п.

есть мнение, что jvm придумана для реальных приложений, для которых она прекрасно подходит. то что она не стыкуется с абстрактно-математическим buzzword -- проблемы этой самой математики, а не виртуальной машины.