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

Вам не кажется, что еслиб было так, то 90% техники сегодня было б не с гуем, а командной строкой?? Подумайте еще раз, создается впечатление, что вы живете в своем мире конца 80х на XT или AT286.
ЗЫ. Кстати, в так вам ненавистной винде командная строка тоже есть и сам иногда пользуюсь ей и bat-файлами...

Тема свелась в холивару ртос\не ртом гуй/не гуй.
А про, собственно, ГЛАВНУЮ причину сложности (так сказать, "источник сложности") все забыли

Перепробовал разные варианты. Скольки-то там ядерный смартфон лежит без дела, а компактный джавафон прижился.


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


Ну я продавал. Человеку было нужно, через конфиг-файлы у меня все было готово, GUI front-end городить долго и дороже. Заказчика устроил мой вариант.


Думаю, 90% пользователей GUI в силу разных обстоятельств даже не пытались серьезно работать в командной строке и сравнивать производительности CLI и GUI.


BAT-файлы, конечно, вещь, но с командной строкой NIX-систем это сравнить невозможно.

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

И самое главное - даже и не будут пытаться..
ЗЫ. какая командная строка, если сейчас тенденция программы "писать" путем тыканья в кнопки и "галочки", вот уж где я не согласен с гуем, так это в программировании, ибо создать граф. форму и растыкать виджеты мышкой - это удобно, но программу писать - это уж клавиатура и текстовый редактор, конечно, с подсветкой синтаксиса, разумеется..

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

Вот поэтому если делать только для своего потребления, получается довольно просто: ни с GUI не надо заморачиваться, ни документацию бешеную писать. Да даже можно баги не исправлять, зная о них.

P.S. Насчет GUI я уже последние лет 5-6 использую веб-морды для всего и вся (в рамках разумного, конечно; если через веб-морду нельзя, делаю какой-нибудь элементарный просмотрщик картинок на openGL или устраиваю конвейер). Повсеместная поддержка браузерами вебсокетов добавила удобства: теперь запросы воистину стали асинхронными и нет нужды чрезмерно нагружать линию поллингами по 10-30 раз в секунду! Остается только проблема с трансляцией видео: НЯЗ, до сих пор ничего, кроме mjpeg'ов (а то и вообще обновления картинки по таймеру), не придумали. Я пробовал через вебсокеты работать — очень медленно получается, т.к. нужно в base64 изображение передавать и жабоскриптом декодировать.
Возможно, следующая реализация вебсокетов будет поддерживать передачу бинарных файлов, а браузеры позволят эти файлы непосредственно отображать. Ну или хотя бы браузеры перестанут течь при приеме mjpeg'ов. И будет счастье.

>Главная причина сложности любой программы — сам программист, который пытается из нее невесть что >универсальное сделать.

Вы давно из песочницы вылезли? Полагаю, что и не вылезали.

Программа - это данные + алгоритмы, как сказал классик.
Данные - это физические параметры, систематизированные (структурированные) наилучшим способом для конкретной задачи.
Алгоритмы - это приближение к физической реальности нашего способа установления взаимосвязей.

Все это, в совокупности, определяет сложность моделирования физического мира через призму нашего примерного описания/понимания его.

Физические параметры какой-либо сущности "живут" без участия какого-либо программиста, математика, физика.
Алгоритмы, как приближение описательного процесса физики явлений - суть нашего недопонимания физики/информатики.

Оч. простая реализация алгоритма X на java - из нумерологии.
Сообразите, что да как:

Arrays.fill(isP, true);
isP[1] = false;
for (int i=2; i*i < N; i++)
if (isP[i])
for (int j=i*i; j < N; j+=i)
isP[j] = false;

Вот это пять!

Ну это же зависит только от того, какую продукцию вы производите Сложно представить себе мультиметр, логический анализатор или осциллограф без GUI, а только лишь с командной строкой. С другой стороны конфигурировать линукс через граф интерфейс действительно не очень производительно.


Нет! Здесь как раз тоже удобно форму описать, используя API графической библиотеки. Это оперативнее по той же причине, которую вы назвали выше, говоря о командной строке.

А пайпы на что? Зачем мучиться с gui, если можно через пайп в gnuplot данные передавать? И будет наглядное отображение. Аналогично с логанализатором: сохраняем данные в файл, потом требующийся кусок рисуем гнуплотом, а на выход выдаем анализ по соответствующему протоколу.

GUI на все случаи жизни — неправильный подход. Неюниксвейный. UNIX-way — это одна утилита под одну задачу. Объединяем толпу утилит в конвейер, и получаем счастье. Мелкомягкие же придумали плодить сущности. В итоге в каждой программе свой GUI, своя проверка правописания, своя подсветка синтаксиса, свои виджетобиблиотеки и т.д., и т.п.

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


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

Нет таких инструментов. Физикам самим приходится становиться программистами.
Скажем, у нас типичный астрофизик — это "все в одном": и слесарь (надо же новое оборудование до ума доводить), и электронщик (как без этого управлять прибором?), и программист (как низкоуровневый — для систем управления — так и чуть повыше, для работы с прибором и обработки данных), и оптик (нужно же рассчитать новый прибор), и конструктор (кто еще нарисует чертежи для изготовления?) и много чего еще. И уж потом он, наконец, может написать статью ☺

А скорость отображения? А оптимален ли gnuplot для такой задачи? Осцилл ведь может и не только в ждущем режиме работать, но и отображать данные в "реалтаме". А управлять им как через gnupolot? Или по ALT+TAB переключаться в консоль, там набирать команду для перключения осцилла в нужный режим, и возвращаться в gnuplot?

Снова опасаюсь за быстродействие.

Ну так вы ратовали за CLI. Теперь допускаете и GUI, ведь gnuplot - это тоже gui.

Решето Эратосфена? Эффективно? Ну-ну...


Тогда поищем то, что умеет в реальном времени графики строить. Простейший способ — веб-морда с гугловской приблудой для построения графиков в SVG или webGL. Данные передавать через вебсокет.
Ъ?

Нормально там все будет. Это же уже не рилтайм, а оффлайн. Как в saleae анализ уже принятого пакета.

А что, есть вариант посмотреть изображение в командной строке? (да, есть: cacalib, но это же убожество!).
Я и говорил, что GUI нужен для не очень большого круга вещей, картинки тоже упоминал.

Не тратьте своё время, коллега


Да, всех пора забанить

Какая тема, такое и содержание. В стиле, "как писать хорошие книги?"

Просто Эдди, вы ленив, как не знаю кто.

Чтобы сделать своё GUI используете аж 5..6 языков и все из командной строки в строчном редакторе: C-и, какой-нить Bash, JavaScript, HTML, CSS, PHP, не удивлюсь если еще Adobe Flash прихватываете и Python
Это при том, что в вашей конторе ваши GUI смотрит один-два человека на вполне известном оборудовании скорее всего с Windows.

Вот она, ядрёная сложность в полном своем цвете!

А лень ваша в том, что не удосужлись освоить RAD инструменты. Под линуксами их конечно не найти.
Большинство embedded программистов всё пишут на одном C/C++ c RAD инструментами и гораздо производительнее вас в плане GUI и пользовательского интерфейса.

Ну так какая разница: делать вебморду (а её все равно придётся делать, что-то править, что-то оптимизировать), или делать си++морду? По мне так второй способ универсальный: можно использовать не только там, где есть ось с вебсервером. Вот если я делаю тот же мультиметр, там мне что, поднимать линукс (виндовс, куэникс) на подходящем камне? Ставить веб-сервер. Нет, я возьму cortex-m0, возьму жк дисплей 12864 и сделаю на нём. И это будет простая бюджетная модель.


Да мне уже просто интересно)


А я его подход вообще не понимаю: с одной стороны он говорит, что ОСРВ использовать не нужно, свои мордочки писать не нужно. С другой стороны он предлагает использовать веб-интерфейс + поднятие веб-сервера там, где можно обойтись меньшими ресурсами. Т.е. если следовать его логике, то все камни без MMU идут боком, т.к. годятся только для командной строки

Очень большая: веб-морда пишется элементарно. А на С/С++ нужно очень долго корпеть с сигналами-слотами. Слишком уж!..

Уж поставить и сконфигурировать по-минимуму NGINX — дело 10 минут! Т

И при чем здесь GUI? LED-экранчик или жк-дисплей, отображающие текст, это -- GUI? ну-ну...

ЧЕГООО? Невозможно обойтись ресурсами меньше, чем веб-морда (естественно, имею в виду ПК, на микроконтроллерах, ясен пень, веб-морда — тот еще геморрой).

А что, есть камни без MMU, на которых иксы можно поднять?

Пример в студию!

Это субъективно. Причём без всяких смайлов.

Кнопки, меню, чек-боксы... продолжать? Почему вы только текст видите на таких экранах вас надо спросить.

Невозможно, потому что не пробовали. За веб-мордой скрывается сервер, браузер, сеть (если машины разные). И это меньшие ресурсы? Троллите, однако.

Вам уже говорили про ucLinux. Однако GUI не одними иксами жив.

Естественно. Кому-то потратить неделю на клепание гуи — элементарно, мне же проще за день набросать веб-морду, чем в этом диком потоке API разбираться.
Тем паче, что Qt, что GTK мне совершенно не нравятся. Нужен нормальный GUI тулкит, чтобы не приходилось в документации тонуть по элементарным вещам.

В данном случае правильной была бы все-таки аналогия с CLI в стиле ncurses, нежели GUI. Разве что у ncurses картинок нет... В любом случае, это не GUI в полном смысле слова. И обслуживается это намного проще, чем форточка с кучей окон, ползунков и прочей...

Потому что только текст имеет значение. Остальное — ненужные украшения без которых легко обойтись (кроме разве что построения всяких графиков, но это уже узкоспециализированные решения вроде осциллографов).

И все это есть на любом компьютере. А вот в случае standalone GUI все намного печальней: юзверю как минимум придется ставить весь зоопарк используемых вами тулкитов и библиотек. Одни только культи столько тянут — мама, не горюй! Я бы с удовольствием без них обошелся, но, увы, очень много полезных приложений зачем-то на Qt написано. Жаль.

Без иксов остается только фреймбуфер. Натянуть на фреймбуфер тот же GTK или Qt — та еще задачка…

Вы вообще о чём? Вы видели исходные коды этих графических систем (используемых в embedded)? Используются реальные шрифты (Times New Roman, Segoe...), картинки на иконках. Ах да, картинки же это лишнее. А шрифты... достаточно одного, двух в стиле DOS.

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

Вы никогда не задумывались, что людям свойственна тяга к прекрасному? Я имею в виду следующее: да, можно каждый день кушать армейский паёк, и жить. Но я предпочитаю и красную рыбку, и сервелатик, и тортик поесть. Можно и в палатке жить, обойтись без квартиры, хотябы летом, но вы же не в палатке живёте. Вы можете делать что угодно для себя. Но если будете делать для людей, то придётся учитывать их интересы.

На моём нет вебсервера и ставить не собираюсь.

Простите за резкость, но это враньё. Вы можете слинковать либы статически.

А затем, что я как пользователь, хочу поставить прогу (желательно portable, если речь о винде) и работать. а не ставить дополнительно веб-сервер.

Какие иксы, какой фреймбуфер? Ау.... кроме линукса (я даже не о винде) есть и другая жизнь.

Извините, коллега - это чушь.
Сложность программы ( а это моделирование некоей реальности ) как раз и определяется сложностью приближения к ней, а отнюдь не качеством мозгов специалиста.
Поэтому и если "простой, как веник" программист не в состояние описать алгоритм для расчета закона Ома - так это не сложность программы, а отсутствие извилин у "спеша".
Если же Вы о том, что в мире наблюдается регресс и мы очень скоро вернемся к обезьянам, таки да - тут я соглашусь, оно и так уже видно.

Например.

Нет. Наплевать.

Если им не понравится, пусть найдут дурака, который сделает со свистоперделками ☺

Дык, ясен пень: вы ж не пишете ничего, связанного с веб... А у меня и просто утилитки есть, которые могут разные полезные данные выводить (JSON, raw text) при обращении на определенный порт. Можно в браузере посмотреть, можно curl'ом или wget'ом...
И вообще, мне нравится клиент-серверная архитектура, чтобы не заморачиваться с кроссплатформенностью.

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

И опять полное отсутствие понимания удобства работы.

Нет, другой жизни нет ☺

Уважаемый, за языком следите. Не первый раз кроме здоровой аргументации переходите на оскорбительные слова и термины. Видимо видите в других своё отражение. С этого момента считаю, что продолжать дискуссию абсолютно бессмысленно.

haker_fox, а как еще назвать тех, кто вместо того, чтобы системными динамическими библиотеками пользоваться, линкует все статически? И так чуть ли не каждый. В итоге загрузишь десяток программ — бац, и 2ГБ оперативы как не бывало (а то и больше отожрет).

В том-то и есть еще один недостаток проприетарщины: в попытках как можно сильней сныкать свой код и как можно меньше ресурсов тратить на поддержку, они стараются не использовать системных библиотек.
Ну и еще один недостаток — отсутствие репозитория с софтом. Пользователю просто неоткуда обновить все актуальные библиотеки, так и сидит со старьем.

Либо это такой толстый троллинг, либо человек "варится в своем соку" уже очень длительное время.

Вас, товарищи вендузятники, троллить бесполезно. Никакого удовольствия. Хоть бы задумались над тем, что говорю. И нашли, где вы не правы!

Да причем тут это. Просто на винде, есть много удобных программ для написания софта, тот же IAR, например, которым сам пользуюсь, чтоб не разгребать непонятно как настроенные гцц с эклипсами, openocd и т.п. Здесь все в одном и работает без бубна. А это очень важно, т.к. хочу, чтоб 90% времени у меня уходило собственно на программирование, а не изучение этой мозаики из програм мейкфайлов и прочего. Удобство прежде всего.

Ну так у вас одни задачи, у меня другие. Здесь я пытался в реальном времени через "малинку" работать. Но оказалось, что она слишком тупит для USB'шного фреймграббера и как обработчик видео ее использовать не получится.
В скором времени буду делать систему термомониторинга. Вот там уж придется поизвращаться: хоть данные и медленно изменяются, но для их визуализации точно придется webGL задействовать. SVG вряд ли поможет построить картину распределения температур в пространстве.

Естественно, все вещи, которые должны работать с кроссплатформенными клиентами, я делаю с использованием веб-морд, потому как я не ССЗБ, чтобы standalone-приложения клепать под все известные операционки! А браузер есть везде.
У нас уже широко применяется практика по управлению малым телескопом через веб-морду (автор не я, если что). Довольно удобно: в подкупольное заходишь, и можно с планшета припарковать телескоп, чтобы оборудование поменять или обслужить.
Вся низкоуровневщина, понятное дело, пишется под линуксом (здесь нет ненормальных, которые будут дорогое оборудование из-под мастдайки крутить), а уж что там у клиента — совершенно наплевать.

Мда... теперь понятно, почему в российскую науку вбухивают огромные деньги, а результатов мало. Еще и Линукс у товарища наверняка фриварный, а не серьезный пакет типа Red Hat.

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

Чушь-то какая! Если узнаю о уязвимости в вебсокетах или CGI, просто обновлюсь.

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

Самопальный, ясен пень. Не покупать же!

Еще один бред сивого мерина!


Черт, что я здесь делаю в этом болоте совершенно неграмотных людей?

Я смотрю, здесь в основном настолько закоренелые вендузятники, что у них уже и мозг в другую сторону думать не может. GUI им обязательно, мышь, проприетарщина...

Воу! Значит, вешать фреймграббер на "малину" - грамотно. Ок. Следовало его на AVR повесить с совтовым USB, ведь так дешевле


Плохо смотрите, телескоп протрите . Тут не "вендузятники", а инженеры. В задачу инженера входит: а) решить проблему, б) получить от этого удовольствие, в) заработать деньги.
А уж каким способом решать, использовать Windows, Linux или другую ОС, это уже не важно. Инженер не должен испытывать ненависти к "мастдайке" или "проприетарщине", ведь это всего лишь инструменты для решения задач, он вправе выбрать подходящий.

Я вам открою секрет. Разрабатывать красивое, быстродействующее и грамотное ПО под Windows (и даже кроссплатформенное) очень дешево: 1) $20 за OEM лиценизию для Windows 7 Professional на ebay, 2) Microsoft Visual Studio 2015 Community Edition - она совершенно бесплатна. Откройте для себя мир профессионального software engineering, отличной документации (MSDN) и примеров.

- Да ты не уймёшься! (с). Эдди, я действительно не понимаю, что Вы делаете в этой теме, если не на Форуме. Сам не программист, но с безапелляционной категоричностью и агрессивным хамством вешаете здесь ярлыки и оскорбляете программистов. Ваш лексикон и уровень ведения дискуссии напомнил мне "младшего научного сотрудника" из "Джентельменов удачи".
Даже совестно за науку.
Но раз моё предложение добровольно снизить пыл не возымело действия, отправляю на недельку в баню принудительно.

Это проявление сложности, а не причина.


"Уже горячее"©
Программа должна сама себя контролировать, т.е. состоять из "умных" частей, следящих друг за другом и взаимодействующих между собой по определенным принципам, и даже модифицирующих код друг друга.
В этом случае мы получим эффект, обратный тому. что сейчас наблюдаем.
Т.е. с увеличением объема кода программой будет становиться не сложней, а ПРОЩЕ управлять. Потому что части будут становится все более и более "умными" и будут помогать программисту писать. Это примерно как если ты разжигаешь костер и щепок мало, любое дуновение ветерка может его задуть, а когда ты уже накидал достаточное кол-во дров и они разгорелись, то уже ничто не сможет затушить твой костер.


Дело в том, что программирование развивается в сторону "визуальности".
И наивно спорить с этим очевидным фактом.
А почему?
А потому что мозг у человека так устроен, что ему так проще работать, когда все наглядно, все на виду. Когда объекты и зависимости между ними, видимые, а не подразумеваемые.
И при этом меньше вероятность совершить ошибку. А когда у тебя только черный экран и клава, а вся картина в голове - то вероятность чего-то не увидеть возрастает.
Системы без ГУИ это уже анахронизм.

Скоро вообще код будут не из символов набивать (потому что это слишком медленно и недостойно человека), а код будут РИСОВАТЬ. Грубыми мазками.
А умный компилятор будет все это дело переводить в исполняемый код. Только так можно РАДИКАЛЬНО увеличить производительность труда программиста и сократить число ошибок.

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

Троллите, дорогой

Для меня и тогда и сейчас, главное:
- решить проблему;
- получить от этого удовольствие;
- получить удовольствие от вознаграждения ( от кого и какое - не так уж и важно ).

Не согласен.
Вы вообще знаете в чем заключается работа инженера?
"В удовлетворении СВОЕГО ЛИЧНОГО любопытства за счет работодателя"©
Т.е. на первом месте "удовольствие от процесса", а не деньги.
Вы же не пойдете в дворники чиста из-за денег?

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

Тю, это не скоро, а прямо сейчас уже делают. Причина также в том, что далеко не все алгоритмисты вообще умеют кодировать на нужном языке. Например, ты знаешь, как описать нужный алгоритм на бейсике или питоне, но, блин, на реальной железяке он должен исполняться в реальном времени, да еще в сто раз быстрее. Интерпретатор туда не засунешь. Остается только нанимать инженера- кодера, который перепишет нужный алгоритм на Си... или переходить на автоматическую генерацию кода.
Многостаночники в данной теме не понимают, что не всегда тот, кто придумывает алгоритмы, также их и кодирует. Они привыкли все держать в голове. Например, у нас на фирме есть гений по силовой электронике и электротехнике, который заткнет за пояс любого здесь по теории управления инверторами, но он нифига не программист, а знает только матлаб. Благодаря автоматической генерации кода мы смогли реализовать немало его идей в железе, в то время как при традиционном подходе отладка занимала столько времени, что программисты просто сдавались. Причина - они вообще не понимали, как данный им алгоритм должен работать, так как не были специалистами в силовой электронике.

Полностью с вами согласен. Главное любить это дело, а деньги придут. Всегда относился с сочувствием к коллегам, которые видели в этом только обязанность...

Господа, мне эту тему в "Общение" переносить? Причём тут деньги, удовольствие, порядок жизненных приоритетов и прочая лирика? Помогите автору писать программы.

уже можно, и даже не интерпретатор нужно засовывать, а описание процесса, графическое, естественно, вместе с компилятором

Подбавим конструктива . Там чувак довольно интересно топит за новые подходы в программировании контроллеров. Так что бы резко стало проще и при этом перестало быть блокирующим. Перекликается с местным фанатом из топика SST. Но опять же без опенсорсного кода. Но то что на слайдиках вкусно, красиво и в целом звучит довольно здраво. Я б такой фреймворк использовал бы.

великий и могучий русский язык. Топит в смысле "уничтожает" или "предлагает" (от top).

А я думал, что это от слова "топить", в смысле, дров подбрасывать

ОФФ. Эх, Эдика забанили, теперь тема заглохнет. А у меня ещё попкорна навалом))

Запись-то посмотрели? Стили речи бывают разными что бы отразить эмоциональное отношение к теме разговора. К примеру избыток лексики не относящейся к деловой может выделяет некоторую ироничность к объекту (напирмер за отсутсвие репозитория с кодом демонстрирующего его идеи) несмотря на то что содержание всё же рассматривается как заслуживающее внимания. А язык и вправду могуч, только вот порой не так как его пытаются упихнуть в свою точку мнения. Ваш, с наилучшими пожеланиями.

Развлекались, значится

Запись посмотрел именно из-за того, что не понятна была Ваша оценка (положительная или отрицательная). Идея интересная, но отсутствие кода вызывает некий скепсис. Было бы интересно сравнить два полностью собранных варианта проекта (классический и предлагаемый) из доклада, но этого не увидел.
Стараюсь сам писать грамотно (орфографически и стилистически) и тешу себя надеждой, что у других подобные стремления . Безграмотно написанное сообщение тяжело воспринимать, на мой взгяд, это неуважение к аудитории для которой сообщение предназначено.

Без нормальных примеров реализации сложно судить. Обычно такие изобретатели сводят фреймворк или "подход" к тестированию на примерах мигания светодиодом или настройки абстрактной периферии типа uart, без живых примеров реальных систем. Презентацию досмотрел с трудом из-за постоянного "right" после каждого предложения

Он теперь ТУТ жгёт