Comments 19
По тем же причинам Java может стать привлекательным выбором и для исследовательского программирования, но инструментарий для этого ещё не совсем готов.
Хорстманну надо бы почитать про scala-cli: вот удивится, наверное.
Когда в руках молоток все вокруг кажется гвоздём
Особенно учитывая фразу про сложность отладки питона из-за динамической типизации.
При подходящем инструментарии Java оказывается на удивление эффективным выбором для написания маленьких программ.
При всем уважении, Java - это один из самых неэффективных и неудобных языков для написания именно маленьких программ. Это тот редкий случай когда из коробки решение представляет из себя буквально ничего. Ни пакетного менеджера, ни сборщика артефактов, ни парсера аргументов командной строки. То что в других языках делаеться с лету встроенным функционалом, в Java нужно обмазываться кучей инструментов, библиотек и плагинов для написания простейшей cli программы.
Статью читали? Сейчас вам ничего не надо собирать, чтобы выполнить программу состоящую из одного файла. Просто java MyProgram.java
Если нужны зависимости для запуска этого файла без компиляции - используйте jbang
Сборка артефактов? Ну тогда вам нужно делать по-нормальному с maven/gradle. Но и тут я не вижу проблемы, это 3 клика в ide на все про все.
(Сейчас вот добавляют возможность импортить все сразу одной строкой)
Ни пакетного менеджера, ни сборщика артефактов, ни парсера аргументов командной строки. То что в других языках делаеться с лету встроенным функционалом
Это в каких? И так чтобы потом сообщество не наизобретало 100 своих пакетных менеджеров и сборщиков, потому что стандартный вышел не очень и теперь у нас pip на анаконде и ты сидишь второй час и пытаешься вникунуть что к чему относится и когда использовать ;) В этом плане в java все отлично: два сборщика полнофункциональных: для ретроградов и для модных.
ни парсера аргументов командной строки
о каком парсере идет речь? аргументы придут в массиве, хотите что-то продвинутей, ну найдите модную библиотеку которая вас устроит
Я просто не пойму с чем вы сравниваете
PS: реально только одна проблема: так никто раньше не делал и к такому не привык.
PPS: насчет оверхеда надо смотреть, где-то будет ок, где-то нет, я не знаю какой реальный оверхед на запуск bash и иных скриптов (но учитывая, что иногда git bash под win зависает - там все тоже не летает)
Статью читали? Сейчас вам ничего не надо собирать, чтобы выполнить программу состоящую из одного файла. Просто java MyProgram.java
Если нужны зависимости для запуска этого файла без компиляции - используйте
jbangСборка артефактов? Ну тогда вам нужно делать по-нормальному с maven/gradle. Но и тут я не вижу проблемы, это 3 клика в ide на все про все.
Есть такая элементарная и очень базовая задача - написать приложение для командной строки. Могу я схожу создать такое приложение имея только Java?
Ну если hello word может быть. Если что-то чуток серьезнее где не один файл или нужна либа то нет. Нам уже нужно установить сборщик Ну ок. Далее мне чтобы получать в удобном виде аргументы командной строки, выводить help сообщения и т.д, нужно искать отдельную либу. Далее мы сможем собрать наше приложение в единый файл? Нет. Нам нужно ставить плагин чтобы хотя бы иметь возможность собрать все в Jar. Окей, будут ли в этом Jar файлы зависимости нашей либы? Нет. Нам нужен еще один плагин чтобы собирать полный Jar. Можем ли мы удобно это запускать как исполняемый файл не заставляя пользователя помнить что нужно прописывать java -jar? Нет не можем, нам опять нужен еще один из плагинов которые будет запускать скрипт когда мы пытаемся запустить Jar. И наконец, можем ли мы сделать полноценный исполняемый файл чтобы бы мы могли его запустить? Да, но нам нужно установить в систему и настроить отдельную JVM. И только после этого всего мы сможем сделать простейшую задачу - написать cli утилиту.
Как итог, можем мы сделать это на Java? Да можем.
Удобно ли это делать на Java? Да нефига.
Я просто не пойму с чем вы сравниваете
Да просто на вскидку. Возьмем Go, накидываем программу, используем встроенные средства для основных задач вроде парсинга аргументов, компилируем и получаем исполняемый файл без всяких танцев с бубном. Ну ок Go компилируемый.
Берем самого очевидного и похожего конкурента C#. Просто через командную строку .net создаем сразу проект cli программы, накидываем что нужно и собираем в том виде в котором нам интересно: либо в единый исполняемый файл требующий виртуальной машины на ОС или в единый запускаемый файл в который уже все встроено. По итогу получаем исполняемый файл который не требует установки ничего и выполняем то что нам нужно. Нам не нужно ставить пакетные менеджеры, не нужно ставить и настраивать 10 плагинов и библиотек, и даже не нужно ставить сторонние виртуальные машины. У нас для элементарной задачи есть элементарное и удобное решение из коробки.
Это называется - удобный языки для написания маленьких программ.
в java тоже можно создать проект одной строчкой со всеми нужными плагинами, библиотеками и папками: есть понятие maven archetype . да, удобно когда есть официальный способ создания, а его нет, надо разбираться и искать кто такой уже делал.
Ну ок Go компилируемый.
да, и теперь мы привязаны к платформе и должны думать как создать билд под другие системы.
Кстати раз такое пошло, то мы тоже можем скомилировать java в испольняемый файл.
Далее мне чтобы получать в удобном виде аргументы командной строки, выводить help сообщения и т.д, нужно искать отдельную либу.
у каждого свое понятие удобности, стандартно вам дают массив, для всего остального лучше библиотека, потому что мода оформления и логика работы консольных программ меняется со временем. + в win и linux изначально схема указания параметров отличалась. Все это веские причины не подавать на вход программы что-то сложнее массива, и оставить эту работу сторонним библиотекам.
Нам не нужно ставить пакетные менеджеры
не вижу проблем поставить во время разработки, более того они идут с IDE и ставить нужно только ее. Собственно так же наверно происходит и с C#, очевидно что будучи частью системы он будет с ней дружить.
Но теперь возвращаясь к теме топика: мне нужна простая программа, которая например сходит на какой-то урл и что-то сделает. 1 файл, я могу в IDE накидать все это без зависимостей и запустить на любой системе где ставили java одной командой как обычный bash скрипт, и работать это будет и под win и под nix. Я даже могу попросить chatgpt создать такой файл, могу поменять его в любой момент да и просто посмотреть что он делает. Можно так же на go или net? Нет, надо разбираться, запускать какие-то команды в консоле чтобы создать проект и скомпилировать его, т.е. иметь компетенцию в этом. С таким же успехом я поставлю всю что мне надо в java, сделаю или исполняемый jar или исполняемый файл. В первый раз будет трудно, если похожего готового мануала не найду, а потом легко.
Если моей программе нужны зависимости и я хочу ее запускать опять без компиляции одним файлом - ставлю jbang. Кстати манул как писать на нем продвинутые консольные команды с парсингом аргументов я видел. Минс: нужно ставить jbang после java, не для прода это.
В сухом остатке получаем что ситуация не однозначная, у каждого подхода есть свои плюсы (в целом все что вы перечислили принимается), но как по мне минимальный порог входа для того, чтобы сделать что-то относительно простое из всего о чем шла речь именно у java. Как я понимаю похожая ситуация с python и ruby. Далее есть варианты и все равно каждый будет использовать то, что он умеет и понимает. Да, наверно мне на java надо будет больше телодвижений, но это не проблема ни разу, которая как-то сильно меня затормозит.
Вам говорят:
на язык X можно создать cli приложение в прямом смысле слова в пару команд, пользуясь официальной документацией, используя встроенную библиотеку и средства разработчика и собрать это в том виде в котором нужно для конкретной цели. Не нужно ничего особо дополнительно устанавливать, не нужно лазить по интернету в поисках решений и библиотек для простейшей задачи. Не нужно дополнительные виртуальные машины ставить. Происто идем по оф. мануалу и вызваем несколько команд.
Хотите кроссплатформенный вариант который будет работать на любой машине где установлена среда выполнения(C#), хотите - исполняемый файл, который будет работать без установленной виртуальной машины(C#/Go). Без проблем. Все из коробки.
Вы говорите:
на Java все делается просто: если так -то вот так, а если вот так - то по другому, а если нужно чуток посложнее то вот это идем идем гуглим читаем доки. Для выполнения простейшей операции нет встроенной в язык функции? Да и не нужно, массив приходит и ладно. Нужно будет поискать еще библиотеки не проблема.
Нужно исполняемый файл? Нужно ставить отдельную виртуальную машину в систему? Ну и ладно.
Можно ли все это сделать на Java, да можно, никто не спорит.
Но когда после вышеописанного, что проще для простой программы: вызвать пару команд или копаться ковыряться в изучении плагинов для элементарных вещей, искать по интернету инструменты чтобы элементарно нормально можно было свое простое решение использовать, вы как ни в чем не бывало пишите:
В первый раз будет трудно, если похожего готового мануала не найду, а потом легко.
...
...но как по мне минимальный порог входа для того, чтобы сделать что-то относительно простое из всего о чем шла речь именно у java.
Это называется фанатизм своим языком программирования вопреки здравому смыслу. Тут спорить бесполезно.
все что вы говорите, мол надо то, надо се - это все несколько строчек в конфиге мавена (я не поманию тут разницу что официально, а что нет). собственно я еще в универе спокойно делал консольные и не только программы на java в netbeans не зная ничего про мавен и градл, и компилировалось оно в jar само, может я не использовал сторонние депенденси, не понмню, их кстати можно руками положить в папку lib если вы прям совсем новичок (актуально для простых jar у которых нет других зависимостей, например для gson, но если вы новичок, то вряд ли вы будете тянуть что-то сложное) Все, никаких проблем, которыми вы пугаете новичков.
Вы говорите, что массив на входе в main это не комильфо, так ведь именно так и приходит в C# который вы нахваливаете!
Далее, go: из коробки который имеет либу "flag", так ведь она ждет unix style формат! Если вы забыли, то в win флаги идут через слеш. Это хорошо и кроссплатформенно? Не очень.
Далее, я работаю под windows, скажите как мне на go или c# собрать нативную версию для linux? Тоже из коробки одной командой? Или надо ставить doker и т.д.?
Ну и основной вопрос, мне нужен простой скрипт (1 файл без депенденси), который будет работать и под linux и под win, например я не хочу писать на bash (но например я админ и я мало что понимаю в программировании, а java или с# есть на проде, потому что у нас такой стек). Могу я сделать это на java? - Без проблем, и компилировать ничего не надо будет, может я даже в web ide какой накидаю этот файл. Для c# надо ставить еще dotnet-script , т.е. мы опять приходим к тому, что нам надо что-то доставлять (и теперь видимо вы будете говорить, мол да ерунда, там всего пару команд? ;) а секурити тима кстати одобрит установку этого пакета?). Просто в таком случаи я могу или поставить jbang или groovy-kotlin, там тоже можно писать скрипт в одну строку указывая вначале нужные сторонние зависимости, т.е. у меня тогда вообще нет никаких проблем и ограничений.
Единственная проблема java - информация по всему этому обычно не пишется в книгах, которые предназначены для новичка, поэтому могу согласиться, что например "вайтивайти", который возьмет в руки книгу по go сделает более прикольную программу, чем тот, который возьмет книгу по java. На этом все. Хотя может сейчас и про maven-gradle пишут. И я не вижу трагедии, что их сделал не oracle. В конце-концов сейчас не начало нулевых, информации предостаточно, найдете какой-то другой гайд, с не офф сайта. Поэтому мы приходим к тому с чего начинали: большой разницы нет, как бы вы не пытались ее выпячивать, при наличии опыта в своем стеке, но примитивную программу-скрипт (без депенденси) проще сделать именно на java и примерно так же на c# (java-kotlin-groovy с депенденси).
Не самый лучший выбор для автоматизации рутинных задач. А что насчёт питона, то там есть inlay hints.
Я обычно использую немного другой подход для "одноразовых скриптов", а точнее просто небольших утилит для личного пользования, которых может быть много. У мавена есть возможность делать мультимодульные проекты, в которых модули организованы иерархически. Модули могут иметь свои зависимости, работать на разных версиях jvm и т.д, а иерархия может добавлять общие настройки группам модулей. Современные IDE вроде IDEA отлично работают с такими проектами. Используя этот подход, все вспомогательные утилиты я много лет складываю в один проект, в котором сейчас 172 модуля. Конфигурации запуска я также группирую иерархически для удобства работы. Поскольку всё это происходит в рамках одного проекта, то с одной стороны доступны все возможности IDE по работе с кодом, а, с другой, вы всегда можете в случае необходимости переиспользовать какой-то код, просто добавив зависимость и убедившись, что они на одной версии рантайма.
Звучит возможно тяжеловесно для "скриптов", но это было вполне сознательное решение после того, как с одной стороны я устал от хаоса при работе со скриптами на скриптовых языках, а с другой периодически появлялась потребность переиспользования кода, которая обычно в мире скриптов решалась копипастой, что добавляло головной боли, если скрипты оказывались не такими "одноразовыми", какими казались вначале.
На универсальность такого подхода не претендую, но лично мне он помог навести порядок.
Для скриптов и маленьких программ есть свои языки, Java в их число не входит.
Познавательно
По ходу автор (оригинальный) написал статью ради статьи.
Какой хаос у него там в баше вообще непонятно. Он вместо баша припёр ВСЮ джавовскую инфраструктуру и пишет в джаве скрипты, которые выглядят почти так же, как выглядел бы скрипт на баше, который делает то же самое. Только теперь у него есть еще и грэдл с мавеном и, соответственно, JVM, которая не бесплатная (в плане ресурсов). Те же вопросы к питону.
Я в чем-то могу его понять, наверное, когда там что-то сложнее, и больше, и имеет смысл использовать ООП. Но, блин, заводить комбайн ради трех колосков?
Просто когда есть знакомый инструмент, а задачи уровня "это для хобби, лепим из говна и палок" - так и хочется вкорячить знакомое)
Я вот тоже, когда в пет проекте нужно поднять север или перелопатить сотню файлов - зачастую поднимаю для этого nodejs. Да, можно файлы и в shell скрипте перебрать, и на python написать все. И не надо будет ничего устанавливать. Но зачем - если вспоминать синтаксис shell скриптов я буду дольше, чем писать весь скрипт на js)
У меня к такому подходу претензий нет вообще ни одной, сам так делаю. Хочешь решать задачу - берешь что удобно, и решаешь. Тут был один камрад, который скрипты на scala писал. Но рассказывать, мол, вот на этом языке у меня плохо получается, и я не могу грамотно организовать свой код, чтобы не создавать самому себе проблем, поэтому пичалька, это ну, такое. Автор статьи примерно с этого тезиса её и начал. Я процитирую:
Берясь за автоматизацию рутины, я обычно смотрю на задачу и думаю: «Никаких проблем, напишу шелл-скрипт». А затем происходит неизбежное: с появлением новых особых случаев скрипт превращается в ужасный хаос bash-кода. И я начинаю жалеть, что не написал его на настоящем языке программирования.
Вот, собственно, и завязка. Если он джаву знает явно лучше, чем баш, зачем он лезет в баш изначально? Я уже где-то писал, что главная проблема баша - это то, что на нем легко писать плохо и трудно писать хорошо, и эта цитата тому хороший пример. Порог входа низкий, но после порога начинается крутая лестница, по которой не каждый полезет.
Посылка типа "С джавой я неплохо знаком, использую ее для автоматизации рутинных действий вот так вот, и получается недурно, вот куча плюсов, вот немного минусов" была бы, на мой вкус, более адекватной. Как человек, которой хорошо знает баш и относительно неплохо знает джаву, я лично выбрал бы баш, и просто написал бы нормально расширяемый скрипт, в хаос он превращается не больше, чем любой другой язык программирования. Мои скрипты, в отличие от скриптов автора, не только не превращаются в хаос, но и имеют тенденцию уменьшаться в размере и становиться проще со временем. Если бы я плохо знал баш, то, может быть, тоже автоматизировал бы на джаве. Или на сишарпе, на нем кросс-платформенные тулы сейчас писать удобнее ИМХО.
В общем, как я это увидел. Автор притащил кучу всего под эгидой замены чего-то другого, гораздо более простого. Проблема не в сути этого действия, проблема в мотивации, он как бы решает не совсем ту проблему, которую он думает он решает. Проблема не заменить что-то, а сразу взять более удобный инструмент, и не надо ничего заменять.
Ссылка не верная
https://github.com/jtaccuino/jtaccuino
Предложу развитие вашей идеи: java-приложение в bash-скрипте, которое запускается как скрипт без каких-либо лишних файлов и команд.
#!/bin/bash
JAVA_CODE='
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
'
echo ${JAVA_CODE} > "$(basename "$0")-tmp.java" && java "$(basename "$0")-tmp.java" && rm "$(basename "$0")-tmp.java"
Java-код задается в переменной JAVA_CODE
Скрипт создает временный файл, запускает java, затем удаляет временный файл.
Пишем скрипты и маленькие программы на Java