Уважаемые форумчане.
сам я не джавист, но заинтересовали некоторые языки для JVM-платформы, в частности Clojure, Jython и еще парочку менее известных. Изучать думаю больше для фана (хотя если подфартит с заработком в этом направлении — было бы круто).
Поэтому у меня есть такой вопрос:
Насколько важны знания самой джавы для jvm-языков?
или достаточно знать основы джавы + как средствами выбраного jvm-языка (например, из Clojure) получать доступ к джавовским библиотекам?
Безотносительно основного вопроса, просто небольшое замечание. Раз уж решились на подобное, то готовьтесь к проблемам. Каждый раз, когда мне приходилось иметь дело с языками и/или технологиями, которые насильно впихнуты в чуждую им экосистему, получалось не очень.
Во-первых, из-за карликового комьюнити часто банально не с кем посоветоваться. Опытных людей в пабликах просто нет, остальные знают вопрос примерно как вы, или хуже.
Во-вторых, из-за мелкой команды разработки, все это сильно забаговано, ошибки не правятся годами, приходится вместо работы заниматься подстановкой костылей чуть ли не на каждом шагу.
В-третьих, при поиске решения результаты вашего поиска будут беспросветно завалены аналогичными темами в контексте материнской технологии, что затрудняет поиск и раздражает осознанием того, что у них-то эта проблема уже решена, а у тебя по-прежнему нет.
Кстати, вопрос автору — с чем связан выбор именно джитона, вместо обычного питона ?
1. я еще не решил использовать именно jython (скорее всего выберу Clojure)
2. если Jython не сильно отличается от обычного питона, то можно будет (я так предполагаю) использовать знания обычного питона, чтобы писать под jvm.
правда, как кто-то тут уже писал что jython просто интерпретатор, так что не знаю — компилит ли он джавовский байткод или только интерпретирует.
Насколько важны знания самой джавы для jvm-языков?Вы
или достаточно знать основы джавы + как средствами выбраного jvm-языка (например, из Clojure) получать доступ к джавовским библиотекам?
2. Что мешает это все не использовать, а пользоваться тем что есть для кложура и готовыми байндингами ?
Я не очень разбираюсь в Clojure, но какая там, например, замена JDBC и JDBC Connection Pool? Или какой другой «кошерный» способ работать с реляционными базами.
Ну давай я погуглю за тебя: github.com/clojure/java.jdbc
Я, например, тоже.
Кложур достаточно популярный, чтобы предположить что и байдинги ждбц и свои либы для работы с базой вполне есть. Гугл если что.
Вот за джитон — не знаю.
Так же, при сравнении, я бы учел, что
1. Scala разрабатывается супер-авторитетом в мире Java/JVM паном Одерским, который, между прочим, автор текущего компилятора javac (ну версии Java 5 так точно, это он вкручивал генерики, в Java 8 лямбды вкручивал уже не он)
2. Scala интенсивно развивается академическим сообществом. Так что если Вам для расширения кругозора — то они там много чего накрутили и продолжают накручивать.
Стоит еще учесть что скала в разы сложнее и мутнее кложура.
Это да.
Не сказал бы, что именно ’мутная’, но очень объемная/сложная и ни один источник детально все детали не объясняет, что это действительно выглядит как ’мутная’.
Когда разберешься, то она выглядит достаточно стройной.
Scala разрабатывается супер-авторитетом в мире Java/JVM паном Одерскима Clojure — не менее авторитетным Ричем Хикки)
«На данный момент в большинстве источников Хикки указывается как „независимый разработчик ПО и консультант с
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 лет писал на скалекак уже все больше подтверждается статистикой — написание собственно кода — малая часть работы программиста.
Другое дело что с джавы перепрыгнуть на скалу с сохранением производительности трудаважнее что результат работы скалистов как-то не показывает феноменального увеличения производительности труда.
то есть, бизнес не видит этих замечательных цифр продуктивности.
и поэтому не хочет платить хотя бы в разы больше.
либо — риски настолько велики, что сводят к нулю ожидаемые преимущества применения технологии.
фсё.
остальное, это на тему:
«Почему академическое программирование ДАВНО провалилось».
Там были авгиевы конюшни на 5 строк.
просто процитирую:
nponeccop: А мне по-й, что хаскель не взлетит
В коде, который компилировался, но не запускался, после запуска обнаружилось 3 бага и 1 воркараунд пришлось залепить. При разборе полётов с воркараундом обнаружилось, что потеря узлов — это какое-то общее место. Теперь только теряет узлы не Hoopl, а мой компонент с пафосным названием GraphDecompiler, который граф обратно в AST переделывает.
Там были авгиевы конюшни на 5 строк. После того, как их разгрёб, обнаружилось, что в одной из этих 5 строк я реализую fmap. Пришлось залепить два синонима типов в 100500 файлах, чтобы сделать функтор из семейства взаимно-рекурсивных типов, представляющих AST, и заменить ручной fmap на отдерайвленный.
...
ответ vit_r: Я ничего не имею против самого подхода, но родятся новые языки и библиотеки от рук учёных, а не инженеров. В результате получается не рабочий инструмент, а хитрые устройства для извращения в малом. По-моему, вышеприведённая цитата — это всё, что нормальный программист и нормальный менеджер должны знать о педофилах фанатах функционального программирования.
...
Думать надо тогда, когда надо думать. А не решать головоломки вместо работы.
Чтобы понять где что, надо усиленно скрипеть мозгами.
ему: Лучше уж авгиевы конюшни на хаскеле — они на экран и в голову помещаются, хотя бы.
Правило номер ноль: ничего не должно помещаться в голове. Всё должно быть на бумаге. А с Хаскеля надо не просто раззиповывать запись, но ещё и расшифровывать код.
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 (немного посмотрел — как по-мне симпатишный
НУ у них там какое то комьюнити есть, их кто-то использует, вон фейсбук недавно зарелизил на окамле какую то тулзу для поиска багов, и на хаскеле борются с спамом.
У кложура тоже есть комюните, и его тоже для всякой фигни успешно используют: dev.clojure.org/...y/Clojure Success Stories
Ладно, с кложурем был неправ. Но он негоден потому что лисп.
Вот, человек правду говорит. Зачем изучать то что мало кому нужно? А вот изучать гугловский новый язык Го, и потом быть в нем экспертом, когда он станет популярным, уух...
Надо отметить что Го уже достаточно популярен в своей нише. Маргинальным называть бы не стал.
Пока он скорее «широко популярен в узких кругах».
Учитывая сколько гугл вкладывает в его продвижение, мог бы быть и популярнее
Для Clojure не надо. Для настройки компиляции и сборки тоже глубоких знаний не требуется, гугл подскажет.
Дергать библиотеки тоже. еще и потому что идеология Clojure очень другая. Если сильно из него дергать джавовские либы — то на кой он нужен, берите Groovy.
про сборщики мусора, генерации куч и прочее всеже рекомендуются почитать :-)
Если сильно из него дергать джавовские либыну я предполагаю юзать кложевские аналоги джавовских либ, а джавовские либы — тока в том случае, если кложевского аналога нет.
груви — может как-нибудь гляну.
Ты не поверишь, но по мере погружения в проект ты всё сильнее отрываешься от языка и используешь его только как синтаксис. Во всём остальном — ты используешь библиотеки, шаблоны, наработки.
Другими словами, в зрелом проекте можно вообще не знать язык на котором программируешь. Процента
IMHO Closure о̶т̶с̶т̶о̶й «на любителя», лучше ориентируйся на Scala. Перспективы лучше, работы больше, фреймворки более зрелые.
ясно) пасиб за совет.
IMHO Closure о̶т̶с̶т̶о̶й «на любителя», лучше ориентируйся на Scala. Перспективы лучше, работы больше, фреймворки более зрелые.ну... насколько я знаю Scala посложнее Clojure будет, да и в Clojure вроде тоже есть зрелые фреймворки (по крайней мере для веба) — Om или Compojure, например. Ну и ClojureScript, естесно.
хотя да, Скала сейчас наверное язык № 2 для JVM по популярности (после самой джавы), из чего следует, что под нее фреймворков и т.д. побольше будет, чем для кложуры. Хотя это не значит, что кложура хуже скалы — она именно на любителя (для тех, кому лисповый синтаксис нравится).
Другими словами, в зрелом проекте можно вообще не знать язык на котором программируешь. Процента2-3, не более.
Например, твои знания русского языка едва ли дотянут до 20%. И при этом ежедневно пользуешься не более
Во первых, взятая с потолка цифра 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-языков подобного рода утилиты (модули, плагины) для большинства популярных задач должны быть?Должны быть.
Наверное, какая-то осведомленность нужна, но не более. Особенно, в случае с Clojure.
надеюсь, что так оно и есть. А то как-то стремно учить и Java, если мне пока интересует только Clojure или Jython)
Jython — это Python, который выполняется в JVM. Надо знать только Python.
Борис Махно
Grez
Ivan Golovach
Grez
Ivan Golovach
reality_hacker
Artem Astafyev
Sergii Vashchyshchuk
Bogdan Shyiak
undefined pointer
Максим Бублик
Dmytro Zaitsev
reality_hacker
Olexandr Vovchok
Mykola Gurov
undefined pointer
Олексій Пєніє
Олексій Пєніє
Iurii Vishnevskyi
Bogdan Shyiak
Андрей
Stanislav Demchenko
70 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів