LINUX.ORG.RU

История изменений

Исправление rukez, (текущая версия) :

Ты забываешь, что далеко не все языковые среды поставляются в виде монолита из сотен прикладных библиотек. Назад риторика была «просто запусти jshell», теперь она сменилась на «просто еще напиши функцию». Кому предлагаешь это делать? Бухгалтеру?

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

в чем собсно разница?

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

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

  • отлов исключений? ага, в серверной вм самое отличное решение
  • вербузный импорт? можешь импортировать с * - будет 2 строчки
    в остальном внезапно (с) код на жс и яве одинаковый

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

а ты точно понял о чём там речь шла? это для создания классов по мете/типу с внешним указанием, внезапно (с) на любом другом языке будет точно так-же - я там вроде пример показывал как можно сделать проще

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

не нравится не используй - никто же не заставляет

Ага, всего-лишь экран импортов нужен — всё просто.

кол-во импортов зависит только от тебя - в последнем примере всё сведено к одному импорту.
если тебе не нравятся импорты, то ты можешь ударить по столу кулаком и всё свети к одному пакету - будет ровно ноль импортов - в этом фишка явы, то что начинающие пытаются отрыгнуть за непониманием, на самом деле годнота и спасает олёшек от случайных печалей - например использования класса List из Awt вместо Util ;-)

Представь себе, в качестве ключа ассоциативного массива в JS может выступать что угодно: хоть число, хоть строка, хоть объект, хоть Symbol. И геттеры-сеттеры есть, причем, дают они чистый красивый интерфейс свойства, потому спора «нужны ли геттеры или можно просто поле» в JS в принципе не возникает, потому что есть то и другое сразу, и легко, и красиво, и понятно.

ты точно программист? :-)
я предлагаю тебе представить то, что твой код, если его взять и выполнить вместо моего кода, сделает совершенно не то, что должен сделать, ибо все вызовы в моём коде, это далеко не просто выбор/установка по индексу массива, и речь именно о том, что мой метод использования скриптов, позволяет выполнять в рантайме всё то-же что и уже болтающийся там - вызывать функции объектов (а не просто перебирать значения полей), использовать синхронизацию и т.п. - перечитай еще разок мои комментарии по замене и представь что выполняется твой код построчно вместо моего :-)

У JS изначально модель многопоточности «shared none», потому проблема одновременного доступа не возникает. Возникает проблема того, как эффективно перекинуть данные между потоками.

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

В JS ты можешь работать с либой на чистом JS, можно дерагать и нативные либы, примерно как JNI. И чтение структуры объекта есть, и модификация структуры объекта.

я кажись понял что ты не понял о чем речь :-)
речь не о JS vs Java, речь о том что внедрять JS в исполняемый Java файл - так себе затея, ибо JS исполняется несколько отрешенно и имеет сильно черезпрослойный доступ к объектам реального исполняемого кода явы, в то время как инжекции в яву кода на самой яве - вполне себе не проблемны и легко организуются с полным контролем всего и вся, будто бы инжектированный код всегда был в твоём приложении

п.с.

А JS легко пишется в блокноте или консоли.

а для явы теперь своя интерактивная консоль из коробки идёт :-P

Исходная версия rukez, :

Ты забываешь, что далеко не все языковые среды поставляются в виде монолита из сотен прикладных библиотек. Назад риторика была «просто запусти jshell», теперь она сменилась на «просто еще напиши функцию». Кому предлагаешь это делать? Бухгалтеру?

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

в чем собсно разница?

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

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

  • отлов исключений? ага, в серверной вм самое отличное решение
  • вербузный импорт? можешь импортировать с * - будет 2 строчки
    в остальном внезапно (с) код на жс и яве одинаковый

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

а ты точно понял о чём там речь шла? это для создания классов по мете/типу с внешним указанием, внезапно (с) на любом другом языке будет точно так-же - я там вроде пример показывал как можно сделать проще

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

не нравится не используй - никто же не заставляет

Ага, всего-лишь экран импортов нужен — всё просто.

кол-во импортов зависит только от тебя - в последнем примере всё сведено к одному импорту.
если тебе не нравятся импорты, то ты можешь ударить по столу кулаком и всё свети к одному пакету - будет ровно ноль импортов - в этом фишка явы, то что начинающие пытаются отрыгнуть за непониманием, на самом деле годнота и спасает олёшек от случайных печалей - например использования класса List из Awt вместо Util ;-)

Представь себе, в качестве ключа ассоциативного массива в JS может выступать что угодно: хоть число, хоть строка, хоть объект, хоть Symbol. И геттеры-сеттеры есть, причем, дают они чистый красивый интерфейс свойства, потому спора «нужны ли геттеры или можно просто поле» в JS в принципе не возникает, потому что есть то и другое сразу, и легко, и красиво, и понятно.

ты точно программист? :-)
я предлагаю тебе представить то, что твой код, если его взять и выполнить вместо моего кода, сделает совершенно не то, что должен сделать, ибо все вызовы в моём коде, это далеко не просто выбор/установка по индексу массива, и речь именно о том, что мой метод использования скриптов, позволяет выполнять в рантайме всё то-же что и уже болтающийся там - вызывать функции объектов (а не просто перебирать значения полей), использовать синхронизацию и т.п. - перечитай еще разок мои комментарии по замене и представь что выполняется твой код построчно вместо моего :-)

У JS изначально модель многопоточности «shared none», потому проблема одновременного доступа не возникает. Возникает проблема того, как эффективно перекинуть данные между потоками.

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

В JS ты можешь работать с либой на чистом JS, можно дерагать и нативные либы, примерно как JNI. И чтение структуры объекта есть, и модификация структуры объекта.

я кажись понял что ты не понял о чем речь :-)
речь не о JS vs Java, речь о том что внедрять JS в исполняемый Java файл - так себе затея, ибо JS исполняется несколько отрешенно и имеет сильно черезпрослойный доступ к объектам реального исполняемого кода явы, в то время как инжекции в яву кода на самой яве - вполне себе не проблемны и легко организуются с полным контролем всего и вся, будто бы инжектированный код всегда был в твоём приложении