metaclass | (no subject)

(no subject)

Аааа, в моих интернетах не все преклоняются перед Хаскелем!:

потом товарищ уволится, или его наконец уволят, сей говнокод выкинут к ебеней матери и вменяемый программист перепишет обычным scanf'ом за пару часов, и спокойно пойдет на обед. код будет работать на порядки быстрее и занимать меньше будет, любой другой программист поймет и сможет поддерживать.
к чему вся эта рекурсивная самоебля?

Threaded | Top-Level Comments Only

О!

А где вы её используете?

в суровой практике, на данный момент, нигде не используем. Как минимум, есть планы генерировать javascript из неё. Несмотря на отсутствие реальных дел на агде, язык очень нравится.

Даёшь птичьи языки в жизнь! Работа провернута нехилая, но неясно, что заставило автора вводить такие ограничения для размера используемой памяти и что помешало поставить нормальный контроллер на свои трекеры. HTTP клиент - звучит достаточно круто для такого экзотического языка, но если учесть специфику - то, что реально работа идет через отправку AT команд на GSM модуль - реализация HTTP клиента становится тривиальной и делается на любом языке вплоть до ассемблера.
Еще в качестве примера, у современных GSM модулей разрешено использовать внутренности мощного проессора (ARM9 как правило) для пользовательских нужд. Варианты языков для внутреннего приложения: C, C++, Lua, Python. В этом свете киллер-фича автора становится бледноватой. :)

С контроллерами у

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

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

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

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

Если мериться письками, то намного круче step7 и ladder. На них не хухры-мухры, а аццкие промышленные конвееры программируются и со всякими верхними уровнями (СКАДАми) состыкуются.

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

О, в официальном faq'е:
Rule of thumb: if the embedded system can run an operating system like linux, then it is probably possible to get current implementations of Erlang running on it with a reasonable amount of effort. Getting Erlang to run on, say, an 8 bit CPU with 32kByte of RAM is not feasible. People successfully run the Ericsson implementation of Erlang on systems with as little as 16MByte of RAM. It is reasonably straightforward to fit Erlang itself into 2MByte of persistant storage (e.g. a flash disk).

это плохие языки для средних потребностей, слишком узкоспециальные, в отличие от текущих участников замера.

А. Ну это малоинтересно.
Вот что-то подобное для 8-биток было бы реально интересно.

Это dsl'и, которые идеально ложатся в те специфические условия.
Причем, программы на них в принципе не могут виснуть, что тоже приятно.

Но зачем?

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

Зачем нужны восьмибитки?
Ну, малоногое маложручее иногда таки нужно.

Плюс, зачвстую, чисто топологически удобнее поставить стадо мелких 8-биток и не тянуть например тучу силовых проводов по всей конструкции.

Ну тут либо шашечки, либо ехать. Либо велосипедить очередную копию кусков линупса, либо писать код, делающий дело.

Самое интересное, что все ответы на вопросы есть в статье. Например, про контроллеры --- MSP430 в полном режиме потребляет в разы меньше, чем любой ARM-контроллер в режиме спячки.

По поводу "модемы разрешают" --- да вы сами видели эти модемы и что они разрешают? Не говоря о том, что использовать нетипизированные или динамически-типизированные языки для скриптинга устройств --- это бред.

С контроллерами была еще цена и энергопотребление, и тут до сих пор неясно, чем заменить MSP430.

8битки уже выходят из моды и писать под них такого рода инфраструктуру никто не будет. А вот под популярные кортексы виртуальную машину эрланга можно было бы переточить.

"MSP430 в полном режиме потребляет в разы меньше, чем любой ARM-контроллер в режиме спячки."
Совсем не факт. На кортексах делают зигби контроллеры, где энергопотребление решает. Можно было бы порыться в даташитах, чтобы уточнить, но там не всегда честные цифры пишут. Кроме того, есть еще и энергопотребление модема. Спят они, конечно, неплохо, но там ведь внутри тот же ARM9 + DSP и на этом фоне экономить микроамперы при помощи MSP не представляется реально обоснованным. Опять же, нужны конкретные цифры, что вы реально сэкономили этим процом.

"По поводу "модемы разрешают" --- да вы сами видели эти модемы и что они разрешают? Не говоря о том, что использовать нетипизированные или динамически-типизированные языки для скриптинга устройств --- это бред."
Видели. Действительно, не впечатляют. Но возможностей, на мой взгляд больше, чем у вашего решения.

Какие вам нужны цифры? Данные по потреблению открыты и есть в даташитах, если им не верите, можно включить и померять. Мы меряли.

Насчет возможностей действительно интересно. Можете привести какие-нибудь доводы?

Ну я посмотрел в даташитах. У MSP430 220 мкА на мипс в активном режиме. В среднем то есть около 2 мА. У STM32 в standby 3 мкА. В слипе - 2 мА. И при этом производительность в 10 раз больше.

Доводы: куча ОЗУ и флэша нахаляву, приличный API, как правило есть API для файловой системы, FTP, HTTP. Бывает готовый SSL, который вы на MSP430 ни в жисть не реализуете. Минусы тоже есть, но для трекеров не особо критичны.

Ну и какой еще скриптинг в standy или sleep? Опять же, откуда взялись нафик ненужные FTP и SSL? И самое главное --- откуда вам известны спецификации трекеров? Впрочем, что ЖЖ наводнен телепатами я уже привык. Опять же, посмотрите на год статьи. В 2009-ом проект уже был запущен. Пойнт в том, что нужен был на пустом месте безопасный скриптинг для MSP430 на скорую руку и он был сделан.

Т.е задача была --- скриптинг на MSP430 c безопасной дистанционной проливкой, которая и сделалась. Не выбор процессора. Не установка модема телит или подобного.

"Впечатляющий объем работ" это всего-то 2000 строк на окамле + сотни три строк рантайма на си, т.е достаточно быстро, просто и дешево, в чем и был главный пойнт статьи, жалко что не удалось донести.

"Ну и какой еще скриптинг в standy или sleep?"
Можно просыпаться изредка и выполнять скрипт.

"Опять же, откуда взялись нафик ненужные FTP и SSL?"
Ну сейчас может не нужные, а потом понадобятся.

"И самое главное --- откуда вам известны спецификации трекеров?"
Мне они неизвестны.

"Т.е задача была --- скриптинг на MSP430 c безопасной дистанционной проливкой, которая и сделалась. Не выбор процессора. Не установка модема телит или подобного."
Ну я же изначально поставил под вопрос именно постановку задачи. К её решению претензий нет. Если так уж сложилось, что задача по другому не ставится, то и вопросов нет.

"это всего-то 2000 строк на окамле + сотни три строк рантайма на си, т.е достаточно быстро, просто и дешево, в чем и был главный пойнт статьи, жалко что не удалось донести."
Не надо жалеть - мне просто интересны технические детали проекта, а не реализация скриптинга. Я еще хотел уточнить, что вы делаете, если ошибка обнаружится в интерпретаторе? Его как-то можно обновить дистанционно?

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

Threaded | Top-Level Comments Only

Page 2 of 3