Gtlab Forum
Флуд => Флейм. Флуд. Обо всем на свете => Тема начата: Peratron от Февраля 01, 2015, 09:26:54 pm
-
Вынесу это в общий трёп - что б не замусоривать конкретную тему...
Итак, об "алгоритмическом мышлении" - как основе инженерного мышления вообще...
В качестве примера - история, которая приключилась у меня в бытность работы в ОКБ МиГ.
Сначала был создан МиГ-29 - на основе тогдашних технологий, при которых каждый прибор обладал собственными мозгами и связывался с датчиками и исполнительными механизмами индивидуальными проводами, которые могли тянуться от верхушки киля в закабинный отсек и потом обратно.
К концу 70-х сложился проект МиГ-29Э (то есть "электронный").
Суть - ликвидация всех локальных мозгов и передача всех вычислительно-логических функций единому мозгу (спец-процессору).
Все провода тоже ликвидируются - вместо них по хребту и скелету тянется сеть с хабами через каждые полметра.
И каждый системщик подключает свой датчик не к своему собственному прибору, а к ближайшему хабу. Аналогично с силовыми постами - клапан или насос подключаются к ближайшему силовому хабу.
Расчётная экономия веса - 900 кг!
ХИНТ: традиционный в авиационных КБ конкурс по экономии веса обещал за 1 кг сэкономленного на борту веса премию в 150 руб!
То есть, такова ценность задуманного технического решения...
Шеф посадил меня - молодого и борзого - за описание ВСЕХ алгоритмов ВСЕХ приборов, находящихся в зоне компетенции нашего отдела.
А это - топливоизмерение, пожарка, управление двигателем. И ещё приличная кучка задачек...
И вот я закапываюсь в техописания - и конвертирую описание работы каждого из наших приборов в алгоритм, для последующей передачи программерам, создающим новый вычислительный комплекс.
Ковырял это полгода. В результате на выходе - четыре тома формата А4 толщиной в ладонь (в длину!).
Хочу акцентироватся на цене ошибки - представляете её?!
Но, собственно, я веду к тому, что произошло дальше - и несколько для меня неожиданно.
Значительную часть инженерной деятельности представляет анализ проблем на борту - "ой, в полете загорелась не та лампочка".
О худших вариантах даже не заикаюсь - не дай, как говорится, бог...
И вот пара-тройка спецов под руководством шефа разворачивает кучу схем и ползает по ним - ведь приборы не сами по себе: они обмениваются информацией и работают, как Система.
Ну, и вот шеф после очередного такого аврала подходит к мне: ты ж описывал всё в комплексе... Ну ка, давай прокатим через твои писания...
Ага!
Проблема разрешилась через четверть часа!!!!
Все были в полном шоке - и спустя короткое время я стал главным спецом по Системе. Системным интегратором ;)
Авторитет подскочил ну просто фантастически ;D
Так к чему это я?
А всё к тому, что я унифицировал всё к одному формату (по требованию тех, кто создавал новый комплекс) - и это позволило найти мощные резервы для развития самолёта в новых проектах.
Иного варианта, чем описывать всё в классическом формате "алгоритма" просто не было - и держать такой объём в голове по определению невозможно.
Моим талмудом я научил пользоваться всех коллег - потому, что это было просто и понятно любому инженеру.
Что характерно - я сделал эту работу безошибочно. То есть, ошибки если и обнаруживались - но на уровне самих первичных приборов.
Я же не переделывал их - я просто формально описывал то, что есть.
Сама эта работа весьма сильно повлияла на мои мозги - уважение к простой и ясной формулировке задачи стало частью моей натуры на всю оставшуюся жизнь...
Пишу это не ради самовосхваления - просто хочу, что б тусовка через мой опыт прониклась важностью такой формализации и относилась к необходимости делать "тупую" работу с должным почтением.
[size=14]Алгоритм - наше всё![/size]
-
Кажется, у меня открылись глаза. :o
-
При этом за пределами топика остался вопрос о генезисе первоначального направления вектора приложения усилий.
-
igorjan
На форуме ператронствовать позволено только Ператрону!
-
"Мужик, я ни х... не понял, что ты мне сказал, ...но ты мне близок, ...ты заговорил, и достучался до сердца" (с)
Напишите клиентскую программу в 22 000 строк высокоуровнего кода с более чем 500 алгоритмами и связями между ними, затем серверную в 40 000 строк, модель виртуального игрового мира, где только в сетевом протоколе 240 команд и столько же алгоритмов обработки информации, потом задумайтесь на каком футбольном поле поместятся все блок-схемы и как ими оперативно пользоваться, ...это не баки заправлять.
-
Согласен с предыдущим оратором. И с Ф. Бруксом в том, что диаграммы алгоритов утратили актуальность после перехода с ассемблера на языки высокого уровня, синтаксические конструкции которых наглядны столь же, как и эти диаграммы. (если автор, конечно, имел в виду именно талмуды диаграмм алгоритмов)
В наше время существует множество других вариантов наглядно представить модель системы и взаимодействие её компонентов.
-
Мужики, а в этом топике общение на каком языке ведётся?
:-/
-
Мужики, а в этом топике общение на каком языке ведётся?
:-/
Должно быть на инженерном, области информационных систем.
Я вижу в коде на Pascal или C++ или VBA алгоритм сразу, а блок схему рисую только для того чтобы показать кому-то непосвящённому как это работает.
За 17 лет программирования разработал методику записи кода таким образом, что беглого взгляда достаточно чтобы понять какие переменные за что отвечают, какие объекты какие классы содержат. Расстановка и верхний регистр чётко подмечаются зрением. Если автор темы мыслит блок-схемами, это значит, что он мыслит алгоритмом. Я тоже мыслю алгоритмом, только его визуализация в виде высокоуровневого кода меня более чем устраивает.
Закончились времена, когда ЭВМ на весь отдел был один, и каждый дома составлял блок-схемы концепции алгоритма, и затем на работе переносил это в ЯП. Я вижу код на Pascal и переписываю его на С++ и наоборот. Надо только синтаксис знать. А если меня не устраивает скорость кода, что интерпретирует компилятор, я вручную пишу вставку на ассемблере. Всё снабжаю подробными комментариями так, что спустя год могу открыть код и продолжать работать над ним понимая алгоритм.
Смотрите, это 1/22 всего кода:
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fdiyfactory.ru%2Fforum%2Fuploads%2Fimg-3498-ca0dbad92a.jpg&hash=3538fdf461481323e10f5a8ddf6d95a5f204e1d1)
Нарисовать блок-схемы - утопия. А серверная программа в 2 раза увесистее этой.
-
Ператрон, с интересом прочел твой рассказ, но саму идею не одобряю. Каждая система должна быть автономна в своей работе и общаться с верхним уровнем ограниченным количеством команд/ответов. Весь вопрос только в границах полномочий. В твоем случае, вероятно, был перекос в другом направлении. Я на военной кафедре изучал еще "решающие усилители" на лампах.
При твоем подходе ошибка в одном из блоков чревата блокировкой всех остальных. Банальное зацикливание, ожидание ответа от отказавшего датчика, неожиданная рекурсия и т.п. Верю, что ты предпринимал меры против этого, но в большой системе ошибок не может не быть. Ошибки, о которых ты говоришь - это всего лишь обнаруженные тобой ошибки. Должны были быть и необнаруженные. И слава богу, что они оказались некритичными или никогда не получали управление.
Формализация процессов нужна - бесспорно. В том числе и графическая. Умея строить блок схему программы, ее гораздо легче потом увидеть в результирующем коде. Без этого умения человек просто не знает, что он должен увидеть. Если у него есть талант и он может это делать по-наитию - честь и хвала. А большинству все же нужно учиться.
-
И впрямь какое то выяснение РК. Peratron валит декларацию, другие бросают ему вызовы :). Мда, придётся и мне с квазиконструктивностью ((c) Peratron) полезть.
Тема то не новая. Визуализации - самое доступное. Я как бы в прошлом - тоже около семи лет отработал программистом, т.е. немножко в теме. Вот немножко из моего опыта (модели):
1. Сложные задачи без выяснения/составки алгоритмов - решать могут только пуристы типа Beermonza. Всё равно они разбивают задачу на куски, и используют код для описания алгоритма, ибо для них это естественно. Тем, кому писание кода занимает долю мозга - обычно сперва составляют алгоритм, потом уже сидят за кодом. Разница если честно - незначительна. Вопрос только в разделении труда, если мозг хорошо ставит алгоритмы, то мучить его составкой кода - довольно не выгодно по финансовой стороне дела. По алгоритму код может составить машина или студент последних курсов.
2. Про разную скорость кода написанного на С ассемблере - если честно, не понял. Всё равно язык ВУ компилируется в машинный код, в наши то времена, когда синхронизацию всё равно берём от прерывании или от таймера, не вижу смысла в асме, даже в вставках. Для того ведь компилятор имеет оптимизации. Про HPC мне басни можно не рассказывать, ибо хлеб свой зарабатываю в сфере, где системы работают с миллионами юзеров и данные мерятся петабайтами. Если идут сложные матвычисления, то матмодель гораздо важнее языка программирования. Оптимизация по конкретному процу, типа учитывание размера кэшов, числа регистров - бывают только в оч. специфических задачах, где в принципе уже строим аппаратно-программный комплекс, а не занимаемся обычным программированием.
3. Командная работа, когда проект "тянет" на тысячи ЧЧ. Вот где по настоящему ярким светом сверкают: ясная разборка алгоритмов, компонентов, связей. Написано кучи разных тулзов. Потому что надо распределить работу по команде, архитект(ы) составляе(ю)т хребет алгоритма, команды/члены команд облепляют его "органами". Например парсером конфигов, ГУИ, сетевой частью, очередями, базой данных и т.п.
Так что алгоритмизация инженерной задачи, проработка исходных данных - важная часть работы. Но, если работаем в полевых условиях, когда ничего неясно в принципе, а решение надо принимать сейчас, кропотливая проработка даёт отличный результат ровно тогда, когда он уже никому не нужен. Современный бизнес - любит кататься на лезвии. Подумаешь лётчика угробим - у нас ещё пять есть! Давай результат, надо было вчера, завтра чтоб всё как нибудь работало, потом починим в сервиспаке. Проект не успел - закрыли, начали другой и т.п. :(.
А для себя, тут нужно смотреть по своим мотивирующим инстинктам. Какой симулякр используется для получения удовольствия. Если стимуляция идёт через результат (инстинкт улучшения жительного пространства) и упражнения логического аппарата, тогда структуризация и алгоритмизация всего и вся - сам бог велел. Если стимуляция идёт через познавательный (открытие новых территории), тогда этим можно и нужно пренебречь, ибо стимуляция идёт через процесс, а не результат.
Sau
-
Re: Об алгоритмах...
Ответ #5 - Сегодня :: 16:53:17 Цитировать
Согласен с предыдущим оратором. И с Ф. Бруксом в том, что диаграммы алгоритов утратили актуальность после перехода с ассемблера на языки высокого уровня, синтаксические конструкции которых наглядны столь же, как и эти диаграммы.
С теоретиками программирования можно было б согласиться - начни они с первоснов новой отрасли и объяснив природу информации, как феномена.
Но они пошли по пути шаманской практики, коей и является по сю пору "информатика".
И потому доверия их умопостроения не вызывают. Хоть тресни...
-
Re: Об алгоритмах...
Ответ #5 - Сегодня :: 16:53:17 Цитировать
Согласен с предыдущим оратором. И с Ф. Бруксом в том, что диаграммы алгоритов утратили актуальность после перехода с ассемблера на языки высокого уровня, синтаксические конструкции которых наглядны столь же, как и эти диаграммы.
С теоретиками программирования можно было б согласиться - начни они с первоснов новой отрасли и объяснив природу информации, как феномена.
Но они пошли по пути шаманской практики, коей и является по сю пору "информатика".
И потому доверия их умопостроения не вызывают. Хоть тресни...
В горном деле "уважаемые старейшины", знающие много про теорию и красиво рисующие блок-схемы процессов до сих пор за применение канатных экскаваторов, обосновывая всё это "научным" бредом, который как обоснование имел весомое значение 40 лет назад. Мой Батя бился с такими постоянно, продвигая новый уровень мышления и применения современных технологий, например, гидравлики.
2. Про разную скорость кода написанного на С ассемблере - если честно, не понял. Всё равно язык ВУ компилируется в машинный код, в наши то времена, когда синхронизацию всё равно берём от прерывании или от таймера, не вижу смысла в асме, даже в вставках. Для того ведь компилятор имеет оптимизации. Про HPC мне басни можно не рассказывать, ибо хлеб свой зарабатываю в сфере, где системы работают с миллионами юзеров и данные мерятся петабайтами. Если идут сложные матвычисления, то матмодель гораздо важнее языка программирования. Оптимизация по конкретному процу, типа учитывание размера кэшов, числа регистров - бывают только в оч. специфических задачах, где в принципе уже строим аппаратно-программный комплекс, а не занимаемся обычным программированием.
Поинтересуйтесь, что такое MMX и SSE регистры центрального процессора, поскольку компиляторы ЯП используют стандартные 32-битные, поэтому пролетают в скорости там, где это жизненно важно.
3. Командная работа, когда проект "тянет" на тысячи ЧЧ. Вот где по настоящему ярким светом сверкают: ясная разборка алгоритмов, компонентов, связей. Написано кучи разных тулзов. Потому что надо распределить работу по команде, архитект(ы) составляе(ю)т хребет алгоритма, команды/члены команд облепляют его "органами". Например парсером конфигов, ГУИ, сетевой частью, очередями, базой данных и т.п.
Сейчас программисты больше напоминают сборщиков. Бездумно применяют готовые алгоритмы, дробят структуру на множество модулей, где каждый занимается своим изолировано, имея мануал, описывающий входы и выходы модуля. Затем сетевым образом это лепится в проект и далее судорожно латаются дыры и исправляются нестыковки. Зато с блок-схемам и "полным" знанием предмета и концепции сути хранения, преобразования и распространения информации. >:(
Работу должен выполнять талантливый специалист, а не любой прошедший обучение по талмуду. Шаг в сторону и они в панике бегут к хозяину теории.
-
Я вижу в коде на Pascal или C++ или VBA алгоритм сразу, а блок схему рисую только для того чтобы показать кому-то непосвящённому как это работает.
Вот сразу и противоречие: "я вижу - но рисую для тех, кто не видит".
ХИНТ: профессиональные шахматисты играют вслепую сразу на сотнях досок - что не делает игру в шахматы вслепую удобным инструментом для промышленного применения, а оставляет высоким искусством, доступным лишь уникальным "волшебникам".
ХИНТ: я владею современными психотехнологиями, учитывающими специфику обработки информации разными органами чувств (модальностями) - и вмазался в эту тему во времена работы в ОКБ, где пришлось заниматься эргономикой приборного комплекса кабины истребителя, где оператор-лётчик находится в условиях колоссального дефицита ресурсов времени, а цена ошибки (управленческого решения) - сама жизнь.
И вот на основе этого опыта, знания нейрофизиологии и полного погружения в тему управления процессами, я вижу, что принятый в ЯВУ принцип структурирования текстовой информации является вынужденным костылём.
Без него вообще полная задница - но он сам по себе функционально недостаточен.
Текстовое структурирование опирается исключительно на "дигитальную" модальность, которая в психике бывает ведущей только у клинических шизоидов.
Основное распределение ведщущих модальностей примерно таково:
- более половины - кинестетика;
- главная часть оставшейся половины - визуалка;
- остальное - аудиалка.
Таким образом, поддержка структурирования в существующих ЯВУ опирается на неестественные психофизиологичнеские механизмы.
И само программирование, как форма деятельности, несмотря на востребованность развитием информационных технологий, остаётся уделом далеко не большей части популяции.
В пику этому, блок-схема_алгоритм опирается на визуальную модальность - которая даже у тех субъектов, которые имеют ведущей кинестетику и аудиалку, развита полноценно.
Блок-схема даёт взгляд на Систему сверху, текстовое структурирование ЯВУ - фокусирует взгляд на нижних уровнях.
ХИНТ: вот пример - к сожалению не полностью удачный - программирования "алгоритмом":
[media]http://www.youtube.com/watch?v=Ua9dUUONjdk[/media]
Неудача тут в неполноценном интерфейсе графического редактора - когда вместо того, что б впечатывать опцию прямо в алгоритмический объект, строка текстового редактора открывается хрен знает где.
Но и прочие убогости - совершенно очевидные для современного пользователя компьютеров с полноценным графическим интерфейсом.
ХИНТ: текстовое структурирование, применяемое ныне в ЯВУ, родилось в эпоху чисто текстовых терминальных консолей и АЦПУ.
Это был естественный и нормальный этап эволюции - но программеры застряли на этом уровне, не желая меняться вместе с ИТ-вселенной.
-
В электронике/электротехнике есть полная аналогия программерскому интерфейсу - схему можно представить графически, а можно и в виде списка цепей.
Что характерно - список цепей удобней для компьютерных целей.
Но что со мной сделают камрады, если я предложу тут для ознакомления и обсуждения схему в текстовом формате "список цепей" вместо классической "графики"? :o :o :o
ХИНТ: при написании программ для МК я работаю в Алгоритм Билдере - программе с текстовым интерфейсом, но элементами алгоритмической графики.
По возможностям АБ полностью идентичен ассемблеру - но работа в нём идёт раз в пять быстрей после недлительного освоения.
Но АБ, разумеется, тоже очень далёк от оптимума - поскольку ориентирован всё на тот же текстовый интерфейс...
-
@ kwlw
Да.
-
Работу должен выполнять талантливый специалист, а не любой прошедший обучение по талмуду.
С точностью до наоборот!
Индустриальный характер развития информационной отрасли требует такой отработанности рабочей процедуры, когда при решении рутинных задач не требуется высокой квалификации персонала.
Профессионально - то есть, в соответствии с требованиями производственного процесса - кодировать должен уметь выпускник первой ступени профобразования.
По прошлым регалиям - выпускник ПТУ.
Превращение программирования в шаманскую практику выгодно цеху "программистов" - но стоит цивилизации слишком дорого: потерянными ресурсами, катастрофическими ошибками, кровью людской...
-
Я вижу в коде на Pascal или C++ или VBA алгоритм сразу, а блок схему рисую только для того чтобы показать кому-то непосвящённому как это работает.
Вот сразу и противоречие: "я вижу - но рисую для тех, кто не видит".
В чём? ...что, извините, баран без блок-схемы не видит то, что в коде вижу я? ...я алгоритм виртуально держу в голове, перевожу его сразу в код. Вы - через "посредника", мысль > блок-схема > ЯП. Для того чтобы создавать модуль мне не надо для себя рисовать блок-схему. Если я делаю модуль для кого-то, я напишу сразу код, и потом в мануал блок-схему, и код и блок-схема = следствия, алгоритм в голове = причина.
Я не против блок-схем, я говорю про то, что сложные задачи блок-схемами снабжаются только на уровне общей концепции, а чтобы в ромбиках записывать те же самые операторы цикла - это двойная работа, высокоуровневый ЯП достаточно визуализирует структуру алгоритма в самом коде. Это в ассемблере ни хрена не видно, там блок-схема поможет кому-то очень сильно.
Но что со мной сделают камрады, если я предложу тут для ознакомления и обсуждения схему в текстовом формате "список цепей" вместо классической "графики"? :o :o :o
Вообще пример не в тему. Код на высокоуровневом ЯП не есть "список", у него конкретная структура. Достаточно видеть оператор и знать его синтаксис, и в голове сразу появляется то, что Вы можете "положить" в голову только по средствам блок схемы. Вопрос, а как Вы вообще рисуете блок-схему? ...не просто же как рисунок, а потом мозг понимает "о! так это алгоритм какой-то!". Мысль - первична, и она в голове как блок-схема не выглядит. Блок-схема - средство визуализации, для понимания твоего кода кем-то другим.
Работу должен выполнять талантливый специалист, а не любой прошедший обучение по талмуду.
С точностью до наоборот!
Именно! ...поэтому промышленность в одном месте, всех пропустили через талмуды, теперь ищут талантливых.
Я ж Вас знаю, Вы будете упираться до последнего, просто переворачивать всё, ...я скажу "делать добро - хорошо", Вы тут же ответите "С точностью до наоборот!", ...так нельзя. :'(
-
Вообще пример не в тему. Код на высокоуровневом ЯП не есть "список", у него конкретная структура.
Абсолютно и строго в тему.
Текстовый код опирается на иные нейрофизиологические механизмы.
То есть мозги по разному обращаются с одинаковой по финальному результату информацией.
Что прямо влияет на скорость работы и на количество ошибок.
Повторю ещё раз: текст - не картинка!
-
Поинтересуйтесь, что такое MMX и SSE регистры центрального процессора, поскольку компиляторы ЯП используют стандартные 32-битные, поэтому пролетают в скорости там, где это жизненно важно.
proof (https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options)
::)
Sau
-
Вообще пример не в тему. Код на высокоуровневом ЯП не есть "список", у него конкретная структура.
Абсолютно и строго в тему.
Текстовый код опирается на иные нейрофизиологические механизмы.
То есть мозги по разному обращаются с одинаковой по финальному результату информацией.
Что прямо влияет на скорость работы и на количество ошибок.
Повторю ещё раз: текст - не картинка!
Ну, так и я Вам повторю, что высокоуровневый код - не список! Если Вы ищите программу, которая переделает Вашу блок-схему в код, то у Вас проблемы с восприятием, а не у миллионов программистов, которым хватает среды и редактора в полной мере, ...это они делают мега-проекты, а не Вы, поэтому бросьте переделывать то, что развилось и работает уже 40 лет. Не по Ператрону? ...да и фиг, я давал список предметов, можете отыскать и ознакомиться.
С уважением, и на этом всё, Вы не навяжете свой стиль мышления.
-
@ 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;
-
@ kwlw
Какой вывод сделали? ...я лично в этом деле, а Вы?
(https://guitartonelab.ru/proxy.php?request=http%3A%2F%2Fforums.superherohype.com%2Fimages%2Fsmilies%2F55ms9.gif&hash=8c35687e4f2ef1eb7f6f88c6e644807be6b69c5b)
Sau
-
А словами?
-
Ну, так и я Вам повторю, что высокоуровневый код - не список!
А что же?
Если Вы ищите программу, которая переделает Вашу блок-схему в код, то у Вас проблемы с восприятием, а не у миллионов программистов, которым хватает среды и редактора в полной мере, ...это они делают мега-проекты, а не Вы, поэтому бросьте переделывать то, что развилось и работает уже 40 лет. Не по Ператрону? ...да и фиг, я давал список предметов, можете отыскать и ознакомиться.
С уважением, и на этом всё, Вы не навяжете свой стиль мышления.
Рано или поздно тема, прикрытая флёром "конструктивности", открывается и переходит в то, что она и есть - в чисто ранговый поединок.
Подробности обсуждаемы здесь: http://forum.gtlab.net/cgi-bin/yabb2/YaBB.pl?num=1422201948
-
А словами?
Peratron уже написал.
Sau
-
Обсессия?
-
А словами?
Peratron уже написал.
Sau
Peratron про регистры не писал, я хочу знать от Вас, что означает картинка в ответ на вопрос "Какой вывод сделали?" относительно рекомендации ознакомиться с MMX и SSE? ...я не терплю слинивание в кусты когда надо держать ответ >:(
-
В электронике/электротехнике есть полная аналогия программерскому интерфейсу - схему можно представить графически, а можно и в виде списка цепей.
Никоим образом не аналог, схема и список связей абсолютно всзаимосвязаны. За исключенем расположения элементов на схеме, что абсолютно не влияет на работоспособность!
А вот алгоритм (квадратики/ромбики/стрелочки) может быть реализован десятком способов с разной степенью эффективности кода.
Например, перестановка двух строчек в исходном коде (не меняющая алгоритм), может привести к появлению избыточного кода. Я, например, пишу программу с учетом тонкостей того, как работает оптимизатор кода компилятора.
А желание переложить свою работу на неизвестно как написанный препроцессор перевода алгоритма в код...
Я в свое время писал компилятор (препроцессор) из графического представления т.н. Ladder Diagram (http://en.wikipedia.org/wiki/Ladder_logic) для программируемых промышленных контроллеров. Но! Потребоввалось это потому, что обслуживающий персонал был - электрики, а не инженеры. Квалифицированные пользователи этой опцией не пользовались.
Еще, алгоритм имеет свойство модифицироваться в процессе написания программы для увеличения ее эффективности.
Поэтому он обычно составляется (по необходимости) уже после отлаживания программы.
PS языки высокого уровня C, Pascal... являются разумным компромиссом между эффективностью и возможностью диагностики технических (не алгоритмических) ошибок.
-
@ KMG
+++!
...есть профессиональные программисты на форуме! ...я думал в одиночку придётся отбиваться от "теоретиков Кунг-Фу" ;D ...никого не хочу обидеть, если задел - простите.
-
А вот алгоритм (квадратики/ромбики/стрелочки) может быть реализован десятком способов с разной степенью эффективности кода.
Фишка в том, что процедура транслирования блок-схемы в код есть изначально рутинная - и не должна занимать пользователя никоим образом.
Однозначная связь между схемой и списком соединений есть всего лишь лёгкий нюанс данного конкретного случая, не затрагивающий суть аналогии.
Ведь и программа сама по себе не обязана быть однозначной по коду - потому это отягчающее условие в программном домене не ставится.
А в применении схем соединений одназначность - обязательный по задаче параметр, никак не связанный с формой представления информации и, главное, с работой психики в этих форматах.
А желание переложить свою работу на неизвестно как написанный препроцессор перевода алгоритма в код...
Эта задача формализуема чисто математически - потому отсутствие совершенных компиляторов есть всего лишь подтверждение текущего шаманского этапа развития отрасли.
Еще, алгоритм имеет свойство модифицироваться в процессе написания программы для увеличения ее эффективности.
Поэтому он обычно составляется (по необходимости) уже после отлаживания программы.
Тоже всё с ног на голову - отладка должна осуществляться именно на уроне алгоритма, нормирующего причинно-следственные связи, составляющие динамический объект.
Нормировка, как и в случае элнектросхемы - строго однозначная: ведь не может существовать первичный объект, функционирующий неоднозначно (тему квантовых неопределённостей пока выносим за скобки - хотя она как раз реализуется алгоритмически на счёт раз).
Моделирование объектов с нечёткой логикой решается на основе однозначных законов мат-статистики - то есть, опять же, алгоритмический граф вполне однозначен.
Потому достаточно отладить именно и только причинно-следственный граф, представленный через алгоритмическую блок схему - и этого должно быть достаточно для полного решения задачи.
Промежуточная трансляция на любой ЯВУ не имеет вообще никакого значения.
ХИНТ: само существование разных МЯ - это нонсенс!
Единственным универсальным языком является язык причинно-следственных связей - и алгоритм-граф есть наилучшая форма его реализации...
PS языки высокого уровня C, Pascal... являются разумным компромиссом между эффективностью и возможностью диагностики технических (не алгоритмических) ошибок.
Если подумать как следует - можно понять, что текстовый формат ЯВУ является вынужденным компромиссом между требованиями причинно-следственного моделирования и техническими средствами интерфейса между оператором-создателем и конечным кодом: в момент появления этой сущности единственной доступной технологией была технология текстового ввода с алфавитно-цифровой клавиатуры и АЦ-терминалов и печатных устройств.
С тех пор всё и зависло - несмотря на появление новых технологических возможностей в человеко-машинном интерфейсе.
И это - абсолютно ненормально.
Хотя и привычно для человеческой цивилизации.
-
...никого не хочу обидеть, если задел - простите.
Намеренность сказанного не вызывает сомнения - потому маскировочный реверанс остаётся всего лишь прикрытием чисто рангового посыла.
По первичной сути темы в посте информации - ноль...
-
@ Peratron
Я тоже Вас люблю, ...извините. :-*
Самокритика тоже приветствуется.
Пишу это не ради самовосхваления - просто хочу, что б тусовка через мой опыт прониклась важностью такой формализации и относилась к необходимости делать "тупую" работу с должным почтением.
Намеренность сказанного не вызывает сомнения - потому маскировочный реверанс остаётся всего лишь прикрытием
-
Фишка в том, что процедура транслирования блок-схемы в код есть изначально рутинная - и не должна занимать пользователя никоим образом.
Это было рутиной, когда использование программ (в советское время) было расчетом какой то математической задачи.
Женя, к сожалению, процессор работает не по алгоритму, а по коду, и перевод в код ЯВУ авляется творческим процессом.
Чем "выше" мы абстрагируемся в описании задачи, тем больше наладные расходы на производительность, память...
А если оставить уровень абстрагирования как для "ЯВУ", то описание алгоритма будет вообще неудобочитаемо.
Собственно поэтому и нет серьезных компиляторов из алгоритмов. Все на уровне "игрушек для электриков".
Возвращаясь на твою плоскость - схемотехники. Цифровой кремний компилится не из схем, а из VHDL, именно из за недопустимых "накладных расходов". Я в свое время разрабатывал FPGA. После альтеровского препроцессора из схемотехнического представления приходилось "ручками" править HDL код.
-
Я, конечно, опытом похвастаться не могу - только образование профильное, поэтому я, по-видимому, не догоняю, в чем, собственно, посыл-то? То, что алгоритмы есть наше всё и так понятно. И языки, вроде, называются алгоритмическими неспроста. За историю спасибо.
То, что все компиляторы работают с текстовым вводом - это плохо? А где же альтернативы? А как же связать графы состояний алгоритма с тем простым фактом, что физические процессоры выполняют инструкции последовательно?
Женя, сказал "А" - давай хоть "Б" ;)
-
перевод в код ЯВУ авляется творческим процессом
Я уже сформулировал: при наличии математического обоснования - технология должна быть реорганизована на отраслевом уровне и шаманство (а не "творческий процесс") должно быть из неё изгнано.
Что б не быть совсем декларативным: во времена оны при освоении нового конструкторского домена - компьютерного - я вполне осознанно сформулировал необходимые теоремы и вполне конкретно нашёл для них решение, позволяющее заниматься "программированием" не на основе шаманизма, а исключительно по строгим правилам, исключающим "творческий волюнтаризм".
С тех пор этим хозяйством и пользуюсь.
Цифровой кремний компилится не из схем, а из VHDL, именно из за недопустимых "накладных расходов". Я в свое время разрабатывал FPGA. После альтеровского препроцессора из схемотехнического представления приходилось "ручками" править HDL код.
Несовершенство конкретных технологий не означает фатальной невозможности иных, более строгих и однозначных решений.
ХИНТ: когда то шахматная игра служила примером "творческого превосходства" человека над машиной и большинство апологетов считало возникающее в игре разнообразие вариантов непреодолимым для машинных алгоритмов.
С того момента, как Дип Блю отодрал амбициозного чемпиона-человека и в хвост, и в гриву, и вдоль, и поперёк, тезис был наконец изъят из употребления.
Акцент на пресловутое "творческое превосходство" перенесён в другие домены - в частности, в сложившуюся практику программистского шаманизма...
-
То, что алгоритмы есть наше всё и так понятно.
Как показывает дискуссия - вовсе не всем.
-
Женя, сказал "А" - давай хоть "Б"
В личку.
В общедоступном домене конструктив будет неизбежно погребён ранговыми амбициями.
Ведь своими тезисами, я, ни много ни мало, но покушаюсь на ЧСВ целого клана профессионалов :-[
-
Peratron про регистры не писал, я хочу знать от Вас, что означает картинка в ответ на вопрос "Какой вывод сделали?" относительно рекомендации ознакомиться с MMX и SSE? ...я не терплю слинивание в кусты когда надо держать ответ >:(
В принципе никого не волнует что вы терпите, а что нет.
А так, ради правды и интереса, как раз при утреннем кофе подвернулся наш главпрог с которым 13 лет бок обок всё строим. Обмусолили тему без ненужных эмоции. Чтож - убедили, был не прав, признаюсь :(. Слишком оптимистично посмотрел на современные off-the-shelf компиляторы и слишком броско на код генерированный ими. Оказывается, иногда компиляторов "тянет" на странные вещи, например рваться использовать память, когда намного быстрей в куске кода высокого повторения обойтись только регистрами. И т.п. "шутки". Т.е. подгоняя под конкретную архитектуру приходится изрешетить код директивами препроцессора и вставками из асма. В наше то время!
И ещё закинул в одну кастрюлю всё. Т.е. посмотрел из своей башни с сотнями гигабайт рама, десятками ядер, спарками да итанюмами :-[... А ведь сам-то, десять лет назад, ругался над сиськой и вставлял асм в процедуры обработки прерываний в программы на всяких аттини и 8052.
Sau
-
Итак, автор дал свой ответ на извечный вопрос "Программирование - наука или искусство?". Это похвально.
Разумеется, алгоритмы это хорошо, это "наше всё". В императивном программировании.
Алгоритм это граф. Как представлять граф - понятное дело, закона нет, кому как нравится. Не думаю, что будет справедливым обвинять в шаманстве тех, кто выбрал для себя текстовое представление этого графа.
ОФФ. Забавно слышать от Ператрона выпады против теоретиков ;D
-
Ведь своими тезисами, я, ни много ни мало, но покушаюсь на ЧСВ целого клана профессионалов :-[
Та наше ЧСВ не страдает. Мы ж как профессионалы делом заняты, а не на форуме про гитарную электронику учим других, как правильно проектировать программно-аппаратные комплексы, например. Нам рассказы про то, как якобы надо, - шо слону дробина.
А любителей абстракций высокого уровня видали. По нынешним временам это выглядит так.
Например, стоит задача построить канал связи, скажем, OFDM. Любитель блок-схем рисует в Матлабе (пользуясь там, кстати, уже приготовленными шаблонами) полный тракт обработки, изучает его поведение, а потом пытается упростить себе работу - в Матлабе есть возможность получить сгенеренный по схеме тракта код. А потом этот код пробуют запихать в живое железо. И наступает звиздец - потому что не лезет - ни по памяти, ни по быстродействию. Можно, конечно, и такой прибор сделать, но сколько он будет стоить? Да и с надежностью у всяких вычислительных монстров очень нешироко.
Профессионал, понятное дело, оценив поведение тракта в Матлабе, пишет полноценную реализацию, с оптимизацией кода в меру своего профессионализма. Что в результате приводит к снижению себестоимости в массовом производстве. И к повышению надежности.
В данном случае не надо путать настоящего профессионала с расплодившимися нынче говнокодерами.
А рассказывать про самолеты нам не надо, ибо "не так все было" (ц). Сами как бы по специальности РТСЛА учились.
-
Peratron про регистры не писал, я хочу знать от Вас, что означает картинка в ответ на вопрос "Какой вывод сделали?" относительно рекомендации ознакомиться с MMX и SSE? ...я не терплю слинивание в кусты когда надо держать ответ >:(
В принципе никого не волнует что вы терпите, а что нет.
Прекрасно это понимаю, но говорю прямо, что мне не нравится.
А так, ради правды и интереса, как раз при утреннем кофе подвернулся наш главпрог с которым 13 лет бок обок всё строим. Обмусолили тему без ненужных эмоции. Чтож - убедили, был не прав, признаюсь :(. Слишком оптимистично посмотрел на современные off-the-shelf компиляторы и слишком броско на код генерированный ими.
"Я снова Вас зауважал" (с) Гараж.
Оказывается, иногда компиляторов "тянет" на странные вещи, например рваться использовать память, когда намного быстрей в куске кода высокого повторения обойтись только регистрами. И т.п. "шутки". Т.е. подгоняя под конкретную архитектуру приходится изрешетить код директивами препроцессора и вставками из асма. В наше то время!
Проблема в том, что высокоуровневый ЯП - уже двойной интерпретатор, напичканный универсальными командами. Внутри команды "CopyMemory" ссылка на модуль "Move" между ними транслятор. "Move" содержит код на ассемблере (тоже ЯП, но более низкого уровня), использует 32-битные регистры. И затем этот код на асме компилятор перешьёт в машинный код. Парадокс в том, что в блок-схеме какого-нибудь алгоритма копирование информации из одного участка памяти в другой выглядит одинаково и для стандартной "CopyMemory" и для скоростной вставки, что я показал выше. Инженеру, не понимающему в программировании толком, нужен факт копирования памяти, и тут кроются сюрпризы. А на уровне структуры ВЯП коды совершенно разные, но выполняют одно и то же с разной скоростью. Поэтому блок-схема как принцип работы программы в целом по входам и выходам - это хорошо, а как способ записи самого кода - бумажная волокита.
Мне недавно Батя говорит "мы находимся на пороге внедрения виртуальной модели карьера, без бумажных планов горных работ, что ускоряет работу в десятки раз", я ему "в каком году я тебе говорил, что это надо делать? ...в 2002!" ...созрели.