Точно так же Scala — очень практичный язык, потому что компилируется в Java и использует все его библиотеки. А библиотек для Java навалом, прекрасных, чего нельзя сказать о хаскеле.
Хаскел мне тоже нравится, конечно, и на нём можно писать, но он из другой культурной среды. Для меня Scala стала естественным выбором, потому что я до этого 12 лет писал на джаве, а также был Smalltalk-энтузиастом и ООП не воспринимаю как ненужное зло (чем грешат многие функциональщики).
Но, конечно, люди приходят в ФП и из других языков программирования.
Интересно, это ЖЖ рассылает уведомления об упоминаниях, или вы их сами находите? :)
> А библиотек для Java навалом, прекрасных, чего нельзя сказать о хаскеле. Я бы сказал, что это для Haskell очень много прекрасных библиотек, а для Java большинство библиотек ужасны, а наиболее популярные - просто нормальные. :)
Но с "практичностью" Scala как абстрактной характеристикой (средней по больнице) соглашусь - в своей нише у него конкурентов просто нет (пока что).
Я не считаю ООП злом само по себе - как и ФП не считаю панацеей. Но как по мне, так Scala наглядно демонстрирует порочность смешения одного со вторым. Одерски - повторюсь - очень умный мужик, и проделал огромную работу, но чтобы разобраться полностью в том как он соединяет в Scala ФП и ООП мне сильно нехватает знаний как первого, так и второго. При том что мне хватило знаний ФП чтобы в Haskell пользоваться existential types и делать инкапсуляцию с их помощью. При этом пользоваться такими продвинутыми ФП-приёмами в Scala сложнее, чем в Haskell уже из-за одного только более громоздкого синтаксиса, а если не пользоваться, то зачем он тогда вообще нужен?
Кстати, как-то раз на собственном опыте убедился, что Streams в Scala (ровно как и в Clojure и многих других) - "обман трудящихся", потому что когда ленивость по-настоящему нужна, она нужна и в хвосте, и в голове, и в самих значениях, там хранящихся. thesz совершенно правильно говорил, что ленивость должна быть правилом, а строгость - исключением, иначе она просто не работает.
Впрочем, наверное, если осилить полностью Scala, то потом никакие Agda 2 и ATS не страшны! :) А чем сильнее программисты напрягают мозг и чем таких больше - тем лучше для индустрии и человечества. ;) Так что я не против Scala - вполне таки за. :)
Пользой, т.е. диапазоном решаемых задач. Исчисление времени ставит уйму задач, и joda.time решает очень многие из них. И API её, для Джавы, почти идеально краток. Мой вкус, конечно, испорчен, почти как у тех, кто любит PHP.
Не вижу: * Итервалов дат. Арифметики над интервалами дат: сравнение/пересечение/дополнение; * Частичных дат (хотя что-то похожее я, кажется, увидел), и типа данных "поле даты" со значением "день/час/минута/секунда"; * Аналога йодовского "периода", как-то "2 дня 3 часа" (это не всегда 51 час).
Может быть, это всё делается средствами другой части стандартной библиотеки Хаскелля - буду рад просветиться.
Но вообще, я был излишне резок. Мне показалось, что в time нет операции "следующий вторник после 16го числа" или разных типов для даты с таймзоной и без. Присмотрелся - увидел.
>Арифметики над интервалами дат: сравнение/пересечение/дополнение;
Возможно сделать через пары дат. Не спорю, что этого нет, но это тривиально.
http://www.haskell.org/ghc/docs/6.10.4/html/libraries/time/Data-Time-LocalTime.html содержит "поля данных": см TimeOfDay и LocalTime. LocalTime содержит Day, который может быть спроецирован в год, месяц и день.
Follow the types!
Насчёт периода не знаю. Наверняка это тоже можно сделать и это опять же будет тривиально.
Да, интервалы, наверное, даже можно соорудить из time и intervals.
> Data-Time-LocalTime содержит "поля данных": см TimeOfDay и LocalTime. LocalTime содержит Day, который может быть спроецирован в год, месяц и день.
Это не то. В Йоде я могу соорудить период "3 часа", состоящий отдельно из переменных "количество=3" и "единица измерения=час". Хотя полезность этой фичи и маргинальна.
> Насчёт периода не знаю. Наверняка это тоже можно сделать и это опять же будет тривиально.
А вот тут не верю. Не вижу, чтобы time-овские абстракции подходили для выражения такого понятия. И операции прибавления периода "add :: LocalTime -> TimeOfDay -> LocalTime" или "add :: LocalTime -> Day -> LocalTime" я не вижу, всюду прибавляются только Int-ы. Это, пожалуй, моя единственная существенная претензия к time. Прибавлять именно Period приходится довольно часто. При построении графиков, например, надо идти в цикле с шагом в Period, и алгоритм должен работать для Period-а размерности Day и размерности Pico - а в time это разные типы.
хм, а как выразить и работать одновременно в зонах CST-6CDT, Europe/Kiev, America/Los_Angeles? как они все ведут себя на весенне/осенних сдвигах? а две последние на исторических сдвигах?
вітя, мінус joda - власна dbtz. ми не використовуємо joda-time dbtz, адаптуємо jre dbtz + parser POSIX TZ, аби коли закони міняються сис міняв конфу енва, а не викладати "новий випуск".
SOAP? Не надо вот этого вот. В крайнем случае SOAP-консьюмер, если некуда деваться, но если кто-то напишет SOAP-сервер на нормальном языке программирования, он будет неправ, потому что SOAP — это зло, и не надо его умножать.
Под «прекрасным» я понимаю в том числе и наличие приборов и материалов, позволяющих делать прекрасные вещи.
Например, в скале есть собственный фреймворк для гуёв, а можно и джавские использовать. Есть много средств для продуктивной работы с базами данных, с вебом, с сетью. Например, где в хаскеле аналог Netty и MINA? Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений? Ничего нет, только сырые сокеты. А как красиво можно было бы сделать... Но никто не сделал.
В скале, если чего-то нет (например, хороших средств для работы с датами), можно взять джавовские, и всё будет работать прекрасно. А тут — либо есть, либо нет. Самому всё не напишешь.
Я не знаю, что такое MINA, но я посмотрел, что такое Netty: "an asynchronous event-driven network application framework" (http://www.jboss.org/netty/)
Прошу прощения, но это натурально не имеет смысла в случае ghc. В GHC RTS весь ввод-вывод асинхронный, на событиях. В этом смысле сеть ничем не отличается от других действий по вводу-выводу.
>Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений?
Пожалуйста, ознакомьтесь с текущим положением дел в мире Хаскеля. Там всё не так плохо, как вы себе представляете. И коль уж зашла речь про понимание, то по-моему мнению, вы не представляете себе, насколько в мире Scala плохо.
Простой пример. Хочу попросить вас посмотреть вот на этот тип: http://hackage.haskell.org/packages/archive/containers/0.5.0.0/doc/html/src/Data-IntMap-Base.html#IntMap
Вот он, чтобы далеко не ходить:
-- See Note: Order of constructors
data IntMap a = Bin {-# UNPACK #-} !Prefix {-# UNPACK #-} !Mask !(IntMap a) !(IntMap a)
| Tip {-# UNPACK #-} !Key a
| Nil
type Prefix = Int
type Mask = Int
type Key = Int
Какой размер будет у значения конструктора Tip в случае реализации этого типа на Scala? Моя прикидка - 5 слов (3 слова на VMT, ключ и указатель на данные + два слова на заголовок объекта). В случае Хаскеля - три слова: тэг, ключ и указатель на значение.
Для IntSet, построенного по той же схеме, но без значений (два слова на конструктор Tip), лишних данных будет ещё больше, вроде, 100% лишнего.
Это я к тому, что большими объёмами символьных вычислений на Scala пользоваться.менее выгодно, чем практически возможно, а мой опыт говорит, что символьные вычисления чрезвычайно практичны в самых разных областях.
Хочу пояснить: я не отрицаю сугубой юзабельности Java - напротив, очень уважаю её стабильность, качество и проработанность. С удовольствием пользуюсь в благоприятных случаях.
Но ничего прекрасного я в Java и окрестностях не вижу. В этом нет ничего плохого, это не мешает get things done.
В самой джаве как языке программирования я тоже ничего прекрасного не вижу. Но это прекрасная платформа.
И можно удачно сочетать стабильность и надёжность джавы с передним краем функционального программирования. Это Clojure (для скобочников) и Scala (для любителей типизации).
А можно использовать Хаскель и какую-либо шину сообщений. Тогда вообще всё великолепно - "стабильность и надёжность джавы" и передний край функционального программирования.
С первым утверждением полностью согласен, а со вторым - не полностью. :)
Во-первых, Clojure - при том, что он мне нравится и я на нём пишу - не передний край ФП, а скорее bottom line. Почти как сама Java для ООП в своё время.
Во-вторых, особенности JVM объективно мешают реализовывать на ней ФП языки.
В-третиих, я не считаю Scala _удачным_ сочетанием Java и ФП.
Но это уже пошла вкусовщина и личные оценки, а в видении объективной картины мы, как мне кажется, совпадаем.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
8/7/12 11:08 (UTC)Хаскел мне тоже нравится, конечно, и на нём можно писать, но он из другой культурной среды. Для меня Scala стала естественным выбором, потому что я до этого 12 лет писал на джаве, а также был Smalltalk-энтузиастом и ООП не воспринимаю как ненужное зло (чем грешат многие функциональщики).
Но, конечно, люди приходят в ФП и из других языков программирования.
(no subject)
8/7/12 14:54 (UTC)> А библиотек для Java навалом, прекрасных, чего нельзя сказать о хаскеле.
Я бы сказал, что это для Haskell очень много прекрасных библиотек, а для Java большинство библиотек ужасны, а наиболее популярные - просто нормальные. :)
Но с "практичностью" Scala как абстрактной характеристикой (средней по больнице) соглашусь - в своей нише у него конкурентов просто нет (пока что).
Я не считаю ООП злом само по себе - как и ФП не считаю панацеей. Но как по мне, так Scala наглядно демонстрирует порочность смешения одного со вторым. Одерски - повторюсь - очень умный мужик, и проделал огромную работу, но чтобы разобраться полностью в том как он соединяет в Scala ФП и ООП мне сильно нехватает знаний как первого, так и второго. При том что мне хватило знаний ФП чтобы в Haskell пользоваться existential types и делать инкапсуляцию с их помощью. При этом пользоваться такими продвинутыми ФП-приёмами в Scala сложнее, чем в Haskell уже из-за одного только более громоздкого синтаксиса, а если не пользоваться, то зачем он тогда вообще нужен?
Кстати, как-то раз на собственном опыте убедился, что Streams в Scala (ровно как и в Clojure и многих других) - "обман трудящихся", потому что когда ленивость по-настоящему нужна, она нужна и в хвосте, и в голове, и в самих значениях, там хранящихся.
Впрочем, наверное, если осилить полностью Scala, то потом никакие Agda 2 и ATS не страшны! :) А чем сильнее программисты напрягают мозг и чем таких больше - тем лучше для индустрии и человечества. ;) Так что я не против Scala - вполне таки за. :)
(no subject)
8/7/12 16:23 (UTC)(no subject)
9/7/12 07:45 (UTC)(no subject)
9/7/12 07:50 (UTC)И API её, для Джавы, почти идеально краток.
Мой вкус, конечно, испорчен, почти как у тех, кто любит PHP.
(no subject)
9/7/12 08:24 (UTC)Думаю, на Hackage найдётся библиотека для решения временных задач. :)
(no subject)
9/7/12 08:27 (UTC)Нету, если я правильно смотрел.
(no subject)
10/7/12 13:45 (UTC)(no subject)
10/7/12 19:57 (UTC)* Итервалов дат. Арифметики над интервалами дат: сравнение/пересечение/дополнение;
* Частичных дат (хотя что-то похожее я, кажется, увидел), и типа данных "поле даты" со значением "день/час/минута/секунда";
* Аналога йодовского "периода", как-то "2 дня 3 часа" (это не всегда 51 час).
Может быть, это всё делается средствами другой части стандартной библиотеки Хаскелля - буду рад просветиться.
Но вообще, я был излишне резок. Мне показалось, что в time нет операции "следующий вторник после 16го числа" или разных типов для даты с таймзоной и без. Присмотрелся - увидел.
(no subject)
10/7/12 20:29 (UTC)Возможно сделать через пары дат. Не спорю, что этого нет, но это тривиально.
http://www.haskell.org/ghc/docs/6.10.4/html/libraries/time/Data-Time-LocalTime.html содержит "поля данных": см TimeOfDay и LocalTime. LocalTime содержит Day, который может быть спроецирован в год, месяц и день.
Follow the types!
Насчёт периода не знаю. Наверняка это тоже можно сделать и это опять же будет тривиально.
(no subject)
11/7/12 20:15 (UTC)> Data-Time-LocalTime содержит "поля данных": см TimeOfDay и LocalTime. LocalTime содержит Day, который может быть спроецирован в год, месяц и день.
Это не то. В Йоде я могу соорудить период "3 часа", состоящий отдельно из переменных "количество=3" и "единица измерения=час".
Хотя полезность этой фичи и маргинальна.
> Насчёт периода не знаю. Наверняка это тоже можно сделать и это опять же будет тривиально.
А вот тут не верю. Не вижу, чтобы time-овские абстракции подходили для выражения такого понятия. И операции прибавления периода "add :: LocalTime -> TimeOfDay -> LocalTime" или "add :: LocalTime -> Day -> LocalTime" я не вижу, всюду прибавляются только Int-ы.
Это, пожалуй, моя единственная существенная претензия к time.
Прибавлять именно Period приходится довольно часто. При построении графиков, например, надо идти в цикле с шагом в Period, и алгоритм должен работать для Period-а размерности Day и размерности Pico - а в time это разные типы.
(no subject)
12/7/12 14:38 (UTC)как они все ведут себя на весенне/осенних сдвигах?
а две последние на исторических сдвигах?
вітя, мінус joda - власна dbtz.
ми не використовуємо joda-time dbtz, адаптуємо jre dbtz + parser POSIX TZ,
аби коли закони міняються сис міняв конфу енва, а не викладати "новий випуск".
(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
8/7/12 17:11 (UTC)(no subject)
9/7/12 07:36 (UTC)Batteries included я никому не обещал, правда же? :)
GUI всё ещё слабое место ФП, поскольку не найдено подходящего формализма, впрочем Fudgets в чём-то прекрасны, хотя и не юзабельны.
А какая нужна работа с сетью не через сырые сокеты?
(no subject)
9/7/12 07:39 (UTC)HTTP, REST/SOAP, SMTP со всеми прилежащими multipart-ами - для начала.
(no subject)
9/7/12 08:17 (UTC)Ну и там как минимум 3 годных веб-фреймворка...
Но я сильно в Hackage не закапывался.
(no subject)
9/7/12 09:44 (UTC)HTTP и SMTP нужны, увы.
(no subject)
9/7/12 10:03 (UTC)Коннектиться к легаси бывает нужно. Хотя этот процесс никогда не бывает прекрасен.
(no subject)
9/7/12 09:41 (UTC)Например, в скале есть собственный фреймворк для гуёв, а можно и джавские использовать. Есть много средств для продуктивной работы с базами данных, с вебом, с сетью. Например, где в хаскеле аналог Netty и MINA? Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений? Ничего нет, только сырые сокеты. А как красиво можно было бы сделать... Но никто не сделал.
В скале, если чего-то нет (например, хороших средств для работы с датами), можно взять джавовские, и всё будет работать прекрасно. А тут — либо есть, либо нет. Самому всё не напишешь.
(no subject)
9/7/12 10:53 (UTC)Прошу прощения, но это натурально не имеет смысла в случае ghc. В GHC RTS весь ввод-вывод асинхронный, на событиях. В этом смысле сеть ничем не отличается от других действий по вводу-выводу.
>Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений?
binary package: http://hackage.haskell.org/package/binary-0.5.0.1
Пожалуйста, ознакомьтесь с текущим положением дел в мире Хаскеля. Там всё не так плохо, как вы себе представляете. И коль уж зашла речь про понимание, то по-моему мнению, вы не представляете себе, насколько в мире Scala плохо.
Простой пример. Хочу попросить вас посмотреть вот на этот тип: http://hackage.haskell.org/packages/archive/containers/0.5.0.0/doc/html/src/Data-IntMap-Base.html#IntMap
Вот он, чтобы далеко не ходить:
-- See Note: Order of constructors data IntMap a = Bin {-# UNPACK #-} !Prefix {-# UNPACK #-} !Mask !(IntMap a) !(IntMap a) | Tip {-# UNPACK #-} !Key a | Nil type Prefix = Int type Mask = Int type Key = IntКакой размер будет у значения конструктора Tip в случае реализации этого типа на Scala? Моя прикидка - 5 слов (3 слова на VMT, ключ и указатель на данные + два слова на заголовок объекта). В случае Хаскеля - три слова: тэг, ключ и указатель на значение.Для IntSet, построенного по той же схеме, но без значений (два слова на конструктор Tip), лишних данных будет ещё больше, вроде, 100% лишнего.
Это я к тому, что большими объёмами символьных вычислений на Scala пользоваться.менее выгодно, чем практически возможно, а мой опыт говорит, что символьные вычисления чрезвычайно практичны в самых разных областях.
(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
10/7/12 13:46 (UTC)http://singalen.livejournal.com/249003.html?thread=1682603#t1682603
Надеюсь, вы с ним ознакомились и мне бы хотелось услышать ваш ответ.
(no subject)
9/7/12 07:44 (UTC)Но ничего прекрасного я в Java и окрестностях не вижу. В этом нет ничего плохого, это не мешает get things done.
(no subject)
9/7/12 09:42 (UTC)И можно удачно сочетать стабильность и надёжность джавы с передним краем функционального программирования. Это Clojure (для скобочников) и Scala (для любителей типизации).
(no subject)
9/7/12 10:55 (UTC)(no subject)
Posted by(no subject)
Posted by(no subject)
11/7/12 06:42 (UTC)Во-первых, Clojure - при том, что он мне нравится и я на нём пишу - не передний край ФП, а скорее bottom line. Почти как сама Java для ООП в своё время.
Во-вторых, особенности JVM объективно мешают реализовывать на ней ФП языки.
В-третиих, я не считаю Scala _удачным_ сочетанием Java и ФП.
Но это уже пошла вкусовщина и личные оценки, а в видении объективной картины мы, как мне кажется, совпадаем.
(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by