Комментарии 58
Жесть, 256кб.
Я сильно впечатлен работой Оракла.
Я сильно впечатлен работой Оракла.
35$ многовато
Это девелоперская плата, сам MCU стоит меньше 10$. Но суть от этого не меняется. Впихнуться в такое маленькое устройство было действительно непросто. Разработчики сломали немало копий, но добились своего.
Не понятно зачем нужны теперь эти подвиги.
Всегда будут находиться области, где самый совершенный и современный набор инструментов не подходит, а нужна какая-нибудь хитрость.
С другой стороны — в космос раньше брали (может и сейчас даже берут) консервы в обычных жестяных банках. Дешевле оказалось залить в ракету лишние сто литров горючего, чем строить технологическую линию по производству «более легкой космической упаковки».
Где применение j2me? В банкоматах ставят windows. В телефоны android. На ноутбуки макос. На МКС? Но зачем экономить на спичках — проще нарастить солнечную панель и доставить оперативку. Может быть в каких-нибудь детских игрушках J2ME найдет свою новую инкарнацию? Ой, сомневаюсь…
Закопайте стюардессу.
С другой стороны — в космос раньше брали (может и сейчас даже берут) консервы в обычных жестяных банках. Дешевле оказалось залить в ракету лишние сто литров горючего, чем строить технологическую линию по производству «более легкой космической упаковки».
Где применение j2me? В банкоматах ставят windows. В телефоны android. На ноутбуки макос. На МКС? Но зачем экономить на спичках — проще нарастить солнечную панель и доставить оперативку. Может быть в каких-нибудь детских игрушках J2ME найдет свою новую инкарнацию? Ой, сомневаюсь…
Закопайте стюардессу.
Gemalto и Telit, две компании, которые занимают ~80% рынка беспроводных модулей 3G. Gemalto уже 2 года выпускают модули с Java ME Embedded. Модули эти используются и в банкоматах тоже. Java ME Embedded находит сейчас своих пользователей в самых разных отраслях. Автомобилестроение, медицина, умные дома. Везде, где требуется сбор данных, их предварительная обработка и безопасная передача в Облако.
А мне вот грустно, что J2ME не продолжила развиваться на мобильной платформе и сейчас вот лишь идёт вялотекущий процесс в сфере микроконтроллеров. Если включить фантазию и представить себе смартфон на J2ME как прямую эволюцию последних ява-мобильников — у такого устройства было бы немало плюсов. Энергопотребление, требовательность к ресурсам, жёсткая системная политика в отношении доступа приложений к автозапуску/сети/камере и пр., никаких незакрываемых процессов в фоне и так далее.
Ну есть ещё много вещей не требующих гигабайтов и гигагерцов, где может пригодиться j2me. Ну например, навскидку — бытовой кондиционер, погодная станция, контроллеры всевозможных двигателей, насосов, различные сигнализации и тд.
В сберовских терминалах на кассах супермаркета, в которые карту вставляешь
в блакбери java есть
цена все ещё имеет значение в Embedded мире
истересно, сколько ест рантайм. Т.е. сколько остается, собственно, приложению =) И сравнить бы с .Net Micro Framework
на netmf.ru написано:
на netmf.ru написано:
Достаточно сказать, что минимальный размер загрузочного модуля .NET Micro Framework составляет 250 Кб.… Кроме того, минимальный объём оперативной памяти микроконтроллера, работающего под управлением .NET MF составляет всего 64 Кб.
Runtime занимает меньше 185 KB, т.е. свободного хипа остаётся больше 60KB
Напоминает Squawk virtual machine на stm32. Встроенной памяти мало и народ подключал внешние модули, только чтобы jvm с hello world запустить
А вот на SunSPOT'ах Squawk бегал отлично. Памяти мне хватало с лихвой.
Да и stm32 настолько широкая линейка. От F0 до F7 и это только F линейка. Причём там есть такие MCU, у которых 2MB Flash и 256KB RAM на борту, что уже больше чем у описанной в посте K64 от Freescale.
Да и stm32 настолько широкая линейка. От F0 до F7 и это только F линейка. Причём там есть такие MCU, у которых 2MB Flash и 256KB RAM на борту, что уже больше чем у описанной в посте K64 от Freescale.
Есть одно отличие — jvm в статье и Squawk это разные виртуальные машины java.
Большая часть самого Squawk была написана на java…
MCU с большим объемом RAM памяти и FLASH а так же более высокими частотами, встроенным FPU и т.п. по стоимости приближаются к Allwinner A10/13 и SOC на MIPS 74Kc. А там уже полноценный linux, обычная java и т.п. Да и лицензии на openjdk не нужны
Какой тогда смысл в таких извращениях как bare metal jvm!?
Если экономим на милливатах, то java тем более лишняя…
Большая часть самого Squawk была написана на java…
MCU с большим объемом RAM памяти и FLASH а так же более высокими частотами, встроенным FPU и т.п. по стоимости приближаются к Allwinner A10/13 и SOC на MIPS 74Kc. А там уже полноценный linux, обычная java и т.п. Да и лицензии на openjdk не нужны
Какой тогда смысл в таких извращениях как bare metal jvm!?
Если экономим на милливатах, то java тем более лишняя…
Ну начнём с того, что для нормальной работы Linux + openJDK на AllWinner A10 нужна не хилая конфигурация, которая может стоить не дёшево.
Вы запускали openJDK на Raspberry PI с Raspbian?
По поводу лицензии, можно купить модуль от Gemalto со встроенной Java ME Embedded и использовать в ваших проектах. Это коммерческая платформа со всеми вытекающими.
По поводу милливатов, Java ME Embedded включает API для Power Management. Да и в принципе, можно сделать JVM, чтобы она работала энергоэффективно, а можно нативное приложение написать не энергоэффективно. ИМХО, JVM тут может жить.
По поводу Java on a bare metal. Если у вас конечное встриваемое устройство, на котором должна работать ваша прошивка, то зачем вам оверхед в виде операционной системы распределения времени с громадным функционалом? Особенно если Java машина устраивает вашим задачам.
Вы запускали openJDK на Raspberry PI с Raspbian?
По поводу лицензии, можно купить модуль от Gemalto со встроенной Java ME Embedded и использовать в ваших проектах. Это коммерческая платформа со всеми вытекающими.
По поводу милливатов, Java ME Embedded включает API для Power Management. Да и в принципе, можно сделать JVM, чтобы она работала энергоэффективно, а можно нативное приложение написать не энергоэффективно. ИМХО, JVM тут может жить.
По поводу Java on a bare metal. Если у вас конечное встриваемое устройство, на котором должна работать ваша прошивка, то зачем вам оверхед в виде операционной системы распределения времени с громадным функционалом? Особенно если Java машина устраивает вашим задачам.
Ну начнём с того, что для нормальной работы Linux + openJDK на AllWinner A10 нужна не хилая конфигурация, которая может стоить не дёшево.
Это разовые расходы на всю партию, а лицензии на Java ME Embedded на каждое устройство…
Вы запускали openJDK на Raspberry PI с Raspbian?
Нет, но я запускал jamvm на mips платформе под openwrt.
По поводу милливатов, Java ME Embedded включает API для Power Management. Да и в принципе, можно сделать JVM, чтобы она работала энергоэффективно, а можно нативное приложение написать не энергоэффективно. ИМХО, JVM тут может жить.
JIT, GC-то ведь никуда не деть! В любом случае, jvm упрощает работу разработчику, но за магию платит аппаратное обеспечение временем выполнения и памятью…
По поводу Java on a bare metal. Если у вас конечное встриваемое устройство, на котором должна работать ваша прошивка, то зачем вам оверхед в виде операционной системы распределения времени с громадным функционалом? Особенно если Java машина устраивает вашим задачам.
Если нужна детерменированность, то java доступна только с извращениями. А полноценная ОС может потребоваться, если нужны большинство из функций уже в ней реализованных и абстрагирование от аппаратного обеспечения.
В SunSPOT как бы и частоты выше и пямяти достаточно.
Its first processor board included an ARM architecture 32 bit CPU with ARM920T core running at 180 MHz. It had 512 KB RAM and 4 MB flash memory. A 2.4 GHz IEEE 802.15.4 radio had an integrated antenna and a USB interface was included
Its first processor board included an ARM architecture 32 bit CPU with ARM920T core running at 180 MHz. It had 512 KB RAM and 4 MB flash memory. A 2.4 GHz IEEE 802.15.4 radio had an integrated antenna and a USB interface was included
А как там дела с беззнаковыми типами? Мне слабо представляется разработка под микроконтроллеры без них.
А какие проблемы? Если размер числовых типов вам известен, то отсутствие беззнакового типа в жаве вас не должно напрячь.
Ну например чтобы производить арифметические действия придется использовать больше памяти, постоянно конвертировать, следить за переполнением, помнить об операторе >>> и т.п. Видел в некоторых библиотеках попытки формализовать все это, вынести типовые операции в статические методы.
Погуглив, обнаружил что в java 8 добавили такие методы, что радует!
Погуглив, обнаружил что в java 8 добавили такие методы, что радует!
И самое интересное, что в java me embedded 8 как раз таки нету этих методов:)
Не понимаю, что вы имеете в виду. Целые числа в машинном представлении — это поля. И поле над числами со знаком подобно полю над числами без знака. Так что о каких накладных расходах может идти речь, если операций всего две: сложение и умножение. Не могли бы вы привести пример, который наглядно бы продемонстрировал некомфортную работу в отсутствии беззнаковых чисел? (деление одной битовой маски флагов на другую битовую маску не предлагайте — это изврат, а операция беззнакового сдвига имеется)
Возможно, в языке стоило бы иметь операции циклического сдвига или еще какие-нибудь, что есть в ассемблерах — поиск первого ненулевого бита например. Но это тема для разговора про Java в целом, а не про Java ME
Возможно, в языке стоило бы иметь операции циклического сдвига или еще какие-нибудь, что есть в ассемблерах — поиск первого ненулевого бита например. Но это тема для разговора про Java в целом, а не про Java ME
Немного разобравшись в теме стало понятно, что операции сложения и умножения в java действительно выполняются корректно как для знакового так и для беззнакового представления числа, так как используется дополнительный код. Это отнюдь не очевидно.
Все же помимо умножения и сложения есть еще деление и остаток от деления, не понимаю почему вы назвали это извратом, мы ведь не только о маске флагов говорим, мы можем работать со значением счетчика например.
Еще есть сравнение, преобразование в строку, которые тоже не одинаково выполняются для знакового и беззнакового представлений, да мало ли какие еще операции можно придумать. Навскидку — задание длины массива, размера буфера.
Не зря ведь в java se 8 добавили методы по ссылке выше.
Если java считает число знаковым, а разработчик беззнаковым — надо думать над каждой операцией, правильно она сработает или нет.
Самый безопасный способ — преобразовать в переменную более широкого знакового типа, что влечет больший расход памяти, но избавляет от массы других проблем.
Все же помимо умножения и сложения есть еще деление и остаток от деления, не понимаю почему вы назвали это извратом, мы ведь не только о маске флагов говорим, мы можем работать со значением счетчика например.
Еще есть сравнение, преобразование в строку, которые тоже не одинаково выполняются для знакового и беззнакового представлений, да мало ли какие еще операции можно придумать. Навскидку — задание длины массива, размера буфера.
Не зря ведь в java se 8 добавили методы по ссылке выше.
Если java считает число знаковым, а разработчик беззнаковым — надо думать над каждой операцией, правильно она сработает или нет.
Самый безопасный способ — преобразовать в переменную более широкого знакового типа, что влечет больший расход памяти, но избавляет от массы других проблем.
Целые числа в машинном представлении полями не являются, так как можно умножить восьмибитное 2 на восьмибитное 128, получить переполнение (256 не влезет в восемь бит и даст 0). Таким образом, получили, что при таком представлении целых существуют делители нуля: 2*128=0
Так что в машинном представлении целые — в лучшем случае — кольца вычетов по разным модулям. Например, восьмибитные неотрицательные целые — кольцо вычетов по модулю 256. Операция умножения должна здесь трактоваться как многократное сложение.
Делителей нуля в поле быть не может.
Так что в машинном представлении целые — в лучшем случае — кольца вычетов по разным модулям. Например, восьмибитные неотрицательные целые — кольцо вычетов по модулю 256. Операция умножения должна здесь трактоваться как многократное сложение.
Да, перепутал поля с кольцами. Спасибо. Посыл остается тот же самый — работа с знаковыми числами и работа с беззнаковыми числами амбивалентны.
Это просто дело привычки.
У «сишников» возникают разные хитрые вопросы для собеседований — какой тип имеет размер массива? int, unsigned? size_t? Как сравниваются знаковые с беззнаковыми? А если это вычисляемое выражение, в котором перемешаны те и другие значения?
Не стоит заводить «религиозные войны» какой из подходов лучше. Я лишь опять хочу заметить, что правильно написанный код на жаве не будет иметь существеных оверхедов в сравнении с сишным из-за отсутствия беззнаковых типов.
Это просто дело привычки.
У «сишников» возникают разные хитрые вопросы для собеседований — какой тип имеет размер массива? int, unsigned? size_t? Как сравниваются знаковые с беззнаковыми? А если это вычисляемое выражение, в котором перемешаны те и другие значения?
Не стоит заводить «религиозные войны» какой из подходов лучше. Я лишь опять хочу заметить, что правильно написанный код на жаве не будет иметь существеных оверхедов в сравнении с сишным из-за отсутствия беззнаковых типов.
Да всё там отлично со всеми типами данных, описанными в JLS :) Но так как в Java нет беззнаковых типов, то их нет и в Java ME Embedded.
Согласен, что это не очень удобно, но обходимо :)
Согласен, что это не очень удобно, но обходимо :)
JavaScript на контроллерах STM32: Espruino
Раз пошла такая пьянка, то и Lua на MCU работает
Ох уж эти извращенцы!
Жабке и на нормальном компьютере места нет: это говно вообще нигде не нужно!
А тут еще и на микроконтроллер.
Эдакая беговая корова: подкованная и оседланная.
Жабке и на нормальном компьютере места нет: это говно вообще нигде не нужно!
А тут еще и на микроконтроллер.
Эдакая беговая корова: подкованная и оседланная.
Конечно, на ассемблере можно написать все что угодно, но жизнь слишком коротка. :)
Си — не, не слышал?
Попробуйте на си перепрошить тысячи устройств разом.
Вы так непонятно выразились, что вас не поняли.
Дело скорее в том, что для каждой новой процессорной архитектуры вам потребуется свой инструментарий — всякие там компиляторы, линкеры, дебаггеры, профайлеры…
А жава-программа будет в принципе одинаково работать что на одном процессоре, что на другом — достаточно портировать на новый процессор *только* виртуальную жава-машину! Вы делаете новый телефон, на котором, допустим, процессор не 64, а 85-разрядный (пример так себе) с другой системой команд и адресацией памяти. Чтобы все существующие программы на си на нем работали — надо их все перекомпилировать и найти ошибки. Чтобы работали все жава-программы — надо только портировать на этот процессор жава-машину.
Дело скорее в том, что для каждой новой процессорной архитектуры вам потребуется свой инструментарий — всякие там компиляторы, линкеры, дебаггеры, профайлеры…
А жава-программа будет в принципе одинаково работать что на одном процессоре, что на другом — достаточно портировать на новый процессор *только* виртуальную жава-машину! Вы делаете новый телефон, на котором, допустим, процессор не 64, а 85-разрядный (пример так себе) с другой системой команд и адресацией памяти. Чтобы все существующие программы на си на нем работали — надо их все перекомпилировать и найти ошибки. Чтобы работали все жава-программы — надо только портировать на этот процессор жава-машину.
Именно. Так же можно подменять ваш код на «горячую» удаленно, что является просто супер плюсом.
Можно даже написать маленький софт, который будет автоматически обновляться с центрального сервера сам.
Можно даже написать маленький софт, который будет автоматически обновляться с центрального сервера сам.
Проблема всех виртуальных машин — производительность, а для микроконтроллеров это очень важно. Наличие сборщика мусора добавляет ещё одну проблему — непредсказуемые задержки в работе кода, что не очень вяжется с realtime-применениями. Java не имеет механизма указателей, а, значит, становится затруднительной реализация эффективных алгоритмов. К тому же, код на Java просто обречён на постоянные выделения памяти в куче, что тоже снижает скорость.
В общем, за портируемость приходится платить — в том числе, и размером рантайма (как его кода, так и потребляемой RAM).
В общем, за портируемость приходится платить — в том числе, и размером рантайма (как его кода, так и потребляемой RAM).
Какое отношение имеет ЯП к перепрошивке устройств?
Мне вот интересно: у ардуринщиков мозгов изначально не было или это им ардуйня мозги разъедает?
А насчет ассемблера — Керниган и Ритчи давным-давно придумали отличный язык программирования высокого уровня. Он настолько прижился, что больше никакой ЯП не способен его затмить. С воистину прелестен!
А безмозглые ардуринщики пусть хоть жабкоскрипт в свои поделки пихают. Лишь бы в ширпотреб эта дрянь не лезла!
А насчет ассемблера — Керниган и Ритчи давным-давно придумали отличный язык программирования высокого уровня. Он настолько прижился, что больше никакой ЯП не способен его затмить. С воистину прелестен!
А безмозглые ардуринщики пусть хоть жабкоскрипт в свои поделки пихают. Лишь бы в ширпотреб эта дрянь не лезла!
А что можно купить аналогично Arduino, чтобы на нём java запускалась? В статье упоминается Freescale K64F с Cortex M4 но в продаже в России я его не нашёл.
Если речь идет о JavaScript:
Из гитхаба Espruino:
2, 3, 4 — вроде как можно найти в любой забегаловке вроде Чип и Дип.
Из гитхаба Espruino:
- Linux — WORKING
- STM32VLDISCOVERY — WORKING — limited memory so some features removed
- STM32F3DISCOVERY — WORKING
- STM32F4DISCOVERY — WORKING
- STM32F429IDISCOVERY — WORKING over serial (A9/A10). No USB and no LCD support
- HY STM32 2.4" — WORKING
- HY STM32 2.8" — WORKING — limited memory so some features removed
- HY STM32 3.2" — WORKING
- Olimexino — WORKING — limited memory so some features removed
- Carambola — WORKING — GPIO via filesystem (no SPI or I2C)
- Raspberry Pi — WORKING — GPIO via filesystem (no SPI or I2C)
- Sony SmartWatch — NOT WORKING — USB VCP support for F2 still needed
- MBed platforms — have not worked for a while — full hardware wrapper still required
- Arduino — has never worked. Used to compile but probably doesn't any more
- LC-TECH STM32F103RBT6 — WORKING, but with some issues (LED inverted logic, BTN needs pullup to work)
2, 3, 4 — вроде как можно найти в любой забегаловке вроде Чип и Дип.
Raspberry Pi — референсная платформа для Java ME Embedded под Linux ARM
Ну что сказать, прогресс не стоит на месте. Если язык C стал когда-то кроссплатформенным ассемблером и упростил переход с одного на новое микроконтроллерное семейство, то Java для встраиваемых еще более упростит разработку. Но конечно не для всех применений это оправдано. Но для определенного сегмента рынка электроники это будет очень хорошим решением с высокой скоростью освоения и скоростью разработки.
Высокая скорость разработки и освоения как правило порождает низкое качество продукта.
Фиг с ним, когда кривой сайт падает, а вот если холодильник вдруг одновременно включит обогрев No-Frost и экспресс-заморозку, он может и немножко сломаться. Если стиральная машинка начнет заливать воду при работающей центрифуге, она тоже может устроить апокалипсец. Таких примеров можно выдать миллион.
Э. Дейкстра, кровный враг бедокодеров и оператора GOTO:
Фиг с ним, когда кривой сайт падает, а вот если холодильник вдруг одновременно включит обогрев No-Frost и экспресс-заморозку, он может и немножко сломаться. Если стиральная машинка начнет заливать воду при работающей центрифуге, она тоже может устроить апокалипсец. Таких примеров можно выдать миллион.
Э. Дейкстра, кровный враг бедокодеров и оператора GOTO:
Многократно предостерегал от попыток превратить разработку программ в некий тривиальный процесс; по его мнению, программирование в сути своей — чрезвычайно сложная научная и инженерная деятельность, и никакие новые методы и инструменты не смогут кардинально изменить это положение — они лишь освобождают программиста от части рутинной работы. Попытки же превратить программирование в простое занятие, доступное каждому, обречены на провал.
Все верно, но мы живем в капиталистическом мире мире и если продукт и важна скорость поступления продукта на рынок. Поэтому новые инструменты с высокой скоростью и освоения становятся более востребованными. Можно создать идеальный продукт, но это неимоверно долгая разработка и очень долгое тестирование. В современных временных темпах это может не выдержать конкуренции. Когда-то разрабатывали на чистом ассемблере для процессоров и микроконтроллеров, но сейчас этот сегмент сократился в пользу языка C. Хотя от этого и идет потеря производительности и эффективность компиляции, но скорость вхождения и скорость разработки увеличиваются. Сейчас часть разработчиков C для части тех же задач уступил место С++. Хотя опять же это потеря производительности и эффективности компиляции. А теперь идет переход к Java, а с другой стороны к Arduino-подобным платформам. Это тоже потеря производительности. Но если представить круговую диаграмму всех разработанных электронных устройств на процессорах и микроконтроллерах. Соотношение там меняется.
Это эволюция.
А в инженерном плане я вас поддерживаю.
Недотестированные продукты сплошь и рядом встречаются. Посмотрите например на планшеты, смартфоны. И машины стиральные и холодильники с багами могут быть. И чем сложнее встроенное ПО тем больше там этих ошибок может быть.
Для этого и существует тестирование. Ну и поэтому некоторым брендом доверяют больше. Ну а потребитель на глючную продукцию все равно находится.
Это эволюция.
А в инженерном плане я вас поддерживаю.
Недотестированные продукты сплошь и рядом встречаются. Посмотрите например на планшеты, смартфоны. И машины стиральные и холодильники с багами могут быть. И чем сложнее встроенное ПО тем больше там этих ошибок может быть.
Для этого и существует тестирование. Ну и поэтому некоторым брендом доверяют больше. Ну а потребитель на глючную продукцию все равно находится.
Тесты помогают обнаружить ошибки, но не гарантируют свободы от них.
Строго формально: никакие тесты не являются доказательством корректности программы (хотя бы потому, что тесты — тоже программы, а значит нужны тесты, потом тесты тестов, потом тесты тестов тестов и так далее).
Именно по этой причине, программы для ответственных областей пишутся с использованием более жестких подходов и формальных доказательств. А встроенные системы — более ответственный продукт.
Поэтому зафлуживание индустрии бедокодерами удручает.
Строго формально: никакие тесты не являются доказательством корректности программы (хотя бы потому, что тесты — тоже программы, а значит нужны тесты, потом тесты тестов, потом тесты тестов тестов и так далее).
Именно по этой причине, программы для ответственных областей пишутся с использованием более жестких подходов и формальных доказательств. А встроенные системы — более ответственный продукт.
Поэтому зафлуживание индустрии бедокодерами удручает.
При создании сложных программных продуктов появление ошибок является обязательным побочным продуктом.
Потому что продукты создаются людьми. Большинство из которых ошибаются.
Если тестирование не делается сразу после разработки его делают потенциальные пользователи продукта,
которые выступают бесплатными тестировщиками.
Без тестирования никуда. Если говорить о реальном рынке.
Подготовка идеального специалиста под конкретную задачу может улучшить положение, но тоже требует времени и денег.
Если специалист хорошо подготовлен, он будет «стоить» дороже. Если такого топового специалиста за те же деньги можно заменить тремя средними и еще нанять трех тестировщиков. Выбор будет не в его пользу.
Команда из шести средних людей будет эффективней. И если человек уйдет его будет кем заменить. Это не нарушит структуру разработки.
К сожалению люди которые разрабатывают электронные устройства больше мотивированы деньгами, а не созданием идеального продукта. И нужны им в коммерческом плане более эффективные системы из людей и программно-аппаратных инструментов. А цель спрос. Недостатки продукта можно скрыть рекламой. В нее сейчас больше денег вкладывают чем собственно в разработку.
Так же сейчас спонсируются, разрабатываются и продаются более удобные инструменты для разработки встраиваемых систем. Их рекламируют и популяризируют. Значит потребление растет. А значит количество т.н. вами «бедокодеров» только увеличится. У этих людей мозги по-другому развиты и ставят другие акценты. Ну я не считаю что это плохо. Просто прогресс идет. Раньше без поисковых систем надо было в библиотеке сидеть, а сейчас можно быстро найти информацию. Упрощение процесса разработки дает больше пространство для творчества, если хорошо сделаны инструменты.
Ну а что-то уйдет в прошлое, как программирование микроконтроллеров на ассемблере (для сложных задач опять же, для порта ОСРВ и сейчас на ассемблере можно написать).
Потому что продукты создаются людьми. Большинство из которых ошибаются.
Если тестирование не делается сразу после разработки его делают потенциальные пользователи продукта,
которые выступают бесплатными тестировщиками.
Без тестирования никуда. Если говорить о реальном рынке.
Подготовка идеального специалиста под конкретную задачу может улучшить положение, но тоже требует времени и денег.
Если специалист хорошо подготовлен, он будет «стоить» дороже. Если такого топового специалиста за те же деньги можно заменить тремя средними и еще нанять трех тестировщиков. Выбор будет не в его пользу.
Команда из шести средних людей будет эффективней. И если человек уйдет его будет кем заменить. Это не нарушит структуру разработки.
К сожалению люди которые разрабатывают электронные устройства больше мотивированы деньгами, а не созданием идеального продукта. И нужны им в коммерческом плане более эффективные системы из людей и программно-аппаратных инструментов. А цель спрос. Недостатки продукта можно скрыть рекламой. В нее сейчас больше денег вкладывают чем собственно в разработку.
Так же сейчас спонсируются, разрабатываются и продаются более удобные инструменты для разработки встраиваемых систем. Их рекламируют и популяризируют. Значит потребление растет. А значит количество т.н. вами «бедокодеров» только увеличится. У этих людей мозги по-другому развиты и ставят другие акценты. Ну я не считаю что это плохо. Просто прогресс идет. Раньше без поисковых систем надо было в библиотеке сидеть, а сейчас можно быстро найти информацию. Упрощение процесса разработки дает больше пространство для творчества, если хорошо сделаны инструменты.
Ну а что-то уйдет в прошлое, как программирование микроконтроллеров на ассемблере (для сложных задач опять же, для порта ОСРВ и сейчас на ассемблере можно написать).
Ну что я могу сказать — все вышесказанное абсолютно верно и отражает действительность.
Со временем тонкое программирование окончательно превратится в искусство для снобов-ценителей. Будет что-то вроде:
-Я закодил мигалку в 24 байта!
-А я закодил в 12 :-)
-А я — в два байта, то есть в одну инструкцию!
-Да ну, у тебя вся память программ исполняется :-|
Со временем тонкое программирование окончательно превратится в искусство для снобов-ценителей. Будет что-то вроде:
-Я закодил мигалку в 24 байта!
-А я закодил в 12 :-)
-А я — в два байта, то есть в одну инструкцию!
-Да ну, у тебя вся память программ исполняется :-|
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Запускаем Java Runtime на 256KB оперативной памяти