А есть ли в природе сабж?
Нет, не JavaScript. Я имею в виду какой-нибудь способ написания скриптов на Java или Java-подобном языке.

Время от времени приходится пилить какие-нибудь вспомогательные утилиты для наших билд-инженеров и тестеров. Там обычно что-то из серии копирования файлов с билдами, генерации XML-ек и тому подобное. Сейчас приходится использовать для этого PowerShell, от которого у меня глаз дергается. Но мотивация такая, что на PowerShell мы им даем скрипт, который запускается на любой Windows-машине, не требует сторонних инструментов и тянет за собой минимум зависимостей (обычно это Azure PowerShell SDK / AWS PowerShell SDK).

Синтаксис этого самого PowerShell мне жутко не нравится, как и в целом языки с динамической типизацией. Вот хочется писать эти вещи на Java, чтоб IDE сразу максимально проверяла корректность кода и типов, предупреждала об ошибках и вот это вот все. Но при этом сохранить "преимущества" скриптов — чтоб те билд-инженеры, при необходимости, могли слегка подправить код и запустить, не мучаясь со сборкой и не раскуривая, в какой jar/war там это собралось. В то же время, чтоб запустить это все можно было на свежеустановленной машине с минимумом зависимостей — ну JDK, Azure/AWS SDK и Maven или Gradle.

Есть ли что-нибудь такое в природе? Пока на ум приходит лишь F# — там достаточно установить Visual Studio и можно "запускать" исходники на F# как скрипты. Но это не Java, эт язык из другой степи, да еще Visual Studio на свежую VM-ку будет устанавливаться черти сколько. Бегло порылся по инету, похоже что Groovy может помочь, я прав?

А еще есть варианты? Вроде в 11-й Java добавили что-то там про загрузку и запуск кода из *.java файлов, это вот то что мне надо или там для каких-то других целей? Можно ль там запустить код как есть, прям из файла, не собирая jar/war/*.class?

Здравствуйте, Artem Korneev, Вы писали:

AK>А есть ли в природе сабж?
AK>Нет, не JavaScript. Я имею в виду какой-нибудь способ написания скриптов на Java или Java-подобном языке.
Python, серьезно. Можно и JS кстати.

AK>Есть ли что-нибудь такое в природе? Пока на ум приходит лишь F# — там достаточно установить Visual Studio и можно "запускать" исходники на F# как скрипты. Но это не Java, эт язык из другой степи, да еще Visual Studio на свежую VM-ку будет устанавливаться черти сколько. Бегло порылся по инету, похоже что Groovy может помочь, я прав?

Груви то вполне себе скрипт и Java библиотек вагон. Но есть ли pip/npm и прочие полещные плюшки? В дженкинсе-грейдле нормально а отдельно не уверен.

Есть еще Kotlin https://kotlinlang.org/docs/tutorials/command-line.html#using-the-command-line-to-run-scripts но тут я теоретик 100%.

Ну jshell и есть.

C:\Users\Vladimir\Projects\test\jshell-test>type test.jsh
/set start -retain DEFAULT PRINTING
/reset
for (var x : List.of("Hello", ", ", "world")) {
    print(x);
}
/exit
C:\Users\Vladimir\Projects\test\jshell-test>jshell test.jsh
Hello, world

AK>А еще есть варианты? Вроде в 11-й Java добавили что-то там про загрузку и запуск кода из *.java файлов, это вот то что мне надо или там для каких-то других целей? Можно ль там запустить код как есть, прям из файла, не собирая jar/war/*.class?

Да, даже shebang Явовский поддерживается. Но код должен быть целиком в одном файле.

Есть только тонкость — нельзя расширение .java скрипту давать
https://stackoverflow.com/questions/52530470/java-11-executing-source-file-via-shebang-is-not-working

Здравствуйте, Artem Korneev, Вы писали:

AK>Есть ли что-нибудь такое в природе? Пока на ум приходит лишь F# — там достаточно установить Visual Studio и можно "запускать" исходники на F# как скрипты. Но это не Java, эт язык из другой степи, да еще Visual Studio на свежую VM-ку будет устанавливаться черти сколько. Бегло порылся по инету, похоже что Groovy может помочь, я прав?

AK>А еще есть варианты? Вроде в 11-й Java добавили что-то там про загрузку и запуск кода из *.java файлов, это вот то что мне надо или там для каких-то других целей? Можно ль там запустить код как есть, прям из файла, не собирая jar/war/*.class?

Groovy.
Но я все равно использую python — из-за легковесности, быстрого старта, скромных требований к памяти.

Здравствуйте, GarryIV, Вы писали:

GIV>Python, серьезно.

Есть у нас тут уже тестовый фреймворк на питоне. Глядя на него, я окончательно в питоне разочаровался — пришел к выводу, что даже вполне профессиональные питонисты не могут добиться чтоб оно гладко работало. Пока еще хочется верить, что там, где питон используется в продакшне, оно все-таки лучше получается (YouTube вроде на питоне и к нему нареканий нет).

Проблем с ним столько, что даже создавать что-то новое на питоне уже даже не хочется. Причем, проблемы фундаментальные, в самой сути динамических языков — если процесса компилляции как такового нет, то корректность кода не проверяется вообще. Если мы имеем несколько сотен профессиональных программеров, каждый из которых пишет прекрасный код, но этот код потом мержится автоматически и результат не проверяется, то проблемы лезут изо всех щелей. Единственный нормальный способ жить с кодом на питоне — покрывать все юниттестами. Но кто будет покрывать юниттестами, собственно, тестовый фреймворк? Да и юниттесты не решают проблему изменения API компонентов — нужно ведь обойти весь клиентский код и обновить его, а билд-система ничего не скажет про измененный API и ошибка вылезает лишь когда этот код запустится — через 3..5 часов после запуска набора тестов.

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

GIV>Можно и JS кстати.

Ой, не. Вот от JS я вообще бегу как черт от ладана.
С ним приходится мириться в Web UI, ибо там ничего другого нет, да и лазить в UI код мне приходится очень редко. А за пределами веба — да что угодно будет лучше, чем JS.

GIV>Груви то вполне себе скрипт и Java библиотек вагон. Но есть ли pip/npm и прочие полещные плюшки? В дженкинсе-грейдле нормально а отдельно не уверен.

Да, видимо, для начала буду пробовать груви.

GIV>Есть еще Kotlin https://kotlinlang.org/docs/tutorials/command-line.html#using-the-command-line-to-run-scripts но тут я теоретик 100%

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

Здравствуйте, scf, Вы писали:

scf>Но я все равно использую python — из-за легковесности, быстрого старта, скромных требований к памяти.

Да, про питон знаю. Но хочется что-то с надеждой на статическую типизацию найти.

Здравствуйте, Artem Korneev, Вы писали:

AK>Есть у нас тут уже тестовый фреймворк на питоне.

Свой собственный тестовый фреймворк? Зачем?

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

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

Здравствуйте, Artem Korneev, Вы писали:

AK>Да, про питон знаю. Но хочется что-то с надеждой на статическую типизацию найти.
Мне тут некоторые сеньер фронтэндеры рассказывают, что на языках со статической типизацией пишут исключительно старые дядьки с маразмом, которые совсем не в состоянии обучаться. А типа на динамических языках пишут самые интеллектуалы. И при этом еще совершенно не нужно на динамических языках тесты писать, вообще никакие .

Здравствуйте, Artem Korneev, Вы писали:

AK>Здравствуйте, scf, Вы писали:

scf>>Но я все равно использую python — из-за легковесности, быстрого старта, скромных требований к памяти.

AK>Да, про питон знаю. Но хочется что-то с надеждой на статическую типизацию найти.
TypeScript https://metanit.com/web/typescript/1.1.php
https://metanit.com/web/angular2/1.2.php

Здравствуйте, Буравчик, Вы писали:

Б>Свой собственный тестовый фреймворк? Зачем?

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

Б>По-моему, если проект разрастется до сотен тысяч строк, то без тестов проект развалится на любом языке. А если тесты есть, то и на питоне можно жить.

Так это само по себе — тестовый проект. Еще и к нему тесты писать — я не решусь предложить.
Я работал с подобными тестовыми фреймворками на C# и на TCL. В случае с TCL там размер команды был менее 10 человек и таких проблем еще не возникало. А в случае с C# помогала именно компиляция. Кода там было много, разработчиков много, но физически невозможно было раскорячить всю систему одним неосторожным коммитом.

Я ж не про баги говорю. Баги это понятно, это случается. Хоть с тестами, хоть без них. Но ситуация, когда я жду 4 часа выполнения тестов только чтобы увидеть сообщение, что тест не упал потому, что не хватает какого-то там параметра в вызове метода, возможна только с динамическими языками.

Б>Для питона можно (нужно) прописывать типы. В этом случае статический анализатор выявит большую часть ошибок типов.

Надо посмотреть в эту сторону.

Здравствуйте, Serginio1, Вы писали:

S>TypeScript https://metanit.com/web/typescript/1.1.php

Это ж все равно JavaScript. Улучшенный, намного более юзабельный, но все равно JavaScript.
Я несколько лет его в UI использовал. Ну в рамках "full-stack" разработки, т.е. основную-то работу UI-девелоперы делали, но мне приходилось писать много кода, взаимодействующего с бэкендом — загрузка данных, аутентификация и т.п.
Контроль типов там нашлепан сверху и он несколько условный. Оно, конечно, во многих случаях дает ворнинги, но поломать код это ничуть не мешает.

Здравствуйте, elmal, Вы писали:

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

Нелогично как-то. Что ж они тогда фронтэндеры до сих пор? За бэкенд платят выше и рабочих мест больше.

E>А типа на динамических языках пишут самые интеллектуалы.

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

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, Artem Korneev, Вы писали:

AK>>Да, про питон знаю. Но хочется что-то с надеждой на статическую типизацию найти.
E>Мне тут некоторые сеньер фронтэндеры рассказывают, что на языках со статической типизацией пишут исключительно старые дядьки с маразмом, которые совсем не в состоянии обучаться. А типа на динамических языках пишут самые интеллектуалы. И при этом еще совершенно не нужно на динамических языках тесты писать, вообще никакие .

Опять троллишь

Я считаю, что языки с динамической типизацией не имеют никакого права на жизнь. Интересно есть им хоть одно оправдание?

Здравствуйте, Artem Korneev, Вы писали:

AK>Нелогично как-то. Что ж они тогда фронтэндеры до сих пор? За бэкенд платят выше и рабочих мест больше.
Они типа были бэкендерами, но захотели реально развиваться и пошли во фронтэнд .

Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>Я считаю, что языки с динамической типизацией не имеют никакого права на жизнь. Интересно есть им хоть одно оправдание?
На самом деле они вполне имеют право на жизнь. Когда нужно быстро наваять что то небольшое. Строчек так на тысячу. Плюс у них есть такие достоинства, как REPL и отсутствие необходимости компиляции. Делаешь мелкие эксперименты, прямо в командной строке, и чтоб получить программу — тупо копипастишь все из командной строки и у тебя есть что то работающее. Очень быстро можно прямо наживую задекорировать код, чтоб он допустим логировал что, кешировал. В случае статических языков будешь фигачить либо на аспектах вместе с определенными фреймворками, либо оборачивать все в функции высших порядков, что будет выглядеть довольно криво, плюс тебе придется перекомпилять все чтобы изменения заработали. Соответственно когда ты пишешь что то небольшое — это очень удобно. Тебе не нужно будет рефакторить, это код на один раз и при изменениях его можно вообще с нуля переписать.

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>>Я считаю, что языки с динамической типизацией не имеют никакого права на жизнь. Интересно есть им хоть одно оправдание?
E>На самом деле они вполне имеют право на жизнь. Когда нужно быстро наваять что то небольшое. Строчек так на тысячу. Плюс у них есть такие достоинства, как REPL и отсутствие необходимости компиляции.
...
В случае статических языков будешь фигачить либо на аспектах вместе с определенными фреймворками, либо оборачивать все в функции высших порядков, что будет выглядеть довольно криво, плюс тебе придется перекомпилять все чтобы изменения заработали.


Причем тут аспекты я не понял. В чем проблема с функциями и какая тут связь с динамической и статической типизацией тоже. REPL поддерживается и в статически типизированных языках. Они так же могут быть интерпретируемыми.

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

В общем, я бы на них свои проекты не затачивад.

Здравствуйте, Artem Korneev, Вы писали:

AK>Здравствуйте, Serginio1, Вы писали:

S>>TypeScript https://metanit.com/web/typescript/1.1.php

AK>Это ж все равно JavaScript. Улучшенный, намного более юзабельный, но все равно JavaScript.
AK>Я несколько лет его в UI использовал. Ну в рамках "full-stack" разработки, т.е. основную-то работу UI-девелоперы делали, но мне приходилось писать много кода, взаимодействующего с бэкендом — загрузка данных, аутентификация и т.п.
AK>Контроль типов там нашлепан сверху и он несколько условный. Оно, конечно, во многих случаях дает ворнинги, но поломать код это ничуть не мешает.
поломать то можно и C# с его динамиками или Object через рефлексию.
Проблема в том что внутри JavaScript так или иначе присутствует утиная типизация. А ты используешь все равно JavaScript классы, где TypeScript это обертка над ними.
От этого никуда не деться. Второй вариант это аналоги Blazor https://habr.com/ru/post/433818/

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>>Я считаю, что языки с динамической типизацией не имеют никакого права на жизнь. Интересно есть им хоть одно оправдание?
E>На самом деле они вполне имеют право на жизнь. Когда нужно быстро наваять что то небольшое. Строчек так на тысячу. Плюс у них есть такие достоинства, как REPL и отсутствие необходимости компиляции. Делаешь мелкие эксперименты, прямо в командной строке, и чтоб получить программу — тупо копипастишь все из командной строки и у тебя есть что то работающее. Очень быстро можно прямо наживую задекорировать код, чтоб он допустим логировал что, кешировал. В случае статических языков будешь фигачить либо на аспектах вместе с определенными фреймворками, либо оборачивать все в функции высших порядков, что будет выглядеть довольно криво, плюс тебе придется перекомпилять все чтобы изменения заработали. Соответственно когда ты пишешь что то небольшое — это очень удобно. Тебе не нужно будет рефакторить, это код на один раз и при изменениях его можно вообще с нуля переписать.

В Hotspot хорошо работает горячая замена класса в дэбаге. Как раз постоянно этой возможность пользуюсь. Менять сигнатуры и добавлять новые методы это не позволяет. Но дописать логинг, или поменять if какой-нибудь. Перекомпилировать один класс и в путь.