metaclass | (no subject)

>код будет работать на порядки быстрее и занимать меньше будет

И его можно будет собрать не только под ПК, но и под мелкий контроллер!

GHC умеет на выходе давать сишный код и llvm. Так что можно и для контроллера на хаскеле писать.

приём байтика из уарта (плюс, асинхронный ШИМ на еще двух ногах) в аттини11 влезет, или для этого llvm придется брать аж мегу, причем тридцатьвторую?

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

>Сейчас кортексы например стоят дешевле 32-й меги.

в 8..20 ногом корпусе бывают? Не везде нужно да и не везде лезет какой-нибудь plcc-48.

>А для хаскеля на контроллере придется брать еще нечто пожирнее, потому что память ест непредсказуемо.

Вот-вот. :) вместо простого быстрого решения, влезающего в 8ножку, мне предлагают нечто еще более эпическое чем 'propeller'(tm) :)

Самый хилый из кортексов в 20ногом корпусе. STM вроде планировали что-то малоногое.
Хаскель в контроллерах и правда не очень круто. А вот эрланг - интересненько. Можно было бы сети делать из контроллеров с удаленным обновлением кода.

>Можно было бы сети делать из контроллеров с удаленным обновлением кода.

это и на сях делается.
В случае всякой мелочи - бутлоадер или обмена скрипта для интерпретатора внутри контроллера.
в случае крупного - обычный линух с обычными ссш/дпкг/крон/итд.

20 ног иногда таки много. Чисто по размерам корпуса.

На сях сеть контроллеров делается крайне нетривиально, а на эрланге прозрачно из коробки. Обновление кода делается с горячей заменой кода - ни один интерпретатор для контроллеров этого не умеет. Кроме того, нехилые возможности по удаленному администрированию, которым ссш сливает по полной. Кроме того продвинутый фейловер, что немаловажно для железа в поле. Кроме того ин-мемори хранилище данных, альтернатива которым для железа сейчас только Sqlite, что явный перебор.

20 ног многовато, да. Ну может сделают 8ногую версию когда-нибудь. Чтобы например I2C/UART/ADC мультиплексированные, а остальное питание, земля, сброс и кварц.

>На сях сеть контроллеров делается крайне нетривиально

на сях уже всё сделано. Ставим линух и имеем готовую отлаженую инфраструктуру. (если контроллер достаточно жирный для линухов)

> нехилые возможности по удаленному администрированию

А можно весь список? ссш, естественно, не под виндой, а на нормальных ос.

> Кроме того ин-мемори хранилище данных, альтернатива которым для железа сейчас только Sqlite, что явный перебор.

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

>20 ног многовато, да. Ну может сделают 8ногую версию когда-нибудь. Чтобы например I2C/UART/ADC мультиплексированные, а остальное питание, земля, сброс и кварц.

Кварц зачастую не нужен. 2 питания, 1 ресет, остальные 5 ног мультиплексированные. Ну или ресет тоже мультиплексированная, но тогда программирование будет чуть затейливее чем у авр через spi.

"Ставим линух и имеем готовую отлаженую инфраструктуру."
Почитай про распределенные приложения в Эрланге. Будешь удивлен. :)

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

"кстати, а как у эрланга с гарантиями-реалтаймами?"
У Эрланга софт-риалтайм. Честно говоря, не совсем понимаю что это такое, но звучит круто. :)

У эрланга GC раздельный для каждого треда. Т.к. у идиоматических эрланг-тредов хип очень маленький обычно (зато тредов много), сборка мусора очень быстро отрабатывает (единицы микросекунд), причём виснет на это время только собираемый тред. Весь сетевой стек при этом продолжает работать (процесс может получать сообщения от сетевого стека, но не начинает их обрабатывать), поэтому в целом система никогда не делает пауз на GC.
В целом же Эрланг делался Эриксоном как раз для АТС, набранных из нескольких вычислительных нод и находящихся где-нибудь у чёрта на рогах. Отсюда удалённая консоль из коробки, отсюда возможность трейса всего и вся наживую, отсюда возможность замены любого кода прямо на лету, причём, возможно, с вызовом кода для смены состояния системы в новый формат. Отсюда куча разнообразных средств для обработки и изоляции ошибок, в т.ч. программиста.

А минимальные требования к системе какие?

А почему эрланг так малопопулярен, если он так крут?

>А минимальные требования к системе какие?
Зависит от того, что нужно. Есть готовые сборки под Gumstix/Beagle вот тут http://www.erlang-embedded.com/ , под ARM компилируется без проблем вроде. По производительности можно брать «чуть быстрее cpython», если не брать в расчёт JIT (я не знаю, работает ли он на ARM). Слышал из первых уст, что кто-то пилит бортовые компьютеры для авто на Erlang'е, ну и Erlang Solutions много рассказывали о том, как они двигают Erlang в embedded — сборки, поддержка от вендоров железа, тестирование на разном железе. Думаю, если заинтересуют, можно с ними связаться.
>А почему эрланг так малопопулярен, если он так крут?
Потому что основная часть софта в количественном плане — сайты по продаже виагры на пхп, там эрланг не нужен.