Я в курсе всего, что вы перечисляете, и много с чем поработал. Может, потому и не разделяю вашей уверенности. А вы сами-то что используете для быстрого прототипирования на Java? Много веб-приложений на com.sun.net.httpserver.HttpServer написали? OSGi у вас во многих проектах используется? Как впечатления о скорости разработки на этих технологиях?
«Новации» в классе Unsafe и должны проходить незамеченными для большинства разработчиков. Этот класс обходит управление памятью, и реально может пригодиться лишь разработчикам альтернативных JVM-языков или высокопроизводительных узкоспециализированных библиотек, но прикладного программиста, сунувшего туда нос, надо бить по рукам.
Для решения каких конкретных задач был придуман Unix? Или язык C?
Жаль, у старины Ритчи уже не спросить, но я думаю, он не просто так писал этот язык, потому что ему захотелось сделать что-нибудь ненужное для своего удовольствия. Язык C преуспел в стандартизации универсальных и портируемых шаблонов процедурного программирования, и за это ему большое спасибо. Думаю, именно для решения этой проблемы он и был разработан, но не берусь судить, так как не имею на нём достаточного опыта.
Да с чего Вы это взяли?
С того, что пишу на Java уже много лет и имею опыт в массе проектов разной сложности и в разных направлениях разработки.
Благодаря статической типизации
Статическая типизация для думающего программиста имеет смысл, только когда в языке система типов нормальная. Scala, Haskell, вот там она действительно даёт плоды. В мейнстримных языках система типов служит, скорее, для исключения совсем уж глупых ошибок (= компенсации криворукости).
вкупе с поддержкой IDE
Давайте называть вещи своими именами, не «поддержкой IDE», а «компенсацией необоснованной сложности благодаря использованию (зачастую) платных монструозных продуктов».
Да, на Java код в целом получается длиннее
Да речь не только и не столько про «длиннее». На Java вообще что-то реально работающее сделать занимает больше времени. У меня ещё свежо в памяти, сколько правильно сформированных файликов нужно было разложить по нужным папочкам, чтобы завелось простейшее веб-приложение на Tomcat, при этом и Java, и Tomcat, и IDE молчаливо разводили руками и не предоставляли абсолютно никаких средств для поиска и исправления проблемы. Хорошо, что в последние годы ситуация немного выправилась, но далеко не до конца. Количество стороннего софта, настроек, кодовых артефактов, которые нужны для решения простейшей задачи, по-прежнему слишком велико.
И забавно, что вы упомянули про прототипирование. Может, в последние годы средства для быстрого прототипирования и начали появляться на Java, но они далеки от того, что хотелось бы иметь. Прототипировать на Java это всё равно что делать макет в масштабе 1:1. Она не даёт абсолютно никаких средств для «срезания углов» при разработке.
Как можно на динамическом языке вообще что-то смоделировать?
О, моделирование, эта священная корова ООПшников. Благодаря этой практике Java-программисты тратят уйму времени на моделирование всего, что движется, и показывают первый результат программы, которая Хоть Что-То Делает, лишь спустя множество человекочасов. А потом на каждое изменение кричат «Да ведь мы же уже так замоделировали! Да что ж вы сразу не предусмотрели! Да тут теперь половину кода переделывать!» Да, для определённых (и, надо сказать, весьма узких) задач моделирование предметки в коде — штука полезная. Но не для тех, в которых не то что модель, а даже метамодель постоянно меняется — а результат нужно показывать в те же сроки.
Поэтому уже написание проекта средней сложности на динамических языках доставляет большой геморрой.
Написание проекта средней сложности на любом языке доставляет геморрой. Я не знаю ни одной платформы, которая бы явно продвигала «на мне легко писать большие проекты!» в качестве своих преимуществ, или у которой это было бы явно заложено при её разработке. Есть мнения конкретных разработчиков о том, где им удобно или неудобно поддерживать крупную кодовую базу, но мнения эти эмпиричны и обусловлены тем, научились ли они «готовить» эту технологию или нет. Для написания больших и сложных проектов единственная нормальная технология — это прямые руки, на любом языке.
Применительно к Java говорить вообще не о чем, модульность там игрушечная, вспомните jar hell. Адекватная система модульности в лучшем случае появится в Java только в следующем году, спустя 21 (!) год после её создания.
Вы не правы. Любая технология делается для решения конкретных задач, которые в тот момент стояли перед разработчиками, или преодоления того, что они считали своей проблемой в тот момент. Все технологии в той или иной степени opinionated. Хотя на крайней стороне спектра стоит как раз Java, на которой одинаково медленно и неуклюже пишется всё, зато в стабильно долгие сроки, а стабильные сроки — это тоже очень важно в определённых задачах. Но технология, которая писалась авторами для решения вот этой конкретной проблемы, всегда будет для неё лучше, чем технология, созданная для написания фабрики фабрик решения любых проблем вообще.
Вот именно, что тёплое с мягким. Я говорю о целых направлениях разработки, а вы приводите в пример одну из технических задач в рамках одного из направлений.
Я могу привести множество примеров, когда я сознательно не стал писать на Java и использовал другие технологии, в том числе и node.js, потому что считал, что для этой конкретной задачи эта технология подойдёт лучше. Где-то опыт был позитивным, где-то не очень, но в целом у меня развилось некоторое чутьё на области применимости. У любого грамотного программиста с широким кругозором, который не считает свою любимую технологию серебряной пулей, найдётся с десяток таких примеров. Каждый такой рассказ можно оформить в отдельную статью.
Вы забили на миллион существующих шаблонизаторов, написанных для Java, и вытащили веб-слой на отдельный сервер со сторонней технологией. И ещё что-то тут говорите про «зачем переходить куда-то с хорошей, годной Java». Да вы с неё уже перешли, только на собственный велосипед.
Если вы не понимаете юзкейсов замены Java на node.js, это значит, скорее всего, что вы не сталкивались с настолько динамичными или масштабными задачами. Конечно, это не уровень «своего дела», для таких задач технология вообще не важна особо, можно писать на том, к чему душа больше лежит.
У чистых сервлетов и JSP проблема, например, в том, что там из коробки недостаточно хорошее разделение между данными, бизнес-логикой и презентацией, и не задан архитектурный паттерн, потому неопытные разработчики часто работают с БД прямо в JSP, а в сервлетах рисуют HTML. Ну просто потому что это же можно сделать, значит, почему бы и нет. Надеюсь, вы не из таких: о)
Hotswap имеет очень ограниченную применимость, так как меняет только код внутри методов и не допускает структурных изменений, для них всё равно приходится перезапускать сервер. JRebel стоит денег, и это ещё один компонент в стек разработки. А теперь посчитайте время на настройку чистой девелоперской машины и разработку на ней простейшего сервера, отдающего динамическую страничку — на Java и на node.js.
Я так понимаю, вы какие-то свои узкоспециализированные задачи решили без дополнительных фреймворков, и у вас Jetty стартует за 20 миллисекунд, и это прекрасно. Но для чуть более сложных задач вам всё равно придётся что-то подключать.
Сервлеты и JSP? Вы это серьёзно? Даже в последнем официальном туториале по Java EE раздел про JSP уже отсутствует, отныне «свято» писать веб-слой на JSF. Перечисленные вами технологии по простоте, скорости разработки и отладки даже близко не стоят с написанием бэкэнда на node.js, где сервер поднимается одним файлом из нескольких строк и перезапускается за доли секунды без перекомпиляции и пересборки. Я понимаю, если бы вы привели в пример что-то посвежее и подинамичнее, хотя бы Spring Boot.
У Java есть серьёзные преимущества перед node.js даже в контексте веб-разработки, но сервлеты и JSP это точно не одни из них. Для некоторых не столь фундаментальных задач стек Java слишком тяжёлый, разработка на нём медленная и не очень гибкая. С этим мы сталкивались во многих проектах, и решили поэкспериментировать с альтернативными технологиями.
Что-то не похож choco на менеджер пакетов. Он скачивает ту же msi, ставит её туда же в Program Files, просто в тихом режиме. А в папке lib у него лежат только нугетовые метаданные. Если он всё остальное ставит так же, то это, скорее, не менеджер пакетов, а менеджер сайлент-инсталлов.
И вообще, PostgreSQL 9.4 нет, зато магазин с футболками есть :o)
Если серьёзно, это, конечно, тоже вариант, но я и не пытался в статье осветить все способы установки, как раз наоборот, дать только один конкретный.
Если по работе нужно писать только в рамках Java SE, то возможно. Но все плагины для популярных фреймворков и языков, без которых почти ни один проект не обходится (EE, Spring, Hibernate, веб, работа с базами данных), есть только в платной версии. Плагин для node.js, кстати, тоже в Community Edition недоступен.
А мне кажется, я понимаю, что имеет в виду IDVsbruck, хоть он и высказался несколько грубо, за что его и заминусовали нещадно. Если сравнить опытного Java-разработчика, догнавшегося до фуллстэка, и опытного специалиста по фронтэнду, научившегося писать серверсайд на node.js, боюсь, сравнение будет не в пользу последнего. Просто потому, что опытный джавист — это не просто веб-разработчик, а человек, рубящий во множестве различных направлений разработки: от хардкорной многопоточности и низкоуровневых клиент-серверных приложений до всяких крупных интеграшек и энтерпрайзов.
«Новации» в классе Unsafe и должны проходить незамеченными для большинства разработчиков. Этот класс обходит управление памятью, и реально может пригодиться лишь разработчикам альтернативных JVM-языков или высокопроизводительных узкоспециализированных библиотек, но прикладного программиста, сунувшего туда нос, надо бить по рукам.
Жаль, у старины Ритчи уже не спросить, но я думаю, он не просто так писал этот язык, потому что ему захотелось сделать что-нибудь ненужное для своего удовольствия. Язык C преуспел в стандартизации универсальных и портируемых шаблонов процедурного программирования, и за это ему большое спасибо. Думаю, именно для решения этой проблемы он и был разработан, но не берусь судить, так как не имею на нём достаточного опыта.
С того, что пишу на Java уже много лет и имею опыт в массе проектов разной сложности и в разных направлениях разработки.
Статическая типизация для думающего программиста имеет смысл, только когда в языке система типов нормальная. Scala, Haskell, вот там она действительно даёт плоды. В мейнстримных языках система типов служит, скорее, для исключения совсем уж глупых ошибок (= компенсации криворукости).
Давайте называть вещи своими именами, не «поддержкой IDE», а «компенсацией необоснованной сложности благодаря использованию (зачастую) платных монструозных продуктов».
Да речь не только и не столько про «длиннее». На Java вообще что-то реально работающее сделать занимает больше времени. У меня ещё свежо в памяти, сколько правильно сформированных файликов нужно было разложить по нужным папочкам, чтобы завелось простейшее веб-приложение на Tomcat, при этом и Java, и Tomcat, и IDE молчаливо разводили руками и не предоставляли абсолютно никаких средств для поиска и исправления проблемы. Хорошо, что в последние годы ситуация немного выправилась, но далеко не до конца. Количество стороннего софта, настроек, кодовых артефактов, которые нужны для решения простейшей задачи, по-прежнему слишком велико.
И забавно, что вы упомянули про прототипирование. Может, в последние годы средства для быстрого прототипирования и начали появляться на Java, но они далеки от того, что хотелось бы иметь. Прототипировать на Java это всё равно что делать макет в масштабе 1:1. Она не даёт абсолютно никаких средств для «срезания углов» при разработке.
О, моделирование, эта священная корова ООПшников. Благодаря этой практике Java-программисты тратят уйму времени на моделирование всего, что движется, и показывают первый результат программы, которая Хоть Что-То Делает, лишь спустя множество человекочасов. А потом на каждое изменение кричат «Да ведь мы же уже так замоделировали! Да что ж вы сразу не предусмотрели! Да тут теперь половину кода переделывать!» Да, для определённых (и, надо сказать, весьма узких) задач моделирование предметки в коде — штука полезная. Но не для тех, в которых не то что модель, а даже метамодель постоянно меняется — а результат нужно показывать в те же сроки.
Написание проекта средней сложности на любом языке доставляет геморрой. Я не знаю ни одной платформы, которая бы явно продвигала «на мне легко писать большие проекты!» в качестве своих преимуществ, или у которой это было бы явно заложено при её разработке. Есть мнения конкретных разработчиков о том, где им удобно или неудобно поддерживать крупную кодовую базу, но мнения эти эмпиричны и обусловлены тем, научились ли они «готовить» эту технологию или нет. Для написания больших и сложных проектов единственная нормальная технология — это прямые руки, на любом языке.
Применительно к Java говорить вообще не о чем, модульность там игрушечная, вспомните jar hell. Адекватная система модульности в лучшем случае появится в Java только в следующем году, спустя 21 (!) год после её создания.
написания фабрики фабрикрешения любых проблем вообще.Hotswap имеет очень ограниченную применимость, так как меняет только код внутри методов и не допускает структурных изменений, для них всё равно приходится перезапускать сервер. JRebel стоит денег, и это ещё один компонент в стек разработки. А теперь посчитайте время на настройку чистой девелоперской машины и разработку на ней простейшего сервера, отдающего динамическую страничку — на Java и на node.js.
Я так понимаю, вы какие-то свои узкоспециализированные задачи решили без дополнительных фреймворков, и у вас Jetty стартует за 20 миллисекунд, и это прекрасно. Но для чуть более сложных задач вам всё равно придётся что-то подключать.
У Java есть серьёзные преимущества перед node.js даже в контексте веб-разработки, но сервлеты и JSP это точно не одни из них. Для некоторых не столь фундаментальных задач стек Java слишком тяжёлый, разработка на нём медленная и не очень гибкая. С этим мы сталкивались во многих проектах, и решили поэкспериментировать с альтернативными технологиями.
И вообще, PostgreSQL 9.4 нет, зато магазин с футболками есть :o)
Если серьёзно, это, конечно, тоже вариант, но я и не пытался в статье осветить все способы установки, как раз наоборот, дать только один конкретный.