Scala developers thread go!
Привет всем!
Расскажите какие наскальные библотеки, фреймворки и scalaz вы применяете на работе, что применяете и вообще, как оно все?
Правильно ли я понял, что наскальных контор/проектов в Украине скорее нет, чем есть?
Facebook
Twitter
LinkedIn
Ivan Pomidorov
Scalaz кто-нибудь пользуется? Зачем все эти монадные трансформеры нужны? Как Вы его применяете?
Пользуемся. Монадные трансформеры нужны, но это не очень хороший, устаревший способ контроля эффектов. Детали (почему так) есть здесь, например: blog.ezyang.com/...wrong-probably
Е. Могги, когда в
Другие, практически более интересные методы, такие как flavors.me/...b7/custom_plain с точки зрения индустрии, к сожалению, еще в колыбели.
Если отвлечься от монадных трансформеров, то scalaz полезна тем, что там много удобных штук. Есть у вас, например, List[Option[A]], а вы хотите сделать Option[List[A]]. Пожалуйста, .sequence, не надо самому писать преобразоваторов. Хотите вы сделать мап, в результате которого получается List[Option[A]], кроме того вы хотите получить Option[List[A]] на выходе, вместо map + sequence используете сразу traverse. Библиотека позволяет хорошо, коротко писать, если знать о ней вещь или две и если остальная команда пугаться не будет. У нас команда небольшая, разобраться и держать всех в курсе несложно, плюс, ненужной сложности никто, упоровшись, на ровном месте не наворачивает. А там, где scalaz снимает лишнюю сложность, она выглядит просто, естественно.
Ivan Pomidorov
А тайп классы как используются?
Тайпклассы делаются и без scalaz на простой скале в две строчки, просто в scalaz очень много готовых инстансов тайпклассов. (плюс есть еще scalaz-contrib, там их еще пачка).
Как используются — позволяют иметь ад-хок полиморфизм без развесистых иерархий. Если помните Джошуа Блоха, Effective Java, иерархии это вообще лишний раз не очень-то, интерфейсы FTW, а тайпклассы еще и интереснее интерфейсов тем, что вы можете подсовывать инстансы ретроактивно, т.е. можете написать инстанс, который реализует некоторый «интерфейс» для вообще чужого типа (у вас для него, допустим, даже кода нет, только .class), и «научить» этот чужой тип новым штукам. В джаве в случае с интерфейсами для такого понадобилось бы менять код «с той стороны».
Какие еще чисто скаловские библиотеки юзаете? Насколько быстрее идет разработка, если бы писали аналогичный проект на Java?
В текущем проекте из популярного: Akka и Play 2, Specs2 для тестов. И всякое по мелочи вроде scala-graph. В других проектах — Lift, Squeryl, Slick, SubCut, dispatch.
Насколько быстрее не скажу, специально не замеряли, могу только прикидывать—гадать не буду. Субъективно писать на скале гораздо приятнее. Плюс некоторые задачи я не знаю сколько я бы на джаве писал. Например, недавно пригодилась scalaz для написания динамического генератора SPARQL-запросов: в scalaz есть scalaz.Tree и TreeLoc, дерево с зипперами к нему, было удобно работать с AST, представленным в таком виде—функционально написанные трансформации над деревом были просто вот правильной абстракцией, вышло коротко и прозрачно.
А чем Akka так примечательна? Чем акторы лучше того же STM? Или play, знаю ребят которые на нем писали, плевались, потом перешли на Spring MVC.
Знаю ребят, которые перешли на Play, и не плюются: LinkedInАга, а Дойчебанк перешел на скалу :)
Но поскольку вы их (чуваков из ЛинкедИна) знаете, то уточните что именно у них на Плее. Из того что я слышал (в основном из их докладов), на Плее там прототипирование и фронт-энд для __некоторых__ сервисов, каких именно не помню.
Что именно не понравилось/не подошло?Из того что мне не понравилось (есть и положительные моменты):
— Сырой. Мап все асинк контекста может вызывать утечки ресурсов, при том на уровне фреймворка и они отвечают «не пользуйтесь таким сценарием».
— Время перекомпиляции, адское. Поменял
— стиль работы с БД очень убогий (я про джава версию). По факту странная интерпретация АктивРекорд-а.
Общее субъективное ощущение: неудачная калька с РоР.
Building web services with Java and Scala can actually be fun!Снова же чисто субъективно, когда начинают рассказывать про то «фан», то это не добавляет доверия.
.
Выводы:
Для небольших/несложных проектов, вполне может быть полезно. Для больших/сложных проектов выбирать его как основной фреймворк — очень стремно.
Основное применение которое нашел для себя — это просто посмотреть на альтернативный путь и попытаться перенести этот опыт на работу с более зрелыми решениями.
Общее субъективное ощущение: неудачная калька с РоР.
Две пиалы чая этому просветленному. Хотя внутри вроде нормальный и очень эффективный враппер для Netty, но внешне не дотянули
reality_hacker
Знаю ребят, которые перешли на Play,Они еще одновременно и на node.js перешли оказывается! venturebeat.com/.../linkedin-node
Одновременно в 2011 году.Ну да, первая статья про плей в линкедине датируется
Ну в любом случае это к делу не относится.Относится тем, что получается что линкедин любит экспериментировать с разными маргинальными фреймворками, но это не означает что они в них серьезно инвестируют и строят на их свои основные сервисы
Ну и не относится к делу, потому что пример с линкедином — это ирония.Ну или ты теперь просто отмазываешься от сказанной глупости
Документация play — сборка его антипаттернов. Вас провоцируют писать шлак в стиле «очередного веб-стартапа» где вот как легко пишется бложек. Сложно выработать строгость в модульности и поддерживаемости
Scala чуть-чуть ускоряет разработку, не фанатистически и не на порядки. Ваш код просто теперь делает больше. Напиример, написать полностью асинхронное приложение на Java — nightmare, потому на Java вы за X времени бы написали синхронное. А Scala спровоцирует вас, раз уж можно, за X времени написать асинхронное.
Я выше отписал свое расширеное мнение, но относительно удобных некоторых функций я с вами согласен. В нашем проекте все же их было проще написать, вместо серьезного переезда на Scalaz потенциальной завязкой на этом сложном и недокументированом фреймворке
Мы не пользуемся. В принципе тут нужно понимать историю появления таких вещей. Может будет звучать несколько резко. Все описаные примитивы, по крайней мере в области программирования, популяризированы хаскеллем. Этот язык имеет определенные особенности, из-за которых использование аппликативных функторов, монад, причем не достаточно безобидных Future/Option, а достаточно вынужденных в хаскелле State, Reader, IO было полезно.
В Scala этих особенностей нет, потому можно все писать пользуясь state непосредственно, причем на практике мутабельные данные в изолированых точках проще и надеждее, чем запутаные монадические вычисления. Но как же не взять и не притащить хаскелль в скалу, раз язык это позволяет? Так и появился Scalaz.
Более того даже DI делают в функциональном стиле, хотя для скала более прост и идиоматичен OOP стиль. Разработчиков на хаскелле можно понять на 100%. Тяжелее понять разработчиков пишущих на Scala код на хаскелле. Это то же самое если бы я до этого программировал на Python и реализовал лямбдами в Scala ООП так чтобы везде торчал self, мне так привычнее.
После многих лет изучения ФП, прочтения тонн книжек мне стала понятна грань адекватного применения ФП. Я мог пы понять если бы я читал книгу по ФП, где в 20 главах мне рассказывали о всяких морфизмах и теории категорий, а потом в последней главе было бы написано «вот с помощью вышеописаных механизмов мы можем с несколько тысяч строчек кода описать искусственный интеллект, который может выполнять вот такие вот задачи». Это было бы понятно, сложный механизм требуется для решения сложной задачи. Но мне зачастую после этого говорят что я могу круто провалидировать формочку. В этом проблема, фундаментальные алгоритмы из сборников Кнута, Кормена, Скиенны как были, так и есть и именно они обрабатывают наши данные, а не Y-комбинатор
Не все так мрачно, есть чрезвычайно простые вещи в ФП, которые дают просто тонны пользы. Различные способы обработки данных, коллекции, и да, монады для асинхронных вычислений, etc, etc. Но вернувшись к Scalaz, это too much сложности, too much решений притянутых за уши проблем, слишком мало алгоритмических улушчений в обработке данных, чем я собственно занимаюсь на работе
Оффтоп:
Тяжелее понять разработчиков пишущих на Scala код на хаскелле.Кстати, одна из притензий к скала-сообществу (субъективный взгляд со стороны):
НЕТ скала-программистов, есть куча Хаскелл-программитов, Руби-программистов, Джава-программистов, которые пишут свой код в файлах с расширением .scala
И самое забавное что разные фракции еще и срутсо между собой.
Правда. Это мотивирует стать Scala-программистом )
reality_hacker
Коментар порушує правила спільноти і видалений модераторами.
Sergey Kucherenko
По-моему, скала-контор достаточное количество, чтобы желающий мог найти себе вакансию по душе.
Успешно используем Play! 2, Akka, scalaz7, довольны. Кстати, we are hiring (Azigo). ;) На проект pangenx.com. Биоинформатика для фармы, офис в Севастополе.
Кстати, огромное число кандидатов хотят вначале получить работу на скале, а потом начать её учить. Потому что «зачем учить, если работы не будет». Мне такй подход кажется странным по меньшей мере. В духе этого комикса ro-che, ro-che.info/ccc/11
Roman Beslik
Получается тупик. Человек не хочет учить, пока нет работы, вы не даёте работу, пока не выучил.
Да вполне полно народу, которые для себя балуются, или даже пишут пет-проекты. Просто севастополь мало кому нужен :-)
А по многим параметрам лучше Киева, Днепропетровска. Можно кататься на яхтах, и до остального Крыма рукой подать :-)
И при этом с инфрастуктурой все нормально.
Ivan Golovach
Говорят, у Вас вечером после 22.00 некуда пойти, все закрыто. Так ли это?
Не замечал проблемы, знаю в центре с десяток кафешек, которые работают круглосуточно, вроде Кофеина. Есть еще места для рейвящейся молодежи, но мне неинтересно, деталей не знаю.
Друг съехал из Харькова в Севастополь год назад.
Сообщает:
Главный плюс — легко на выходные уйти на природу в горы (что и делает).
Главный минут — в городе мало ночной жизни (В Харькове тоже, но больше).
У нас большая часть команды переехала из Днепра, выбрав Севастополь, как наиболее пригодное место для жизни (именно жизни) в Украине.
Если не Киев, то уж лучше Львов, среди плюсов — львовяне
среди минусов тоже :)
У меня наиболее позитивный опыт. Среди минусов я так понимаю водоснабжение
Я про львовян :) Проехали...
Хз, если уж и переезжать на постоянку то, имхо, стоит двигать на запад к цевилизации, а не в село подальше от оной.
Bogdan Shyiak
Годная тема ушла в срач, который благополучно начал и слил ТС, приведя как пример силы скалы код какого-то школьника.
Вот более интересные (и более реалистичные) примеры scala-кода в сравнении с java bit.ly/1fslPSf
Max Ischenko
Работодатели: djinni.co/...rds=scala&city= DataArt, Sigma, Svitla, Injoit, Azigo.
Котэ гуляющее само по себэ
Расскажите какие наскальные библотеки, фреймворки и scalaz вы применяете на работе, что применяете и вообще, как оно все?Настоящих буйных (к счастью) мало.
Правильно ли я понял, что наскальных контор/проектов в Украине скорее нет, чем есть?
Дайте ей умереть достойно.
ваше мнение очень важно для нас!
Датаарт вробе ищет скалистов, с опытом. Врядли смогут найти много людей с коммерческим опытом в скалке.
Все ищут, это не плавный переход и эксперименты, это массовый набег из-за сильной популяризации на конференциях
это массовый набег из-за сильной популяризации на конференцияхШота мне подсказывает шо будет история как с Руби (РоР): все набежали, дорости до
Учитывая количество ЯП и размеров «рынка» в целом, это сотни тысяч руби разработчиков. Зато какой эффект от Руби, до сих пор на слуху, плюс все ЯП успешно содрали принципы рельсов себе в той или иной форме. Сейчас наверное уже ничего особенного такого что нет у других, но влияние большое оказало на веб-культуру
хотелось бы полюбопытствовать, какие именно принципы были содраны из рельсов ?
хотелось бы полюбопытствовать, какие именно принципы были содраны из рельсов ?«Принципы» и «содраны с» — это все-таки очень громко сказано. Скорее РоР __подтолкнул популярность в массы__ таких вещей как:
— шаблон ActiveRecord;
— скрипты генерации, не просто создание класса, а того что вам надо для реализации задачи;
— CoC и DRY;
— Prototype/script.aculo.us и Web 2.0;
— CoffeeScript, Backbonejs так же вышли из «культуры Руби» и дали импульс для развития и языков транслируемых в JavaScript и клиентских MV*-фрейворков;
— REST (!)
Но это все было, а сейчас уже ничего нового нет. И пока Скала движется в ту же сторону, то есть не «ЦПП для джавы», а очередной Руби.
Фактически главный шанс Скалы — это если провалится Джава8, если же релиз Джавы8 будет успешным, то я не вижу той самой ниши где Скала выносит всех.
после сравнения скалы с жабовосьмеркой можно даже не обращать внимание на все, написанное выше.
после сравнения скалы с жабовосьмеркой можно даже не обращать внимание на все, написанное выше.А кто сравнивал Скалу и Джава8? Больше читайте меньше фантазируйте.
Кстати:
я не вижу той самой ниши где Скала выносит всехА вы видите? Если да, то озвучьте.
По-вашему, уже настал тот момент, когда можно переходить к метанию говна, или можно еще подождать пару комментариев?
В чем столжность сравнить?
Java 8
List<string> strings = Arrays.asList("1“, “2”, “3”).stream().filter(p -> p.startsWith("1")).collect(Collectors.<string>toList());
Scala
val strings = Seq("1“, “2”, “3”).filter(_.startsWith("1″))
Без комментариев :)
Кстати справедливости ради стоит заметить что в Java 8 мы конвертируем коллекцию в абстракцию Stream, производим операции и потом трансформируем у желаемую коллекцию. Этим Java продолжает традицию следования принципу the least surprise и это хорошо для языка с такой широкой аудиторией.
В Scala это очень контраверсионно реализовано, у Одерски не раз спрашивали. Уже приводили выше в треде похожий пример.
(0 until 10).toSet[Int].map(_/2) = Set(0, 1, 2, 3, 4)
WAT? Операция map вернула меньше элементов чем в оригинальной коллекции? Такое бывает, но может быть как раз big surprise. В Scala хотя коллекции явно не нужно конвертировать в тип поддерживающий различные ФВП над коллекциями, они поддерживаются сразу в любой коллекции. И приводить назад тоже не нужно. Тип коллекции сохраняется со всеми его свойствами. «Внимательный читатель» может упомянуть то, что Set монада и потому вообще от map/flatMap можно ожидать чего угодно и все правильно. Это ок. Но начинающий и не очень начинающий программист может острелить себе ноги.
С другой стороны обычно все хорошо, а человек с опытом на такие грабли не наступит, зато получит более короткий код, который вы привели. Более того очень часто хочется видеть именно такое поведение, собирая данные из многих источников. Хуже будет если вам в метод прийдет сферический Iterable в вакууме. Но тогда можно всегда прямо конвертировать в toList если нужно поведение списка, который сработает вхолостую если это действительно просто список
Я считаю что правы и разработчики Scala и Java 8, их решения оправдывают себя при существующих исходных данных
я не понял, почему от монады в операциях map/bind можно ожидать «чего угодно», и что конкретно предлагается не ожидать от Set в случае map. Неужто кто-то может ожидать там 9 элементов?
Да, кто-то будет. Это лишь другой assumption. Кто-то может ожидать что map конвертирует Set например в List/Seq/Iterable. Просто потому что этот человек считает что map должен возвращать такое же количество элементов сколько получил на вход, а это не всегда возможно при сохранении типа.
Ну я к тому что в отличии от стандартизированого map, который обязан себя как то одинаково вести для всех коллекций, это просто операция которая будет делаться так как считает та или иная монада и все. И если у Set такое поведение, то он имеет право возвращать то количество элементов которое например сохраняет свойства коллекции, в данном случае множества.
«стандартизированный map», штоэтао?
map :: Monad m => (a -> b ) -> m a -> m b<code>
где тут например написано что там оно обязано себя вести как-то еще более стандартно, чем в здесь?
Не написано. Но есть много языков в которых map с монадами никак не связан, потому многие могут ожидать безобидное преобразование любой коллекции в список из такого же количества элементов после трансформации. Или не ожидать строго, но по крайней мере не задумываться о строгости правила и писать код расчитаный на это
то есть речь тут идет о людях, которые нифига не читают ничего? ну так у них с любым языком будет проблема, скала-то ту причем?
Я думаю, любой программист будет ожидать, что неявное преобразование типов происходит, если тип аргумента не соответствует типу функции. То есть он сначала посмотрит тип функции map. Полагаю, это всё прояснит.
map — это действие функтора на морфизмах. Монада излишня.
«Стандартизированный» map для конечных множеств можно получить с помощью понятия свободного идемпотентного коммутативного моноида. (Конечные мультимножества — коммутативный моноид, списки — моноид.)
К сожалению, нельзя опираться на ожидания разных программистов. Есть те, кто не ожидает, что множество может содержать повторяющиеся элементы. Их мнение тоже нельзя списывать со счетов. В конце концов, вы зайдёте в тупик, потому что любой выбор будет неправильным, потому что он противоречит мнению каких-то программистов. Тогда лучше вообще никаких новых языков программирования не делать. :-)
Думаю все будет норм, просто потому что Scala — не нескучная Java с лямбдами в отличии от Kotlin, Ceylon, Groovy, etc
Думаю все будет норм, просто потому что Scala — не нескучная Java с лямбдамиНу как-то так:
все набежали, дорости доСнова же суть того что я сказал была не в «лямбдах», а в том что у джавы есть ниша (при том гигантская) — это энтерпрайз и высоконагруженные системы, в случае провала джава8, откроется возможность для других языков (инфраструктур) занять эту нишу.1-2% рынка и на этом все закончитсо.
Основная ниша которую видно для скалы (на данный момент) — это «устал писать на джаве, но хочу все джавовские либы» (не «не хватает фич», а именно «устал/надоело»), но тут у нее есть сильный конкурент в виде Груви (со спрингсорсом).
Может вы знаете другую нишу. Если да, то назовите. (Eugene Dzhurinsky
так и не смог придумать ничего лучше «переходить к метанию говна»)
скажите, а вы что про скалу знаете-то? ну кроме «писал наджави, устал, ухожу».
Я вот пишу иногда проект на Scala, тяжело дается из-за сложных алгоритмов, преобразований коллекций, парсинга XML/JSON форматов, ленивых коллекций, concurrent кода. Но вот когда напишу, то понимаю, что если бы писал ЭТО на Java то уже бы рехнулся, просто не вылез из этих алгоритмов и пол года отлаживал баги
если бы писал ЭТО на Java то уже бы рехнулсяСупер. То есть ниша пока остается:
«устал писать на джаве, но хочу все джавовские либы»-----------
Сейчас внимание: То что написано далее — это НЕ троллинг или попытка доказать свою правоту.
если бы писал ЭТО на Java то уже бы рехнулся, просто не вылез из этих алгоритмов и пол года отлаживал баги
Я вот пишу иногда проект на Scala, тяжело дается из-за сложных алгоритмов, преобразований коллекций, парсинга XML/JSON форматов, ленивых коллекций, concurrent кода.1) Алгоритмы. Приведите пример, поскольку я не могу легко придумать алгоритм, который бы принципиально отличался в сложности реализации на разных языках. Тут куда важнее хороший стиль кодинга (в том числе и ФП — это во многом стиль программирования, чем фича языка).
2) Преобразований коллекций. Даже не смешно (2013 год): Гуава, ЛямбдаДж, ФункциоанлДжава, ГС-Коллекшинс. Снова же, сильно упирается именно в стиль, но на этот раз не просто кодирования, а программирования в целом.
3) Парсина XML/JSON. Говорят у Скалы есть для этого чуть ли не встроенный ДСЛ (я с ним не работал) — это таки плюс. Но чем не подходит, тот же дом4Дж? Джава последние
4) Ленивые коллекции. См № 2. + «Зацени эту классную штуку»: bit.ly/195KiKi :)
5) Concurrent код. Снова же стиль программирования (и архитектуры). Никто не требует писать код с использованием synchronized, уже давно есть j.u.c (в том числе и Future). Ну и Akka которая вполне может быть использована в джава программах.
1) Короче код — не просто меньше печатания. Это обозримость алгорима, который в Java раздувается на десятки классов. И при простоте отдельного модуля совершенно не понятно что делает приложение
2) Гуава одна из моих любимых Java библиотек. Но это детский садик по сравнению с коллекциями Scala. И функциональный стиль кстати не очень поощряется, он раздут все равно, в документации говорят что лучше подождать Java 8
3) Ну одно дело размечать аннотациями сущности, другое дело написать xml // «Element»
4) OMG
5) Отличаем блокирующие Future от composable Futures? j.u.c.Future худшее что можно придумать, сколько же проблем мне создают так называемые «асинхронные» библиотеки из Java, которые встроить практически с существующий асинхронный пайплайн невозможно.
1) Короче код — не просто меньше печатания.bit.ly/1bPtNmV
Это обозримость алгорима, который в Java раздувается на десятки классов.Повторяю:
Тут куда важнее хороший стиль кодингаНикто вас не заставляет писать ФабрикуФабрик. И
Person.IS_ADULTзачастую предпочтительнее (для понимания кода) чем
person => person.age > 21или
_.age > 21, а что там за этим Person.IS_ADULT уже не столь важно. Пусть там хоть целый пакет классов.
2) Гуава одна из моих любимых Java библиотек. Но это детский садик по сравнению с коллекциями Scala.Еще раз github.com/.../gs-collections
Отличаем блокирующие Future от composable Futures?Еще раз:
. Ну и Akka которая вполне может быть использована в джава программах.И из «вашей любимой Гуавы» docs.guava-libraries.googlecode.com/...kage-frame.html
bit.ly/1bPtNmV
Уже не ново, 1000 раз уже обсуждали. Ваше мнение имеет право на существование. Мое мнение — IDE не всегда должно оправдывать недостатки языка, пример — геттеры и сеттеры и их вечная генерация.
зачастую предпочтительнее (для понимания кода) чем person => person.age > 21
В тех случаях когда предпочтительно я так и пишу. И предпочел бы выбирать когда предпочтительнее, а когда нет
gs
IfProcedureWithInt, SplitDoubleSumProcedure, SplitIntSumProcedure? Пожалуйста, хватит этих ужасных костылей, это нужно в рубрику «Угадайте ЯП по названию класса». Эти детские библиотечки уже не смешны. Давайте так, вы сначала досконально изучите Scala, потом пожалуйста приходите и начинайте троллить как-то обосновано «в Scala нет EnumMap», «mapValues — выстрел в ногу», а так просто приводите библиотеки, которые пытаются компенсировать отсутствие фич в библиотеке коллекций Java очередным переизобретением того что уже есть в Scala, готово, оттестировано и хорошо дружит со всей инфраструктурой сторонних библиотек.
И из «вашей любимой Гуавы» docs.guava-libraries.googlecode.com/...kage-frame.html
Да я радуюсь каждому мигу когда кто-то мне возвращает из Java библиотеки ListenableFuture, спасибо DataStax например. Но почти все, включая стандарты Java EE в асинхронных реализациях возвращают уродливый Future, до Java 8 CompletableFuture еще ждать и ждать, а пока на него перейдут библиотеки можно и состариться. И главное — культура Java программистов, думающих что j.u.c.Future — это нормально. Нет уж, спасибо, буду лучше программировать на Scala где Concurrency сделано лучше.
Кстати, цепочку из Guava ListenableFuture как будем делать?
К самой Java напрямую претензий нет, она просто более низкоуровнева, но дает прекрасные примитивы построения того, что есть в Scala. Я предпочитаю пользоваться более высокоуровневым ЯП. Проблема в некоторых Java программистах застрявших в парадоксе Блаба и пиарящих ненужность того чего они не понимают
Нет уж, спасибо, буду лучше программировать на Scala где Concurrency сделано лучше.1) Не лучше или хуже, а по другому.
Кстати, цепочку из Guava ListenableFuture как будем делать?
2) Что мешает использовать Акку в джава проекте, если вам нравится данный подход?
К самой Java напрямую претензий нет, она просто более низкоуровнева, но дает прекрасные примитивы построения того, что есть в Scala.Ок, пообсуждали языки. Теперь к началу разговора:
__Где ниша Скалы?__ (уже не первый раз повторяю вопрос, и никто пока не ответил на него)
Все о чем мы говорили ограничено:
«устал писать на джаве, но хочу все джавовские либы»
----------
Проблема в некоторых Java программистах застрявших в парадоксе БлабаПобеждает не язык, а экосистема: язык, среда выполнение, набор инструментов, сообщество и тд.
ИМХО, ссылка на «парадокс Блаба» — это уже путь в проигрышу платформы.
Почему-то ЦПП, Джава, Ц№, ПХП, Питон стали популярными, а Хаскелл, Руби, Груви, пока еще Скала, Лисп (!) — нет.
Почему же?
Упрощенный вариант:
Потому что первые определили и смогли занять некоторую нишу.
А вторые это просто «это массовый набег из-за сильной популяризации на конференциях». Да, у языков из второй группы много плюсов, они во многом мощнее языков из первой группы. Но их сообщества или держатся обособленно или ставят себя в позицию __альтернативы к языку из первой группы__. Эти языки не решают проблему, а всего лишь показывают альтернативный путь, как пример те же рельсы которые показали путь, этот путь многие скопировали, а Руби застыл (в контексте рынка труда) на том же месте что и около
Что мешает использовать Акку в джава проекте, если вам нравится данный подход?
Причем тут Акка, это лишь один из способов работы Concurrency, самый громоздкий, хотя и громко распиареный. В нем есть свои преимущества, но композицию асинхронных вычислений в Java сделать не так просто. Или по крайней мере не получается делать не раздуто.
Теперь к началу разговора:
__Где ниша Скалы?__
Более сложная бизнес логика, в которой больше трасформаций коллекций. Так же асинхронные вычисления, etc. Вообщем там где можно использовать и Java, платформа есть, но синтаксически можно при этом сильно запутаться и раздуть код.
Побеждает не язык, а экосистема: язык, среда выполнение, набор инструментов, сообщество и тд.
Вот Scala и побеждает из-за всего этого из Java мира.
Более сложная бизнес логика, в которой больше трасформаций коллекций. Так же асинхронные вычисления, etc.:)
Более сложная чем та что уже лет 30 реализуется на других языках? Мир идет как раз к упрощению бизнес логики.
Асинхронные вычисления, работа с коллекциями — это не ниши, это инструменты. Ниши — это энтерпрайз, десктоп приложения, мобилочки, банковский софт, скрипты автоматизации и тд. И проблема в том что скала везде — альтернатива, а не принципиально новое решение. И занять какую-то нишу она может или вытеснив кого-то, или когда ниша освободится (как пример я приводил, возможность провала джава8).
Вообщем там где можно использовать и Java, платформа есть, но синтаксически можно при этом сильно запутаться и раздуть код.И снова:
устал писать на джаве, но хочу все джавовские либыИ опять:
ставят себя в позицию __альтернативы к языку из первой группы__.И про раздуть код:
Тут куда важнее хороший стиль кодинга---------
Вот Scala и побеждает из-за всего этого из Java мира.От пока не особо видно: 1 вакансия на скала против
Я уже говорил, 0,5% — это десятки или сотни тысяч разработчиков. И 1 вакансия там где вы смотрели не мешает мне получать Scala вакансий в почту не меньше чем Java
code.google.com/...la-versus-java
пусть здесь полежит, искателям ниши Scala и адептам EJB/Spring/Hibernate оно без надобности, а нормальные люди смогу сделать свои выводы.
Типичный популизм скала фанбоев, например: code.google.com/...itionFacts.java что мешало реализовать похожий интерфейс как в scala case classes(один класс с методом copy), зачем нужны хеш код и тоСтринг в данном примере, зачем нужны аксессоры если можно сделать паблик филды как в case classes? И такие же дела во всех примерах там.
Igor Mazur
Все это конечно можно, но:
1. Вы часто видели POJO без set\get методов?
2. copy придется писать вручную для каждого класса в отдельности, либо юзать рефлекшен — что будет ударом по производительности.
3. hashCode + equals реализован потому что case классы автоматом реализуют эту функциональность.
4. ну и это конечно косметика — но case class пишется в 1 строку обычно. Аналог на Java даже без аксессор методов, copy, equals и hashCode — в одной строке будет слишком уродлив.
1. Вы часто видели POJO без set\get методов?Ну так это ведь не из-за ограничений языка, а из-за определенной сложившейся культуры программирования. К тому же весь этот boilerplate(аксесоры, хешкоды, тустринги, иквалзы, конструкторы) генерится в IDE парой кликов мышки.
2. copy придется писать вручную для каждого класса в отдельностиПрийдется, но это все равно снизит обьем кода, т.е. пример не отражает действительность.
Кейс классы такие маленькие что я при соответствующем настроении могу их написать внутри метода.
Ну я бы не сказал что он не отражает действительность. Тут просто на Java реализовали полную функциональность case класса — это типа то что я получаю «из коробки» только объявив его.
Но например мне зачастую нафиг не надо ни авто equal ни hashCode ни copy — мне просто надо структурировать набор данных. В таком случае в Java я могу не писать весь этот
boilerplateНу а в скале это все идет прицепом — хоть и полностью скрыто ситаксисом.
Тут просто на Java реализовали полную функциональность case класса —Это не просто функциональность, но и еще определенный стиль программирования. Я уж не говорю что в джаве ты можешь заюзать какие нибудь протобаферы которые дадут абсолютно все тоже самое + еще и сериализироваться будут быстро.
Это не просто функциональность, но и еще определенный стиль программирования.Ну вот в том то и дело — что текущий хороший стиль, как я уверен, в подавляющем большинстве случаев включает в себя генерацию с IDE большей части этих методов.
Что ухуджает (как уже выше гдето писали) обозримость кода. Вон в C# кстати тоже уже это поняли давно и сделали конструкции типа {get;set;}.
Та же ИДЕ замечательно помогает навигировать по большим кускам кода.
2. copy придется писать вручную для каждого класса в отдельности, либо юзать рефлекшен — что будет ударом по производительности.А вы больше никаких отличий не увидели между Скала и Джава вариантами? (Например, по количеству аллоцированых объектов)
А это довольно вязкая почва для споров :)
С одной стороны — это как бы функциональная парадигма такая — иммутабельные переменные + копирующие алгоритмы.
С другой стороны современные процы любят хардкор с перекладыванием данных в массивчики байтов и предсказуемым переходам по ним.
Тут пожалуй каждый для себя решает что ему дороже хипстерская функциональщина или хардкорный ByteBuffer :)
никто же не запрещает объявить например var-ы унутре и делать все мутабельно. Хотя JVM и борьба за память/конвейер — это как-то, мягко говоря, странно.
Хотя JVM и борьба за память/конвейер — это как-то, мягко говоря, странно.Всякое бывает:
jug.ru/...e/-/blogs/20987
jug.ru/...e/-/blogs/11484
там вовсе не о конвейере речь, если послушать/почитать, а о чуть других вещах.
Там по 2 часа выступления. Там и конвееры и байт буферы и то что в java не всегда можно абстрагироваться от памяти.
я это слушал, да, но про конвейеры там ничего нет.
А, я лох, я перепутал с другой презенташкой Елизарова. Смотрю с удовольствием, спасибо )
Тут пожалуй каждый для себя решает что ему дороже хипстерская функциональщина или хардкорный ByteBuffer :)Выбирать из крайностей — это глупо. Надо уметь использовать подходы.
С одной стороны — это как бы функциональная парадигма такая — иммутабельные переменные + копирующие алгоритмы.Ну так почитайте про такую классную штуку как билдеры :)
Простой здравый смысл, а не поклонение парадигме:
Локально у вас все мутабельно, но оно локально, поэтому проблем нима: и память не выделяем по каждому чиху (соответственно сборка мусора не молотит шо бешеная) и код получаем надежный.
Я уже как-то говорил что и Скала и Ц№ — очень классные инструменты __для профессионала__, а в руках джуна или какого-то хипстера — это бомба, которая бабахнет в самый неподходящий момент.
А нельзя билдер написать на Scala? Или не написать в случае когда это бесполезная оптимизация?
А нельзя билдер написать на Scala?Можно, конечно же, но тогда «сферический пример» становится еще более смешным.
Или не написать в случае когда это бесполезная оптимизация?Контекст: мы говорим о создании иммутебл объектов (ПОДжО) через билдер.
Когда оно надо? Когда у вас много полей, то есть будет много копирований. И тут речь не об оптимизации (бессмысленной оптимизации) некоторого кода, а о том что вы заведомо пишете не эффективный код.
Подумайте когда вам нужны, в реальной жизне, такие ПОДжО (кайс класс), так ли они нужны иммутабельными и тд.
вы можете пояснить простую мысль — зачем вы здесь? Я вот например топик писал не для того, чтобы толстые жаботролли с EJB головного мозга рассуждали о pojo, а скорее для рассказа кто из правильных чётких пацанчико что где пользует на раёне Скалы. А вы что тут забыли? Интересно же.
Я вот например топик писал не для того, чтобы толстые жаботроллиpastebin.com/qSEbVhRk
вы можете пояснить простую мысль — зачем вы здесь?Поучаствовать в дискусии, которую вы, к сожалению, уводите из технического русла в русло компенсации своих комплексов (это я про сантиметры).
А если есть притензии к срачу, так высказываете их авторам этих комментов:
dou.ua/...ic/8292/#367033
dou.ua/...ic/8292/#367007
которые нафантазировали наезд (которого не было) на их няшную скалу.
И чуваку dou.ua/...ic/8292/#367157 который привел как пример, по которому можно понять силу скалы, код какого-то школоло.
Претензий к срачу и устроенной вами клоунаде нет на самом деле никаких, мотивация ваша понятна и в чем-то даже вызывает сочувствие. Пишите еще ;)
Ну никто и не говорит что скала торт. Могу прочитать лекцию сколько там отстрелов ног. Но когда приходят с детскими аргументами которые действительно не проблема day to day, то не могу согласиться. Представьте слоупока который прибежит «эй, я тут вчера прочитал что в джаве нету unsigned типов, да ну нет, это же не серьезно»
Ну никто и не говорит что скала торт. ...Не понял. Это вы сейчас все к чему сказали?
Ну я не смотрел что там за пример. Но если у меня 100500 полей и билдер, то я бы сделал поля билдера мутабельными, а потом в конце сделал кейс класс и не вижу проблемы. Кейс класс мне бы нужен для того чтобы отдать его во внешний мир и не париться когда либо о всяких синхронизациях, JMM, неправильных equals, hashCode и т.д. Обычный иммутабельный value object, все хорошо, никто не страдает
Выбирать из крайностей — это глупо. Надо уметь использовать подходы.Ну так скала это не хаскель. Тут можно сделать var вместо val и, вперед и с песней, как на Java только чуть синтаксис другой (в смысле буков часто меньше). А можно при желании функционально.
Вобщем у меня пока одни положительные впечатления.
Самые большие проблемы связанные с синтаксисом (пару раз которые возникали — но к которым надо просто привыкнуть и быть внимательным) — были с тем что типы задаются неявно.
Например:
val a = someCollection()
val b = batchSelect(a)
val c = a.zip(b)
По задумке я получу соответствие каждому a элемента из b. Ну и все работает пока someCollection возвращает List. Потом через какоето время появляется гениальная идея возвращать Set — все компилится, но работает уже не так как надо.
В какойто мере «виновата» scala — она за val прячет реальный тип и выводит его в процессе компиляции.
Но как по мне в любом языке есть способ незаметно выстрелить себе в ногу — разобраться с ними просто дело времени.
val a = someCollection()
val b = batchSelect(a)
val c = a.zip(b)
Меня дрожь взяла на последней строчке. Зрительная ассоциация с маркой на которую плюнули и прилепили сбоку на коробку )
Не совсем понял — что тут такого удивительного.
были с тем что типы задаются неявно.еще есть мнение что автовыведение типов делает очень трудным чтение и разбирание больших обьемов кода в больших проектах, так как непонятно какого типа какая переменная(нужно мышкой много возюкать и смотреть).
в IDEA есть офигенная штука как alt+=, показывает тип. Рекомендую )
Ну так она подсказывает когда пишешь код локально. А когда меняешь возвращаемый тип метода — она ж не говорит — «ты шо творишь — там то и там то ожидается именно семантика List, а не Set»
вот как раз в ситуации «val smth = createSomeColl()» на «smth» Alt+= покажет, что ж там будет после createSomeColl.
Я совершенно не о том.
Я о ситуации когда
val smth = createSomeColl()это файл A — а редактируется файл B — в которм меняется createSomeColl: List на createSomeColl: Set.
да хоть оно будет в файле C, из которого там в B вызывается какая-то функция, которая и вернет коллекцию (транзитивный вызов) — скальный плагин для идеи это все прожует и покажет <b>актуальный</b> тип. То есть если вы поменяете в C коллекцию с List на Set — в A на smth будет показан именно Set.
Ок — а если потом в файл A НЕ ЗАХОДИТЬ и НЕ СМОТРЕТЬ что там показывает Idea? Или еще хуже файл A написал один человек а файл B изменил — другой?
а если вообще не иметь сорцов — так и правда совсем непонятно кто чего и каким типом. Я там отвечал вообще говоря на вопрос «как бы посмотреть выведенный тип», а не на «НЕ ЗАХОДИТЬ И НЕ СМОТРЕТЬ» ;)
Та нет же. Дело не в том как посмотреть выведеный тип. Дело в том что он выводится автоматически во вермя компиляции. И однажды написанный код может запросто поломаться из-за того что подменили тип входящих данных.
Это естественно не проблема скалы — на java таже фигня может быть запросто. Просто скала это скрывает за val\var декларациями — и согласитесь с alt обычно весь проект не перечекивается после любого изменения. А вот в java надо вручную писать тип переменной — и как бы больше вероятность, что компилятор обнаружит «подмену».
Ну, да, за все надо платить. Если типы переменных так важны — аннотируйте. Что хорошо в скале — что-то можно аннотировать, а что-то очевидное можно оставить на совесть компилятора и потомков. То же самое с отсутствием throws :)
Я же говорю, если читаешь много чужого кода, нужно много мышкой елозить, а в джаве он сразу на ладони.
не сказал бы, что вот прям так и на ладони весь. Случаи-то они разной степени бывают, фабрики обсерверов шаблонных методов над флайвейт объектами никто не отменял же.
Это уже иррелевантно языку, такое можно и на скале, и даже покруче заварить.
ну так об чем речь? творить чернь можно на всем, пожалуй чем более продвинут язык — тем сильнее. На жаби чернь творить получится менее эффективно, чем на скале. Лучше/мейнстнимнее/няшнее/кавайнее жаба при этом? не сказал бы.
Лучше/мейнстнимнее/няшнее/кавайнее жаба при этом?Бизнесу нужен стабильный, читабельный поддерживаемый код. Кавайность это к красноглазой школоте.
Так стабильный, читабельный и поддерживаемый код не является прерогативой языка как такового. Какие-то вещи писать проще на жаби, какие-то — на скале, а что-то лучше на ерланге. Бизнесу по-большому счету вообще посрать на чем там что писано, главное чтобы оно решало бизнес-задачи. У меня есть примеров, когда откровенный говнокод при правильном процессе работал десятилетиями, и когда правильный жабошедевр проваливался потому что отдел маркетинга лососнул тунца.
Все правильно, но на джаве вероятность появления неразгребаемых куч гавнокода под которых никого не найдешь намного меньше, поэтому скала — это пока ниша неохипстеров.
Я не знаю, с какими проектами и как вы сталкивались, но лично мне доводилось видеть ТАКОЭ на жаби, что лучше б я этого не видел никогда. На скале я такого не видел (и это хорошо, я уже не так молод), но я все ж надеюсь что порог входа в скалу сильно повыше жабы и пхп, что повышает мои шансы не увидеть ничего эдакого. В этом смысле идеален хаскель, но там другая крайность.
На скале я такого не видел (и это хорошо, я уже не так молод),Это очевидно потому что на ней пишут полторы конторы, которые еще не успели нагенерить тонны легаси кода.
но я все ж надеюсь что порог входа в скалу сильно повыше жабы и пхпЭто ошибка, абстрактный индус способен начать генерировать гавнокод на скале так же быстро как и на джаве и похапэ.
Вам виднее, в вашей вселенной может и полторы конторы. Равно как и индусов.
Не сливай так быстро, сколько ты видел проектов на скале с кучей программистов и кучей легаси кода?
ойц, трололо из нулевых! киса, ты с какова раёна? ;)
паблик филды как в case classes?
А вот и не угадал :P
Ну «паблик филды в кейс классах» сразу выдают Scala эксперта
Ну понакидывай еще. Твое любимое занятие.
напишете там конрпримеры на Java, которые делают код таким же лаконичным, как и на Scala или зассал ? ;)
А я говорил где то что код на джаве ТАКОЙ ЖЕ лаконичный?
Я уж не говорю про то что есть языки полоканичнее скалы, но не все упирается в размер кода.
напишете там конрпримеры на Java, которые делают код таким же лаконичным, как и на Scala или зассал ? ;)Скажите, а вам не стыдно показывать такое вот гуано?
Про аллокацию объектов — это такое, прижмет, можно написать нормальный билдер,
но вот
trait ModernHospital extends Patientcode.google.com/...sition.scala#54
Это уже диагноз! Какая речь может идти о лаконичности, когда сущность СовременнаБольница __расширяет__ сущность Пациент?!
мне не стыдно, у меня 35 см. А у вас?
А постоянные самоутешения вообще путь к разложению личности ))
вот и я про что, я бы туда еще отнес поиски ниш там, где это не нужно делать.
Разная в сознании каждого, зависит от реакции на новое. От «прикольно, буду/не буду использовать», до «не нужно, джава тьюринг полная и имеет костыли для решения всех проблем»
тут было мнение в соседнем блоге, что ниша как раз у жабы, а у скалы — будущее. Я с ним даже согласен )
Значит нереализованные надежды )) Ок.
Ждем сравнения с Гитлером
Ждем сравнения с ГитлеромОт серьезно, о каком успехе инструмента может идти речь, если сообщество вокруг него не способно вести, конструктивный разговор?
Вы говорили что одной из составляющих успеха скалы есть сообщество «из джава мира», но как раз сообщество скалы куда хуже чем сообщество джавы (это чисто ИМХО, подтвержденное примерами из данной ветки).
Ну я просто понял что после скатывания последних нескольких реплик в «а вы!», «нет, а вы!» разговора уже ничего не получится.
Может мы уже не такие плохие как вы думаете. Но да, от сообщества скалы можно пострадать. После прочтения одной книги все бегут писать библиотеку со своим DSL, но без документации, которую потом распиарят на конференциях
Кстати еще вариация на туже тему: jnb.ociweb.com/...jnbJan2010.html
Lombok был клевым до того момента, когда на скале стало программировать чуть больше полутора человек, включая Одерского. Использовать lombok, functionaljava и прочие lambdaj — это нужно иметь стальные тестикулы и неизбывный оптимизм.
По факту скала еще не прошла проверку гавнокодом. Вот когда кодерки вроде Петрука наколбасят по 50мб кода в продакшне, и конторки не будут загибаться от всяких side эфектов выразительности скалы погрязнув в багфиксинге, тогда и можно будет сказать что скала индустриально зрелый язык. Пока что же саксессториз на уровне мифов.
ну, ок, твиттер — миф, форсквер — тоже миф. У меня тут мифический продакшн на скале в омазоновском кластере. Нормальное такое мифотворчество ;) С третьей стороны, я пожалуй соглашусь с ежебистом в том, что говнокод на скале по разрушительности сравним с говнокодом на хаскеле — хрен ты там без поллитры и телепатии что поймешь. Так что классический «да наймем деревню индусов, дадим им книжку по жабе одну на всех — и через два месяца выйдем в продакшн» не сработает.
Никто толком не знает что именно у твитера на скале. 4square единственный удачный скала шоп, но какого уровня там сидят программисты, с какими проблемами они столкнулись и как они их решают, и насколько распространим их опыт на индустрию не понятно.
я толком знаю, что у них там на скале, помимо личных общений с местными девелоперами — они еще на митапах докладывают, как у них все там клева. Оно ведь как в ДМБ — ты суслика видишь?
А как послушаешь ерлангеров как у них все клево, так вообще непонятно зачем все остальные языки программирования нужны. А как палочкой потыкаешь, то опять понятно становится ))
это с любым языком так, что с цацкелем в продакшне, что с скалой в твиттере. Всегда найдутся еретики, которых правящая партия сожжет после прихода к власти. Я бы например запретил EJB и дизайн-паттерны.
о нет, я не хочу вспоминать кошмары инвестбанков и вебсферу, пусть кто-то другой ответит ;)
А что вебсфира? Помоему очень крутая штука была для своего времени, приватное облако, где все менеджилось из веб консоли, куча встроенной функциональности включая логи, перформанс мониторинг, кластеризация, и т.д. и т.п. Современным ПааС до такого еще расти.
нет, что ты делаешь, прекрати, я не хочу это вспоминать!
Сейчас EJB уже не такой
его уже можно трогать пятиметровой палкой?
Нестор Иванович
ну у меня есть поделие на свежем-свежем JEE -уже даже почти на JEE7. CDI вместо спрингов, glassfish 4 свежайшие primefaces
оно даже не ужасное, руки мыть хочется только под вечер а не сразу по старту IDE.
Но сказать что это прикольно или там модно и молодежно — я бы не рескнул.
ну клева, хотя я без паттерн-матчинга, имплиситов, кейс-классов, каррирования и extendable control structures жить уже не смогу
да JEE7 в том виде что ее выпустили больше похоже на оттягивание конца. что то новое добавили но мало и совсем не так кучеряво в реальности после исследования. ну например поддержка json в которой его надо тупо руками парсить для чтения и билдить для записи. И все. синхронизация- не не слышали. и так что не ткни, всуду ржа и разложение.
ща вам тут проснуццо и расскажут про космические корабли Ынтерпрайз Жаботрек 8, которые бороздят и мейнстрим.
ага, при этом имея на продакшене 1.4 под вебсферой :)
Зато на эту радость можно нанять пучок паков не задорого, а вы тут свое ботанство разводите.
Начать что ли завивать усы что ли как перейду на скалу, для пущей не майнстримовости.
Да начиная с Java EE 6, лучше 7. Желательно на JBoss AS/Wildfly чем на Glassfish. Второй просто чуть тяжелее и медленнее. JBoss наоборот удивляет с каждой новой версией. Wildfly у меня запускается 7 сек с нуля, деплоймент 200 мсек. WAR файлы с приложениями могут быть без единой библиотеки и размером например в 300 кб. Hello World может состоять из WAR файла с 1 class файлом без единого XML.
По сравнению современным Java EE на JBoss, Spring+Jetty — громоздкий и неповоротливый.
Есть правда вещи, которые лучши избегать — JSF. Java EE + JAX-RS + HTML5 + AngularJS будет работать пошустрее многих хипстерских поделок. И особенно что примечательно, иногда короче
Он идет в поставку Java EE и культура страха перед JavaScript еще не умерла
Для жаба скрипта давно ужо есть ГВТ... тоже не без изъянов и заморочек, тем не мение. Говорят даж скала версия есть, интересно, ее ктонить пробовал ?
Я не фанат GWT еще больше чем JSF, но если кому-то помогает то норм чо
GWT как по мне еще большая проблема чем JSF
хз, у нас его вполне успешно применяли, и все им более-мение были довольны. А главное — никакого джаба скрипта.
А главное — никакого джаба скрипта.
В том то и проблема что он есть, но внутри, в 100 раз больше, компилируется по 10 мин. И дебагать нужно иногда именно его, а не дырявую абстракцию над ним.
А решение одно — начать отсюда
В том то и проблема что он есть, но внутри, в 100 раз больше, компилируется по 10 мин. И дебагать нужно иногда именно его, а не дырявую абстракцию над ним.
Вот прям тоже самое люди говорят про эту вашу скалу )))
Но жить можно, не правда ли ?
Ну в случае скалы я дебагаю именно ее и работаю на ней из-за повышение продуктивности. И раньше работал не GWT. С полной ответственностью говорю что продуктивность на AngularJS+Twitter Bootstrap+JavaScript намного выше чем Java+GWT.
С полной ответственностью такое могут заявлять у кого кредо жизни, насрал гавнокода и перебежал в другое место. А вот люди которые потом гавнокод разгребают, сразу видят преимушество джавы над скалой и гвт над джаваскриптом, без всяких ответственностей.
шо же делать, я вот вижу и превосходство скалы над жабой, и превосходство жабы на скалой и даже превосходство GWT над жабоскриптом! Доктор, мне к умным или красивым?
А источник цитаты не проясняет ответ на твой вопрос?
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Котэ гуляющее само по себэ
«я скакала за вами 15 верст, чтобы сказать как вы мне безразличны».
Верста — 1.066 км.
Недалеко же пришлось скакать :-/
А вот два дня и две ночи...
да живой, куда оно денется...
primefaces вон например его сильно прокачали при помощи jQuery но конечо нервным людям в js их компонентов лучше не смотреть, тк там куча жести.
Java EE + JAX-RS + HTML5 + AngularJSЛучше уж так JavaEE( EJB, JPA, Jax-RS ) + HTML5 + Backbone.js + Common.js + Jquery
Кому как
у меня на стекляннорыбе не все так шоколадно. Всякая мало вразумительная хня случалась, типа permGen после нескольких редеплоев.
А включен class unloading?
вроде да. давненько был косяк, но помнится что все предписаные шаманства не помагали.
Vlad Svitlychnyi
я как-то заикнулся тут про «дизайн-паттерны не нужны», меня чуть не съели)
ну, сюда бы чистякоу, его дизайн-паттерны многим в рот не поместятся.
Я бы например запретил EJBДа ты офигел, EJB 3.2 на голову выше спрингов всяких.
дизайн-паттерныИ cake-pattern в первую очередь?
все запретить, программистов на урановые рудники, меня в президенты галактики! «ТАК!» победим! разом нас багато!
Давай за 42 чатла купим планету Хануд, потом еще полгода «мама-мама» по галактике поиграем и атмосферу туда завезем. Все ринутся на планету, а мы будем заставлять их ползать на карачках и плеваться.
что значит никто не знает? вам в гитхаб.ком/твиттер совесть или религия не позволяет заглянуть? + куча презенташек/постов где они описывают что у них и как крутится на скале, и да личные разговоры
гитхаб.ком/твиттерТвитер уже та, выложил свою serving infrastructure, или я что-то пропустил?
куча презенташек/постов где они описывают что у них и как крутится на скалеНе набрасывай просто так, есть ссылки — кидай, не стесняйся ))
выложил свою serving infrastructurefinagle, например, как backbone инфраструктуры
Не набрасывай просто такмне не жалко:
blog.twitter.com/2013/braindump
из последнего — summingbird:
speakerdeck.com/...ingbird-at-cufp
само собой полностью свой firehose они не выложили/выложат
finagle, например, как backbone инфраструктурыНу я к примеру не в курсе какой adoptation level у finagle в твиттере. А ты?
из последнего — summingbird:Смешно, это же просто API к не скаловским проектам (storm, cascading).
speakerdeck.com/...ingbird-at-cufp
само собой полностью свой firehose они не выложили/выложат
какой adoptation level у finagle в твиттередва года назад официально было так: lh3.ggpht.com/...gle+Diagram.png сейчас, насколько я знаю, он используется еще шире
это же просто API к не скаловским проектам (storm, cascading)скажи это ребятам которые делают pig, cascading и hive — это ведь просто api к хадупу
два года назад официально было так: lh3.ggpht.com/...gle+Diagram.png сейчас, насколько я знаю, он используется еще ширеИ откуда взялась эта диаграмма?
скажи это ребятам которые делают pig, cascading и hive — это ведь просто api к хадупуНу я то понимаю, что это не просто АПИ к хадупу, поэтому такого говорить не буду ))
И откуда взялась эта диаграмма?внезапно из их собственного блога
blog.twitter.com/...stic-rpc-system
хотя да, справедливости ради — на момент публикации оно было under development
Внезапно извини что не смог прочитать твои мысли в предыдущем посте ))
Blitz
Ведущий .net веб-фреймвёрк делался с оглядкой на рельсы. Знакомый Рубист-Дотнетчик говорит, что много общего.
св Антоний
Как замечательно, что такого гoвносрача не бывает под .net :)
это скучно же, вы просто никому не нужны ;)
Бугога, поржал :)
Я просто оставлю эту цитату здесь:
Зарубите себе на носу — программирование на Яве сделает из вас индуса, в хреновом смысле слова. Потому что под предлогом кроссплатформенности и простоты, вас научат писать программы на сотни и тысячи мегабайт, которые программист на С++ уложит в единицы, максимум, в десятки мегабайт.
Вы будете создавать невероятно громоздкий код, который будет работать в виртуальной среде ява-машины и далеко не на каждом ноутбуке он будет работать без звукового матового сопровождения оператора. А нормальная софтинка будет летать на любом компе в чистой среде ОС и радовать юзера.
Вобщем, можно и тупым топором рубить лес. Но нахуа, если давно есть бензопилы?
C++ - довольно таки примитивное, но монстровое поделие, полное исторически сложившихся нелепых нагромождений. Человек, который хорошо в нем ориентируется — это хорошее зубрилко а не хороший программист. Умение героически преодолевать трудности, которые создает твой собственный инструмент, вместо того, чтобы решать непосредственно прикладную задачу, в современно мире ценится разве что только среди прыщавых сосок. Работодатель же это сомнительное умение не ценит, и совершенно справедливо.
Hotspot написан на C++, и написан так, что руки бы оторвать всем виноватым. Вся остальная Жаба написана на Жабе. Тоже паршивенько, конечно же, но Hotspot хуже всего прочего намного. Так что гордиться там нечем совсем.
Рантаймы же для нормальных платформ пишут обычно на голом Си, и они как правило очень компактны и минимальны.
В общем, так: хороший программист обязан знать Си. Хороший программист может знать C++, но это не обязательно уже. Главное, чтоб C и C++ не были единственными доступными программисту инструментами — иначе это адски паршивый программист.
Hotspot написан на C++, и написан так, что руки бы оторвать всем виноватым.OpenJDK в открытом доступе — если есть замечания по существу — вперед, напишите лучше, сделайте патч и этот мир станет чуточку лучше
То просто давно не было .net vs Java. Классика жанра, хуле.
Устарело и не интересно
Есть более изощрённые варианты: Xamarine vs PhoneGap или Xamarine vs Qt или Unity vs *любой двидок*.
Я лично люблю старое добро ООП vs ФП.
Сишарпосрачи в принципе не интересны
Ведущий .net веб-фреймвёрк делался с оглядкой на рельсыКак так можно богохульствовать? Это RoR был передран с asp.net mvc :)))
Я даж искал не так давно рапоту — нинашел.
Даж жинн ни разу не помог.
Закапывайте ;-)
так может лучше все ж откопать? языг будущего жеж, C++ для жабы!
Когда у вас будут вакансии, тогда и поговорим ;-)
Вакансии у нас были, и наверное даже будут, правда во Львове.
Тут есть целых три:
jobs.dou.ua/...s/?search=scala
Я в курсе, если что ;-)
против 114 вакансий на жабе — эт даж не смешно ;-)
Тут www.indeed.com/...s?q=scala, java приблизительно такая же пропорция. Наверное, есть риск не дождаться времени скала-мейнстрима.
зависит что понимать под мейнстримом, если мейнстрим — это похапе, сайтовизитки и прочие форумочятики, то и жаба не сильно там в мейнстриме.
Целые три вакансии не означают, что нужно целых три скалиста(:
А сколько целых скалистов нужно Сигме?
Нам нужно целых 5 на ближайшее время, а дальше посмотрим.
И мы готовы брать людей без коммерческого опыта в скале, но с джавой и которые скалу пробовали, щупали, и понравилось(:
Более того, кроме Одессы и Харькова, мы готовы и удаленно сотрудничать на контрактной основе.
только тссс, никому не говорите...
Вот вам еще для вдохновения:
blog.djinni.co/...ost/62316060829
Сегодня только читали-обсуждали(:
По мере возможностей — стараемся(:
а что там с контрактной работой и какие подробности? Есть в родной украине народ, который как раз хотел бы контрактить скалу.
Не понял вопроса
я наверное не ту тыцку тыцнул для ответа Даше
Кстати, сигма, единственная контора, которая вообще никак не отреагировала на мое «откликнуться». Так что, видимо, не так уж и надо ;-)
Сорри, если вдруг что-то случилось, я в пнд разберусь, отпишусь.
а че прикольно выглядит вакансия. Был бы в Украине — подался бы, лол. Не все же JEE пилить
Мало компаний готовы брать чтобы обучать, им сениоров подавай.
это трагедия просто, отседого и все вот эти сеньоры с 1.5 годами опыта о возрасте 21 года.
Дак такии компании на скалу темболее не будут смотреть, либо там в менеджменте полные, извините, идиоты))).
Ruslan Shevchenko
Проекты есть, но не очень много ;)
Из того что я использовал — play / salat [это ОРМ для монго] ;
play / squerly (мигрируется сейчас на slick).
play — вполне хорошо если нужно просто веб фремворк, мне он больше чем lift нравится (в lift уровней абстракции всюду ровно на одну больше чем нужно). Но это конечно зависит от задачи. Если просто API выставить — есть легкий и красивый spray.io
Akka — есть почти в каждом проекте.
Еще присматриваюсь к storm/kestrel и всяким оберткам/аналогам handoop-а но проект еще не стартовал.
Коментар порушує правила спільноти і видалений модераторами.
Ruslan Shevchenko
Ну смотря где и смотря кому. Объем кода при работе с БД он сокращает, таблички в case классы маппит, кусочки sql композируюется лучше чем в squeryl. Недостаток — его DSL чуть дальше чем sql, надо знать как именно он sql генерирует. Но к этому быстро привыкаешь.
Про объем кода я категорически не согласен. Далее, я довольно плотно читал их список рассылки. Саппорта как такового там нет, есть вероятность попасть на странные вопросы. После того, как я прошелся дебаггером по потрохам слика — я понял, что здесь кина не будет — он принципиально не умеет prepared query, соответственно каждый раз на каждый запрос строится SQL с нуля. Причем некоторые моменты вообще неочевидны — просмотр сгенерированных SQL привел к пониманию — оно не умеет нормально строить джоины, запросы с группировками могут тупо не работать — потому как не будет group by.
Что в очередной раз меня убедило — лучший способ работать с базой — это самому писать SQL, по крайней мере точно будешь знать что там и как. А не получить при апгрейде версии либы совсем другой SQL на тот же «запрос», пусть и тайпсейф во все места.
1. (prepared-by) ага — ты 1.0.1 cмотрел. В 2.0.x есть compiled, правла с ограничениями ;)
2. джойны — ну не знаю, в моих ситуациях нормально. Это надо детали смотреть.
(я бы в качестве идеала видел бы все-таки type-safe DSL в стил squeryl но composable и с меньшими багами — но место текущего хобби проекта у меня уже занято ;). Так что будем надеяться что slick эволюционирует.
Контролировать sql руками — конечно так проще всего, но долго.
2.0 еще сырое совсем-совсем.
контролировать SQL руками — ну пацаны, ей богу, такое чуйство что вы SQL каждые три часа переписываете и вам вот кровь из носу надо, чтобы оно было typesafe с выводом типов по хиндли-милнеру. Монады и стрелки еще не требуются в SQL?
как по мне, чем ловить блох в непонятном сгенерированном кем-то как-то SQL, уж лучше потратить на 2 минуты больше и написать его руками. В здеcь mybatis живее всех ленинов. И да, они мне платят по 1000 мильёнов баксов за умоминание этого слова в каждом посте.
Что в очередной раз меня убедило — лучший способ работать с базой — это самому писать SQL, по крайней мере точно будешь знать что там и как.
Так и сделал. JDBC враппер на 150 строчек. Транзакции, освобождение ресурсов, все дела, ленивость. Доволен
Włodzimierz Rożkow
Akka-то зачем?
Есть мнение что ее можно использовать не как средство асинхронных или параллельных вычислений, а как middleware для организации приложения в целом, разделения на компоненты, понижения связности.
Vlad Svitlychnyi
(и этот человек порицал меня за то, что я сижу на доу!)
В харьковском офисе Grid Dynamics пилят undeploy.me на скале, но каких-то подробностей о библиотеках/фреймворках я не знаю
ну а чо делать, не все в илитном скайпочятике о бабах да теории категорий
Włodzimierz Rożkow
Отпишите вот тут — dou.ua/...ums/topic/8237
Igor Petruk
В принципе только Play2 среди библиотек. На Scala пишем много и много алгоритмов, конвертируем данные. Для продакш использования мало библиотек Scala достаточно хороши, стабильны и документированы. Многие из них злоупотребляют DSL, который тяжело понять. Потому пишем врапперы вокруг качественных Java библиотек, например асинхронные запросы Datastax Cassandra оборачиваются в интерфейс Scala Future и потом комбинируются.
Но библиотека коллекций родная и очень хорошая, для IoC — родной cake pattern
Ладно, начну с себя тогда уж
— spray.io в качестве REST клиента/сервера. Что в нем ок — это DSL для построения роутинга ресурсов, очень шустрый сервер с akka и неблокирующим IO. Штатные обертки на все случаи жизни (запаковать-распаковать, сбайндить форму в кейскласс) и связки с разными JSON-парсерами от Lift или банальный jackson. Весьма рекомендую.
— typesafe config — хоть оно и pure java, но на его основе можно собирать клевые конфиги на object, очень получается typesafe. Иерархии свойств, подстановка, оверрайд через sysenv или runtime properties. Притом один джар и никаких зависимостей. Счастье же!
— scalatest/specs2 — тесты никогда никто не отменял, даже для монад и прочего «матана», потому кому что нравится — или писать в стиле junit, или писать в стиле acceptance testing scripts. Не слушайте всех этих модных хаскельщиков, у которых если что-то там собирается — то оно автоматически работает правильно. Такое могут сказать только адепты Coq, но они ничего рабочего в продакшн как правило не пишут.
— scalaquery — интересная игрушка, чем-то напоминающая spring-jdbc, но как по мне оно все сырое, генерируемые запросы иногда далеки от идеала, с prepared queries беда в случае использования агрегирующих функций. Старый добрый MyBATIS ftw.
— akka — куда ж нынче без актеров, это модно, стильно, молодежно! С другой стороны, обычные тредпулы и прочие CompletionService никто не отменял. Что хорошо в актерах — это применение мышления в стиле ерланга «вот тут мы засунем сообщение, и кто-то когда-то где-то его как-то обработает». С кастомными mailbox можно делать разные штуки типа приоритетов, ну а встроенный механизм связи по HTTP делает все сильно приятнее, чем какой-то RMI. Ну это имхо.
— Lift framework — объективно в моей реальности лучший фреймворк всех времен и народов, правильный nextgen. По сравнению с лифтом Play! — это спринг, EJB и прочий энтерпрайз в полный рост. Да еще и с maven толком не работает. В общем, если быстро, клево, по-хипстерски фигачить в продакшн — то лифт лифтее всех лифтов.
задавайте свои ответы.
а play2 в сравнении с lift пробовали? Я на нем писал но только на java, что вызывало мощный когнитивный диссонанс
ну я там про play и писал, он у меня и на скале вызывает когнитивный диссонанс своей многословностью и ынтерпрайзностью
ну вот да, многословен. и на жаве еще страдает от развесистого синтаксиса. Чуваки которым это разгребать досталось были вообще в трансе по моему ощущению.
Вам Lift не кажется слишком DSLным (что ясное дело синоним слова «плохой»)? И как вы там делаете IoC чтобы тестировать модули?
нет, не кажется, весь dsl что там есть — это обработка HTML, его можно и без DSL писать. Но с DSL все ж удобнее. IoC в скале можно делать 100500 разных способов, я лично применяю модное слово cake pattern и Google Guice.
А что вы делаете на Akka?
роутинг сообщений, роутинг запросов. Она особо больще ни за чем не нужна.
Почти тоже самое.
Только без Lift и вместо scalaquery — scalikejdbc(тот который без interpolate)
Нравится тем что это просто тонкая прослойка между SQL и Scala — гораздо больше spring-jdbc’like чем что-либо что я видел. Но разработчик таки ударился в DSL и теперь развивает interpolate версию — которая еще не очень(например for update пока никак не сделать — без хачинья либы).
Но разработчик таки ударился в DSL и теперь развивает interpolate версию
«Пропал дом...» © Преображенский
а Circumflex ORM ок/неок?
circumflex был, да, но я его по итогу выкрутил в пользу mybatis. Впечатлений не оставил никаких, разве что вот вся эта «давайте теперь сущности назовем таблицами и напихаем туда стопиццот ненужных методов для индексов и внешних ключей» задалбывает до невменяемости.
Нестор Иванович
отпишусь в теме что бы последить за развитием.
Я слышал от людей что занимаются но 1)мало 2) редко
так что да — скорее нет чем есть :(
это как минимум странно, потому как я с завидной регулярностью получаю писем от разных киевских контор на тему «айда к нам лабать нетленку». Аж любопытно стало — как с этим дела на ДОУ.
мне ни разу не приходили — но я для киевских контор личность не интересная :)
та же фигня, но почему-то пишут и пишут
я в первый год эммигрантской жизни много получал. потом по маленьку притихло. видимо самые активные таки вынесли из черных списков.
ну, оно обычно как бывает — работал ты например в люксофтах, уволился, те рекрутеры которые там уже давно — они про тебя в курсе и не трогают, а потом приходит новый набор шушпанчиков — и понеслась «Евгений, у нас открыта супер-пупер вакансия в офигенном проекте галактического масштаба, варп-двигатели и девственницы с планеты Шойгу бонусом, идите к нам в Киев работать». И даже не знаешь, что б им такого ответить погуманнее, дабы не травмировать от входа.
262 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів