Горький вкус Java

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

Я уже предчувствую велостоянку или даже целый велотрек из поделок: контроллеры/DAO/формы и гениальные утилиты по парсингу даты из формата в формат и все это практически с нуля. Grails мог бы сэкономить 80% времени разработки, но нам его использовать не дадут, потому что заказчик считает Groovy детским развлечением и готов платить в 5 раз больше, или его убедили в этом. NoSQL база и хранить объекты в JSON, отказ от hibernate-ов и сокращение разработки еще на 40%? Ни в коем случае, заказчик хочет переиспользовать свой SQL-server и «решения» под него из подпорок и костылей...

Почему при разработке на Java всегда тяжело и всегда испытываешь страдание? Ну например сваять простенький интернет-магазин. Знакомые PHP-шники смеясь делают за 1-2 дня, в то время как нам требуется месяц. Небольшая система, которую я один написал бы на Groovy за 7 дней в команде из 3-х человек на Java занимает полгода. Я думал над этим все эти годы и не понимаю причины...

Почему Java жрет так много памяти? почему для средненького проекта нужно 1-2гб выделить под Heap, а на моем текущем используется 128 гб RAM облака и 8 процессоров...

Почему сам язык настолько беден и неуклюж? Почему работы с датами/потоками/коллекциями вызывают недоумение и неудобство. Поэтому на каждый чих — dependency, получаем на выходе гигантский артефакт/-ы и постоянные конфликты транзитивных зависимостей...

Почему 95% задач формошлепство или двиганье кнопочек? Неужели недостаточно уже существует подобный систем, что нужно создавать новый хаос, обкладывать функционал кучей work-around-ов. Но нет, взять готовую CMS-ку не с руки, всем нужно оживить их франкенштейна и пришить ему еще одну конечность...

Я разочаровался в Java как в языке так и в диаспоре/проектах под нее, думаю плотно переключаться на Scala и расти под нее.

👍НравитсяПонравилось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

я бы посочуствовал если бы не этот стон про грейлс (что есть глубочайший петушатник, я лучше на go буду програмировать)

Пацан, переїжджай на Rails/Grails, сам джавакодив багато років, пересів на Rails—волосся стало густішим та блискучішим. Брат живий, залежність є. Назад повертатися не хочу, але час від часу маю тому що саппорт. На java-девелоперів які там тілібонькають контролери з сервісами та пишуть даошечки тепер шкода дивитися.

Прогресу в нас (java) немає і не буде.

Чому така мова—тому що робилась спеціально щоб індуси могли девелопити ентерпрайз в ентепрайзних масштабах.

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

По теме: с Джава-смежным стеком технологий легче всего найти работу за границей.

примерно как в анекдоте, когда Рабинович по телефону напел Битлз

Grails мог бы сэкономить 80% времени разработки, но нам его использовать не дадут, потому что заказчик считает Groovy детским развлечением и готов платить в 5 раз больше, или его убедили в этом.
Может потому что архитекторы в крупных компаниях-заказчиках тоже люди и тоже хотят кушать и кормить семью красной икоркой. А на опенсорс проектах сильно не разбогатеешь. В нашем проекте в одном крупном европейском банке оба архитектора ездили на авто класса порш кайен. Возможно потому что продвигали в банк продукты oracle (например GoldenGate которые никак не могли взлететь из-за проблем с нагрузками), а возможно просто талантливые — это мое субъективное мнение

у меня счас один свежепризванный деятель уже 7 месяцев внедряет Microstrategy, потратили уже гдето 400к и конца края не видно. Сначала сдвинули с Мая на Июль, потом на Сентябрь. Без всяких диаграмм ганта, без всяких тренигов команде которая внедряет ( два чела которые и SQL плохо понимали вначале). Все это снабжается рассказами что боссам нравятся графики и босы ждут не дождутся посерфить статистичку с айпада, боссам он тоже что то красивое впаривает и требует увеличения бюджета потому что нада нанять экпириенсед инженера для завершения вовремя, а это где то еще 12-18к в месяц. Я так думаю — это талант свистеть и какой то личный интерес боссов.

Мы сейчас в нашем проекте тратим $300 на хостинг серверов (пока нет нагрузки, обходимся амазоном с medium инстансами), все остальные затраты IT — это зп разработчиков. Но какой вменяемый босс поверит, что серьезный проект может так дешево стоить? Конечно же его проще убедить на $400к чем $3к

И че, вы микростратегию за пару месяцев наклепали? Думаешь твой пример релевантен?

А на опенсорс проектах сильно не разбогатеешь. ... Возможно потому что продвигали в банк продукты oracle
Если че, за Grails стоят SpringSource/Pivotal или глубже EMC/VMware. Так шо не надо про кайены.
Может потому что архитекторы в крупных компаниях-заказчиках тоже люди и тоже хотят кушать и кормить семью красной икоркой.
Вы пытаетесь оправдать коррупцию? А иначе проталкивание инструментов за откаты/преференции и назвать нельзя.

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

Вы договаривайте, если Oracle продаст свой SAP за 10 млн$ данной фирме, то чувак за это черную икру не получит, ну не обменяют в магазине чувство благодарности на икру. А вот если Oracle отблагодарит...я думаю именно это он и имеет ввиду.

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

Если все так прозрачно и честно, то за какой счет он покупает икру?

большая зарплата, плюс годовой бонус, плюс инвестиции. В основном это конечно инвестиции, но для них нужны первые два пункта. Что бы ездить на порше в европе нада гдето от 7к евро чистыми получать если у вас уже есть где жить. Можно и меньше конечно, но тогда он будет не сильно новым. зарплат от 7к евро чистыми в европе есть, но очень мало, как правило это контракторы в очень востребованных сферах или топ менеджмент. даже при 7к евро за 20 лет карьеры (считаем что вы вышли на 7к в 30 лет) вы заработаете около 1,7 ляма евро и сохранить сможете около ляма включая недвигу шутк на 700, тоесть у вас будет в кеше около 300к евро что в принцепе хватает, но не на икру. А вот если вы начнете инвестировать в акции или еще там во что то то за 10 лет под 10 процентов вы сможете удвоить сбережения, а если повезет то и утроить и упятерить. Вот тут уже можна будет и икры поесть.

большая зарплата, плюс годовой бонус, плюс инвестиции.
Как это связано с использованием Oracle vs open-source? Или бонус платится исходя из этого?Не растекайтесь мыслью по древу со своими фантазиями про миллионы и недвижимость.

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

Получается компании понесут большие расходы на такие решения. Где им еще взять большие бонусы и более высокую з.п. для своего менеджера по сравнению с open-source?

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

все может быть, просто если у чела пакет на штук 15-20 баксов то сколько ему нада выдать в конверте за небольшую услугу ? вот может и идут в ход такие неформальные методы типа яхты, виноградники, и прочие мелочи.

Фиг его, внедряю опенсорс в банке, все ок. Распил-откат это же скучно, не? Проблема в том, что обычно внедрение опенсорса это горящие глаза и «все будет круто!». А манагеры, которые в крупных компаниях, обычно цифры понимают. Когда ты им посчитаешь кейс и в цифрах покажешь выгоду, то, как правило, тебе дают зеленый свет и пили что хошь.
Резюмируя — проблема опенсорса в том, что обычно люди, которые его внедряют, не умеют его п(р)одать, а не в том, что он опенсорсный и денег не попилишь.

тут еще есть ньюанс, что опенсорс-адепты пытаются его воткнуть везде, зачастую и туда где он вреден и не нужен

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

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

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

Это специфика проектного софтостроения
или того что описано в книге
Дефрагментация мозга. Софтостроение изнутри
Автор: Сергей Тарасов

там, ИМХО, неряшливо многое написано, а многое из категории «старого пердунства», но от на что там постоянно указывается что проектирование то и — ушло из софтостроения.

а софтостроение стало напоминать создание анимационных фильмов, по процессу. не мое, я с автором этого тезиса даже поспорил. но, через полгодика — согласился что он прав см vit-r ЖЖ рубрика it

Рецензия Виталия: vit-r.livejournal.com/753845.html
Готова новая книга «Работа с СУБД для программиста. Базы данных изнутри», позволяющая, при вдумчивом чтении, избежать скоропостижных переходов на NoSQL.

ну, я то и не являюсь фанатом NoSQL. и приводил ссылки на статьи Зубинского, редкого в русскоязычном пространстве «itшного журналиста». в его блоге на КО посмотрите, как он эту революцию в кавычки берет :)

Надеюсь, его кто-то услышит. Большинство будут набивать шишки о слабоструктурированные модели данных, не зная об их существовании.

ой, а вы часом не есть сам автор? тогда поясню что «старое пердунство» употребляю и к себе :) Мне понравилось у Голубицкого пару лет тому — «старым пердуном я стал лет в 35». ну и он метко описал это качественное изменение :)
молодежь просто многое в книге так и будет воспринимать, проверено на себе :)

Во Франции более распространен другой термин, «vieux con», который в зависимости от степени вменяемости можно переводить, как «старый *удак», подставляя вместо звездочки нужную букву. Разница лишь в пороге, +10 лет примерно по сравнению с РФ. Ну, а процесс трансформации из молодых парней в старые чудаки описан в послесловии книжки :)

еще не дочитал :) в метро читаю, день Дефрагментацию, день «Белую одиссею» Ильина
в целом — согласен, особенно с вопиющими фактами, и как раз рецензия vit-r сподвигла на прочтение.

про ORMы — один случай помнится — как-то в одном проекте стала система как-то мееедленно работать, по локальной сети. причем все по локалке стало тупить, а не только она. админов кляли все за это.
неугасающие лампочки хаба меня смутили, и возьми да проверь дневной внутренний трафик. потому что непонятно было, кто в сети то так грузит.
оказалось при БД размерчиком с полгига, накручивало по 15-20 гиг.
пришлось рыться в коде.
а там — мало того что о те самые выборки гирлянд объектов ради одного поля, кто-то еще самопальный кэш вклепал — он эти гирлянды наперед вычитывал, многопоточность, хуле простаивать, вдруг пригодятся!

итого, при еще добавленных тройке машин — не просто сервер БД лег, а вся локалка легла.

«перекрестился» что не мне это дело переписывать :)

Это много хуже допотопных файл-серверных систем, крутивших в локальной 10 Мбитной сети на 150 пользователей файлы с сотнями мегабайт данных, сервер пентиум-1 200 МГц, память 8-16 МБайт (везде М, а не Г, т.е. железо в 1000 раз слабее).
Потому что ОРП часто используют так же, как файлы в клиппере.
Навигационная обработка, добро пожаловать в 1980-е...

Это много хуже допотопных файл-серверных систем
я знаю :) как-то видел систему написанную на plain C, на границе 90ых, под arcnet. БД ребята изобрели свою, как и описание экранных форм чтобы просто — генерировались. и оказалось — чтобы десятки терминалов в такой сети обслуживать — не надо и большой науки, просто — аккуратность, и «ничего лишнего». причем она была еще — и распределенной :)

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

Навигационная обработка, добро пожаловать в 1980-е...
именно.
спрашивается — какого? я на MUMPS отак бегал, теперь тоже самое — только по объектам. а где обещанный SQL?
причем на MUMPS я бегал очень «точно», никаких лишних чтений вместо меня он не делал. а тут — дай поле — на тебе десяток объектов.

вобщем, «старые» мы с вами «пердуны» :)

Иерархическая модель — по графу особо не побегаешь :)
Успехов вам в софтостроении, как и автору темы!

P.S. Анонс книги «СУБД для программиста. Базы данных изнутри» и опрос общественного мнения. Рапространение приветствуется.
arbinada.com/main/node/1372

Не могу не заметить ограниченность автора. Поймите наконец: заказчику абсолютно по барабану какая технология эффективней и какие плюшки есть в каких-то языках. Ровно также ему не интересно насколько чист ваш код с точки зрения профессионализма. Главная задача — это уверенность в том, что проект заработает.
Какая разница в каких футболках (Java или Groovy) будут сантехники (программисты), если результатом должен быть работающий кран? Популярность стоит за джавой. Специалистов в этой области больше. А значит меньше рисков. Больше готовых проектов, которые подтверждают репутацию джавы.
Вот что важно для заказчика. Перестаньте идеализировать технологию. Программисты — это слесари 21-го века. А вы когда слесаря выбираете, вы сильно обращаете внимание на его инструменты? Лично я, выбираю, по резюме слесаря и по отзывам о нем, пусть хоть он работает молотком и зубилом.

Я вот тоже разочаровался в крестовой отвертке — не все шурупы откручивает. Перейду на плоскую.

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

А что еще разворачивать? Языки программирования — это инструменты в ремонтном наборе ремесленника под названием Программист. Чем больше у тебя инструментов, которыми ты умеешь пользоваться, тем лучше.

А говорить, что PHP — это хорошо, потому, что на нем можно слепить веб страничку за два дня — признак незрелости. Кстати, автор подзабыл, что Java — это не только ценный мех, но и супер мощная JVM, на которой будет выполняться откомпилированная cool Scala.

А восьмая Java — просто песня. Я недавно написал пару блогов о lambda and closures. Посмотрите здесь: yakovfain.com. Кому-то скучно? Мне нет.

да что говорить...человек только 4 проекта провел на Джава. Выводы делать рано. Под каждую задачу — хорош свой «инструмент» в лице ЯП.

Я разочаровался в Java как в языке
Автор нічого не дає взамін. Що заважає йому взяти дві книги — специфікація віртуальної машини та мови і розробити свою мову, яка працювала під ВМ? Створити щось нове слабо?

Да, Николай, мне до вас далеко конечно. Как успехи у вашей группы, что успели освоить за 2 месяца?

я закончил тренинг по java core и начал смотреть что бы мне такого еще выучить что бы приблизится к уровню junior. Налево посмотрел — какие то java EE , направо — android, посредине Spring, слева Hibernate. За что браться — нефига не понятно. Пошел посмотрел вакансии на джине — для новичков ничего нету. Посмотрел PHP, Perl, Ruby, Python. На PHP требуют знаний фреймворков — то зенд, то йойо, то симфония — короче дофига учить. На питоне — можна приходить с начальными знаниями но позиций мало, на руби — тоже берут после пары учебных проектов позиций побольше. Вот и выходит — вход на рынок джавы требует дофига подготовки, тогда как на другие языки берут прямо после курсов. Может ну его нафиг эту джаву ?

Я близок ко всему сказанному. Разве что с поправкой для PHP, туда берут и без знания фреймов, причем очередь работодателей стоит, о качестве, конечно, сказать не возьмусь.
Но раз уж java core закончил, чего сдаваться-то на полпути. Я свернул направо, посмотрим чё там будет:)

Меня реально бесит JPA/Hibernate, есть так много вещей которые можно сделать на SQL гораздо проще и все это будет работать быстро и что самое важное как написано так и работает, а не генерирует 16 outer join’ов. Но все программисты привыкли к ORM’ам и не хотят с них слазить.

P.s. Рекомендую mybatis он простой, эффективный, легковесный.

Может стоит уже завязать с Agile и начать хоть немного проектировать архитектуру, анализировать слабые места и проверять адекватность требований на моделях? Я понимаю что для заказчика и для аутсорсера Agile — манна небесная. Аутсорсеру — бабло, заказчику — лапшу на уши по фиче каждые 2 недели. По факту это индусский фекало-конвейер.

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

Hibernate — хороший инструмент, свой «велосипед» имеет смысл писать, если:
— ДЕЙСТВИТЕЛЬНО есть требования к очень высокой производительности
— Hibernate является узким местом системы, а не скажем бизнес-логика, открывающая/закрывающая вручную транзакцию 100-200 раз для построения каждой сущности.

Реляционная модель хранения данных нежизнеспособна при росте/адаптации системы
Выбирайте любое:
1) лол просто лол
2) А мужики то и не знают
3) Дашотыгавариш?!

4) Если франкенштейн (реляционная модель) передвигается/как-то пыхтит, то он — жив и все хорошо?

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

Интересно — а есть хоть одна АБС на нереляционке в природе?
Или ERP?
Имею ввиду реально внедренные и работающие у клиентов.

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

NoSQL с сохранением из нее критичных данных в SQL.
Кстати да — идея интересная. Спасибо!
Энтерпрайз традиционно направление аналитики заливает деньгами (Vertica, HANA etc.), а идея такого «гибрида» выглядит изящно. Классно если взлетит!

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

да это стандартное в общем-то решение
Скорее концепция.
В существующих АБС я пока про реализацию не слышал. Хотя тут у меня мало опыта, возможно уже появились.
Или ERP?
1. данные в бизнес системах обычно — однотипные по характеристикам, и ключевые, важные для бизнеса, характеристики данных количественные.
2.а изменение количественных характеристик обычно требуется атомарно — многих.
2.б причем при старте атомарной операции часто невозможно предсказать ее успешное завершение, согласно бизнес-правилам.
3. эти атомарные операции частенько конкурируют за общие данные. а порядок изменения данных в бизнесе — обычно очень важен. на оси времени.

какие БД лучше всего оперируют с операциями над количественными данными в жирных транзакциях, с произвольным проверками, с конкурентным доступом к данным?

данные в бизнес системах обычно — однотипные по характеристикам, и ключевые, важные для бизнеса, характеристики данных количественные.
Хмм, нет.
Вся первичка, склады, кадры, финансы — наборы документов со строгими хар-ками и индивидуальным прохождением.
Требования к целостности превалируют над всеми остальными (абсолютно критично), требования к доступности также высоки для выполнения операционной деятельности.
.
А вот построенная на них аналитика уже обладает перечисленными вами хар-ками. И в этом конфликт подходов и проявляется.
В прошлом данные просто сгружались в ОЛАПы и датаварехаузы, где начинали жить собственной жизнью по отношениею к оперативным. Но датаварехаузы быстро дохли от нарастания энтропии, которую сервероцентричные реляционки жутко не любят.
.
Гибридные системы видятся годным путем развития имхо.
От реляционок явно в следующие лет 10 отказываться рано.
Вся первичка, склады, кадры, финансы
кол-во денег, кол-во штук, кол-во ставок, кол-во отработанных часов
Требования к целостности превалируют над всеми остальными
потеря информации «на сколько денех продано» критичней потери «чего продано»
А вот построенная на них аналитика
и опять — кол-во. причем, если в первичке была инфа о «названиях пылесосов», то в аналитике свернуто по «бытовая техника», и опять — кол-во денех, кол-во штук.
Гибридные системы видятся годным путем развития имхо.
не очень понятно — на кой.

если брать системы документооборота, то она требуется для другого вида документов. в которых нет этих кол-во. а в общем случае — фиксация этапов бизнес-процессов или еще какого workflow. то бишь — то за что отвечают отдельные BPM сервера(или их совмещение с архивом в виде PLM систем). бизнес-транзакция тогда состоит из двух серверных — «отмечаем изменения состояния по карте процесса» «изменяем кол-во» — откат если одна из операций не прошла.

какой выигрыш от применения связки NoSQl и SQL? не вижу.

Реляционная модель хранения данных нежизнеспособна при росте/адаптации системы, получается эдакий Франкенштейн и каждая фича — пришитая к оживленному мертвому телу конечность.
А не наоборот? На маленьких проектах хорошо, когда нет SQL, но с ростом требований типа «хочу показывать связанные сущности тут и там» оказывается, что хорошо, когда данные реляционные.
Может стоит уже завязать с Agile и начать хоть немного проектировать архитектуру, анализировать слабые места и проверять адекватность требований на моделях?
Скажите, а Вы когда-нибудь начинали проектировать архитектуру в отсутствии требований по проекту от заказчика? :)

иногда лучше жевать чем говорить
поговорим снова как вас первый раз унизят в скала мейлисте

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

да нет просто там как в академической среде — быть мдаком почетно

Это что выходит, я зря начал java изучать? :D

джаве ничего не грозит. обсуждения в этой теме не касаются ее будущего. ее будущее определяет совсем другое.

Это еще что, вот когда риалтайм, низкие латентности и оффхип — вот тогда яд.

— grails, groovy это не java, не проще тогда сразу разрабатывать на ruby on rails, а не на его жалком поделии в виде grails? Всё правильно, что вам не дали использовать groovy в java проекте.

— nosql база данных, зависит конечно от проекта, но скорее всего вас просто зазомбировали идеологи nosql. Так что есть подозрение, что заказчик и тут прав выбрав свой SQL сервер.

Почему при разработке на Java всегда тяжело и всегда испытываешь страдание

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

Почему Java жрет так много памяти?

Другие жрут не меньше и даже больше, сложные проекты на ruby on rails, например discourse жрут гораздо больше. Scala жрёт дохрена, не меньше, чем java, даже больше. Тем не менее, я без проблем запускаю java веб-проекты на 512Mb, просто использую легкие технологии jetty и tapestry 5.

Почему сам язык настолько беден и неуклюж? Почему работы с датами/потоками/коллекциями вызывают недоумение и неудобство. Поэтому на каждый чих — dependency, получаем на выходе гигантский артефакт/-ы и постоянные конфликты транзитивных зависимостей

Может вы просто не умеете их готовить?

Я разочаровался в Java как в языке так и в диаспоре/проектах под нее, думаю плотно переключаться на Scala и расти под нее.

Мдя, а scala, значит память не жрёт, веб-фреймворки на ней прекрасные, особенно понравился play, который выжрал 500 метров оперативки на холодном старте hello world... С dependency, там проблем нет и т.д?

В общем, вывод, что у вас просто небольшой опыт, либо просто работаете с говнопроектами, сделанные индусами. Я тоже с таким сталкивался, опыт придёт, а работу просто нужно поменять :)

tapestry 5.
да, для джава мира удивительно непривычный фреймворк.

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

То, что нет, инструментов под веб,
"
означает что есть другие инструменты :)

конечно, на tapestry 5 есть немало проектов, и как на нем правильно готовить показывают ребята из Atos Worldline. но... может потом как-нибудь напишу о нем.

grails, groovy это не java
да, потому что овса не требуют.

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

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

сколько народу бренькает на гитаре?
а вот на арфе — как-то не очень.
арфа хорошая, а гитара плохая? или наоборот, гитара для болванов а арфа для элиты?

весь топ-10 на Tiobe — это классные инструменты в инженерном плане
И джава там, обычно на первом, втором месте уже как кучу лет.
означает что есть другие инструменты
Какие? Grails? Так это поделие, клон Ruby on Rails, спрашивается зачем использовать поделие, когда доступен оригинал?

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

я к тому помянул что говорить о том что находится в топе Тiobe «инженерный» — это тавтология, масло маслянное

Так это поделие, клон Ruby on Rails, спрашивается зачем использовать поделие, когда доступен оригинал?
отвечается, словам Эккеля:
в мире JVM Java со временем может стать ассемблером, если уже не стала.

поясняется, для фанатиков

1. в случае необходимости, часть модулей можно переписать на Java. в Ruby on Rails придется на C дописывать расширения интерпретатора Ruby
2. в мире JVM тьма инструментов которые можно будет использовать в проекте на Grails

так что с точки зрения здравого инженерного мышления — Grails хороший выбор.

В мире джава давно встретил самокритичную шутку:
— вот это, можно написать?
— это? не, низя, нет такой библиотеки

потому что:
на Java сложно, долго писать.

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

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

Не проще сделать вот так en.wikipedia.org/...y#Ruby_on_Rails ?

С чего это долго и сложно писать? Там что, какие-то иероглифы или синтаксис кардинально отличим от php, c, c++, javascript? Думаю этот миф появился из-за высокого порога вхождения и из-за преобладания JavaEE стека. И порождают такие мифы авторы как и автор данного топика. Но профессионализм подобных авторов можно проследить по нижележащим постам...

Достаточно вот такого перла «Вот смотрите, чем больше умеет язык, тем меньше сторонних либ и приблуд надо подключать. Меньше либ, меньше памяти, меньше памяти, меньше (в среднем) нагрузка на CPU.», а потом начинается, что «на java сложно и долго писать»

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

Еще забавно что как альтернативу автор предлагает недофреймворк на который все забили с тем же хибернейтом и спрингом внутри, написанный на тормозном языке с динамической типизацией. Как это должно решать проблему 128ГБ памяти и 8 процов?

Я изложил свое виденье разработки на Java за свои честные 3,5 года опыта. Я вижу в Scala будущее для себя в профессиональном плане. Меня интересует исключительно профессиональный рост, а не уборка фекалий за кем-то другим за любые деньги.

Как это должно решать проблему 128ГБ памяти и 8 процов?
Писал раза 4 уже в разной форме. Вот смотрите, чем больше умеет язык, тем меньше сторонних либ и приблуд надо подключать. Меньше либ, меньше памяти, меньше памяти, меньше (в среднем) нагрузка на CPU.
Вот смотрите, чем больше умеет язык, тем меньше сторонних либ и приблуд надо подключать. Меньше либ, меньше памяти, меньше памяти, меньше (в среднем) нагрузка на CPU.
От именно поэтому я и говорил что «лямбды — это зло». :)
1) «Либы» (классы) занимают пермген (метаспейс). Тут речь идет про мегабайты (даже не сотни мегамайт)
2) Груви/Скала не так уж и много умеют на уровне языка/компилятора. Большая часть их фич это синтаксический сахар который уходит в те же либы. Стандартная библиотека загружается в память точно так же как и сторонняя.
Ну и вам сказали что магический Грейлс — это сахар поверх спринга и хибера, при том те кто «остался на джаве» имеют возможность выбирать более легковесные инструменты.
Я изложил свое виденье разработки на Java за свои честные 3,5 года опыта. Я вижу в Scala будущее для себя в профессиональном плане. Меня интересует исключительно профессиональный рост, а не уборка фекалий за кем-то другим за любые деньги.
Ухаха, а код на скале исключительно фекалий содержать не может?
Писал раза 4 уже в разной форме. Вот смотрите, чем больше умеет язык, тем меньше сторонних либ и приблуд надо подключать. Меньше либ, меньше памяти, меньше памяти, меньше (в среднем) нагрузка на CPU.
А с чего ты взял что в грельсах депенденсей меньше чем на абстрактном спринг проекте?

никого не хочу обидеть, тем более что сам в джава мире, но как-то часто, не только на доу, разговоры о джава превращаются в ситуацию (мое по мотивам фразы Генри Форда):

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

Яркий и частый пример:
А как же без ORM сложную дата модель обслуживать???

То есть — следствие перепутано с причиной:
вначале наворотим сложную дата модель, разрисуем UML по рецептуре DDD, а потом покажем что без овса то — никак не возможно.

С этим примером есть и другой казус, похлеще:
Детальная проработка предметной области подразумевает — проектирование.
которое, встречал, может занимать до 70-80% времени.
А какое оно при радостном — а у нас аджайло-скрам по оригинальной рецептуре!
проектирование то?

в итоге, дата модель не просто сложна, в ней навалено конями, на каждой итерации стоооолько, что жевать овес уже приходится ваятелями, а не этой штукой, под названием ORM

а какая разница на чем эти модели воротить? Т.е. на том же PHP можно сделать то же самое со скарамами\аджайлами, но просто и несложно?

Детальная проработка предметной области подразумевает — проектирование.
которое, встречал, может занимать до 70-80% времени.

У меня есть знакомый, который пытается организовать аутсорсинговую компанию. От клиентов он требует детальной проработки задачи. Какие либо изменения в проект (к которым мы так привыкли с аджайлом) вносятся только в виде ооочень большого одолжения. К нему никто не хочет идти. Мало кто изначально четко знает что ему нужно.
Можно хоть 300 раз спроектировать гениальнейшую архитектуру, но потом сроки с задачи так или иначе сделают из нее монстра. Я не очень спец в других технологиях, но большие проекты на джаве и питоне, которые я видела — все этим страдали.

а какая разница на чем эти модели воротить?
вопрос не в чем — а в почему
Т.е. на том же PHP можно сделать то же самое со скарамами\аджайлами, но просто и несложно?
недавно на тусовке phpистов мне ответил один об одном фреймворке — это не php way

Но вы задаете все тот же вопрос:
— а чем оно овес то жует?

От клиентов он требует детальной проработки задачи
а самим себе программы писать он от клиентов не требует?

вы посоветуйте ему погуглить на тему «Сбор и управление требованиями».

Мало кто изначально четко знает что ему нужно.
Это откровение я встречал в стольких канонических учебниках по программированию, с разъяснением что они, клиенты совершенно и не обязаны знать, что им нужно, что не знаю — почему оно откровение для многих программистов и удивляет?
Можно хоть 300 раз спроектировать гениальнейшую архитектуру
как сказал Фаулер:
«архитектура — это застывший дизайн».
сказал он в контексте, который мне напомнил уличные туалеты на Севере, возле военных сооружений —
полметра до мерзлоты яма, пол, метр до дырки, и растет сталагмит. Когда высота его начинает подходить к дырке — посылается джун("дух") с ломом. ну, или провинившийся.
на улице −30 обычное дело. Крепка архитектура получается!

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

то бишь вопрос — а нужно то, проектировать архитектуру?
тем более когда ее — мало кто проектирует, а оно как-то само получается.

Стадия 1. Делаем абы как (собственно как делать по другому не знаем). Получается плохо.
Стадия 2. Решаем что неплохо было бы распланировать работу. Все жестко планируем — получается плохо.

Теперь уже возможны варианты. Либо «ну его нафиг» и goto 1, либо «нужно лучше планировать» и goto 2, либо

Стадия 3. Понимаем что есть вещи которые нужно планировать, и есть вещи которые планировать бессмысленно.

А как же без ORM сложную дата модель обслуживать
Как-то потратил пару месяцев, удаляя Hibernate из средних размеров проекта. Все как-то работало пока не пришлось снимать образы современных баз сверхбольшого размера. Сохраняя посредством ORM сверхбольшие структуры, приходится иметь дело с пропорциональным расходом памяти, и всякие ухищрения типа stateless sessions в случае, когда в ходе записи необходимо чего-то перечесть, не слишком помогают. Похоже, надо сильно извратиться, чтоб записать с Hibernate сложную структуру неограниченного объема, располагая ограниченным объемом памяти, но и тогда такое извращение будет работать неоправданно долго.

вот вот.

конюхи обычно и холиваров Rich vs Anemic не читали.
вот и получается — намыслили в Rich стайл, держа в уме Hibernate, а потом удивленно спрашивают: А как же без Hibernate эту жирную модель в базе держать???

действительно, если поставить вначале левую ногу на ступеньку, как же поставить раньше ее правую ногу на эту ступеньку?

ессно надо уточнить (а то набегут с банальностями)
1. серебряной пули не существует
2. сложные проблемы вряд ли имеют простые решения

у технологии, подхода X поэтому мы всегда найдем список действительных недостатков.

Как-то потратил пару месяцев, удаляя Hibernate
выколупывание Хибера — проверенный паттерн при оптимизации тормозной аппликухи.

Хоть это и проходит по ведомству оптимизации, нас больше заботила scalability. ORM неплохо справляется с ростом сложности сохраняемой модели. Хуже, когда рост сложности сопровождается существенным увеличением объема данных. В принципе, клиент с пониманием относится к увеличению времени обработки возросших объемов данных, но его никак не устраивает out of memory exception в качестве конечного результата этого процесса.

А мені — подобається :)

1) Учтите, что уже есть Java 8;
2) Сам смотрел в сторону Scala. Очень интересный, современный язык, но есть ли необходимые фреймворки для создания полноценного enterprise приложения? Что если я должен использовать реляционную базу, то есть ли какой-либо стоящий аналог Hibernate? Есть ли аналоги Spring (не только DI, но и MVC, Security, AOP и т.д.).
3) По поводу NoSQL баз. Интересовался когда-то MongoDB. Опять же очень удобно и интересно, но там вообще нет транзакций и join-ов. Это критично, вообще-то, если я не могу откатиться или выбрать данные за один запрос. Есть ли другие NoSQL базы, в которых эта проблема решена?

P.S. вопросы совсем не риторические, правда интересно

Scala не взлетит, как массовый ЯП.

но я о п2 — «есть ли необходимые фреймворки»

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

напр этот пост я написал без всяких фреймворков. почему?

по п3 я тоже не разделяю восторгов о «серебрянной пуле»

нравится:
Зубинский
NoSQL. И никаких «революций»
NoSQL. Column-Oriented

чем более богат ЯП, для реализации требования по месту, тем меньше есть нужда в фреймворках

Не совсем ясно. DI и ORM должны быть частью ЯП по-вашему?

зачем, скажем в Haskell — DI?
т.е. — а удобный костыль — обязателен ли к использованию здоровым?

ORM — а оно — откуда, почему взялось? Критику ORM как подхода приводить не буду, ее очень много уже существует. Например есть такая, практическая: «ORM создан для тех кто не в состоянии асилить декларативный SQL» конечно это утрировано, и преимущества использования ORM есть. Но вот в очередной раз пободавшись с хибером, чтобы заставить его элементарной в SQL операции... понимаю что этой боданины не замечают те кто SQL не знает даже на моем, весьма посредственном уровне. А такой посредственный мой уровень еще и потому что — а не даст никто использовать SQL. Запрещено!
SQL при использовании реляционных баз данных — запрещен!
о как на планете Java.
Если есть здоровые ноги — ХОДИТЬ ими запрещено! Только на костылях!
а если богат, только погрузчиком в кресло кабриолета, даже костыли запрещены.

Как и Groovy, а уж про Grails...

Скажу еще что даже этот подход, ORM, можно очень по разному реализовывать.
В зависимости от свойств ЯП.

не понял про ORM. сложно увидеть какую-то логическую цепочку. наверное, не работали с реально сложными доменными моделями

критики от программистов на других ЯП — «что делает Java с мозгом программиста» — тоже хоть отбавляй.

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

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

Вопрос удобства рефакторинга в реально сложной доменной модели, должен беспокоить куда больше, чем быстрый и прозрачный запрос. Сегодняшний этап развития ORM в связке с языком со строгой системой типов вроде java и возможностями ООП будет практически всегда предпочтительней для реализации сложно бизнес логики, чем процедурный sql по многим причинам.

Вопрос удобства рефакторинга в реально сложной доменной модели
Но ведь доменная модель всегда будет как минимум такой же сложности, как лежащая под ней реляционная?
Основной плюс ОРМ — совместимость как с реляционными, так и нереляционными СУБД и большая экономия времени при переходе от первой ко второй.
Во всех остальных случаях ИМХО реляционный подход будет выигрывать.
Но ведь доменная модель всегда будет как минимум такой же сложности, как лежащая под ней реляционная?

Но работать с ней и модифицировать будет в разы удобней при использовании ОРМ и обьектно ориентированного языка, нежели при использовании процедурного sql кода.

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

Но работать с ней и модифицировать будет в разы удобней при использовании ОРМ и обьектно ориентированного языка, нежели при использовании процедурного sql кода.
Беда только в том, что при этом будет стремительно накапливаться энтропия и теряться управляемость. В тот момент, когда у программистов окончательно потеряется в голове представление о нижнем реляционном уровне — пойдут бока.
Думаю, что с нереляционными хранилищами будет в этом плане полегче, там тяжелее «наступить себе на хвост».
но это практически всегда будет сопровождатся потерей гибкости, ухудшением качества кода, ростом количества багов и времени требуемого для добавления новых фич.
В этом плане SQL как раз очень прост и нагляден — там или сразу не работает, или работает правильно и проблемы возникают уже при многократном увеличении нагрузки.
Мощный SQL программист-DBA как правило избавляет всю команду от вышеописанных эффектов гарантировано при любой сложности модели.
Но т.к. у SQL есть нерешаемая на сегодня проблема «сервероцентричности» и уходящей в космос стоимости владения при значительных повышениях нагрузки, на этапах проектирования систем, когда еще неизвестно будет ли этот порог превышен (и такая вероятность не мала), безусловно стоит либо прокладывать ОРМ, либо сразу закладывать nosql решения.

может эти дяди не хотели учить что-то новое?

дяди стареют и умирают, а SQL всё тот же.
ну почти))

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

А прикинь какой бы был ад если бы эти дядьки писали на похапэ?

Вони що, ці дяді, компілювали в себе локально і бінарники комітали ? O_0

К сожалению нет, просто они отвечали за функционал = куски кода и не позволяли никому кроме себя эти куски править, а если кто-то просил рассказать что происходит там — посылали подальше. Некоторые делали «job-security» — одноуровневый пакет 200-300 классов без единого комментария и переменными типа «пыщ пыщ адин-адин».

Да, такое бывает, ведь senior-ы могут позволить себе практически всё.

Жесть, просто жесть. (((
Добре що я не стикався з таким в ніжному віці.

если есть здоровые ноги, то накой машины да самолеты? Пешком, везде пешком...

я же написал — если есть машины, то на машине, на машине, только на машине!

а на самолете вообще удобно нужду справлять, дырку прорезал — экономия на унитазах и канализации!

Scala может использоваться совместно с любым Java и Java EE фреймворком. Вообще говоря из Scala можно использовать любой Java класс.
НО, как правило желание использовать Spring/Hibernate и пр.. в процессе разработки на Scala очень быстро улетучивается в силу того, что Scala ( точнее Typesafe stack ) предлагает другое виденение архитекутры. А если сюда добавить еще и Akka persistent actors + CQRS/Event sourcing то Hibernate уже начинает выглядеть как нечто весьма допотопное ( как паровой двигатель по сравнению с электромотором ).

так и не понял, как мапить в базу данные

У них же каждые полгода мейнстримный ОРМ меняется, сейчас вроде слик на этом месте.

И что в этом плохого? Это гораздо лучше чем тянуть 100500 deprecated г*вно методов как в Date или Thread, которые использовать как бы низзя, но они есть, чтобы не сломать фекальный велосипед 1997-го года. Хочешь юзать deprecated — сиди на Java 1.1 — 1.3, ну я так считаю.

Ну вот пишешь ты клевый проект, у тебя 100500 юзеров, уже гигабайт кода, а потом вдруг оказывается что на твой фреймворк все забили, баги не фиксят, фреймворк морально устарел и фичами не обрастает. Все переписывать? И так каждые Н лет?

Если вы тянете своего мамонта в новую версию, то будьте любезны соответствовать, переписывать не так уж много. Вдруг у вас там 2 млрд sleep-ов по всему коду?

Либо если все работает и все протестировано на Java 1.3 — не лезьте в него и не повышайте версию. Неоднократно видел 1.5 -> 1.7, 1.6->1.7, 1.6 ->1.8 и фсьо, проект уже не подымается. Так это просто базовая Java, а если опен-сорс фреймворки без обязательств, то там вообще поломалось — пеняй на себя.

Если вы тянете своего мамонта в новую версию, то будьте любезны соответствовать, переписывать не так уж много
Речь не о новой версии, а например о каком нибудь вебпортале, который может эволюционно и инкрементально развиваться хоть 20 лет.
Либо если все работает и все протестировано на Java 1.3 — не лезьте в него и не повышайте версию. Неоднократно видел 1.5 -> 1.7, 1.6->1.7, 1.6 ->1.8 и фсьо, проект уже не подымается. Так это просто базовая Java, а если опен-сорс фреймворки без обязательств, то там вообще поломалось — пеняй на себя.
1.3 уже давно не поддерживается, бизнесу таких рисков не нужно.
На джава 8 весь код должен работать, если там какие то хаки не использовались.
На джава 8 весь код должен работать, если там какие то хаки не использовались.
А фреймворки манипуляции с байткодом уже починили? Если нет, то тот же хибернейт не будет работать (не всегда, иногда, но больше и не надо).
Подробностей хотелось бы
Подробностей не будет, так как «мопед не мой».
Пересказ в свободной форме:
Люди обновили джаву до 8-ки (где в апреле), начали юзать лямбды и тд, и хибер начал вести себя непредсказуемо — джава не находит классы, хотя на некоторые запросы с использованием данных классов отвечает.
Думаю это временно, но те фиксы которые будут (в джавассисте и тдт), потянут за собой не слабое обновление, которое подкинет проблем тем кто сидит не на самой последней версии всех фреймворков.
.
Но я спрашивал не с целью возразить, скорее узнать состояние дел.

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

Grails мог бы сэкономить 80% времени разработки, но нам его использовать не дадут,
80 не 80, но глядя на текущие проекты, на 50 — так точно, и по паре процентов экономия бы прибавлялась с каждой эволюционной итерацией.

Spring MVC + Sencha Ext JS — я не знаю какая технология была бы «дороже»... С++ на бэкэнде и написание собственного специализированного клиента для GUI на клиенте а-ля web-browser наверное.

но, 150% — о Grails и заикаться нет смысла.

Знакомые PHP-шники смеясь делают за 1-2 дня, в то время как нам требуется месяц.
никогда не имел с ним с дела, а в последние месяцы волею судеб и просто любопытства использую, и... да, пхп на самом то деле, очень по многим параметрам более лучший выбор чем Java.
пхп на самом то деле, очень по многим параметрам более лучший выбор чем Java.
Дожили :)

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

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

Джава — это всемирный заговор производителей вычислительной техники под руководством Оракла :-) Если бы не жаба, то где сейчас был бы рынок навороченных компов, которыми тут так любят меряться? )))))

Некоторые из описанных проблем — вездесущи и не зависят от Java.
Legacy cr@p — это бич программистов, да.

Жабка кстати язык на котором очень приятно рефакторить из за мощных ИДЕ, так что это даже в плюсы джаве.

Ни одно ИДЕ никогда не сможет зарефакторить легаси креп.

Сама нет, но очень помогает это делать. На джаве рефакторинг в 2-10 раз веселее идет чем на питоне.

Я разочаровался в Java как в языке так и в диаспоре/проектах под нее, думаю плотно переключаться на Scala и расти под нее.

Scala — под JVM.
Поэтому вас ожидает ещё немало подобного:

Почему Java жрет так много памяти? почему для средненького проекта нужно 1-2гб выделить под Heap, а на моем текущем используется 128 гб RAM облака и 8 процессоров...
NoSQL база и хранить объекты в JSON

И это будет работать с базой в 200 млн записей?

Как раз для таких случаев NoSQL и используются.

Может попробовать найти работу по душе, чтобы жизнь не превращалась в день сурка? Если задолбало фомпочкоклепание — займитесь чем-то серьёзнее. Какие проблемы?

Есть платформа Adobe ColdFusion, в которой сочетаются преимущества скриптовых языков с преимуществами java платформы, бизнес-приложения и вебсайты пишутся просто и быстро, деплой происходит на java серверы. Но есть проблема... никто ее не использует для новых проектов — немодно.

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

Судьба AS3 и Flex это действительно печаль. Имел удовольствие работать с ним, а сейчас смотрю на косяки, хаос библиотек и мнений в JS мире, скучаю по стройности и предсказуемости разработки на AS3. Недавно был в страховой, увидел привычный бизнес-интерфейс на Flex3, подумал как долго нужно было б писать те же бизнес-правила и многостраничные формы на JS.

Grails мог бы сэкономить 80% времени разработки
На этапе разработки, или включая этап эксплуатации/развития?
NoSQL база и хранить объекты в JSON, отказ от hibernate-ов и сокращение разработки еще на 40%?
На этапе разработки, или включая этап эксплуатации/развития?
И откуда такие цифры? 5 систем по 3-5 лет каждая — это 15-25 лет, у вас, вроде как, поменьше опыта (исходя из других тем)
.
Знакомые PHP-шники смеясь делают за 1-2 дня, в то время как нам требуется месяц. Небольшая система, которую я один написал бы на Groovy за 7 дней в команде из 3-х человек на Java занимает полгода.
Когда-то делали небольшой эксперимент: джава против рейлс для небольшого проекта, делает 1 человек (который знает инструмент), потом другие люди туда добавляют фичу.
Результат: отличий по скорости разработки особых нет, новую фичу вкрутить оказалось быстрее на джаве чем в рельсовый проект, но, если я все правильно помню, то различия так же были не очень значительными.
Следовательно, разруха не в клозетах, а в головах ©
Ближе к вашему примеру, я не поверю что за счет языка трудоемкость увеличилась с 7 человеко-дней до 1.5 года. Но я могу придумать причины которые повлияют на качество результата.

Grails

На этапе разработки, или включая этап эксплуатации/развития?
На любом этапе.
NoSQL
 — особенно на этапе развития.
Представьте что у вас есть сформированная реляционная БД и вам надо добавить/убрать у класса переменную, либо модифицировать иерархию классов и маппингов на реляционной схеме, не раз видел невозможность что-то поменять в таком случае, пришлось писать рядом свои таблички, на уровне кода объекты мержить друг в друга — ад и гемор.
Ближе к вашему примеру, я не поверю что за счет языка трудоемкость увеличилась с 7 человеко-дней до 1.5 года.
Ваше право, вы можете не верить.
Но на позапрошлом проекте задачи по прикрутке 2-х сервисов, парсингу данных XSD<-> JAXB и обратно, сохранение в БД и небольшие валидации заняли ровно 7 месяцев в команде из 3-х человек. На новом проекте было похожее задание и я его сделал ровно за 7 дней на Groovy, даже данных было больше.
2-х сервисов, парсингу данных XSD<-> JAXB и обратно, сохранение в БД и небольшие валидации заняли ровно 7 месяцев в команде из 3-х человек. На новом проекте было похожее задание и я его сделал ровно за 7 дней на Groovy,
Вы уверены что не упустили например: наличие/качесвто тестов, опыт команды разработчиков, качество ТЗ и тд.
NoSQL
— особенно на этапе развития.
Не совсем понятно за счет чего (каких фич) вы получили улучшение скорости разработки и добавления новой функциональности в работающий проект.
Но на позапрошлом проекте задачи по прикрутке 2-х сервисов, парсингу данных XSD<-> JAXB и обратно, сохранение в БД и небольшие валидации заняли ровно 7 месяцев в команде из 3-х человек. На новом проекте было похожее задание и я его сделал ровно за 7 дней на Groovy, даже данных было больше.
Нет ничего проще, чем решенная задача. Повозитесь с какой то фигней годик-другой, выдайте на-гора готовую версию (откинув кучу тупиковых вариантов и переделок), и всегда найдется новичок с рельсами, который сделает «такое же с нуля за два дня».

А вообще — догадок можно строить много, но не видя кода, разговаривать смысла нет.

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

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

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

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

Павел, здравствуйте. Где можно найти ваши статьи или иметь возможность с вами общаться. Киньте ссылочку. Спасибо.

Ты как то предметно набрасывай, типа вот код на джаве, он кривой и некрасивый, а вот в груви даты сами конвертируются, памяти он совсем не ест, и работает быстрее джавы в 100 раз поэтому не нужно 8 процов и 128Г памяти.
Или например вот у меня на хибернейте такие то косяки, а на модном носкл все отлично работает, транзакции и развесистые супервложенные запросы летают наура.
А то может оказаться что у тебя в руках проблемы, и ты нам будешь искренне благодарен за их выравнивание когда дойдет до конкретных примеров.

Хорошо, вот примеры. Здесь мы рассматриваем чистые возможности обоих языков.

Groovy полностью объектно-ориентированный язык, в нем размеры всех структур данных можно получить .size(), а не length(), length, size() как в Java, это просто странно. В Java примитивы — первоклассный геморрой и источник проблем.
Ну и предметно насчет примитивов в Groovy вы никогда не испытаете типичный WTF Java:

public static void main(String[] args) {
        int i = 10;
        something(i);
        System.out.println(i);
    }

    private static void something(int i) {
        i++;
    }

0) В Groovy не надо ставить точки с запятой и ловить null, это вроде бы мелочь, но очень приятно и мотивирует.
1) Прочитать строчки из файла и вывести на консоль
Groovy:

new File('E:\\Java_topics_list.txt').eachLine {println it} 
Java(это еще хороший вариант, представьте что у вас JDK 6 без autocloseable) :
import java.io.BufferedReader;
import java.io.IOException;
import java.io.FileReader;

public class Sample {

    public static void main(String[] args) {
        try (BufferedReader br = new BufferedReader(new FileReader("C:\\testing.txt"))) {
            String line;
            while ((line = br.readLine()) != null) {
                System.out.println(line);
            }

        } catch (IOException e) {
            e.printStackTrace();
        }

    }
}

2) Примеры работы с датами на Groovy

def nowCal = Calendar.instance
y = nowCal.get(YEAR)
Date nowDate = nowCal.time
m = nowDate[MONTH] + 1
d = nowDate[DATE]
println "Today is $d $m $y"
nowCal.set DATE, 1
nowCal.set MONTH, FEBRUARY
println "Changed to $nowCal.time"

3) Расширяемость языка, в Groovy можно запросто добавить свои операции над объектами:
Account + Money, Account — Money, Account1 transfer Money to Account2
В Java о таком можно мечтать.

4) Родная поддержка коллекций/замыканий на уровне языка в Groovy

Map map = ['a':1, 'b':2]
map.each {key, value -> map[key] = value * 2}
assert map == ['a':2, 'b':4]

Closure doubler = {key, value -> map[key] = value * 2}
def doubleMethod (entry) {
    entry.value = entry.value * 2
}

doubler = this.&doubleMethod
map.each {doubler}
assert map == ['a':8, 'b':16]

5) Работа с XML, HTML, CSV, пока что пример для XML, например пробежаться по xml-ке и вытащить типы вложенных элементов language.
Java:

import org.xml.sax.SAXException;
import org.w3c.dom.*;
import javax.xml.parsers.*;
import java.io.IOException;

public class ParseXml {
  public static void main(String[] args) {
    DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
    try {
      DocumentBuilder db = dbf.newDocumentBuilder();
      Document doc = db.parse("src/languages.xml");

      //print the "type" attribute
      Element langs = doc.getDocumentElement();
      System.out.println("type = " + langs.getAttribute("type"));

      //print the "language" elements
      NodeList list = langs.getElementsByTagName("language");
      for(int i = 0 ; i < list.getLength();i++) {
        Element language = (Element) list.item(i);
        System.out.println(language.getTextContent());
      }
    }catch(ParserConfigurationException pce) {
      pce.printStackTrace();
    }catch(SAXException se) {
      se.printStackTrace();
    }catch(IOException ioe) {
      ioe.printStackTrace();
    }
  }
}

Groovy:

def langs = new XmlParser().parse("languages.xml")
println "type = ${langs.attribute("type")}"
langs.language.each{
  println it.text()
}

6) Параметризируемые конструкторы/методы/замыкания в Groovy
Представьте что у вас есть класс с 5-20 переменными и вам время от времени при создании разных объектов нужно инициализировать разное количество переменных, в Java будь добр пиши либо внутренний статический класс-билдер, который будет инициализировать переменные, либо 100500 конструкторов, либо столько же статических методов.
Пример в Groovy:

Foo foo = new Foo(param1: "one", param5: 5, param13: "thirteen");

7) Проверяемые исключения в Java — авторы знают толк в извращениях
Какой смысл в этих исключениях? Зачем нам ловить например SQLException, IOException, SAXException если в 99% случаях мы ничего сделать не можем и программа все равно должна уйти в штопор. Безопасней обвалить поток и залогировать исключение, чем оставлять пустые catch блоки, которые я видел не меньше миллиона раз. Но нет же! Я должен поймать проверяемое исключение, залогировать и бросить непроверяемое чтобы таки обвалить поток.
Нет слов...

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

Отношения, как правило делят на стадии типа «влюбленность, обыденность, конфликты, притирка, вечная любовь».

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

Не согласен с этой моделью, если люди постоянно ругаются и не понимают друг друга, то лучше разойтись. В плане инструментов: «Зачем использовать шуруповерт если есть дрель, отвертка и советский дюбель?» Вечна любовь к COBOL/ASM сродни антипаттерну золотой молоток на генном уровне. Если инструмент неудачен я выберу более удачный, вот и все.

Проблема в том, что на определенном этапе все ругаются.

Я просто к тому, что перейдя на груви, вы со временем таки обнаружите, что это далеко не идеальный инструмент (и его тоже не всегда юзают по назначению)

new File(’E:\\Java_topics_list.txt’).eachLine {println it}
Когда файл считывают конструкцией new File, один котик на планете начинает плакать.

Не пишу на джаве или груви, но такое чувство, что автор ностальгирует по тому, что было в дотнете во второй (если даже не в первой) версии.

типичный WTF Java:
public static void main(String[] args) {
int i = 10;
something(i);
System.out.println(i);
}

private static void something(int i) {
i++;
}

и что же вам не нравится в поведении приложения в этом примере? Это не в Java проблемы а в чьих-то базовых знаниях, что не знает, чем отличается передача по ссылке от передачи по значению...

Я в курсе, иначе бы не привел. Только вот такого кода пруд пруди, а ведь это базовые вещи. ИМХО неудобная и стремная вещь, лучше бы ее не было как и примитивов.

Есть мнение, что функция должна возвращать значение, а не изменять параметр. Так что лично я считаю, что лучше всего это было реализовано в С/С++, где передача по ссылке была явной.

Хотя опять таки, если понимаешь, что такое «ссылочный тип» — то проблем не будет.

не пользуйтесь примитивами и не будет вам примитивов. В чем WTF в примере так и не понял...

1)

Files.readAllLines(path, charset).forEach(System.out::println);
Здесь мы рассматриваем чистые возможности обоих языков.
Files.readAllLines(path, charset).forEach(System.out::println);
Здесь мы рассматриваем чистые возможности обоих языков.
Уууу, похоже открыта тайна почему 3 человека писали 7 месяцев простой проект на джава: Среди них не было людей которые знают этот язык :)

Даже на 7-ой жабе это можно легко написать намного проще чем криворукий ТС:

for(String s: Files.readAllLines(...)) System.out.ptintln(s);

чем же принципиально отличаются эти два подхода?

2) JodaTime умеет приблизительно все то же

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

Если язык настолько беден, что для работы с датами, потоками ввода-вывода нужны библиотеки
Встраивать работу с датами в язык? А где такое сделано? И накуя?

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

или все же создают? А потом гордо отвечают — JodaTime умеет приблизительно все то же!

но раз это реализовано тонной библиотек — ура! это ж не в язык всобачено!

НЕ вставлять в ЯП — это такая самоцель что-ли? ;)
а может самоцель — убрать из языка средства для создания своих типов?

НЕ вставлять в ЯП — это такая самоцель что-ли? ;)
А где такое сделано?

Головне не де так зробили ,а чому в жабі цього не зробили

а чому в жабі цього не зробили
Патамуша это никаму нах не надо :)

мне кажется, такое выносится из «ядра», но включается в поставку компилятора.
такое себе STL

мне кажется, такое выносится из «ядра», но включается в поставку компилятора.
такое себе STL
Такое не включают в язык ваапшэ. То что вы назвали «включается в поставку компилятора» называется стандартная библиотека. Возвращаясь к примеру ТСа, это похоже на каленарь-АПИ, оно есть в джава, вроде, с версии 1.1. А йода (с небольшими изменениями) вошла в 8-ку.
Суть претензии не ясна.

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

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

На скала не писав, але судячи по цьому коментарі і по прикладу автора ... Якщо вам хочеться «свободи» — спробуйте старий добрий Lisp, думаю він вставить і скалу і інше подібне.

Почитайте історію ІТ, чому ми маємо C та Java і чому на них «підвис» інтерпрайз. Вони зменшують число важко вловимих помилок. Думаю, було б добре взагалі викинути половину «цукру» і ввести ще жорсткіші правила, як то, щоб компілятор не допускав однакових імен змінних у всьому класі, а не лише в області видимості і т. д.

Чому зараз вертається мода на різні «слабко типізовані мови\бд», на зразок сервер сайд джаваскрипт \ носкл і т.д. — тому що в багатьох проектах для широкого вжитку, як то інтернет магазин за 7 днів чи стартап по продажу піци — треба робити швидко, і помилки не спричинять втрат мільйонів, тим паче при скрамі — «ви не можете відсортувати список піци по інгрідієнтам? вносимо в скрам ліст, через дві неділі все буде готово»

Я маю значний досвід зі «старим» носкл :) - IBM Domino, сайти на ньому писати — жодних проблем, додаєш\видаляєш які хочеш поля і як хочеш. А от системи аналізу даних — це жесть, кров і сльози. Що я хочу сказати — пишеш сайт\магазин\формошлепку — носкл саме те що треба, пишеш білінг систему\аналітику — реляційна база.

можно кложур, который тоже под жвм :-)

5 — белые люди делают такие задачи каким нибудь xpath

6 — это называется — именованные параметры, но это принимается, полезная фича.

в Java решается добавлением в проект либы типа Lombok, которая автоматом строит билдер (да, не именнованные параметры но тоже удобно и писать ничего не надо).

6 — это называется — именованные параметры, но это принимается, полезная фича.
Именованные параметры, то именованные, но __не принимаетсо__.
Если у вас метод принимает 100500 параметров, это значит что у вас проблемы с дизайном.
Фича не столько полезная, сколько прикольная. (Но может у вас есть примеры/аргументы лучше чем пример от Gabriel Angelos)

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

Плюс один к проблемам дизайна. Три параметра на функцию — правило которое можно нарушать только сознательно. Я иногда разворачиваю объекты цепочку параметров для statless вычислений — тестировать удобнее. Но если подходить православно — можно ввести допонительный dto.
А фича полезная только в случае, если у параметров есть значения по-умолчанию иначе разницы никакой. Но прикольная, согласен

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

а контракт тебя заставит их все обработать.
Предложите вменяемый вариант обработки падающего SQLException-а помимо обваливания потока.

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

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

Зависимости очевидно на потребление памяти не влияют, но некоторые фреймворки действительно прожорливы. Но их можно не юзать если критично.
А вообще 128ГБ памяти это месячная ЗП программера наверное, дешевле их втыкнуть чем чето серьезно оптимизировать.

дешевле их втыкнут
тут можна тільки сказати, що місце в ДЦ не гумове і швидко закінчується з таким підходом

Практика показывает что 128ГБ памяти хватает для 98% апликух на джаве что бы обрабатывать несколько сотен QPS без какой то супероптимизации. Место в датацентре будет заканчиваться только для апликух типа фейсбука, тогда можно и пооптимизировать.

Похоже, вы не представляете себе стоимости памяти в надёжных компьютерах, — и не только стоимость покупки, но и её экспулатацию.
Вы удивитесь, во сколько раз она дороже той, которая у вас в десктопе.

А вообще 128ГБ памяти это месячная ЗП программера наверное, дешевле их втыкнуть чем чето серьезно оптимизировать.

Первая ссылка в гугле, 128ГБ ЕЦЦ — 1.5К баксов, как я и говорил пол ЗП синьёра. eshop.macsales.com/...DOaEaAqTq8P8HAQ

та какое, нада смотреть плату расширения например под НР сервер на которой стоит 128 гигов, она наверно пару штук стоит

Ну вот, собственно:
en.wikipedia.org/...sts#cite_note-5

Помимо этого, есть ещё экспуатация — не очень понятно, из чего складывается стоимость, но 1GB под tomcat за год стоит каких-то дурных денег, измеряется в $K.
Откуда — не спрашивайте, сам не понимаю.

Ну вот, собственно:
en.wikipedia.org/...sts#cite_note-5
Моя непонимать что ты сказать хотел, по поиску в гугле 16ГБ стоит $190, или полторы штуки 128ГБ, все как я и говорил.
Помимо этого, есть ещё экспуатация — не очень понятно, из чего складывается стоимость, но 1GB под tomcat за год стоит каких-то дурных денег, измеряется в $K.
Откуда — не спрашивайте, сам не понимаю.
Ну я тебе могу и за $М продать, не вопрос.
Grails мог бы сэкономить 80% времени разработки, но нам его использовать не дадут, потому что заказчик считает Groovy детским развлечением и готов платить в 5 раз больше, или его убедили в этом.
Разумеется, заказчик идиот. Или наоборот, он понимает, что через полгода все разрабы в очередной раз сбегут на +100 в соседнюю контору, а ему прийдется искать на рынке специалистов, имеющих опыт работы с **9 знает каким набором фреймворков, языков и прочих штучек, согалсных разбираться с чужим кодом.
NoSQL база и хранить объекты в JSON, отказ от hibernate-ов и сокращение разработки еще на 40%?
А если задачи таките, что NoSQL ну никаким боком не подходит?
заказчик хочет переиспользовать свой SQL-server и «решения» под него из подпорок и костылей...
У заказчика уже есть какая-то экосистема, куда он хочет добавить еще один компонент. Разумеется, нужно эту экосистему прибить и все переписать с нуля, потому что в команде разрабочтиков завелся хипстер, который любую задачу решает NoSQL и кложурой.

Кто платит, тот и музыку заказывает. Может проблема не в языке / платформе / фреймворке, а в вас ?

думаю плотно переключаться на Scala и расти под нее
косяки в скале, как например в этом докладе www.youtube.com/...h?v=TS1lpKBMkgg — не пугают ?

автора таким не испугать, 4ре крупных проекта на java за плечами и тысячи коментариев на доу

думаю плотно переключаться на Scala и расти под нее.
На кложур посмотри еще

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

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

Да, дофига заказчиков твердо «знают» при помощи каких инструментов и фреймворков/CMS должна быть выполнена задача, и пох, что «простенький», но до тошноты кастомизированный интернет-магазин я подниму за пару-тройку недель либо на ненавороченном фреймворке, либо хоть с нуля, в то время как на втискиваемом ими вордпрессе придется несколько месяцев ставить костыли, распорки, подтирать гoвно и фиксить баги, проклиная себя за корявость принимаемых решений, тонны вынужденного индусского кода и прочие доводящие до нервного хихиканья маразмы (это к твоему замечанию о «смеющихся ПЫХарях» и пхрелестях готовых ЦМС), и так, упаси Б-г, после каждого обновления самого ВП, либо каких-то ключевых задействованных модулей.

P.S. Да, да, да! Но при этом дофига заказчиков щедро оплачивают свои прихоти, поэтому мне в упор не понятна твоя зависть к джумло-макакам, которые высырают по интернет-магазину каждые два дня. Там просто нечему завидовать. Тех, которые могут родить пять статических ХТМЛ страничек а-ля под Татяныча и взять за это пятизначную сумму — единицы. Остальные по факту если не сосут с голоду зaлупу, то пребывают в перманентном стрессовом шоке от каждого нового заказчика, из-под которого надобно еще вытащить хоть какую-то спецуху.

Посмотрите глазами заказчика:
С вордпрессом все предсказуемо. Да, пусть впихивать туда функции чуть дольше(по вашим словам), однако одна команда сможет поддерживать все проекты.

Ага, мой любимый аргумент. И кто только им эту туфту внушает? Не вы часом стараетесь? :)
Сами хоть понимаете, что это именно «глазами заказчика»? Накастомизировать можно так, что никто в здравом уме потом не возьмется поддерживать, и до срaки, вордпресс лы там был, джумла или свой гипер-цмс-костыль (зачастую, долбаться с последним и то приятней).

В самом худшем случае, внутри вордпресса впаяют свою цмс. В случае с собственным костылем — мы имеем дело с велосипедом в любом случае. С нулевым количеством доков и тому подобного.

В самом худшем случае, внутри вордпресса впаяют свою цмс.

Угу. Только поправка: в чуть более чем докуя случаев; и не ЦМС, а кипу индусского гoвнокода. И ковыряться в таком дерьме куда хуже чем в самописном (даже не своем) костыле с нулевым кол-вом доков, зато более-менее адекватно написанном.
Заказчики, которые уже обожглись, подтвердят безсмысленность поисков священной коровы в виде «готовой» CMS, в которой «любая макака легко заменяема на новую, ведь та за полдня разберется» ©
А вообще, у вашего мифа ноги уж с очень интересного места растут...

В случае с собственным костылем — мы имеем дело с велосипедом в любом случае.

Напоминаю, все что шло после ныне покойной PHP-Nuke, а возможно и раньше — априори велосипед.

Нда, классический аргумент «хороший A лучше, чем плохой Б».
Повторюсь ещё раз: При прочих равных (одинаковой кривизне рук) использование популярных технологий приводит к более поддерживаемым результатам, чем использование собственных наработок.

А так то да, дело не в фреймворке, дело в программисте.

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

Ну а остальном, шо ж, удачи в поддержке «результатов» ;) «Довольных» клиентов можете сразу направлять ко мне на «лечение».

не согласен. дело в ожиданиях и как они могут подложить свинью.
получив задачу доработать joomla-plugin я ожидаю совпадения с рекомендациями разработчикам этих плагинов. следование контракту в плане логики работы и прочее. с самописным костылем я изначально буду подозрителен.

Знакомые PHP-шники смеясь делают за 1-2 дня, в то время как нам требуется месяц.

Так то они над своей ЗП смеются ))

А у вас, батенька, кризис среднего возраста походу в самом разгаре, и Джава тут ни при чем.

та ладно норм ПХП может спокойно получать 4,5К

норм жаба, может спокойно получать 10к+, такто.

подходим, меряемся, не стесняемся ))

Да я в курсе, сам вот уже почти подобрался к этому заветному «потолку», но речь не обо мне ведь была, и не о тех, которые получают, речь была о «хихикающих мальчиках», которые не понимают, нах чего-то учить, когда можно разворачивать 100-баксовые сайтики на Джумле за два дня. Есть примеры, чтоб такие организмы получали

4,5К
?

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