JVM-языки и знания джавы

Уважаемые форумчане.

сам я не джавист, но заинтересовали некоторые языки для JVM-платформы, в частности Clojure, Jython и еще парочку менее известных. Изучать думаю больше для фана (хотя если подфартит с заработком в этом направлении — было бы круто).

Поэтому у меня есть такой вопрос:

Насколько важны знания самой джавы для jvm-языков?
или достаточно знать основы джавы + как средствами выбраного jvm-языка (например, из Clojure) получать доступ к джавовским библиотекам?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Безотносительно основного вопроса, просто небольшое замечание. Раз уж решились на подобное, то готовьтесь к проблемам. Каждый раз, когда мне приходилось иметь дело с языками и/или технологиями, которые насильно впихнуты в чуждую им экосистему, получалось не очень.

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

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

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

Кстати, вопрос автору — с чем связан выбор именно джитона, вместо обычного питона ?

1. я еще не решил использовать именно jython (скорее всего выберу Clojure)
2. если Jython не сильно отличается от обычного питона, то можно будет (я так предполагаю) использовать знания обычного питона, чтобы писать под jvm.
правда, как кто-то тут уже писал что jython просто интерпретатор, так что не знаю — компилит ли он джавовский байткод или только интерпретирует.

Насколько важны знания самой джавы для jvm-языков?
или достаточно знать основы джавы + как средствами выбраного jvm-языка (например, из Clojure) получать доступ к джавовским библиотекам?
Вы
1. Или разрабатываете самостоятельный продукт (скорее всего что-то распределенное, многопоточное, облачное) — в таком случае Вы, почти наверняка, используете ограниченный круг крутых компонент из мира Java (Zookeeper, Netty, ...) и Вам достаточно синтаксиса Java.
2. Или пилите полноценное/банальное web-приложение с реляционной базой. В таком случае Вам часто придется использовать (или интегрироваться) все эти Hibernate, Spring, JUnit, Mockito, Log4j, ... из-за того, что они хорошо отлажены, популярны, ...

2. Что мешает это все не использовать, а пользоваться тем что есть для кложура и готовыми байндингами ?

Я не очень разбираюсь в Clojure, но какая там, например, замена JDBC и JDBC Connection Pool? Или какой другой «кошерный» способ работать с реляционными базами.

Я, например, тоже.
Кложур достаточно популярный, чтобы предположить что и байдинги ждбц и свои либы для работы с базой вполне есть. Гугл если что.
Вот за джитон — не знаю.

Так же, при сравнении, я бы учел, что
1. Scala разрабатывается супер-авторитетом в мире Java/JVM паном Одерским, который, между прочим, автор текущего компилятора javac (ну версии Java 5 так точно, это он вкручивал генерики, в Java 8 лямбды вкручивал уже не он)
2. Scala интенсивно развивается академическим сообществом. Так что если Вам для расширения кругозора — то они там много чего накрутили и продолжают накручивать.

Стоит еще учесть что скала в разы сложнее и мутнее кложура.

Это да.
Не сказал бы, что именно ’мутная’, но очень объемная/сложная и ни один источник детально все детали не объясняет, что это действительно выглядит как ’мутная’.
Когда разберешься, то она выглядит достаточно стройной.

Scala разрабатывается супер-авторитетом в мире Java/JVM паном Одерским
а Clojure — не менее авторитетным Ричем Хикки)

«На данный момент в большинстве источников Хикки указывается как „независимый разработчик ПО и консультант с 20-летним опытом работы в различных областях разработки ПО“» © ru.wikipedia.org/wiki/Хикки,_Ричард

Jython — ересь, так как есть оригинальный Python.
Выбирайте между Scala и Clojure.
Критерий прост — посмотрите, на каких языках (кроме Java) создают «значимые» вещи под JVM.
Scala: Akka (de facto стандарт реализации акторов под JVM), Spark (потенциальный убийца Hadoop/MapReduce от университета Беркли), Kafka (очереди сообщений от LinkedIn), Mahout (machine learning tool, переписывают с Java), Samza (Stream processing engine from LinkedIn), Finagle (микросервисы, на которых работает Twitter), Scalding, Zipkin (distributed tracing system from Twitter)
Clojure: Storm.
---
В целом «клевые» компании типа Twitter/Facebook/LinkedIn, если пишут что-то интересное для облаков под JVM, но не на Java, то почти всегда это Scala. А ведь «сто тысяч зеленых мух не могут ошибаться»?
:)

Могут, кто реально работал, тот знает :) Scala — это академический понт. Когда пишешь реальные проекты, больше времени уходит на написание в Scala-way, чем концентрация на проблеме. А потом вдруг оказывается, что подключить простую Java-библиотеку не так-то просто. А как дело доходит до поддержки, то специалистов днем с огнем не найдешь.

Я воспринимаю Scala как крайне гибкий и мультипарадигменный язык. Вы могли бы для обсуждения привести пример, когда бы

написание в Scala-way
сильно связывал Вам руки.
Scala — это академический понт
Ну я воспринимаю Scala, как состощую из двух достаточно независимых частей.

Первая: OOP, Functional Programming, Custom control flow structures, Generics (without higher-king types), Tuples, Pattern Matching, For-Comprehensions, Implicits, Structural types — очень красивый и гибкий гибрид OOP+FP, более красивый и удобный чем Java.

Вторая: Path dependent types, Generics of higher-king, Type calculations, Macroses, Scala Reflection — действительно академична, но так что заставляет кого-либо ее использовать?

действительно академична, но так что заставляет кого-либо ее использовать?
У людей могут быть очень разные мотивы, а тебе разгребать.

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

Как раз в том и аргумент, что потому что джава проще, гавнокод на ней разгребать тоже проще.

Шансов встретить говнокод на скале меньше, так как в среднем уровень скалистов выше, чем джавистов

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

Шансов встретить говнокод на скале меньше, так как в среднем уровень скалистов выше, чем джавистов
... при условии равномерного распределения.
Так же надо помнить про то что нам не интересны чисто формальные отличия, то есть количества гуана должны отличатся существенно.
Одна из множества проблем скалы — это ее позиционирование как «крутого языка». В результате многие недосиньоры -с комплексом неполноценности- ломанулись туда.
Скала более сложный инструмент, соответственно допустить ошибку проще, что в свою очередь увеличивает уровень говнокода.
.
Это я не к тому что скала хуже, лучше или хуже можно сказать только определив критерии и проведя измерения, а не строя домыслы на форуме. Это все к тому что не надо упрощать модель настолько на сколько это сделали вы.

несколько уточнений на примере:

Шансов встретить говнокод на Ruby меньше чем на PHP
привело к тому что у рубистов средний уровень выше чем средний у пхпистов.

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

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

то же уже происходит и с Хаскелем, и, как понимаю уже, или скоро будет со Скалой.

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

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

то же уже происходит и с Хаскелем, и, как понимаю уже, или скоро будет со Скалой.

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

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

особенно учитывая то что успех стартапа мало зависит от технологии :)

как их подбирают для новых проектов на PHP,
вообще-то подавляющее большинство новых проектов как раз и делается на джаве или пыхе :)
новый проект != стартап
утрировано
запуск стартапа — это когда проект делается перед поиском денег.
а новый проект — когда деньги на него уже нашли.

отсюда — разница в пиаре.
стартап пиарится везде где можно.
новый проект — в спец СМИ, скупонько.

и возникает ложное ощущение что кругом одни стартапы, а новых проектов — нет.

процесс тот же в политическом пиаре. «раскрутка политика» делается по тем же правилам оболванивания.

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

Проблемы со скалой в том,
что это слишком академический ЯП.
если бы ты 5 лет писал на скале
как уже все больше подтверждается статистикой — написание собственно кода — малая часть работы программиста.
Другое дело что с джавы перепрыгнуть на скалу с сохранением производительности труда
важнее что результат работы скалистов как-то не показывает феноменального увеличения производительности труда.
голословно да, постоянно можно слышать —
«Функциональный программист пишет код, который в 100 раз надежнее и в 5 раз эффективнее, и пишет он это в 5 раз быстрее, чем «объектный».
© Влад Патрышев aka ivan_gandhi
но, как он же написал далее
«Но нанять его хотят по цене объектного»

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

фсё.

остальное, это на тему:
«Почему академическое программирование ДАВНО провалилось».

Там были авгиевы конюшни на 5 строк.

просто процитирую:
nponeccop: А мне по-й, что хаскель не взлетит
В коде, который компилировался, но не запускался, после запуска обнаружилось 3 бага и 1 воркараунд пришлось залепить. При разборе полётов с воркараундом обнаружилось, что потеря узлов — это какое-то общее место. Теперь только теряет узлы не Hoopl, а мой компонент с пафосным названием GraphDecompiler, который граф обратно в AST переделывает.

Там были авгиевы конюшни на 5 строк. После того, как их разгрёб, обнаружилось, что в одной из этих 5 строк я реализую fmap. Пришлось залепить два синонима типов в 100500 файлах, чтобы сделать функтор из семейства взаимно-рекурсивных типов, представляющих AST, и заменить ручной fmap на отдерайвленный.
...

ответ vit_r: Я ничего не имею против самого подхода, но родятся новые языки и библиотеки от рук учёных, а не инженеров. В результате получается не рабочий инструмент, а хитрые устройства для извращения в малом. По-моему, вышеприведённая цитата — это всё, что нормальный программист и нормальный менеджер должны знать о педофилах фанатах функционального программирования.
...
Думать надо тогда, когда надо думать. А не решать головоломки вместо работы.

Чтобы понять где что, надо усиленно скрипеть мозгами.

ему: Лучше уж авгиевы конюшни на хаскеле — они на экран и в голову помещаются, хотя бы.

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

vit-r.livejournal.com/814184.html

Kevin Scott (LinkedIn):

We are not getting rid of Scala at LinkedIn. We’ve recently made the decision to minimize our dependence on Scala in our next generation front end infrastructure which is rolling out this year. We’ve also made a decision to focus our development infrastructure efforts on Java 8, Javascript, Objective-C, Swift, C++, and Python given the nature of things that we are building right now and will be building in the foreseeable future. That said, we have a ton of Scala code running in production, and will continue to provide basic support for Scala and those Scala systems for the foreseeable future.

Автор Kaffka ушел из Linkedin, стало меньше людей (сколько их там всего — хз) кто проталкивал решения на Scala

а Typesafe Inc. en.wikipedia.org/wiki/Typesafe_Inc. ? или решения для скалы в основном на линкедине проталкивались? (просто интересно)

Scala, Kotlin и Groovy как в связке, так и по отдельности удовлетворят Ваши потребности.
Прям Advanced знаний в Java Вам не понадобится, при этом базис будет просто необходим.
Я бы порекомендовал Вам, прежде чем разбираться в чем-то Java-подобном, разобраться и с самим языком Java, чтоб было с чем сравнивать, ощущать преимущества и недостатки.

Java надо знать.
Jython — ересь. Потому что есть канонический ортодоксальный Python. :-)

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

Кложа, джпитон — это какая то полная маргинальщина.
А хаскель с окалом, значит не маргинальщина ? :)

ну я знаю, что есть Frege, Jaskell (две известные мне реализации хаскеля на джаве) и Ocamljava (реализация окамла на джаве). Также находил такое — mth.github.io/yeti (немного посмотрел — как по-мне симпатишный ML-язык для джавы). И это я бы сказал еще бОльшая маргинальщина, чем оригинальные Haskell, Ocaml и SML)))

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

У кложура тоже есть комюните, и его тоже для всякой фигни успешно используют: dev.clojure.org/...y/Clojure Success Stories

Ладно, с кложурем был неправ. Но он негоден потому что лисп.

Вот, человек правду говорит. Зачем изучать то что мало кому нужно? А вот изучать гугловский новый язык Го, и потом быть в нем экспертом, когда он станет популярным, уух...

Надо отметить что Го уже достаточно популярен в своей нише. Маргинальным называть бы не стал.

Пока он скорее «широко популярен в узких кругах».

Учитывая сколько гугл вкладывает в его продвижение, мог бы быть и популярнее

Для Clojure не надо. Для настройки компиляции и сборки тоже глубоких знаний не требуется, гугл подскажет.
Дергать библиотеки тоже. еще и потому что идеология Clojure очень другая. Если сильно из него дергать джавовские либы — то на кой он нужен, берите Groovy.

про сборщики мусора, генерации куч и прочее всеже рекомендуются почитать :-)

Если сильно из него дергать джавовские либы
ну я предполагаю юзать кложевские аналоги джавовских либ, а джавовские либы — тока в том случае, если кложевского аналога нет.

груви — может как-нибудь гляну.

Ты не поверишь, но по мере погружения в проект ты всё сильнее отрываешься от языка и используешь его только как синтаксис. Во всём остальном — ты используешь библиотеки, шаблоны, наработки.

Другими словами, в зрелом проекте можно вообще не знать язык на котором программируешь. Процента 2-3, не более. Так что не задавай глупых вопросов раньше чем столкнулся с реальной проблемой. Ставь и пользуйся. Когда же столкнёшься с ограничением — к этому моменту ты уже будешь чётко понимать чего хочешь, и гугл как правило с лёгкостью ответить на твою хотелку.

IMHO Closure о̶т̶с̶т̶о̶й «на любителя», лучше ориентируйся на Scala. Перспективы лучше, работы больше, фреймворки более зрелые.

ясно) пасиб за совет.

IMHO Closure о̶т̶с̶т̶о̶й «на любителя», лучше ориентируйся на Scala. Перспективы лучше, работы больше, фреймворки более зрелые.
ну... насколько я знаю Scala посложнее Clojure будет, да и в Clojure вроде тоже есть зрелые фреймворки (по крайней мере для веба) — Om или Compojure, например. Ну и ClojureScript, естесно.

хотя да, Скала сейчас наверное язык № 2 для JVM по популярности (после самой джавы), из чего следует, что под нее фреймворков и т.д. побольше будет, чем для кложуры. Хотя это не значит, что кложура хуже скалы — она именно на любителя (для тех, кому лисповый синтаксис нравится).

Другими словами, в зрелом проекте можно вообще не знать язык на котором программируешь. Процента 2-3, не более.

Это какоето эпическое заблуждение :-)
Если «формошлепство», аля добавить новое поле в базу и на формочку — то да, возможно проканает. Если чтото по сурезнее — то знающие 2-3 процента будут вам генерировать чистый б-код.

2-3 процента не так и мало. Наработки в языке достаточно огромны, а учить что-то чем пользоваться не будешь — бесполезно.

Например, твои знания русского языка едва ли дотянут до 20%. И при этом ежедневно пользуешься не более 1-2%. Простой пример: рукописное письмо. Пользуешь редко. Уверен, что им владеешь? Сравни с прописями.

Во первых, взятая с потолка цифра 20% — весьма спорна.
Во вторых сравнивать разговорный язык применяемый на форуме и инженерное дело — не корректно.
Объем приложенных усилий, и ответственность за результат — намного разные.

Очень даже корректно. Вопрос был надо ли учить Java при пользовании других языков под JVM. Ответ — НЕТ. А если и понадобится, то учить основную часть и по мере надобности, а никак не весь расчудесный объём «лучших практик» и musthave-библиотек.

Вопрос был надо ли учить Java при пользовании других языков под JVM. Ответ — НЕТ.

Вопрос то был, только вы утверждали нечто иное:
Другими словами, в зрелом проекте можно вообще не знать язык на котором программируешь. Процента 2-3, не более.

Увы, но это не так. Родные языки люди знают очень и очень хорошо. Потому чтобы выучить иностранный язык на уровне человека, у которого это родной — надо много лет учится, очень много.

Но при общении с машиной требования ниже. К примеру, настроить программу на английском может и школьник. Те же требования и к языкам под JVM — не нужно раньше времени учить java. Только если понадобится, и только ту часть которая понадобится.

Учить нужно только то, что требуется для работы, а остальное по желанию.

никогда не знаеш что и где тебе пригодиться.

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

вот я примерно так же и предполагаю — учить только ту часть джавы, которая нужна для знания выбраного jvm-языка. Если (как в случае с Clojure как языком синтасически и идеологически — функциональный, в отличие от объектно-ориентированной джавы) особых знаний джавы для кодинга «для фану» не нужны — тем лучше. :)
а вот Clojure либо Scala, Kotlin или Groovy — я еще подумаю и решу) (хотя склоняюсь все же к Clojure).

а вот Clojure либо Scala, Kotlin или Groovy — я еще подумаю и решу) (хотя склоняюсь все же к Clojure).
главная фича Кложи — реализация Software transactional memory на уровне ядра ЯП. вот ради чего его стоить пощупать, а то и использовать в продакшене. лисповость то второстепенное.

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

Scala, Kotlin
или fantom.org

спасибо за разьяснения насчет джитона)
фантом — судя по синтаксису симпатишный вроде. Вот разве что оффициальная документация мне кажеться несколько запутанной (хотя возможно это только на первый взгляд).

При выборе языка еще рекомендуется учитывать степень поддержки ИДЕ.
Например идея нативно поддерживает груви, и оч хорошие официальные плагины под скалу и, разумееться, котлин. Вот всякие житоны с фантомами — скорей всего плагины сомнительного состояния, и плохой интеграции со всем остальным.
Для кложуры есть отдельно оч интересный концепт — lightTable.

для кложуры (помимо бесспорно рульной LightTable) я знаю есть еще две ИМХО симпатишные IDEшки: Clooj ( github.com/arthuredelstein/clooj , простенькая, наверное больше редактор с реплом нежели полноценная ide, видимо больше для начинающих кложуристов ) и NightCode ( github.com/oakes/Nightcode , sekao.net/nightcode ).
В Clooj, например, пробовал кодить по одному видео-туториалу, да и NightCode смотрел — понравился (чем-то напоминает IDEA с «темной» темой («дракула» вроде тема называется)).

Для clojure рекомендую обратить внимание на cursive (cursiveclojure.com ) для idea. Весьма хорошо работает, не смотря на то что оно ещё не готово.
Ну или cider (github.com/clojure-emacs/cider ), если для emacs.

попробую) и про cursive, и cider про слышал, но не пробовал еще.

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

Наверное, какая-то осведомленность нужна, но не более. Особенно, в случае с Clojure.

надеюсь, что так оно и есть. А то как-то стремно учить и Java, если мне пока интересует только Clojure или Jython)

Jython — это Python, который выполняется в JVM. Надо знать только Python.

Підписатись на коментарі