Вынесу это в общий трёп - что б не замусоривать конкретную тему...

Итак, об "алгоритмическом мышлении" - как основе инженерного мышления вообще...

В качестве примера - история, которая приключилась у меня в бытность работы в ОКБ МиГ.

Сначала был создан МиГ-29 - на основе тогдашних технологий, при которых каждый прибор обладал собственными мозгами и связывался с датчиками и исполнительными механизмами индивидуальными проводами, которые могли тянуться от верхушки киля в закабинный отсек и потом обратно.

К концу 70-х сложился проект МиГ-29Э (то есть "электронный").

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

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

Расчётная экономия веса - 900 кг!

ХИНТ: традиционный в авиационных КБ конкурс по экономии веса обещал за 1 кг сэкономленного на борту веса премию в 150 руб!
То есть, такова ценность задуманного технического решения...

Шеф посадил меня - молодого и борзого - за описание ВСЕХ алгоритмов ВСЕХ приборов, находящихся в зоне компетенции нашего отдела.
А это - топливоизмерение, пожарка, управление двигателем. И ещё приличная кучка задачек...

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

Ковырял это полгода. В результате на выходе - четыре тома формата А4 толщиной в ладонь (в длину!).

Хочу акцентироватся на цене ошибки - представляете её?!

Но, собственно, я веду к тому, что произошло дальше - и несколько для меня неожиданно.

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

И вот пара-тройка спецов под руководством шефа разворачивает кучу схем и ползает по ним - ведь приборы не сами по себе: они обмениваются информацией и работают, как Система.

Ну, и вот шеф после очередного такого аврала подходит к мне: ты ж описывал всё в комплексе... Ну ка, давай прокатим через твои писания...

Ага!
Проблема разрешилась через четверть часа!!!!

Все были в полном шоке - и спустя короткое время я стал главным спецом по Системе. Системным интегратором 

Авторитет подскочил ну просто фантастически 

Так к чему это я?
А всё к тому, что я унифицировал всё к одному формату (по требованию тех, кто создавал новый комплекс) - и это позволило найти мощные резервы для развития самолёта в новых проектах.

Иного варианта, чем описывать всё в классическом формате "алгоритма" просто не было - и держать такой объём в голове по определению невозможно.
Моим талмудом я научил пользоваться всех коллег - потому, что это было просто и понятно любому инженеру.

Что характерно - я сделал эту работу безошибочно. То есть, ошибки если и обнаруживались - но на уровне самих первичных приборов.
Я же не переделывал их - я просто формально описывал то, что есть.

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

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

Алгоритм - наше всё!

При этом за пределами топика остался вопрос о генезисе первоначального направления вектора приложения усилий.

"Мужик, я ни х... не понял, что ты мне сказал, ...но ты мне близок, ...ты заговорил, и достучался до сердца" (с)

Напишите клиентскую программу в 22 000 строк высокоуровнего кода с более чем 500 алгоритмами и связями между ними, затем серверную в 40 000 строк, модель виртуального игрового мира, где только в сетевом протоколе 240 команд и столько же алгоритмов обработки информации, потом задумайтесь на каком футбольном поле поместятся все блок-схемы и как ими оперативно пользоваться, ...это не баки заправлять.

Мужики, а в этом топике общение на каком языке ведётся?

Ператрон, с интересом прочел твой рассказ, но саму идею не одобряю. Каждая система должна быть автономна в своей работе и общаться с верхним уровнем ограниченным количеством команд/ответов. Весь вопрос только в границах полномочий. В твоем случае, вероятно, был перекос в другом направлении. Я на военной кафедре изучал еще "решающие усилители" на лампах.

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

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

Цитата:

С теоретиками программирования можно было б согласиться - начни они с первоснов новой отрасли и объяснив природу информации, как феномена.

Но они пошли по пути шаманской практики, коей и является по сю пору "информатика".
И потому доверия их умопостроения не вызывают. Хоть тресни...

Цитата:

Вот сразу и противоречие: "я вижу - но рисую для тех, кто не видит".

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

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

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

Основное распределение ведщущих модальностей примерно таково:
- более половины - кинестетика;
- главная часть оставшейся половины - визуалка;
- остальное - аудиалка.

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

В пику этому, блок-схема_алгоритм опирается на визуальную модальность - которая даже у тех субъектов, которые имеют ведущей кинестетику и аудиалку, развита полноценно.

Блок-схема даёт взгляд на Систему сверху, текстовое структурирование ЯВУ - фокусирует взгляд на нижних уровнях.

ХИНТ: вот пример - к сожалению не полностью удачный - программирования "алгоритмом":


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

ХИНТ: текстовое структурирование, применяемое ныне в ЯВУ, родилось в эпоху чисто текстовых терминальных консолей и АЦПУ.
Это был естественный и нормальный этап эволюции - но программеры застряли на этом уровне, не желая меняться вместе с ИТ-вселенной.

@ kwlw

Да.

Peratron писал(а) 02.02.2015 :: 17:11:04:

В чём? ...что, извините, баран без блок-схемы не видит то, что в коде вижу я? ...я алгоритм виртуально держу в голове, перевожу его сразу в код. Вы - через "посредника", мысль > блок-схема > ЯП. Для того чтобы создавать модуль мне не надо для себя рисовать блок-схему. Если я делаю модуль для кого-то, я напишу сразу код, и потом в мануал блок-схему, и код и блок-схема = следствия, алгоритм в голове = причина.

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

Peratron писал(а) 02.02.2015 :: 17:20:53:

Вообще пример не в тему. Код на высокоуровневом ЯП не есть "список", у него конкретная структура. Достаточно видеть оператор и знать его синтаксис, и в голове сразу появляется то, что Вы можете "положить" в голову только по средствам блок схемы. Вопрос, а как Вы вообще рисуете блок-схему? ...не просто же как рисунок, а потом мозг понимает "о! так это алгоритм какой-то!". Мысль - первична, и она в голове как блок-схема не выглядит. Блок-схема - средство визуализации, для понимания твоего кода кем-то другим.

Peratron писал(а) 02.02.2015 :: 17:31:16:

Именно! ...поэтому промышленность в одном месте, всех пропустили через талмуды, теперь ищут талантливых.

Я ж Вас знаю, Вы будете упираться до последнего, просто переворачивать всё, ...я скажу "делать добро - хорошо", Вы тут же ответите "С точностью до наоборот!", ...так нельзя. 

Цитата:


proof



Sau

@ kwlw

Какой вывод сделали? ...я лично в этом деле, а Вы?

@ kwlw

Вместо CopyMemory попробуйте это, поймёте о чём речь:


asm
    push esi
    push edi

    mov ecx, {длина блока}
    mov esi, {указатель на буфер}
    mov edi, {указатель на приёмник}
  @jj:
    movups   xmm0, [esi]     // буфер -> в регистр
    movups   [edi], xmm0     // приёмник <- из регистра

    add esi, 16
    add edi, 16

    dec ecx
    jnz @jj

    pop edi
    pop esi

    emms
  end;

А словами?

Цитата:


Peratron уже написал.

Sau

kwlw писал(а) 02.02.2015 :: 19:38:51:

Peratron про регистры не писал, я хочу знать от Вас, что означает картинка в ответ на вопрос "Какой вывод сделали?" относительно рекомендации ознакомиться с MMX и SSE? ...я не терплю слинивание в кусты когда надо держать ответ 

@ KMG

+++!

...есть профессиональные программисты на форуме! ...я думал в одиночку придётся отбиваться от "теоретиков Кунг-Фу"  ...никого не хочу обидеть, если задел - простите.

Цитата:

Намеренность сказанного не вызывает сомнения - потому маскировочный реверанс остаётся всего лишь прикрытием чисто рангового посыла.

По первичной сути темы в посте информации - ноль...

Цитата:

Это было рутиной, когда использование программ (в советское время) было расчетом какой то математической задачи.
Женя, к сожалению, процессор работает не по алгоритму, а по коду, и перевод в код ЯВУ авляется творческим процессом.
Чем "выше" мы абстрагируемся в описании задачи, тем больше наладные расходы на производительность, память...
А если оставить уровень абстрагирования как для "ЯВУ", то описание алгоритма будет вообще неудобочитаемо.
Собственно поэтому и нет серьезных компиляторов из алгоритмов. Все на уровне "игрушек для электриков".

Возвращаясь на твою плоскость - схемотехники. Цифровой кремний компилится не из схем, а из VHDL, именно из за недопустимых "накладных расходов". Я в свое время разрабатывал FPGA. После альтеровского препроцессора из схемотехнического представления приходилось "ручками" править HDL код.

Цитата:

Я уже сформулировал: при наличии математического обоснования - технология должна быть реорганизована на отраслевом уровне и шаманство (а не "творческий процесс") должно быть из неё изгнано.

Что б не быть совсем декларативным: во времена оны при освоении нового конструкторского домена - компьютерного - я вполне осознанно сформулировал необходимые теоремы и вполне конкретно нашёл для них решение, позволяющее заниматься "программированием" не на основе шаманизма, а исключительно по строгим правилам, исключающим "творческий волюнтаризм".

С тех пор этим хозяйством и пользуюсь.

Цитата:

Несовершенство конкретных технологий не означает фатальной невозможности иных, более строгих и однозначных решений.

ХИНТ: когда то шахматная игра служила примером "творческого превосходства" человека над машиной и большинство апологетов считало возникающее в игре разнообразие вариантов непреодолимым для машинных алгоритмов.

С того момента, как Дип Блю отодрал амбициозного чемпиона-человека и в хвост, и в гриву, и вдоль, и поперёк, тезис был наконец изъят из употребления.
Акцент на пресловутое "творческое превосходство" перенесён в другие домены - в частности, в сложившуюся практику программистского шаманизма...

Цитата:

В личку.
В общедоступном домене конструктив будет неизбежно погребён ранговыми амбициями.

Ведь своими тезисами, я, ни много ни мало, но покушаюсь на ЧСВ целого клана профессионалов 

Итак, автор дал свой ответ на извечный вопрос "Программирование - наука или искусство?". Это похвально.
Разумеется, алгоритмы это хорошо, это "наше всё". В императивном программировании.
Алгоритм это граф. Как представлять граф - понятное дело, закона нет, кому как нравится. Не думаю, что будет справедливым обвинять в шаманстве тех, кто выбрал для себя текстовое представление этого графа.

ОФФ. Забавно слышать от Ператрона выпады против теоретиков 

kwlw писал(а) 03.02.2015 :: 06:48:29:

Прекрасно это понимаю, но говорю прямо, что мне не нравится.

kwlw писал(а) 03.02.2015 :: 06:48:29:

"Я снова Вас зауважал" (с) Гараж.

kwlw писал(а) 03.02.2015 :: 06:48:29:

Проблема в том, что высокоуровневый ЯП - уже двойной интерпретатор, напичканный универсальными командами. Внутри команды "CopyMemory" ссылка на модуль "Move" между ними транслятор. "Move" содержит код на ассемблере (тоже ЯП, но более низкого уровня), использует 32-битные регистры. И затем этот код на асме компилятор перешьёт в машинный код. Парадокс в том, что в блок-схеме какого-нибудь алгоритма копирование информации из одного участка памяти в другой выглядит одинаково и для стандартной "CopyMemory" и для скоростной вставки, что я показал выше. Инженеру, не понимающему в программировании толком, нужен факт копирования памяти, и тут кроются сюрпризы. А на уровне структуры ВЯП коды совершенно разные, но выполняют одно и то же с разной скоростью. Поэтому блок-схема как принцип работы программы в целом по входам и выходам - это хорошо, а как способ записи самого кода - бумажная волокита.

Мне недавно Батя говорит "мы находимся на пороге внедрения виртуальной модели карьера, без бумажных планов горных работ, что ускоряет работу в десятки раз", я ему "в каком году я тебе говорил, что это надо делать? ...в 2002!" ...созрели.