?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Next Entry
Java: нет сходимости
nyaload
_winnie
Обычно решение проблемы создает некоторые новые проблемы. Мы их начинаем решать. Ряд в конце концов сходится. В случае Java он сходится очень медленно, как геометрическая прогрессия с фактором 0.95. Каждое новое решение порождает новые проблемы, для которых нужен новый инструмент со своими проблемами. Spring, Maven, Hibernate ... веб-сервисы для репозиториев мавена... IDE с рефакторингом, мерж рефакторингов в репозитории, вакансии для новых Java-программистов которые пишут ещё больше Java-кода... Тесты для тестирования кода решающего проблемы... Билд-фермы для паралельного запуска тестов, что бы за пару часов хотя бы тесты проворачивались...

Перманентно висящие демоны из-за долгого старта JVM... Динамическая перезагрузка jar демонов...

Перенос логики в XML-файлы... Такого же объема или больше, как java-код для написания этой логики.

Есть всякие clojure и scala, но из-за вот этой вот культуры обмазывания слоями решения проблем от решения проблем не хочется даже близко подходить к тому, что почему-то работает на платформе JVM.
Tags: ,


  • 1
В мемориз, мне кажется:)

вспомнил былое что ли? :)

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

А вдруг Винни прав?

В .net такая же точно фигня, если не хуже.

GreenTea

(Anonymous)
Каждый верит в то, во что ему хочется верить =)
Spring, Maven, Hibernate - вещи абсолютно ортогональные, а не как ты пытаешься изобразить будто одна технология исправляет косяки другой..
Spring - гибкий настраиваемый каркас приложения.
Maven - утилита для сборки сложных проектов. Чтобы не парится с зависимостями придумали репозитории, куда мавен заглядывает и вытягивает все что нужно.
Hibernate - ORM библиотека, для работы с базами данных.
"IDE с рефакторингом" - удобство работы с исходным кодом и не более того.
"Тесты для тестирования кода" - а в C++ не пишут юнит тесты?
Перенос логики в XML-файлы - в XML файлы переносят не логику а настройки. И то не всегда, сейчас есть тенденция переносить из XML в аннотации в коде, так иногда удобнее..
Так что нету никакого ассоциативного ряда, просто набор инструментов удобных для решения текущих задач. Хочешь пользуйся одним не пользуйся другим. Все зависит от твоих задач..

> "Тесты для тестирования кода" - а в C++ не пишут юнит тесты?

Практически не пишут. Особенности языка превращают юнит-тестирование в изрядный геморрой.

Ну и вдобавок юнит-тестирование статически типизированного кода имеет куда меньше смысла.

(Deleted comment)
(Deleted comment)
слабоват наброс

недооцениваешь ты мощь Java :)

Понимаю твой крик души (и мне он даже где-то близок), но всё же мне кажется что он сродни жалобам на то что для техобслуживания КАМАЗа нужны тяжеленные инструменты, а на велосипеде вон всё в бардачок помещается - а по городу на велосипеде добраться даже быстрее получается ;)

Сегодня просто Java hater day какой-то :)

http://tonsky.livejournal.com/256417.html

> Java: нет пути
Так мне увиделся заголовок.

(Deleted comment)

Re: В порядке бреда

"java приучает мозг думать пышно"
в мемориз!

Язык-то тут причем. CI практика или TDD, разделение кода, рефакторинг, управление зависимостями - это надязыковые проблемы. Если вы знаете, как решить их, более простым способом, напишите книге - я куплю и прочту.

Надъязыковые проблемы создаются языком. Те инструменты, которые нужны для проекта в 1000000 строк не нужны для проекта в 10000 строк. Культура Java подталкивает к тому, что бы нанять ещё 10 программистов, которые напишут 1000000 строк. http://users.livejournal.com/_winnie/342753.html?thread=4569057#t4569057

> Если вы знаете, как решить их, более простым способом, напишите книге - я куплю и прочту.
Использовать несколько языков в одном проекте. Java - такой кроссплатформеный ассемблер без segmentation fault. Scala - для умных. Closure - для тех частей кода, где не нужна скорость. Kotlin. Взаимодействие с процессами, написаными на C,C++,Python,bash,ruby через пайпы. GUI - на JavaScript или C#. Может быть Ruby/Python вместо Java в конце концов, если нет требований "только JVM".

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



Там часть проблем из-за ниши, в которой язык позиционировали маркетёры Sun. Разработка крупных проектов шаблонными архитекторами и стадами кодеров низкой квалификации.

Если взять сегодняшние динамические языки, то там подобные проблемы тоже выражены, особенно в вебе. И есть 100500 дебильных template engines, которые выбираются и выкидываются при каждом редизайне сайта. Потому что на маленьком сайте проще выкинуть. А на большом проекте придётся всё поддерживать, ибо заменить дороже и требует более грамотных спецов. Характерный пример фейсбук, где разработали свой PHP-компилятор для поддержки легаси.

Так что, без Java мы имели бы тот же жабий ад, только на Python, Ruby или C#.

Вот буквально с языка у меня сняли. :)

Единственная поправка - похапэпитоноруби не настолько заточены для разработки стадами кодеров настолько низкой квалификации, насколько ява. Так что ад был бы ещё адовее.

Ну типа сходимости на проектах определённого размера нет ни у одного языка. И чем хуже качество рядовых исполнителей, тем этот потолок ниже.

  • 1