Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 119
согласен, но этот совет подходит любым программистам, не только на Java
Есть мнение (высказал кто-то из великих), что программист должен учить каждый год новый язык.
Ученые выяснили, что если регулярно есть 1200 яблок, по одному яблоку в месяц, то можно дожить до 100 лет.
Ну это юмор, немного не точный. :) Насчет каждого года не знаю.
Я двигаюсь по пути delphi -> php -> python -> java. Сейчас перешел на питон. Заметил очень интересную вещь: переходя от языка к языку, познаешь недоступные ранее истины прошедших языков. Т.е. изучая новый язык, хоть краем, но получается изучать другие языки. Очень удобно и интересно.
Ну это юмор, немного не точный. :) Насчет каждого года не знаю.
Я двигаюсь по пути delphi -> php -> python -> java. Сейчас перешел на питон. Заметил очень интересную вещь: переходя от языка к языку, познаешь недоступные ранее истины прошедших языков. Т.е. изучая новый язык, хоть краем, но получается изучать другие языки. Очень удобно и интересно.
Я двигаюсь по пути delphi -> php -> python -> java. Сейчас перешел на питон. Заметил очень интересную вещь: переходя от языка к языку, познаешь недоступные ранее истины прошедших языков.
Интересно, что бы вы могли узнать из Джавы такого, что не узнали бы при изучении Питона.
Получить лучшую инфраструктуру: производительность, библиотеки, среды разработки: нужно распространять django-приложение с работой out-of-box - пожалуйста, jetty/berkleydb/jython к вашим услугам. JRuby уже нашёл применение в Enterprise: Oracle Mix, TW Mingle.
Я не спрашивал про достоинства джавы, как платформы.
Всё зависит от того для чего мы учим новый язык, если для решения задач - то и рассматривать Java надо не только как язык, но и как платформу. Если в "академических" целях, то лучше сразу переходить к haskell & lisp.
> Я двигаюсь по пути delphi -> php -> python -> java
У меня почти такой же путь, только я пока на python'e остановился. Хотя так же после pythona есть мысли изучить java
У меня почти такой же путь, только я пока на python'e остановился. Хотя так же после pythona есть мысли изучить java
И кто этот "великий"? Языки программирования нужны чтобы выполнять конкретные задачи, а не для того чтобы их все подряд учили без дела. Если поучить нечего, историю родной страны можно поучить, или фонетический словарь... Полезнее для саморазвития во много раз будет, нежели изучение чёрт знает чего чёрт знает которое зачем чёрт знает может чёрт знает чем вам помочь (да и то на 90% вы к тому времени его уже забудете =)
Не согласен. Говорится о том, что необходимо поднимать общий уровень знаний. При изучении нового языка действительно изучаешь новые парадигмы (особенно если изучить принципиально отличающийся язык, например, Lisp или Prolog после Java). После этого в голове остается не язык, его синтаксис и семантика (детали забываются со временем), а именно основные идеи, заложенные в основу.
На самом деле, вы же не будете отрицать, что каждый язык создавался по той причине, что существующие языки не поддерживали все необходимые для разработки инструменты? Следовательно, если расставить языки программирования по прямой времени, то становится несколько более понятно, зачем это было сделано. И в итоге оно дает предпосылки к тому, куда двигаться дальше в этом направлении. И если за этим следить и, более того, участвовать, то будешь становиться все более и более классным специалистом.
Хотелось бы дополнительно отметить, что это высказывание сохраняет силу вне зависимости от специализации программиста на каком-то рабочем наборе языков.
На самом деле, вы же не будете отрицать, что каждый язык создавался по той причине, что существующие языки не поддерживали все необходимые для разработки инструменты? Следовательно, если расставить языки программирования по прямой времени, то становится несколько более понятно, зачем это было сделано. И в итоге оно дает предпосылки к тому, куда двигаться дальше в этом направлении. И если за этим следить и, более того, участвовать, то будешь становиться все более и более классным специалистом.
Хотелось бы дополнительно отметить, что это высказывание сохраняет силу вне зависимости от специализации программиста на каком-то рабочем наборе языков.
И в качестве нового языка не обязательно должен быть руби.
И наоборот :)
А почему именно с C-подобным?
Т.е. ruby-программист джаву учить не должен?
Т.е. ruby-программист джаву учить не должен?
Руби-программисту джаву учить бестолку - она ему ничего не даст.
Объясните почему.
Потому что абсолютно всё, что можно сделать в Джаве, можно сделать и в Руби. Можно сказать, что руби-программист Джаву уже знает полностью.
На ассемблере тоже можно сделать все, что в Джаве или в Руби.
Новый язык это не только новые конструкции и библиотеки. Это еще и подходы к решению задач, которые сформировались в той или иной среде. И вот именно ради них и есть смысл изучать новые языки.
Новый язык это не только новые конструкции и библиотеки. Это еще и подходы к решению задач, которые сформировались в той или иной среде. И вот именно ради них и есть смысл изучать новые языки.
Сила Джавы, как мне кажется, больше не в самой платформе (язык не поворачивается назвать её «языком программирования») сколько в библиотеках и фреймворках.
В случае разработки вочень ысоконагруженного приложения — это не так актуально—большую часть надо будет писать самим (но руби в той сфере я тоже не вижу). А в случае разработки, например бизнес—систем позволяет сэкономить большое количество времени использованием Apache, JBoss, OpenSymphony, UI-фреймворков (список неполный).
В случае разработки вочень ысоконагруженного приложения — это не так актуально—большую часть надо будет писать самим (но руби в той сфере я тоже не вижу). А в случае разработки, например бизнес—систем позволяет сэкономить большое количество времени использованием Apache, JBoss, OpenSymphony, UI-фреймворков (список неполный).
Мы здесь обсуждаем не применимость языка, а стоит его изучать, или нет. Причём не с точки зрения получения зарплаты, а с точки зрения роста себя, как программиста.
Я бы поостерёгся записывать веб-сервер Apache в плюсы к Джаве. А то так ещё и Линукс можно записать в плюсы :)) Ну и вы думаете, что в других языках нет библиотек и фреймворков? (это риторический вопрос)
А в случае разработки, например бизнес—систем позволяет сэкономить большое количество времени использованием Apache, JBoss, OpenSymphony, UI-фреймворков
Я бы поостерёгся записывать веб-сервер Apache в плюсы к Джаве. А то так ещё и Линукс можно записать в плюсы :)) Ну и вы думаете, что в других языках нет библиотек и фреймворков? (это риторический вопрос)
Простите, видимо не так выразился. Я больше к тому, что Руби — язык программирования, а Джава — платформа. Джава, как язык — ничем не примечательна.
p.s. Apache — джава проекты Апача (пакет org.apache) и сервлет-контейнеры, а не веб-сервер.
p.s. Apache — джава проекты Апача (пакет org.apache) и сервлет-контейнеры, а не веб-сервер.
Да, действительно, JVM, как платформа - свой закрытый мирок, из которого наружу никто не смотрит, и в который снаружи никто не смотрит. Я вот не знаю, зачем эти сервлеты нужны, какие у них преимущества есть (если есть, конечно :) ) по сравнению с другими методами взаимодействия (FastCGI, WSGI, etc). Если это кратко - просветите, пожалуйста :)
Я попробую, но за качество не отвечаю — я не java-разработчик :)
Сервлет-контейнер (по сути — application server) — содержит несколько зарегистрированных (например, /access — первый, /admin — второй) сервлетов. Сервлет должен уметь обрабатываь GET и POST запросы (методы doGet и doPost). Контейнер — разбирает кому отдать запрос и отдаёт, дальше не его дело.
Сравнить с WSGI или FastCGI, простите, не могу — до этого на питоне писал на Zope (там был свой «велосипед» — без FastCGI и прочего).
Обычно на уровне сервлетов мало кто пишет — эта логика уже на уровне UI фреймворка — например в Tapestry именно так (заглянул в стенд продукта компании :).
Сервлет-контейнер (по сути — application server) — содержит несколько зарегистрированных (например, /access — первый, /admin — второй) сервлетов. Сервлет должен уметь обрабатываь GET и POST запросы (методы doGet и doPost). Контейнер — разбирает кому отдать запрос и отдаёт, дальше не его дело.
Сравнить с WSGI или FastCGI, простите, не могу — до этого на питоне писал на Zope (там был свой «велосипед» — без FastCGI и прочего).
Обычно на уровне сервлетов мало кто пишет — эта логика уже на уровне UI фреймворка — например в Tapestry именно так (заглянул в стенд продукта компании :).
Ясно. Достаточно странное решение, как на меня, ну да ладно :)
Servlet API и WSGI по сути одно и тоже. Только в Java это придумали по-раньше, когда возникла необходимость пускать одни и те же приложения на разных app servers. Лучшим сравнением наверное будет посмотреть исходники modjy - своеобразный "маппинг" wsgi на сервлеты, чтобы wsgi приложения пускать на jvm под jython'ом)
По преданию Ruby-программист - центр вселенной, и ему абсолютно незачем учить другие языки.
(шепотом) бабки даст и карьеру
вакансий на яву больше и платят там, в среднем, больше.
вакансий на яву больше и платят там, в среднем, больше.
Ну насчёт руби не знаю, но за Питон платят больше, чем за Джаву, причём достаточно ощутимо.
это дело очень легко проверить вот таким образом http://www.job.ru/searchResults.html?selectType=2&country=1&_showOffersFromLast=&keywords=python&jobCategories=-1®ions=2
как видно, в большинстве вакансий питон вообще не идет в заголовке, а только где-то одним из желательных требований
зарплаты совершенно обычные
как видно, в большинстве вакансий питон вообще не идет в заголовке, а только где-то одним из желательных требований
зарплаты совершенно обычные
Я не обращал внимания ни на российские вакансии, ни на средние - я обращал на те, куда я мог бы пойти работать, и куда меня приглашали. И у питонских вакансий зарплата была, в среднем, на 30-60% выше.
хм, если вы говорите не о российских и не о средних (кстати, что такое средние в данном случае?), а о вакансиях предлагавшихся вам лично, то правильно я понимаю, что 30-60% выше - это тоже сравнительно к непитоновским "вакансиям предлагавшимся вам"? может ли это странное сравнение быть показателем вообще чего-либо в любую сторону?
> если вы говорите не о российских
Я в Украине живу ;)
> и не о средних (кстати, что такое средние в данном случае?)
Средние - средние по зарплате. Я смотрел статистику с developers.org.ua.
> то правильно я понимаю, что 30-60% выше - это тоже сравнительно к непитоновским "вакансиям предлагавшимся вам"
Не только те, которые мне предлагали лично, но и те, куда я, в общем-то, мог пойти работать. И не только я, но и некоторое количество моих знакомых. И вот в питоновских вакансиях зарплата на 30-60% выше, чем в более-менее аналогичных джавовских вакансиях. Я думаю, что это именно потому, что «Джава даст бабки и карьеру», и её учат все. А Питон - не так.
Я в Украине живу ;)
> и не о средних (кстати, что такое средние в данном случае?)
Средние - средние по зарплате. Я смотрел статистику с developers.org.ua.
> то правильно я понимаю, что 30-60% выше - это тоже сравнительно к непитоновским "вакансиям предлагавшимся вам"
Не только те, которые мне предлагали лично, но и те, куда я, в общем-то, мог пойти работать. И не только я, но и некоторое количество моих знакомых. И вот в питоновских вакансиях зарплата на 30-60% выше, чем в более-менее аналогичных джавовских вакансиях. Я думаю, что это именно потому, что «Джава даст бабки и карьеру», и её учат все. А Питон - не так.
сделал поиск на developers.org.ua. получил целых СЕМЬ вакансий про питон. опять же, в большинстве вакансий он "побочен".
количество вакансий на Яву просто так не посчитаешь, там сотни.
внимание, вопрос: каким образом можно делать сравнения по зарплане на таком рынке?
количество вакансий на Яву просто так не посчитаешь, там сотни.
внимание, вопрос: каким образом можно делать сравнения по зарплане на таком рынке?
Да я не собираюсь вам ничего доказывать :) Статистика - я не про вакансии, а про такое: http://www.developers.org.ua/archives/max/2008/03/06/kiev-it-salaries-raised-by-40-percent/ (ссылку не могу поставить из-за отрицательной кармы)
Ну а сами вакансии - то что знакомые говорили, то что на конференции (Exception) обсуждалось, то что мне в мыло падало. У меня нет задачи собрать полную статистику по всем программистам СНГ :)
Ну а сами вакансии - то что знакомые говорили, то что на конференции (Exception) обсуждалось, то что мне в мыло падало. У меня нет задачи собрать полную статистику по всем программистам СНГ :)
о господи. при чем тут зарплата, если вакансий нет? есть грубо говоря всего несколько мест, где нужны именно питонисты. допустим питонистов мало (хотя порог входа низкий, потому начальным уровнем любой может овладеть махом) допустим, кому-то они нужны позарез и им ставят зарплату 3000EUR. одного нашли, второго нашли, третего нашли. ВСЁ. остальные привычно идут писать на ПХП. Все данные по вакансиям России и Украины говорят именно о такой ситуации. В евпропе не намного отличается (соотношение вакансий питона и явы 1 к 30 в Великобритании)
Порог входа низкий, но, по факту, программистов на Питоне не хватает. У нас в конторе не хватало. И у знакомых тоже не хватало. И сейчас ни там, ни там не хватает. А, как я уже сказал, собирать полную статистику - не моя задача.
Это не в питоне дело. Толковых программистов вообще не хватает :)
Я понимаю, но почему-то товарищ выше думает, что раз для питона меньше вакансий, то там такой проблемы нет. Такой проблемы не будет, если мне нужно будет нанять одного-двух человек для Эрланга, Хаскелля или чего-то подобного - но, опять же, зарплата будет сильно выше, чем в случае с Джавой или другим подобным языком.
Главное - не уходить совсем далеко в стороны. Скажем идеи из Lisp'а ещё можно как-то прикрутить к Java, но из Haskell или Erlang - вряд ли. Либо вы проникнитесь их подходом и будете потом с отвращением писать код на Java, либо, наоборот, он вам не понравится - и вы просто будете жалеть о петерянном времени.
Конечно если вы изучаете Erlang и Haskell имея (пусть потенциальную) возможность их в будущем применять в своих проектах - тогда другое дело...
Конечно если вы изучаете Erlang и Haskell имея (пусть потенциальную) возможность их в будущем применять в своих проектах - тогда другое дело...
Есть еще вариант, что такой программист со временем напишет очередной эмулятор Хаскела на яве. :) Которым никто не будет пользоваться.
ага, я тоже уже с первых строк статьи хотел дать ссылку Чем изучение Haskell/Python вредит программисту : )
Только Erlang, без a после E. Вообще от JVM уходить совсем не обязательно, функциональное программирование и actor-model есть у Scala. За динамикой можно обратиться к Groovy.
один (достаточно умный) товарищ в жж сообществе ru_java сказал примерно следующее:
"проблема java программистов в том, что они живут в своем мальеньком мирке jvm, грея себе душу рассказами о кроссплатформенности и всячески пытаясь уйти подальше от системных вызовов"
"проблема java программистов в том, что они живут в своем мальеньком мирке jvm, грея себе душу рассказами о кроссплатформенности и всячески пытаясь уйти подальше от системных вызовов"
учить лучше основной язык, а вот интересоваться и читать литературу нужно и по другим.
лучше быть гуру своего языка, чем "читал пару книжек" по 10, но 2 из них были про Java, поэтому я Java программист.
лучше быть гуру своего языка, чем "читал пару книжек" по 10, но 2 из них были про Java, поэтому я Java программист.
учить лучше основной язык
К сожалению, в таком языке, как Джава, очень быстро наступает момент, когда ничего нового уже не будет. Новые библиотеки - возможно, новые возможности - нет. Разве что "а вот появится в следующей версии JVM", которая выйдет через пару лет. Но пару возможностей за два года - это, скорее, деградация, чем развитие.
мне всегда казалось, что хороший программист это не "учить новое, читать про рюшечки и changelog, only", я всегда думал, что хороший программист - этот тот, кто может писать это новое по мере своей необходимости.
да и не знаю я людей, которые знают всю Java, даже Гослинг признавался в свое время, что это практически невозможно.
да и не знаю я людей, которые знают всю Java, даже Гослинг признавался в свое время, что это практически невозможно.
хороший программист это не "учить новое, читать про рюшечки и changelog, only", я всегда думал, что хороший программист - этот тот, кто может писать это новое по мере своей необходимости.
Вы неправильно поняли то, что я написал. Я говорил о "новых" возможностях языка. Добавьте в джаву list comprehensions, например. Ну или именованные аргументы.
да и не знаю я людей, которые знают всю Java, даже Гослинг признавался в свое время, что это практически невозможно.
Я так понимаю, что под "знанием всей Java" вы подразумеваете знание всех (распространённых) библиотек. Нет, я не это имел в виду. Перечитайте ещё раз предыдущий комментарий?
Если вы программист - научитесь играть на пианино. Или на любом другом инструменте.
Это сделает вас лучше как человека.
P.S. Угадайте, почему тяжело играть на скрипке? ;)
Это сделает вас лучше как человека.
P.S. Угадайте, почему тяжело играть на скрипке? ;)
Мысль, что смотреть по сторонам дело нужное поддерживаю. А на счет Руби нет. У Джавы есть Груви. Зачем ей Руби? :)
Компилится в джава-байт-код. Работа джава-груви, груви-джава совершенно прозрачна. Хочешь наследуй, хочешь вызывай.
Имеет все, что умеет Руби, но предлагает кроме duck-typing еще и статику.
Рекомендую пользоваться Груви сначала просто в юнит-тестах.
Удобств и гибкости тонны, груви тут как раз и усиливает, а скорость выполнения уже не критична.
Компилится в джава-байт-код. Работа джава-груви, груви-джава совершенно прозрачна. Хочешь наследуй, хочешь вызывай.
Имеет все, что умеет Руби, но предлагает кроме duck-typing еще и статику.
Рекомендую пользоваться Груви сначала просто в юнит-тестах.
Удобств и гибкости тонны, груви тут как раз и усиливает, а скорость выполнения уже не критична.
Вы изменили свой стиль разработки на Java после изучения другого языка?
Мне кажется, стиль меняется не только после изучения другого языка, но и по ходу изучения даже одного.
пиар Ruby
Зачем нужен Ruby, когда есть Groovy?
а можно узнать, за что минус?
хм..
>Изучение другого языка заставит вас погрузиться в другое сообщество.
Верно для груви? Верно!
>Изучение другого языка может научить вас новым идиомам.
Верно для груви? Верно!
>Изучение другого языка также заставляет вас использовать другие инструменты и процессы.
верно для груви? В пределах тех мыслей, что рассматриваются в статье - верно!
А интеграция с Java'ов для Java-разработчика - тем более плюс.
А теперь бы хотелось услышать _настоящие_ аргументы в пользу Ruby перед Groovy.
P.S. А ведь есть ещё такая интересная штука, как Grails!
>Изучение другого языка заставит вас погрузиться в другое сообщество.
Верно для груви? Верно!
>Изучение другого языка может научить вас новым идиомам.
Верно для груви? Верно!
>Изучение другого языка также заставляет вас использовать другие инструменты и процессы.
верно для груви? В пределах тех мыслей, что рассматриваются в статье - верно!
А интеграция с Java'ов для Java-разработчика - тем более плюс.
А теперь бы хотелось услышать _настоящие_ аргументы в пользу Ruby перед Groovy.
P.S. А ведь есть ещё такая интересная штука, как Grails!
есть гипотеза Сепира — Уорфа согласно которой структура языка определяет мышление и способ познания реальности. Как следствие этой гипотезы, чем больше человек знает языки, тем более у него богаче представление о реальности. Это применимо и к языкам программирования.
http://en.wikipedia.org/wiki/Sapir%E2%80%93Whorf_hypothesis#Computer_coding_language_conceptual_correlate
http://en.wikipedia.org/wiki/Sapir%E2%80%93Whorf_hypothesis#Computer_coding_language_conceptual_correlate
А почему все говорят "Джава"? Разве не "Ява"?
Нет, не "Ява", это английский, а не немецкий. Можете послушать какие-нибудь доклады сотрудников Sun, там ясно слышно, что они говорят "Джава" ;)
А "Job" как же тогда произносить ? :)
Потому что от Явы до Жабы недалеко.
Java разработчикам стоит учить Flex фреймворк!! Пусть Ruby овладевают мастера PHP!!
Знаю одного Java-программиста, который однажды открыл для себя Perl - и с тех пор очень зол, что не сделал этого раньше :). На Java он больше не пишет.
Этот топик я на Хабре уже видел ;)
А если знаком с Object Pascal, C++, PHP, JavaScript, Java легко освоится? Просто каких только мифоф не слышал об "отуплении" "Жаберов".
Если вы не занимаетесь написанием вещей, где критичен performance (тогда ваш выбор C++, D), то я бы рекомендовал как минимум знать один язык со статической типизацией (отличной заменой Java является Scala), один функциональный язык (та же Scala, Haskell, Erlang на выбор), один язык с динамической типизацией (Groovy, если хотите быстро адаптироваться после Java или Ruby/Python на выбор). Мировоззрение меняется это факт.
Вопрос к автору, чем плоха конструкция на Java:
final String[] animals = {"lion", "tiger", "bear"};
for ( String a : animals )
System.out.println( a );
Тем, что проста, понятна, последовательна, легко отлаживаема и выразима на любом алгоритмическом языке? К чему извраты вроде code injection в коллекцию объектов с абстрактным итератором? Как Вы будете пошагово отлаживать свой код, если надо сделать более сложные вещи, нежели вывод объекта? Closures в Java - зло! Java не нужны новые идеи - она самодостаточна.
А проблема в том, что вы не понимаете разницы между алгоритмическими и скриптовыми языками и цели их использования. Декларативное программирование и скриптовые языки хороши там, где кончается архитектура и начинаются прикладные задачи, типа определения бизнес правил и написания сценариев. А весь используемый функционал имплементируется фреймворком более низкого уровня, написанном на нормальном языке типа Java или C/C++.
final String[] animals = {"lion", "tiger", "bear"};
for ( String a : animals )
System.out.println( a );
Тем, что проста, понятна, последовательна, легко отлаживаема и выразима на любом алгоритмическом языке? К чему извраты вроде code injection в коллекцию объектов с абстрактным итератором? Как Вы будете пошагово отлаживать свой код, если надо сделать более сложные вещи, нежели вывод объекта? Closures в Java - зло! Java не нужны новые идеи - она самодостаточна.
А проблема в том, что вы не понимаете разницы между алгоритмическими и скриптовыми языками и цели их использования. Декларативное программирование и скриптовые языки хороши там, где кончается архитектура и начинаются прикладные задачи, типа определения бизнес правил и написания сценариев. А весь используемый функционал имплементируется фреймворком более низкого уровня, написанном на нормальном языке типа Java или C/C++.
а теперь ту же конструкцию для Map'ов, пожалуйста ;)
и сравните с тем же groovy
и сравните с тем же groovy
Вы про то, что в Java нет константной инициализации мепов? Так это любой школьник напишет. Например так:
final String[] mapConst = {"key1","value1","key2","value2" };
Map map = new HashMap();
for ( int i = 0; i < mapConst.length; i+=2 )
map.put( mapConst[i], mapConst[i+1] );
При этом не уродуется язык, а функциональность расширяется за счет собственно функций.
final String[] mapConst = {"key1","value1","key2","value2" };
Map map = new HashMap();
for ( int i = 0; i < mapConst.length; i+=2 )
map.put( mapConst[i], mapConst[i+1] );
При этом не уродуется язык, а функциональность расширяется за счет собственно функций.
решение оригинально, спору нет, но на том же groovy оно в 4 раза короче и понятнее:
Map map = [key1: "value1", key2:"value2"]
Map map = [key1: "value1", key2:"value2"]
Не понятней. Во-первых, где контроль типов в вашем мепе? Во-вторых, какой имплементирующий тип мэпа возвращает эта конструкция: HashMap, TreeMap, LinkedHashMap или VasyaPupkinInternalMap? В-третьих, как ведет себя сия коллекция в многотредовой апликации? Является ли она синхронизированной или нет?
Ответы на эти вопросы остаются за кадром и не ясны из контекста. В итоге язык усложняется и обрастает ненужными конструкциями и допущениями. А это возврат на 30 лет к PL/M (думаю, молодые программисты даже не знают что это такое). Все последущие языки эволюционировали в сторону упрощения, то есть при помощи минимальной функциональности и простоты покрыть максимальный объем задач. А вовсе не как сократить количество символов в программе. В итоге был найден определенный компромисс, который имеют все структурные языки. Функциональность расширялась за счет подключаемых библиотек или ООП.
Скриптовые языки типа groovy не являются структурными ибо служат для написания сценариев в уже существующей архитектуре и не более того. Писать что-либо серьезное на groovy будет большой ошибкой.
Ответы на эти вопросы остаются за кадром и не ясны из контекста. В итоге язык усложняется и обрастает ненужными конструкциями и допущениями. А это возврат на 30 лет к PL/M (думаю, молодые программисты даже не знают что это такое). Все последущие языки эволюционировали в сторону упрощения, то есть при помощи минимальной функциональности и простоты покрыть максимальный объем задач. А вовсе не как сократить количество символов в программе. В итоге был найден определенный компромисс, который имеют все структурные языки. Функциональность расширялась за счет подключаемых библиотек или ООП.
Скриптовые языки типа groovy не являются структурными ибо служат для написания сценариев в уже существующей архитектуре и не более того. Писать что-либо серьезное на groovy будет большой ошибкой.
отвечу по-порядку:
Контроль типов опционален. В вашем мэпе я его тоже что-то не вижу ;)
По-умолчанию имплементация - LinkedHashMap. Хочется другой имплементации - пожалуйста:
HashMap map = new HashMap([key1: "value1", key2: "value2"])
Хочется синхронизированности - пожалуйста:
[key1: "value1", key2: "value2"].asSynchronized()
Энивэй, в данном контексте проблемы groovy не в простоте, а в нестатической типизации.
Контроль типов опционален. В вашем мэпе я его тоже что-то не вижу ;)
По-умолчанию имплементация - LinkedHashMap. Хочется другой имплементации - пожалуйста:
HashMap map = new HashMap([key1: "value1", key2: "value2"])
Хочется синхронизированности - пожалуйста:
[key1: "value1", key2: "value2"].asSynchronized()
Энивэй, в данном контексте проблемы groovy не в простоте, а в нестатической типизации.
В моем примере контроль типов съел хабр (он подумал, что это html тэги).
HashMap map = new HashMap([key1: "value1", key2: "value2"])
Я так понимаю, что это транслируется в код, который сначала делает LinkedHashMap, а потом из нее HashMap ;)
Умолчания - для молчунов. Вся документация по groovy - это сборник рецептов и враперов для уже существующих api. Никакой формализации, никакой структуры. Словом, помойка для удовлетворения сиюминутных потребностей. Еще раз повторяю, что closures - абсурд. Не понимаю, чем он лучше функционального подхода? В чем философия Collection.each() ? Сама коллекция не имеет свойства обходить свои элементы и делать с ними что-то, пришедшее извне. И не нужно ее учить это делать при помощи closures. Коллекция - для хранения элементов, не более.
HashMap map = new HashMap([key1: "value1", key2: "value2"])
Я так понимаю, что это транслируется в код, который сначала делает LinkedHashMap, а потом из нее HashMap ;)
Умолчания - для молчунов. Вся документация по groovy - это сборник рецептов и враперов для уже существующих api. Никакой формализации, никакой структуры. Словом, помойка для удовлетворения сиюминутных потребностей. Еще раз повторяю, что closures - абсурд. Не понимаю, чем он лучше функционального подхода? В чем философия Collection.each() ? Сама коллекция не имеет свойства обходить свои элементы и делать с ними что-то, пришедшее извне. И не нужно ее учить это делать при помощи closures. Коллекция - для хранения элементов, не более.
Кстати да, скорее всего так и происходит.
Ну если уж на то пошло, то груви действительно "врапит" уже существующие апи, это одна из "фич", и я не вижу в этом ничего плохого. Насчёт формализации не согласен - достаточно посмотреть что такое true в груви или на то, что size() можно вызвать практически на любом объекте, у когорого размер действительно есть - от файла и до матчера.
Опять же, пользоваться closures никто не заставляет - в большинстве случаев они работают как тело того же цикла или статический внутренний класс. Опять же Collection.each() - для удобства, не более того. Или может быть вы скажете, что findAll() - тоже абсурд?
зы философия и смысл groovy - не в замене java, а в её более удобном использовании, про grails можно сказать то же самое.
ззы может быть продолжм наш разговор в каком-нибудь более приспособленном для этого месте?
Ну если уж на то пошло, то груви действительно "врапит" уже существующие апи, это одна из "фич", и я не вижу в этом ничего плохого. Насчёт формализации не согласен - достаточно посмотреть что такое true в груви или на то, что size() можно вызвать практически на любом объекте, у когорого размер действительно есть - от файла и до матчера.
Опять же, пользоваться closures никто не заставляет - в большинстве случаев они работают как тело того же цикла или статический внутренний класс. Опять же Collection.each() - для удобства, не более того. Или может быть вы скажете, что findAll() - тоже абсурд?
зы философия и смысл groovy - не в замене java, а в её более удобном использовании, про grails можно сказать то же самое.
ззы может быть продолжм наш разговор в каком-нибудь более приспособленном для этого месте?
Ну и в чем смысл size()? Что он измеряет? Размер в байтах, в элементах или в попугаях? В java для этого служат интерфейсы. Например Comparable служит для любых сравнимых сущностей. Collection - для всего, что может содержать элементы. Так что никакой четкоопределенной универсальной абстрактной функции у size() нет.
Далее. Строгая типизация просто необходима. 30-летний опыт показывает, что она - в момент компиляции обнаруживает большинство ошибок. Не даром в java добавили generics.
Ничего принципиально нового в Closures нет. Он использовался еще в C как паттерн function callback. Но уже в C++ он стал одним из антипаттернов и заменен более адекватными шаблонами (типа Iterator).
Я согласен с Вами, что основная задача groovy - удобство и скорость программирования. Однако удобство и правильность - разные зачастую несовместимые понятия. Это как искусство и коммерция. Программирование, шаблоны, ООП и языки выросли из философских соображений, нежели из соображений удобства, и имеют определенную идею. Гослинг, разработавший Java - идейный человек, а разработчики groovy - комерсанты, завлекающие разработчиков удобством.
Далее. Строгая типизация просто необходима. 30-летний опыт показывает, что она - в момент компиляции обнаруживает большинство ошибок. Не даром в java добавили generics.
Ничего принципиально нового в Closures нет. Он использовался еще в C как паттерн function callback. Но уже в C++ он стал одним из антипаттернов и заменен более адекватными шаблонами (типа Iterator).
Я согласен с Вами, что основная задача groovy - удобство и скорость программирования. Однако удобство и правильность - разные зачастую несовместимые понятия. Это как искусство и коммерция. Программирование, шаблоны, ООП и языки выросли из философских соображений, нежели из соображений удобства, и имеют определенную идею. Гослинг, разработавший Java - идейный человек, а разработчики groovy - комерсанты, завлекающие разработчиков удобством.
конструкция хороша, спору нет.
"А проблема в том, что вы не понимаете разницы между алгоритмическими и скриптовыми языками и цели их использования" - вы не сильны в телепатии
статья лишь о том, что стоит знать о существовании других подходов.
"А проблема в том, что вы не понимаете разницы между алгоритмическими и скриптовыми языками и цели их использования" - вы не сильны в телепатии
статья лишь о том, что стоит знать о существовании других подходов.
С философской точки зрения знание о том, что теоретически зубы можно лечить через жопу, занимательно, однако практически бесполезно.
знание того, что зубы надо лечить через рот, само по себе не развивает человека. а вот _понимание_
этого факта полезно. а в программизме (имхо) важнее всего понимае того, что определенный подход для определенной задачи оптимален.
этого факта полезно. а в программизме (имхо) важнее всего понимае того, что определенный подход для определенной задачи оптимален.
Численно оптимальность подхода выражается в человекочасах, затраченных на решение. Оно включает не только написание кода, но и архитектурное проектирование, отладку и последующее сопровождение (другими программистами). Вполне вероятно, что начиная с комплексных задач средней сложности, Ваш подход перестанет быть оптимальным. Проект погрязнет в ошибках, программисты, пришедшие в проект не будут понимать код других... можно брать лопату и хоронить.
Оптимальным, может быть, для написание серверной вебстранички одним программистом.
Оптимальным, может быть, для написание серверной вебстранички одним программистом.
А как на счет начать програмирование именно из Ruby ?
Я имею кое-какие познания в PHP, но Ruby более понравился.
Потом думаю перейти к Python. Что скажете ? :)
Я имею кое-какие познания в PHP, но Ruby более понравился.
Потом думаю перейти к Python. Что скажете ? :)
Полностью согласен, правильный совет.
Я лично совсем по-другому посмотрел на программирование, изучив в универе Haskell.
А RSpec — это тема, её стоит попробовать всем программистам независимо от их языка.
Я лично совсем по-другому посмотрел на программирование, изучив в универе Haskell.
А RSpec — это тема, её стоит попробовать всем программистам независимо от их языка.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Java разработчикам стоит учить Ruby