не попадалось публикаций свежих или не очень по адаптации акторной модели для программирования IoT систем в целом как распределенные вычислительные сети? Smalltalk акторный жизнеспособен как IoT-язык?
PS: тезисы вчера накидал в ВК, но ссылку шарить еще рано — есть концепция, нет реализации, понятия не имею взлетить или нет
Smalltalk — чистое ООП, программирование на передаче сообщений.
Акторная модель — на передаче асинхронных сообщений.
Оба подхода ведут напрямую к теме, взлетающей в глобальных масштабах — программирование для распределенных, гетерогенных сетевых структур, состоящих из разнородных вычислительных узлов, которые появляются и исчезают в зависимости от связности сети, и запуску и останову серверов on demand.
да, про звонкий пук японцев и США в том числе, но скорее про саму ситуацию, когда пытаются пропихивать ногами незрелую технологию под хайп и распилы, при этом ни конечные пользователи ни сами разработчики толком не понимают саму технологию и что и как с ней можно делать, а что не пролезет в концепцию — в результате разочарование, и смерть штуки которая могла работать при правильном применении
ЗЫ: не наезд на статью и конкретно Вашу разработку, общее впечатление
ЗЫЫ: не увидел слово «предиктивный анализ» (отказов, поведения системы)
А есть ли будущее у технологии, если пойти дальше Smalltalk, и заменить модель сообщений запрос/ответ на чистую асинхронку и акторное программирование? Думаю такой язык был бы крайне интересен для современных задач по облачному программированию, GRID, микросервисов и т.п., если реализовать его как расширение для mainstream технологий поверх той же JVM.
Сейчас идет большой хайп про IoT, а как бы это не область где такой язык принципиально необходим, в виде полноценного LLVM-кросскомпилятора для встраиваемых систем. Go делает слишком жирные бинарники, минимум на порядок толще чем это оправдано на железе типа RT5350. И решилась бы проблема с интероперабельностью межде системами разных архитектур — сейчас передача данных по MQTT вызывает головную боль с выбором методов сериализации, пакеты длиной от 50 байт (LoRa), на принимающей стороне IoT платформ зоопарк библиотек и протоколов декодирования.
Большие вопросы скорее вызывает то что Smalltalk не пошел в mainstream.
Его модель с передачей сообщений очень масштабируема не только в смысле параллельных вычислений, но и программирования для распределенных систем.
Даже самые примитивные операции выполняются только на сообщениях, и эта точка потенциального взрыва использования языка если думать про параллелизацию и distributed computing (микросервисы и вот это вот все).
И тем не менее, Smalltalk почти умер (несколько десятков энтузиастов и группа Pharo это не жизнь языка программирования), в чем же причины?
а почему до сих пор не делают подобное ни на одной linux-железке?
дело в себестоимости, сложность сделать качественную клаву (китайцы вроде умеют), или что-то еще?
чувак, ты или не в теме, или на голову слабоват — кто из источников возьмет на себя ответственность раскрыться, и под первый отдел попасть? ответственная сборка до сих пор под грифом
Значит физики и не должны писать код, в штате обязательна пара профессиональных высококлассных программистов, свободно владеющих численными методами и мат.методами рабочей области. Или можно дойти до того, что профессор обязан уметь пользоваться всеми видами сварки, быть асом электроники, и точить на станках свое экспериментальное оборудование. Можно разве что потребовать умение работать в какой-нибудь мат.среде типа mathematica, для которой проф.программист пишет заказные модули расширения.
Есть такая штука как Shared Translation Memory — заведите общую базу на всю рабочую группу, и подчищайте забаненные варианты когда при вощникновении идеологического конфликта и его решении будет принято решение использовать тот вариант, не использовать другой
PS: тезисы вчера накидал в ВК, но ссылку шарить еще рано — есть концепция, нет реализации, понятия не имею взлетить или нет
Smalltalk — чистое ООП, программирование на передаче сообщений.
Акторная модель — на передаче асинхронных сообщений.
Оба подхода ведут напрямую к теме, взлетающей в глобальных масштабах — программирование для распределенных, гетерогенных сетевых структур, состоящих из разнородных вычислительных узлов, которые появляются и исчезают в зависимости от связности сети, и запуску и останову серверов on demand.
ЗЫ: не наезд на статью и конкретно Вашу разработку, общее впечатление
ЗЫЫ: не увидел слово «предиктивный анализ» (отказов, поведения системы)
Сейчас идет большой хайп про IoT, а как бы это не область где такой язык принципиально необходим, в виде полноценного LLVM-кросскомпилятора для встраиваемых систем. Go делает слишком жирные бинарники, минимум на порядок толще чем это оправдано на железе типа RT5350. И решилась бы проблема с интероперабельностью межде системами разных архитектур — сейчас передача данных по MQTT вызывает головную боль с выбором методов сериализации, пакеты длиной от 50 байт (LoRa), на принимающей стороне IoT платформ зоопарк библиотек и протоколов декодирования.
Его модель с передачей сообщений очень масштабируема не только в смысле параллельных вычислений, но и программирования для распределенных систем.
Даже самые примитивные операции выполняются только на сообщениях, и эта точка потенциального взрыва использования языка если думать про параллелизацию и distributed computing (микросервисы и вот это вот все).
И тем не менее, Smalltalk почти умер (несколько десятков энтузиастов и группа Pharo это не жизнь языка программирования), в чем же причины?
а даже миниSD уже проблемны
дело в себестоимости, сложность сделать качественную клаву (китайцы вроде умеют), или что-то еще?
Значит физики и не должны писать код, в штате обязательна пара профессиональных высококлассных программистов, свободно владеющих численными методами и мат.методами рабочей области. Или можно дойти до того, что профессор обязан уметь пользоваться всеми видами сварки, быть асом электроники, и точить на станках свое экспериментальное оборудование. Можно разве что потребовать умение работать в какой-нибудь мат.среде типа mathematica, для которой проф.программист пишет заказные модули расширения.
Рассматривали ли часовые станки Т28? Для серии модет подойти решение на ручных станках + копир-оснастка