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

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

DM>>>Этот минус JVM Рич исправил, математика на кложури на порядки медленнее.

AA>>И нет, на днях, изучая кложу, заметил, что жвмоский вариант выполняет
AA>>

AA>;>(reduce + (range 1 1000000))
AA>;>

AA>>Мгновенно, в отличии от, например CLR-кложи и C#.
AA>>Понятно, что там использована какая-то жесткая оптимизация, но это же доказывает
AA>>возможность получения высокопроизводительного кода на трушном языке.

DM>Ну возьми чуточку сложнее пример, даже не нужно сильно сложнее, и сравни с другими языками. См. срачи тут, например:
DM>https://tonsky.livejournal.com/322036.html
DM>https://tonsky.livejournal.com/322450.html

DM>(человек несколько лет профессионально на кложе писал, и зае устал)


И да, человек зачем-то сравнил динамику со статикой. у них разные нишы.

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

AA>И да, человек зачем-то сравнил динамику со статикой. у них разные нишы.

Ниши их хорошо пересекаются (почти по всей площади области применения динам. ЯП), сравнивать можно. И когда начинаются такие речи, это признание того, что динамика тормозит, т.е. Рич таки загубил хваленую скорость JVM.

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

FDS>Ещё пару вопросов насчёт выбора языка программирования.

FDS>Есть ли язык программирования, в котором есть следующие фичи:

Нет такого языка программирования и не будет в обозримом будущем.
А вот анализатор исходного кода, который бы все это отлавливал, можно сделать. Да уже и сделано много таких анализаторов — https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Что характерно, юольше всего анализаторв следано для C/C++ — вероятно, потому, что они там нужнее. На втором месте Java, полагаю потому, что легче делать благодаря четкой спецификации.

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

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

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

AA>>И да, человек зачем-то сравнил динамику со статикой. у них разные нишы.

DM>Ниши их хорошо пересекаются (почти по всей площади области применения динам. ЯП), сравнивать можно. И когда начинаются такие речи, это признание того, что динамика тормозит, т.е. Рич таки загубил хваленую скорость JVM.

Да, динамика по определению полиморфна, и возможно, это важнее безопасной работы с памятью с точки зрения гибкости ПО и соблюдения DRY.
Сфера применения кложи достаточно четко определена — бизнес-приложения под веб. Аналогично javascript. Ведь никому не придет в голову использовать джс для сложных вычислений.
Его ниша — гибкая и быстрая разработка клиента.
Требуется правильный выбор инструментов. Еще важно, знание особенностей. Если чего-то не знаешь, кажется что это сложно. На деле все по другому.

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

FDS>Тут пол форума троллинг. Как пришёл человек с практическим вопросом — два человека только понять могут, что человек хочет.
FDS>Дожили

1. Вот это вот всё, про то, что тут троллинг, а что нет -- само по себе лютый офтопик, да и троллинг тоже
2. Вовсе и не два. Просто мало кто может дельный совет дать. Возможно есть какие-то хитрые DSL с такими свойствами, или на чём-то вроде ады или ограниченных чем-то плюсов можно такой слабать…

3. По поводу ограничения доступа к API. Я бы вообще разделил программу на два процесса : внешний и внутренний. И всё подозрительное API звать из внешнего, а 95% кода пусть во внутреннем крутятся, у которого можно и права задавить и средствами OS или анализа зависимостей, проверить, что ничего подозрительного из него не зовут.

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

E>1. Вот это вот всё, про то, что тут троллинг, а что нет -- само по себе лютый офтопик, да и троллинг тоже

Согласен


E>3. По поводу ограничения доступа к API. Я бы вообще разделил программу на два процесса : внешний и внутренний. И всё подозрительное API звать из внешнего, а 95% кода пусть во внутреннем крутятся, у которого можно и права задавить и средствами OS или анализа зависимостей, проверить, что ничего подозрительного из него не зовут.

К сожалению, это только вариант подавления некоторых API типа файлового ввода-вывода.
Там всё гораздо сложнее, чем я ранее в этой теме сформулировал.

Я даже начал собственное расширение ассемблера писать. Но что-то сложновато, староват я, запала уже не хватает.
Похоже, не напишу я это .

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

FDS>Ещё пару вопросов насчёт выбора языка программирования.

Можно посмотреть на LUA.

FDS>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули

Есть.

FDS>2. Аналогичный запрет для всех функций, которые вызываются из данной функции

Их тоже можно запретить.

FDS>3. Помечать код как неизменяющий состояние программы

Непонятно.

FDS>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.

Пометить можно, но в динамике.

FDS>Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние).

Это можно.

FDS>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.

Только если объект есть — объекта нет.

FDS>F-star знаю, но его очень не хочется. Всё очень глючно, на костылях и очень сложно.

LUA — классический встраиваемый язык, простой и надежный.

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


FDS>К сожалению, это только вариант подавления некоторых API типа файлового ввода-вывода.
FDS>Там всё гораздо сложнее, чем я ранее в этой теме сформулировал.

Ну так сформулируй подробнее...

FDS>Я даже начал собственное расширение ассемблера писать.
Зачем расширение ассемблера писать, когда есть аппаратная поддержка отладчиков?

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


FDS>Есть ли язык программирования, в котором есть следующие фичи:
FDS>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
FDS>2. Аналогичный запрет для всех функций, которые вызываются из данной функции
FDS>3. Помечать код как неизменяющий состояние программы

FDS>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
FDS>Причём нужно, чтобы была возможность автоматически построить список всех явный приведений типов между зелёными и красными (а ещё лучше — запретить)
FDS>Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние).

FDS>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.

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

А что за дополнительные метки (п.4)? Можете дать use case? По описанию интуитивно кажется что что-то весьма интересное, но описание уж больно расплывчатое

Пункт 5 это что-то вроде typestate, которое хотели сделать в Rust но не сложилось?

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

FDS>Ещё пару вопросов насчёт выбора языка программирования.

FDS>Есть ли язык программирования, в котором есть следующие фичи:

Помоему java подходит как нельзя лучше.

FDS>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
FDS>2. Аналогичный запрет для всех функций, которые вызываются из данной функции

Каждой такой функии выдать свою permission, для вызываемого кода выдавать полномочи -> остальное заблокируется.
Можно сделать свой SecurityManager и в момент проверки доступа делать какие-нибудь хитрые вещи типа прверки стека функций, кто кого вызвал и прочее.

FDS>3. Помечать код как неизменяющий состояние программы

Я думаю это возможно сделать через анотации, если данные и те кто их изменяет помечены разными аннотациями.
что-то вроде этого:
https://www.baeldung.com/checker-framework

FDS>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.

Аннотации + классы.

FDS>Причём нужно, чтобы была возможность автоматически построить список всех явный приведений типов между зелёными и красными (а ещё лучше — запретить)

наследование+агрегация

FDS>Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние).

Аннотации.

FDS>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.

инициализирован-выполнились стати методы на классе и блоки кода до конструктора.
объект в работе — конструктор был вызван
объект завершил работу — объект попал в очередь на удаление тобишь в ReferenceQueue.
бъект подвергся деструкции — обхект пооностью не доступен и память его очищена GC


FDS>F-star знаю, но его очень не хочется. Всё очень глючно, на костылях и очень сложно.

Посмотри МультиОберон.
Люди как раз занимались реализацией ограничений в компиляторе.
Типа атрибутов. Например: не использовать динамическую память в данном модуле/проекте.
И любая попытка написать new приводит к ошибке компиляции.

rfq>Нет такого языка программирования и не будет в обозримом будущем.
Я бы не был так категоричен. Есть люди, которые озабочены именно тем, чтобы разработать ограничительный компилятор.
Чтобы можно было в проекте запрещать использовать некоторые возможности языка.
Например, запретить использовать динамическую память.
Это не простые фантазии, а реальная потребность при разработке для разных микроконтроллеров.
Но писать новый компилятор для каждого нового — не хотят.
Сделали МультиОберон — с подкладкой LLVM на данный момент.