IVM ну для начала я в C# всего года 3. И в этом нет ничего странного, основная проблема СИНТАКСИС языка.
Если человек знает синтаксис ST, то в другом языке он будет потеть, пока разберется.
Ну вот пример С++ if (x & 8000) не будет работать в C#, потому что там надо if ( x & 8000 > 0) то есть банальные отличия в синтаксисе языков заставляют тратить время на приведение в соответствие записей. И если я не писал на ST, то как-то и не хочу
Плюс в языках по сравнению с ST нельзя прыгать по массивам через метки, можно только в небезопасном коде, но включать этот режим не есть хорошо.
У ПЛК то есть watchdog, если что перегрузится, а ПК или Планшет ? тупо зависнут может.
IVM с какого перепуга проще ? ну ка код на ST копирования из массива в массив приведите ?
Или вот 334,56789 - сделайте из числа два числа 334 и 0,56789
Или остаток от деления 16970/16
Будьте любезны кодом в ST покажите простоту
https://www.owen.ru/forum/showthread...l=1#post139492
Ну вот пример одного и того же кода на C++ (на C# просто синтаксически будет отличаться) и на ST (в коде ST отличие только в полиноме и начальном значении) Суть кода одна и та же.
capzap остаток еще проще, mod или X%Y и всех делов. Я просто для примера, что первым в голову взбрело.
з.ы. я к тому, что в языках многое одинаково, просто отличия в способах записи... и если человек знает что это такое при такой-то записи, то найти как это же записать на другом языке не составляет больших трудов...
Последний раз редактировалось melky; 04.07.2019 в 11:06.
1) Про Android я не особо в курсе, и с Rhino могут быть проблемы. Например, Rhino (~JavaScript) на обычной Java активно генерирует код для оптимизации вычислений. Не факт, что это всё допустимо в Android. Например, может оказаться, что Rhino запускается, но работает крайне медленно
2) По моему опыту (разработки среды программирования на ST), ST -- неудачный язык с точки зрения системы типов. Там понамешали знаковых, беззнаковых битовых и прочих типов, при этом в стандарте нет чёткого определения того, какой тип переходит в какой.
3) При добавлении "скриптового языка" важно определиться каким образом будет идти обращение аргументам и состоянию системы.
Например, если пишем макрос преобразования датчика, то всё просто: у него вход это значение датчика, выход это результат обработки. И ничего другого такому блоку не нужно.
Если же значение хочет зависеть, например, от "текущего номера экрана", то уже интереснее.
Можно "текущий номер экрана" объявлять точно так же входным сигналом этого блока (т.е. из текстового языка разрешать обращение только ко входам). Это неплохой подход, и при этом будет сразу видно "от чего зависит блок". Но, возможно, придётся объявлять слишком много. Например, если блок зависит от времени, то удобно бы было обращаться к "текущему времени" без объявления его отдельным входом.
И тут начинается: "всегда существующая переменная с номером экрана", "всегда существующая переменная с текущем временем" (а, возможно, это несколько переменных, т.к. переменные "час", "минута" тоже удобны, и на Android не хочется набирать длинных выражений в духе to_number(to_char(current_date(), "HH")). И к прочим системным регистрам (или как они в К* называются) тоже удобно обращаться прямо так.
Так тоже можно делать, но главное сделать так, чтобы для каждого вычисления не приходилось заново проставлять текущие значения всех этих переменных. Ведь окажется, что выражение простое (x+y*z), а для его вычисления мы начинаем проставлять 100500 переменных (которые потом не используются).
Вот пример кода из Apache JMeter: https://github.com/apache/jmeter/blo...java#L123-L149
Там они для каждого выполнения скрипта проставляют 11 переменных, и делать так в К* вряд ли желаемо.
Конечно, варианты есть, и нужно просто задуматься над этим. Как видно, в JMeter не задумались.
По языкам же, думаю, стоит перебрать несколько популярных и посмотреть в каком состоянии есть готовые реализации для Android и не сильно ли косо будут выглядеть формулы.
JavaScript (возможно), Lua (возможно), Python (вряд ли)
Эзотерика в духе ClojureScript, Forth, Tcl, Eta-lang это забавно, но вряд ли для К*
В КаСкаде 200 регистров, из себя они int. Первые 10 (от 0 до 9) это системные, там и номер экрана и бит наличия интернета и тек. время и т.д. от 10 до 199 это пользовательские.
Лично я вижу что-то такое на javascript
$ - обращение в сис регистры.
$10 = $100 + $101 * Math.sqrt($102); //Метод Math.sqrt() возвращает квадратный корень числа,
или
var a = $10; //сначало объявим переменные
var b = $11;
var c = $12;
a = b + c;
или условие
if ($10 > 5) { //если сис.регистр больше 5, то
$11 = 1;
}
if ($10 > 7) { //если сис.регистр больше 7, то
$11 = 2;
}
Чем удобен javascript движок, так это простотой и уже готовым довольно простым синтаксисом
Вот его математический методы https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Math
Да, надо подумать как доставать bool и float, но эти кейсы можно потом обдумать.
Последний раз редактировалось KaScada; 04.07.2019 в 12:57.
HMI for Android http://www.hmi-kascada.ru/kaskada/
Я, конечно, это видел, и для меня подобное не укладывается в 21-ом веке.
По-моему, "регистры" должны именоваться, а не нумероваться.
Ну или, если нумерация зачем-то нужна (зачем?), то хорошо бы иметь возможность называть сами регистры.
Т.е. назвали, что вот "текущее_время", и чтобы потом можно было не вспоминать $8 это или $23. И, разумеется, у "системных регистров" должны быть названия, чтобы не ходить в документацию и не выяснять какой для чего.
А плох он тем, что там нет операций с целыми. По сути, в JavaScript либо boolean, либо строки, либо float.
Возможно, это не так и плохо, но учитывать стоит. Для пользователей может быть неприятный сюрприз при "округлениях" (см https://0.30000000000000004.com/ ).
Например, 7/2 будет 3.5. Кому-то нужно целочисленное деление, а кому-то дробное.