Редактировалось 5 раз(а), последний 2021-05-21 06:04:36

Сделанную тобой конфетку(Блочное строительство) не скушаешь пока не вскроешь оболочку и не возьмешь содержимое(подручный материал для шалаша), иначе подавишься

Набрел вот случайно на эту тему.....

За эти годы кое-чего произошло таки. Решил поделиться своими (уже сегодняшними соображениями) про то, какова таки судьба Программирования вообще, и HiAsm в частности.
Ну, скажем, моя сегодняшняя работа.
Меня взяли на работу для создания/организации процесса создания новых изделий на неком предприятии.
Грубо говоря – начальник отдела разработки. Который, несмотря ни на что, не потерял знаний прошлого тысячелетия о том, что такое профессия Инженера.
Это и конструирование, и электроника, и программирование...

И какие же я предъявляю требования к своим программистам (заранее зная, что они не сумеют их выполнить, если я (потому что больше некому) их не научу)

1) Сделанный код должен не только отвечать показателям назначения (грубо говоря - работать). Это всего лишь первое требование.
2) Он должен быть понятен любому – мне, моим работодателям, коллегам программистам. Время вхождения нового человека должно быть разумным (не более недели - для проведения грамотных и безошибочных модификаций/расширений функционала). Увы, но сегодня это не меньше чем полгода. Если автор перед этим год работал.
3) Результирующий код должен быть эффективен. Хотите верьте, хотите - нет: но реальный малопотребляющий Cortex-M3 - это всего лишь 72МГц и 64К встроенного ОЗУ. Есть, конечно, и гигагерцовые камни, и камни с внешним ОЗУ, но нам нужны камни, на которых можно решать real-time задачи. Да и с энергетикой проблемы - не могу себе позволить роскошь, типа 1Вт на камень.
Тут я не виноват - наш потребитель находится в шахте, искробезопасная цепь, длинные расстояния. Просто – именно такова жизнь, даже если это кому-то не нравится.
4) Даже если ты использовал чужой код (например - операционная система, speex-кодек звука, и т.п.), то отвечать деньгами будешь именно ты. А не авторы некого стороннего софта – то, что ты купил этот софт (к примеру), никакого значения иметь не будет.
5) Некоторые real-time характеристики должны быть "доказаны". Бог с ней с "абсолютной математикой" (типа – не все сразу), но должны быть экспериментальные данные значительно более убедительные, чем "я проверил - оно работает".
6) Оно должно работать ВСЕГДА. Добавление этого коротенького слова увеличивает трудозатраты от 3-х до 10 раз. Собственно, это обычное дело в инженерной практике. Сделать нечто, и даже пользоваться потом самому - это одна история. А вот сделать так, чтобы и изготавливали другие, и пользовались другие, а ты про это напрочь забыл – совершенно другая история... Ну не совсем другая – так, всего лишь в те самые 3-10 раз сложнее, не более того.
7) Почти то же самое, что и предыдущий пункт: скорость создания кода не приоритетна. Качество – во много, много раз важнее.

В качестве короткого резюме для этой вводной части: работой Инженера вовсе не является создание некого изделия, но создание некого технологического процесса, который потом самостоятельно будет изготавливать эти изделия. Ну типа: не сделать детальку, а сделать станок, изготавливающий такие детальки. Эдакий метапереход
Собственно говоря, софт становится автоматически деталькой этого «станочка», если он сделан с выполнением вышеозначенных пунктов. А моя лично работа: создать технологический процесс производства таковых «станочков». Типа: метапереход уже второго порядка


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

А дальше начинается самое интересное
Ну то, что почти все это вызвало некоторый шок у моих коллег-подчиненных - это пропустим
К тому, что «работает же!» - вообще никаким аргументом не является, коллеги уже привыкать начинают. Электроников я уже научил рисовать схемы так, чтобы вхождение нового коллеги в тему – не более дня.
((принципы то простые и знакомые: структурирование по объектам, чтобы минимизировать количество взаимосвязей. На одной схеме – 10-20 объектов, не более. Узнаете «брата Колю»? ))

Пока шлифовалась электроника, программисты осваивали камень (STM32F105 – тоже, еще тот фрукт), speex-кодек, работу с сопутствующей электроникой, сочиняли протокол взаимосвязи, делали коды для исследования/наладки этой сопутствующей электроники.
Наступил момент перехода к боевым кодам, а структура уже такова, что начинает потихонечку сыпаться. В том смысле, что введешь изменения в одном месте, а неожиданные последствия (пока еще вполне преодолимые) выясняются уже в другом. Через недельку-другую.
Даю задание: уважаемые коллеги, давайте нарисуем структурную (функциональную – да какую хотите) схему того, что мы пытаемся сотворить. Чтобы мы все (включая работодателей) понимали происходящее, могли предлагать адекватные предложения по изменению функционала, и понимали наши потенциальные возможности.

Опять же, хотите верьте, хотите – нет: самый убежденный Плюшник начинает рисовать после этого квадратики, и соединять их стрелочками и линиями.
Ничего не напоминает
Все это настолько же прекрасно, как и в HiAsm. За исключением семантики нарисованного.

Про семантику квадратиков – понятно. Это также как и у нас: семантика мультика – она определяется вложенной схемой.
А вот с семантикой линий – полный беспредел. Спросишь – получишь длинный разговор с активной жестикуляцией руками. Причем, разные люди, глядя на одну и ту же взаимосвязь, будут говорить совершенно разные слова. Тут HiAsm далеко впереди – никакой неоднозначности.

Активно (хех ) обсудивши все это дело, даю следующее задание коллегам: давайте проведем эксперимент – нарисуем то же самое, но чтобы семантика связей была такой же, как и в HiAsm.
Грубо говоря, чтобы это и была схема в HiAsm. Состоящая из уникальных элементов, коды которых – это и есть задача для программиста, на порядок более простая, чем полная задача. А применяемость в исходной схеме – техническое задание для программиста.

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

Весьма интересно

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

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

Тут так: мне не кажется, что "Редактор блок-схем" -- наше светлое будущее

Начинаю кое-что припоминать
Было оно значит так: ТС набрел на сайт oberoncore.ru, на котором декларируется принадлежность к инженерному программированию (как потом мне стало понятно, термин-то они ввели, а что такое инженерия - понятия не имеют)
И представил там HiAsm. Накинулся на него народ - мама не горюй. Пришлось заступаться, и посбивать несколько спесь с "ученых".
Некоторые потом даже признали "некоторую академичность среды"
И там же кучковался Паронджанов ( с книгой "Как улучшить работу ума") - очень большой теоретик Графического программирования с помощью именно блок-схем.
И этот графический язык, со своими некоторыми правилами, назвал он -- ДРАКОН. И на сайте даже поддерживается редактор именно этих блок-схем, и даже с возможностью генерации кода.

Чем мне не нравится этот подход.
Там разделены императивные и декларативные связи. И визуализированы только императивные.
Т.е., смотришь на схему - и запросто можно не увидеть некоторых подводных камней. Которые обусловлены каким-нибудь конфликтом данных.
И, по словам Паронджанова - "невозможно объединить ужа с ежом"

В общем, я там сказал народу что-то типа того: "... это Вы, ни разу не видевши визуализацию, кидаете все в одну кучку. Мой же вкус уже гораздо тоньше -- у нас же Уж с Ежом прекрасно объединяются в элементе Memory, например. И никаких проблем"

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

А теперь смотрите, я попытаюсь связать свои выводы с изложенными ранее принципами.
Пусть меня интересует, прежде всего, управляемость проекта и его безошибочность (скажем, это будет пункт 2).
Пока что мне известен только один способ достижения безошибочности - структурирование задачи, чтобы каждый логический уровень иерархии был ограничен по объему.
Есть такая гипотеза (никем не опровергнутая), что в схеме из 10 элементов за конечное время разработки можно достигнуть нулевого количества ошибок.
Не 0.1, не 0.01, не 0.0001, а именно 0. Видимо потому, что количество ошибок измеряется целым числом.
И для 10-ти элементов - это не месяц работы... И, пожалуй, даже и не неделя.

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

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

И мое мнение такое, что доработка языка HiAsm значительно более перспективна, чем языка, в котором нельзя скрестить Ежа с Ужом

И хотел бы обратить внимание еще вот на что. Схема, нарисованная в каком то языке предназначена не только для того, чтобы ее компилировать, но и чтобы ее мог прочитать другой (пункт 2).
В профессии Инженера второе не менее важно, чем первое.
А сейчас я рассматриваю крайний случай, совсем непривычный для простого народа: я допускаю, что компилирования вообще нет.
((сделайте паузу, чтобы прошел шок, потом читайте дальше ))
Вовсе не потому, что я противник компиляции. Просто, сначала надо создать язык (потому что сегодняшнего языка HiAsm чуть-чуть не хватает), а потом думать об автоматической компиляции. Естественно, достойной Инженерной практики.
Ну а пока, я намерен обойтись применением человеков-программистов вместо компилятора.

((продолжение следует))

Помню года 3 назад, в процессе поиска "пропавших" пользователей данного ресурса (HiAsm), дабы удостовериться что все живы и здоровы, наткнулся на тему "HiAsm - визуальное конструирование программ" ресурса oberoncore.ru, и обсуждение как раз только начиналось
HiAsm - визуальное конструирование программ

А что, кто-то куда-то пропадал Че-то я такого не помню

nesco, ну как оказалось - нет

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

Одна из моих целей - вскрыть эту причину. И сделать некоторые предложения по преодолению.
Но не все сразу. Подойдем еще

Особенно ТС, где он только не пиарил конструктор, в итоге ушёл учить паскаль и с концами

andrestudio, я тебе один умный вещь скажу, только ты нэ обыжайся

Ты разницу понимаешь между холиваром, и выполнением работы, за которую платят зарплату
Так вот, мне платят зарплату вовсе не за создание некого кода для некого изделия. Зарплату именно за это получают мои подчиненные.
А я -- за то, чтобы проект был управляемым, а результат безошибочным. Меня брали на работу на таких условиях.

Уж не предлагаешь ли ты мне изучить Паскаль, C++, Оберон, или еще какую нибудь скриптовую хрень (типа из функционального программирования)
Для решения именно моей задачи (если не понял задачу -- перечитай на две строки выше)
Потому что иначе уловить смысл твоего поста несколько затруднительно.

Все это ты уже излагал. Где новизна-то


P.S. И, кстати говоря, какие языковые решения я приму на нашем предприятии - так оно и будет.
Даже если бы и ты был у нас кодером (ориентируюсь на аватору).
Есть время для холиваров, а есть и для реальной работы.
За которую платят зарплату

"Светлое будущее" - это вообще-то утопия.