Ну как исполняется — как javascript. Например, в первом релизе интерпретатора фаза компиляции или построения AST отсутствовала, код исполнялся «прямо из строки», и частота мигания светодиода зависела от количества пробелов в коде. Это уже пофиксили, но думаю много других джавоскриптизмов осталось (как например отсутствие целого типа в языке и костыли чтобы это обойти конкретно в Espruino).
Есть open source среда разработки и компилятор/интерпретатор?
Язык интерпретируемый, компиляция в байткод происходит при интерпретации. Если вы о том, можно ли компилировать в байткод на хосте и грузить байткод на target — сначала было нельзя (см. выше), сейчас не знаю. Среда разработки? Vim/emacs, не? Если «не», то взгляд на github.com/espruino показывает, что есть аж две:
EspruinoWebIDE
The Espruino Web IDE — A Chrome Web App for programming Espruino
EspruinoOrion
Plugin for Eclipse Orion + Espruino
Я детально Espruino не смотрел, потому что — правильно! — javascript. Слава богу, после появления MicroPython необходимость в этом отпала (я сам подбивал автора MicroPython открыть код как можно скорей, чтобы спасти людей от необходимости ковыряться с javascript или lua, если требуется unbloated встраиваемый скриптовый язык).
Статья немного улыбнула, ее смысл можно свеcти к «closed-source библиотеки едят ваши данные бенчмарки!!!11». Но ведь это и так все знают, не так ли? Кто хочет качество, использует библиотеку с открытой реализацией известного алгоритма, которую можно проверить (и даже оптимизировать). Кто хочет дописать строчку с аббревиатурами и buzzword'ами в прес-релиз, тоже имеет свой вариант. Для всех есть место под солнцем, и никому ни перед кем извиняться не надо.
Я думаю народ намекает на более простые вещи, например, что неплохо бы на github положить файлик с main(), который бы чего-то считал, а после делал бы хотя бы assert на memcmp с ожидаемым результатом.
> Сленг — это, конечно, прикольно для комьюнити, но как же напрягает, когда только начинаешь разбираться.
Согласен. Может через 20 лет, когда Rust основательно «проржавеет» это и будет восприниматься нормально, а пока выглядит несерьезно и только отталкивает от языка.
> Блин, это уже третий Ваш комментарий, смысл которого мне не понятен :(
Я рад изложить свои мысли более подробно, особенно если вы не будете воспринимать их как критику. Глобальный вопрос, над которым я здесь философствую — это как мы (международное сообщество любителей Open Source Smart Home'а) дошли до жизни такой, что есть 20-30 проектов, причем половина из них — реально активные, и при этом все время появляются новые, и некоторые люди (например вы) отдают им месяцы своего времени. И при всем этом, другие люди (например я), которые не хотят писать свое с нуля, а хотят найти подходящий проект для использования/участия, не могут такой найти, при казалось бы большом выборе «на любой вкус».
> FYI это было сделано не из-за ограничений платформы,
Конечно же, возможность пихать ресурсы в DLL — это не ограничение платформы. Это ее дополнительная фича. И вы эту фичу abuse'ите! Вы же сами привели ссылку «на вы все еще не любите JavaScript?» и там же одним из главных пунктов идет легкость вхождения и доступность. Если я захочу сделать динамическую веб-страничку, я могу это сделать на любом компе, потому закинуть на любой сервер, и если потом найду проблему, зайду на этот любой сервер и прямо там исправлю. А теперь сравните с вашей системой — я поставил ее, а через месяц увидел мелкую проблему в веб-интерфейсе. Я прекрасно знаю, как чинятся проблемы с веб-интерфейсом, залажу в каталог, и вместо привычных html, css, js вижу какие-то бинарники и узнаю, что чтобы поправить веб-интерфейс, вы хотите меня заставить вспоминать .NET и изучать, что там нового сталось за N лет, что я его не трогал. Тут-то наши пути и разойдутся.
> для удобства установки плагинов (чтобы все необходимое было в одном файле).
И на это я отвечал уже — это очень удобно для пропраетарного коммерческого продукта, и очень неудобно для open-source проекта (вы просто совершенно искусственно подымаете порог вхождения для потенциальных contributor'ов).
человек, который разработал ScriptGUI просто написал нам письмо: «что так мол и так. Я написал графическую оболочку для редактора сценариев. Посмотрите». Нам нужно было сказать: иди лесом?
Вот так сходу — точно нет конечно. Но одним из возможных продуктивных ответов (не в вашем случае — вообще) является: «Замечательно! Напишите, испытывали ли вы сложности с интеграцией — возможно, что-то недокументировано? А так, будем рады, если вы будете maintain'ить ваш проект сами — мы не можем тянуть все, а вот создать интеграционную платформу, которую бы поддерживали разные независимые разработчики — очень хотим».
Впрочем, если «которую, кстати, успешно использует треть пользователей ccu.io», то все очень хорошо. А откуда данные? Короче говоря, пишите новые статьи о вашей системе, если будет время — очень интересно.
Так что для разных потребностей, опять таки, разные инструменты. Yahui для телефона. DashUI для таблета и десктопа.
Ну т.е. иными словами, идея «web-технологии позволяет 1 раз сделать интерфейс, который будет работать везде» реально не работает…
но можно создать платформу к которой можно подключать разные модули для разных задач.
Вот это как раз суть того, что я хочу найти, и что увы не нахожу. Все норовят представить свою систему как «блекджек со ...», никто не пишет «наша система состоит из фронтенда и бекенда, все зависимости между ними четко документированы, если вас не устраивает наш моднячий бекенд на Java+.Net+Mongo+NodeJS в одном флаконе, выкиньте его нафик, и напишите свой.» Ближайшее, что я видел в этом направлении — это phpMyDomo но и тот зачем-то тащит PHP. А так в большинстве случаев мы имеем ситуацию, что если например проект на .NET, то даже юзеро-интерфейсный javascript надо прятать в DLLки, как же иначе.
А представьте, человеку интересен «умный дом», описывается вполне развитая система, а тут раз, и .NET — что, проходить мимо?
Собственно, я бы например, не комментил, если бы статья была на старом добром хабре «до fallout'а». Но посмотрите, что мы имеем сейчас — хаб здесь, на geektimes, пуст, по сравнению с тем, каким он был на habr. Большинство интересных статей осталось там. Но потеряли тег раздела «умный дом». Их уже трудно найти. Они еще имеют тег «DIY», но и он в очереди на выпиливание. Поэтому либо мы, люди интересующиеся «умным домом», таки соберемся здесь на GT, отметимся в каментах, и попытаемся восстановить community, либо-либо…
Спасибо за ответ. Но суть его можно свести к «имеет смысл делать почти одинаковые вещи двумя разными способами» и «я думаю, что работать с кодом будет удобнее не так, как с ним работали испокон веков, а как-то по-другому». Звучит неубедительно. Нет, на самом деле, я и сам мог наверное хотеть бы делать как-то так, если бы реально не делал что-то такое свое и не вел список из ~20 других проектов, которые тоже что-то как-то, но не всегда понятно, зачем, делают.
Собственно, не спора ради. Просто «свежая» мысль, которой хотелось поделиться с авторами систем умного дома.
Если Вы планируете использовать мой проект и эта доработка необходима срочно — напишите мне, я сделаю ее в первую очередь.
Не смогу, даже если я захочу. Во-первых, инструкции по установки предполагают Windows, у меня его нет (впрочем, вру, есть — недавно получил Intel Galileo с Windows for IoT — будет под ним работать ваша система?). Далее, мой «умный дом» сейчас крутиться на Android планшете. Даже если ваша система (за)работает под Mono, скольку усилий придется потратить на сборку Mono в каком-нибудь Optware и как он будет там работать? Ну и наконец, виджеты только двух размеров — «normal» и «wide» меня не устраивают — а если я хочу 1x2 или 2x2? (Последняя проблема собственно объективно отражает суть моей критики веб-код-редакторов и прочих плюшек — зачем тратить на них время, вместо того, чтобы сделать базовые фичи, как например виджеты произвольных размеров?)
Вот то редактирование кода в бразуере — на кого оно рассчитано? Дело в том, что имея сотню скриптов (ведь мы говорим об умном доме, правда?), которые нужно разрабатывать и настраивать в течение долгого времени, то когда я захочу сделать правку, первым делом я захочу сделать git blame, git log -p и т.п. на этот скрипт, а потом уже вносить изменения. Так для кого все эти редакторы кода в бразере? Для блондинок? Увы, они не будут писать код вообще. А те кто будут писать код, очень скоро, если не сразу, захотят доступную структуру (как в дереве каталогов файловой системы), контроль версий, комфорт любимого редактора и т.п.
Собственно, вопрос не только к вам, а ко многим авторам, которые в последне время постились на Хабре. Вот Bluefox'а, автора этой системы, удалось «поймать» на признании: «Сразу скажу, что наверняка есть возможность то же самое сделать с ScriptGUI, но я этим не пользуюсь, т.к. мне быстрее написать JS, чем рисовать.» Т.е. в его системе есть супер-пупер гуевый редактор скриптов и ивентов, только он сам говорит, что рисовать комиксы более сложно и нудобно, чем просто писать на языке.
Дальше больше — зачем писать скрипты в браузере, не лучше ли это делать в терминале, в любимом редакторе или IDE, с git'ом под рукой? Дальше больше — в системе Bluefox'а есть редактор форм — опупеть, можно сделать произвольные страницы управления и отображения в браузере. Вот только позиционирование абсолютное, т.е. делаются под конкретное разрешение экрана. Нужен умный дом на компе, планшете, телефоне? Сделай одно и тоже три раза подряд. У жен другой телефон? Сделай еще раз. Купил новый планшет? И еще раз сделай тупую обезьянью работу. Вопрос все тот же — а зачем такое редактор форм нужен? Не легче ли зупустить vim/mc/sublime и неспешно патчить CSS, чтобы добиться responsive design, коммитая в git, чтобы через пол-года легко найти, откуда взялся какой-то regression.
И подытоживая, главный вопрос — господа, для кого вы пишите все эти системы, кто их target audience? Все эти гуевые редакторы — прекрасно для еще одного стартапа-который-не-взлетел (ну потому что не будут простые милые добрые люди писать код и алгоритмы — хоть в браузере, хоть без, хоть в буквах, хоть в комиксах), но вполне себе излишни для open-source-проекта-чтобы-реально-работал.
Ну, там прототипы падов, а не всей шины. Как Eremenko говорит, они остановились на форме «horsehow inductor», ну а для индуктора нужно два вывода для подвода тока (в отличии от емкостного элемента, где пады с разных сторон представляют собой обкладки одного конденсатора). Но вопрос с питанием для модулей да, живой, очевидно без хотя бы пары физических контактов дело не обойдется.
> Представьте себе, например, ваших жен, подруг, матерей и дочек
Я например нифига не разбираюсь в моделях техники фирмы Apple, особенно учитывая названия вроде «iPad» и «New iPad», но это не означает что это rocket science и нельзя спросить консультанта в магазине.
К тому же, Project Ara не стремиться захватить весь мир — вот так и сразу. Для начала это способ продать еще один телефон тем, у кого их уже три и кто поклялся впредь покупать только дешевые китайские телефоны, потому что устал от реального отсутствия инноваций у «брендов».
Никаких плат не будет — все будет замотано изолентой залито высокопрочным компаундом. По крайней мере, это то, что они хотят сделать. Посмотрим, лифт в космос они уже строили…
Вопрос надежности — это первоочердной вопрос, вызывающий скепсис в модульном дизайне. Современные монолитные телефоны работают слишком ненадежно, что тут уж говорить о модулях. Так вот — внезапно — люди, работающие над Project Ara это понимают и предлагают реально инновационные методы решений — электропостоянные магниты (http://en.wikipedia.org/wiki/Electropermanent_magnet), бесконтактные шины, динамическая реконфигурация на уровне софта и т.п. По крайней мере, презентация Еременко реально вдохновляет (например www.youtube.com/watch?v=IQhbM55F23U, с 45й минуты).
Шина вообще будет бесконтактная, индуктивно-емкостная, т.е. контактные площадки не будут электрически соприкасаться, а просто должны быть на малом расстоянии друг от друга, чтобы обеспечить нужную пропускную способность шины (могут вообще не торчать наружу, а быть скрыты в слое пластика).
Ну как исполняется — как javascript. Например, в первом релизе интерпретатора фаза компиляции или построения AST отсутствовала, код исполнялся «прямо из строки», и частота мигания светодиода зависела от количества пробелов в коде. Это уже пофиксили, но думаю много других джавоскриптизмов осталось (как например отсутствие целого типа в языке и костыли чтобы это обойти конкретно в Espruino).
Язык интерпретируемый, компиляция в байткод происходит при интерпретации. Если вы о том, можно ли компилировать в байткод на хосте и грузить байткод на target — сначала было нельзя (см. выше), сейчас не знаю. Среда разработки? Vim/emacs, не? Если «не», то взгляд на github.com/espruino показывает, что есть аж две:
EspruinoWebIDE
The Espruino Web IDE — A Chrome Web App for programming Espruino
EspruinoOrion
Plugin for Eclipse Orion + Espruino
Я детально Espruino не смотрел, потому что — правильно! — javascript. Слава богу, после появления MicroPython необходимость в этом отпала (я сам подбивал автора MicroPython открыть код как можно скорей, чтобы спасти людей от необходимости ковыряться с javascript или lua, если требуется unbloated встраиваемый скриптовый язык).
> Самое интересное какая платформа станет наиболее популярной, как когда-то стала архитектура x86.
Наверное, у каждого будет своя индивидуальная? habrahabr.ru/post/118534/
данныебенчмарки!!!11». Но ведь это и так все знают, не так ли? Кто хочет качество, использует библиотеку с открытой реализацией известного алгоритма, которую можно проверить (и даже оптимизировать). Кто хочет дописать строчку с аббревиатурами и buzzword'ами в прес-релиз, тоже имеет свой вариант. Для всех есть место под солнцем, и никому ни перед кем извиняться не надо.People 468
Online now 3
Conversations 730
Comments 5,939
Согласен. Может через 20 лет, когда Rust основательно «проржавеет» это и будет восприниматься нормально, а пока выглядит несерьезно и только отталкивает от языка.
Я рад изложить свои мысли более подробно, особенно если вы не будете воспринимать их как критику. Глобальный вопрос, над которым я здесь философствую — это как мы (международное сообщество любителей Open Source Smart Home'а) дошли до жизни такой, что есть 20-30 проектов, причем половина из них — реально активные, и при этом все время появляются новые, и некоторые люди (например вы) отдают им месяцы своего времени. И при всем этом, другие люди (например я), которые не хотят писать свое с нуля, а хотят найти подходящий проект для использования/участия, не могут такой найти, при казалось бы большом выборе «на любой вкус».
> FYI это было сделано не из-за ограничений платформы,
Конечно же, возможность пихать ресурсы в DLL — это не ограничение платформы. Это ее дополнительная фича. И вы эту фичу abuse'ите! Вы же сами привели ссылку «на вы все еще не любите JavaScript?» и там же одним из главных пунктов идет легкость вхождения и доступность. Если я захочу сделать динамическую веб-страничку, я могу это сделать на любом компе, потому закинуть на любой сервер, и если потом найду проблему, зайду на этот любой сервер и прямо там исправлю. А теперь сравните с вашей системой — я поставил ее, а через месяц увидел мелкую проблему в веб-интерфейсе. Я прекрасно знаю, как чинятся проблемы с веб-интерфейсом, залажу в каталог, и вместо привычных html, css, js вижу какие-то бинарники и узнаю, что чтобы поправить веб-интерфейс, вы хотите меня заставить вспоминать .NET и изучать, что там нового сталось за N лет, что я его не трогал. Тут-то наши пути и разойдутся.
> для удобства установки плагинов (чтобы все необходимое было в одном файле).
И на это я отвечал уже — это очень удобно для пропраетарного коммерческого продукта, и очень неудобно для open-source проекта (вы просто совершенно искусственно подымаете порог вхождения для потенциальных contributor'ов).
Вот так сходу — точно нет конечно. Но одним из возможных продуктивных ответов (не в вашем случае — вообще) является: «Замечательно! Напишите, испытывали ли вы сложности с интеграцией — возможно, что-то недокументировано? А так, будем рады, если вы будете maintain'ить ваш проект сами — мы не можем тянуть все, а вот создать интеграционную платформу, которую бы поддерживали разные независимые разработчики — очень хотим».
Впрочем, если «которую, кстати, успешно использует треть пользователей ccu.io», то все очень хорошо. А откуда данные? Короче говоря, пишите новые статьи о вашей системе, если будет время — очень интересно.
Ну т.е. иными словами, идея «web-технологии позволяет 1 раз сделать интерфейс, который будет работать везде» реально не работает…
Вот это как раз суть того, что я хочу найти, и что увы не нахожу. Все норовят представить свою систему как «блекджек со ...», никто не пишет «наша система состоит из фронтенда и бекенда, все зависимости между ними четко документированы, если вас не устраивает наш моднячий бекенд на Java+.Net+Mongo+NodeJS в одном флаконе, выкиньте его нафик, и напишите свой.» Ближайшее, что я видел в этом направлении — это phpMyDomo но и тот зачем-то тащит PHP. А так в большинстве случаев мы имеем ситуацию, что если например проект на .NET, то даже юзеро-интерфейсный javascript надо прятать в DLLки, как же иначе.
Собственно, я бы например, не комментил, если бы статья была на старом добром хабре «до fallout'а». Но посмотрите, что мы имеем сейчас — хаб здесь, на geektimes, пуст, по сравнению с тем, каким он был на habr. Большинство интересных статей осталось там. Но потеряли тег раздела «умный дом». Их уже трудно найти. Они еще имеют тег «DIY», но и он в очереди на выпиливание. Поэтому либо мы, люди интересующиеся «умным домом», таки соберемся здесь на GT, отметимся в каментах, и попытаемся восстановить community, либо-либо…
Собственно, не спора ради. Просто «свежая» мысль, которой хотелось поделиться с авторами систем умного дома.
Не смогу, даже если я захочу. Во-первых, инструкции по установки предполагают Windows, у меня его нет (впрочем, вру, есть — недавно получил Intel Galileo с Windows for IoT — будет под ним работать ваша система?). Далее, мой «умный дом» сейчас крутиться на Android планшете. Даже если ваша система (за)работает под Mono, скольку усилий придется потратить на сборку Mono в каком-нибудь Optware и как он будет там работать? Ну и наконец, виджеты только двух размеров — «normal» и «wide» меня не устраивают — а если я хочу 1x2 или 2x2? (Последняя проблема собственно объективно отражает суть моей критики веб-код-редакторов и прочих плюшек — зачем тратить на них время, вместо того, чтобы сделать базовые фичи, как например виджеты произвольных размеров?)
Собственно, вопрос не только к вам, а ко многим авторам, которые в последне время постились на Хабре. Вот Bluefox'а, автора этой системы, удалось «поймать» на признании: «Сразу скажу, что наверняка есть возможность то же самое сделать с ScriptGUI, но я этим не пользуюсь, т.к. мне быстрее написать JS, чем рисовать.» Т.е. в его системе есть супер-пупер гуевый редактор скриптов и ивентов, только он сам говорит, что рисовать комиксы более сложно и нудобно, чем просто писать на языке.
Дальше больше — зачем писать скрипты в браузере, не лучше ли это делать в терминале, в любимом редакторе или IDE, с git'ом под рукой? Дальше больше — в системе Bluefox'а есть редактор форм — опупеть, можно сделать произвольные страницы управления и отображения в браузере. Вот только позиционирование абсолютное, т.е. делаются под конкретное разрешение экрана. Нужен умный дом на компе, планшете, телефоне? Сделай одно и тоже три раза подряд. У жен другой телефон? Сделай еще раз. Купил новый планшет? И еще раз сделай тупую обезьянью работу. Вопрос все тот же — а зачем такое редактор форм нужен? Не легче ли зупустить vim/mc/sublime и неспешно патчить CSS, чтобы добиться responsive design, коммитая в git, чтобы через пол-года легко найти, откуда взялся какой-то regression.
И подытоживая, главный вопрос — господа, для кого вы пишите все эти системы, кто их target audience? Все эти гуевые редакторы — прекрасно для еще одного стартапа-который-не-взлетел (ну потому что не будут простые милые добрые люди писать код и алгоритмы — хоть в браузере, хоть без, хоть в буквах, хоть в комиксах), но вполне себе излишни для open-source-проекта-чтобы-реально-работал.
Я например нифига не разбираюсь в моделях техники фирмы Apple, особенно учитывая названия вроде «iPad» и «New iPad», но это не означает что это rocket science и нельзя спросить консультанта в магазине.
К тому же, Project Ara не стремиться захватить весь мир — вот так и сразу. Для начала это способ продать еще один телефон тем, у кого их уже три и кто поклялся впредь покупать только дешевые китайские телефоны, потому что устал от реального отсутствия инноваций у «брендов».
замотано изолентойзалито высокопрочным компаундом. По крайней мере, это то, что они хотят сделать. Посмотрим, лифт в космос они уже строили…