Третья встреча Scala-разработчиков в Санкт-Петербурге

ФП вредно и бесполезно. ООП в стиле Java идеально и самодостаточно.

А вот и нищеброд пожаловал!

ФП вредно и бесполезно

диванный эксперт в треде, все в машину!

Что-то последнее время анонимусов-троллей на ЛОРе развелось, причем еще и далеко не тонких, как хотелось бы

деградирует анон, да.

Я может и диванный, но все же эксперт. И свою позицию могу доказать научно.

И свою позицию могу доказать научно.

интересно. только сначала дай формальное определение понятиям «вредно» и «бесполезно», чтобы не вести пустые разговоры.

И свою позицию могу доказать научно.

С нетерпением ждем

vertexua

А ты-то что задёргался? Ты же у нас сертифицированный с головы до ног Java-инженер. Или модных хипстерских журнальчиков начитался?

свою позицию могу доказать научно.

просим, просим!

просим, просим!

Не давите на учёного! Вы же знаете, что наука - это очень сложный и кропотливый процесс. Приходите через года два, а лучше через три, когда статью в pdf можно будет купить со скидкой.

Ну все правильно. Вы так говорите как будто Java и ФП - враги до смерти. Нет, нет, только у безграмотных анонимусов

Вы так говорите как будто Java и ФП - враги до смерти.

Да, про это не раз рассказывал Kuka и другие опытные Java-профессионалы.

А кто ты такой? Какой-то там джуниор с парой месяцев опыта по рисованию окошек для секретарш, фи.

lol. Ну а сам то что можешь сказать, без всяких Kuka? =))

lol. Ну а сам то что можешь сказать, без всяких Kuka? =))

А что ты имеешь против Шмоэля Семёновича? Шмоэль Семёнович - гигант enterprise разработки! ЧЕЛОВЕЧИЩЕ!

Только благодаря таким людям, как Шмоэль Семёнович Кукинштейн, мы пишем операционные системы, которые работают везде — от смарт-карт, мобильников, DVD-проигрывателей до мощнейших кластеров, АЭС и космических аппаратов. Без нас твой компьютер был бы просто грудой железок. Мы обрабатываем аудио и видео и отрисовываем 3D-модели. Благодаря нам компьютеры сегодня находятся на службе у искусства. Мы моделируем, программируем, обсчитываем, анализируем физические, химические и биологические процессы. Без нас не было бы современной медицины и энергетики. Мы обрабатываем огромные массивы данных, обеспечивая логистику, бизнес, экономику и телеком. Без нас ты бы не сидел на ЛОРе и не писал бы чепухи. Мы обеспечиваем оборону. Без нас ты бы ходил в мечеть, носил бы бороду и восхвалял Аллаха. Если бы остался в живых.

А такие как ты, которые не хотят работать, которым только элитные новомодные игрушки подавай, только мешают в его важной и нужной работе.

На лурк не забудь скинуть, одобрят )

Поискал в гугле про Шмоэль Семеновича. Нашлось только «Кукинштейн - 20см». Совсем немного, должен я заметить, для гиганта и ЧЕЛОВЕЧИЩА.

И в чем принципиальная разница?

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

Разница в том, что комбинаторы уже не принадлежат коллекциям.

Раскрой слово «принадлежат»?

Не нужно городить сложную иерархию с наследованием.

Эта иерархия с наследоваением позволяет например сделать так

scala> val set = Set(List(Some(1),Some(2),Some(3)),List(Some(2),None,Some(4)),List(Some(3),None,None)); 
set: scala.collection.immutable.Set[List[Option[Int]]] = Set(List(Some(1), Some(2), Some(3)), List(Some(2), None, Some(4)), List(Some(3), None, None))

scala> for(l <- set; s <- l; x <- s)  yield x
res7: scala.collection.immutable.Set[Int] = Set(1, 2, 3, 4)

Что по факту транслируется в:

set.flatMap(l => l.flatMap(s => s.map(x => x)));

На F# это можно написать тоько если знаешь конкретные типы set,l,s. То есть что-то типа:

Set.flatMap(fun l -> List.flatMap(fun s -> Option.map(fun x-> x) l) set)

Видишь проблему? В скале достаточно чтобы оно было TraversableOnce и у типа есть flatMap и map чем бы оно там в реальности не оказалось. Чтобы сделать это на F#/Ocaml модулях тебе нужно либо точно знать тип либо сделать мегамодуль с кучей полиморфных методов flatMap/map со всеми известными типами, и дописывать это туда, либо изобрести ad-hoc полиморфизм на модулях такого же вида: модуль TraversableOnce который будет иметь метод flatMap со структурной сигнатурой а-ля flatMap : 'A -> 'B < flatMap: 'A->'B; ...> < flatMap 'A -> 'B;....> и т.д. То ечть чтобы это работало тебе придется вынестикак минимум итерацию, append, map, flatMap в некий общий модуль.... короче очень наркоманское решение и все для того чтобы писать на F#:

TraversableOnce.flatMap(fun l -> TraversableOnce.flatMap(fun s -> TraversableOnce.map(fun x-> x) l) set)

Я сейчас хочу сделать скальный аналог for компрехеншенов для для эрланга и столкнулся именно с этой проблемой.

Так что там все весьма неплохо, учитывая возможности.

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

Вот как раз на практике попробуй реализовать на f# абстракцию про которую я говорю и увидишь что изобретаешь ад-хок полиморфизм на модулях, или висишь на делегатах с необходимостью тут же править кучу кода при появлении очередной реализации коллекции.

Kuka и другие опытные Java-профессионалы

I LOLed.

от смарт-карт, мобильников, DVD-проигрывателей

Да, да. Вы у нас все своровали:

“Don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/ Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list.” [Kent Pitman]

Да еще учти что у скалы есть higher kinded types, чего у F# нету, поэтому можно декларировать точные типы там где F# может сводить только к общим в случае указанного решения. Поэтому реализация flatMap для Set вернет точный статически известный Set. А в F# если реализовать это все наркоманство то после общей реализвации какого нить filter в результате получишь TraversableOnce, несморя на то что фильтровал конкретный тип. Поэтому в F#/OCaml все эти комбинаторы в модулях имеют дублирующие реализации - в каждом реализовано отдельно итерация, fold, map и прочие. И с появлением нового типа надо реализовывать стопицот комбинаторов.

Тут вопрос стоит в том, какие выбрать приоритеты. Что важнее, ад-хок полиморфизм, о котором ты пишешь, или простой и понятный код, да еще такой, чтобы запускался на андроиде без проблем?

Кстати, на счет андроида похоже, что все очень серьезно. Жаль. На прошлой неделе приобрел андроид, и была задумка написать одну вещь для него на scala. Похоже, что здесь меня ждет полный облом: Scala 2.9.x's problems with the DalvikVM. Проще и надежнее будет написать на java.

Что важнее, ад-хок полиморфизм, о котором ты пишешь,

Он всего лишь метод. Как показывает практика без такого полиморфизма реализация вышеупомянутого примера это ужас. А заглядывание в реализацию модулей окамла показывает кучу кододубликации. Очень простой и понятной кододубликации.

У меня например сейчас например в эрланге куча пробелм с этим - есть код который надо оптимизировать по перфомансу. НЕсмотря на то что весь код - это набор комбинаторов - я не могу абстрагировать его на стандартных коллекциях от знания о том что именно я фолдаю итерирую или фильтрую - в результате не могу эксперементировать с разными структурами данных без переписывания кучи кода, чтобы он «а теперь другие модули звал». А учитывая что компрехеншены работают только на списках - вообще торба. А если код вложенно итерируется по различным структурам - фан я имею неимоверный. А в скале я бы просто подменил в момент инициализации одну структуру на другую и вуаля - все работает. Хотя конечно реализация этого под капотом значительно больше сносит крышу чем заглянуть в какой нить модуль List и увидеть простую реализацию всех комбинаторов. Только эта простота не помогает с ними работать.

Я думаю, что у тебя не типичный use case. И сочувствую :)

ProGuard или как там его

Да, его зовут ProGuard. Я бы не стал рассчитывать.

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

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

Женитесь на нем, чего уж скрывать то. ;-)

Есть вариант для андроида: использовать scala, но не использовать ни одну ее библиотеку. Только зачем такое счастье? Тем более, компилятор жутко тормозной.

но не использовать ни одну ее библиотеку

Мда, я так понимаю List входит в ее библиотеку. Тяжеловато без него )

А что там с 2.10?

Да, его зовут ProGuard. Я бы не стал рассчитывать.

Насколько я знаю юзание прогуара чуть ли не стандарт для скальных приолжений.

По-моему библиотека коллекция особо не изменилась. Как я понял, проблема в ней.

Я уже особо не слежу, но в какой-то версии они именно коллекции сильно переписывали.

В 2.8 здорово переписали. В 2.9 добавили параллельные коллекции и возможно (??) разные view.

Поддерживаю.