OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 06:33

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Снова о важности базовых техник
СообщениеДобавлено: Понедельник, 26 Июль, 2010 23:00 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Геннадий Тышов писал(а):
У Вас, как у преподавателей студентам программирования, на первом месте стоит программирование, а алгоритмизация игнорируется.
...
Ваше игнорирование алгоритмизации лишает студента на начальном этапе обучения выработке важнейшего навыка, снижает его способности к самообразованию, к исследовательской работе.


В чём-то Вы правы - центральным звеном в обучении я действительно признаю отточенную технику программной реализации алгоритма. Я считаю, что это резонно - у студента должна быть опора, на которую он всегда может уверенно и быстро "спроецировать" свои идеи. Иначе он будет непозволительно много времени и внимания тратить на рутину - и как раз времени на самообразование и исследовательскую работу не останется.
Средний программист тратит 40-60% времени на отладку - это что, как не бессмысленные потери времени? 10% - не более, при отработанной технике. Пусть этот самообразующийся студент не проводит время за компом, отлаживая программу, а быстро её закончит и пойдёт дальше самообразовываться - книжки читать и думать новые мысли :)
Это с позиций образования.

С позиций реального дела. Вот приходит мальчишка-студент с горящими глазами - "хочу реальную задачу, дайте..." И энергия есть, и сильная хватка - но наворотит он такую вещь, которую потом всё равно взять "в дело" нельзя будет, из-за негодной реализации идеи. И кому от этого хорошо? Студенту этому хорошо? Поэтому думается, что лучше сначала тренаж. Как на физмате - 2-3 года матана с решением задач по задачникам, пока от зубов не начинает отлетать..

Ну и, наконец, если Вы про уровень алгоритма - то уж совсем неясно, откуда там goto. Ну, нет в окружающих нас процессах, которые мы алгоритмизируем, goto. А вот всё те же схемы полного прохода и линейного поиска просматриваются всё время. Что ещё до программирования отражено в логических кванторах "для всех" и "существует такое, что".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 26 Июль, 2010 23:08 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Геннадий Тышов писал(а):
Вы, имеете проблемы с преподаванием студентам темы цикла.


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

Суть в том, что идёт борьба за такой стиль программирования, при котором:
1) программист имеет возможность, немного аккуратно подумав, сразу получить правильный алгоритм (в частности, цикл, как наиболее сложную и ошибкоопасную часть алгоритмов) - с точностью до случайных опечаток;
2) для любого специалиста, читающего его код, сразу было бы очевидно, что он работает именно так, а не иначе (сравните - открыть код и увидеть привычный и очевидный линейный поиск, или увидеть цикл на больше чем страницу с несколькими break, который нужно долго мысленно "гонять").


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июль, 2010 20:36 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья, может быть Вы окажите нам честь, и расшифруете, что означает на данном форуме УМЕНИЕ ПРОГРАММИРОВАТЬ.
В моем понимании это довольно слабо связано с умением "правильно писать циклы" ((хотя морально уже готов услышать, вообще - чего угодно))

Ибо передо мной лежит код (на Обероне), в нем неоднократно встречаются линейные поиски, и у меня нет проблем с их пониманием. А вот, несмотря на "филигранно поставленную технику" - цель програмного продукта достигается кривовато как-то...

Да, проблема, справедливо Вами отмеченная - ЕСТЬ. Но она от того, что людей не научили Думать, а вовсе не "шаблону линейного поиска".

В моем понимании, если у кого-то очень хорошо поставлена "техника укладки кирпичей", то это вовсе не означает, что он уже Строитель. Т.е. сможет построить Дом (надежный, имеется в виду). Как отметил выше, противоположный пример - у меня перед глазами.
А в Вашем :?: :wink:


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июль, 2010 21:02 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Galkov писал(а):

Да, проблема, справедливо Вами отмеченная - ЕСТЬ. Но она от того, что людей не научили Думать, а вовсе не "шаблону линейного поиска".

Обучение - сложный, многоэтапный процесс. Когда человек с крутым высшим образованием, но особенно никого учивший, говорит красивые слова про "нужно учить думать" - для любого педагога это звучит очень... верхоглядно, что ли. Мозг не может уметь эффективно думать на какую-то тему, пока у него нет массы эмпирического сырья на эту тему. Так он устроен. Любое обобщение, любой действительно острый ум вырастает над соответствующим опытом. А опыт - это и рутина, и мелочи, и обычная техническая набивка разных мелких умственных навыков/компетенций. В какой момент ребёнок перестаёт считать, сколько будет два яблока да три яблока, и начинает "учиться Думать"? Где граница? Её нет, есть непрерывный очень сложный процесс развития ребёнка в окружающем мире. И в специальных обучающих "обстановках", что и является предметом науки педагогики (её "реальной" части).
"Царских путей нет". Всё остальное - слова.

Цитата:
В моем понимании, если у кого-то очень хорошо поставлена "техника укладки кирпичей", то это вовсе не означает, что он уже Строитель. Т.е. сможет построить Дом (надежный, имеется в виду). Как отметил выше, противоположный пример - у меня перед глазами.
А в Вашем :?: :wink:

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

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

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

Цитата:
И профессиональная обязанность Инженера - понимать эти нетривиальности. Если он (Инженер) это понимает, тогда "правильное написание цикла" - мелкая деталь, не достойная того времени, которое затрачено на этом форуме.

Достойная, потому что как таковых программных инженеров ещё почти нет. В отрасли ещё не устоялись элементарные нормы работы, проектирования, качества процесса разработки.
А ввиду нематериальности продукта, как уже сто раз говорилось, механизмы отбора/конкуренции очень медленно отфильтровывают "кустарщину". В обычном производстве отбирающую роль играл элементарный фактор себестоимости производства экземпляра продукта, в ПО этого фактора нет в принципе. И т.п.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июль, 2010 21:16 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Если говорить лично от себя, почему проблема столь наболевшая...
То это связано с невозможностью быстро пустить в проект ни одного из посторонних программистов. Есть острая - не то слово - необходимость именно в аккуратных, толковых исполнителях, которые могут реализовывать по заданию модули так, чтобы ведущий разработчик проекта был уверен на в них на 100%, как в своих. Чтобы с приходом нового человека в коллектив не возвращалось подзабытое слово "надо отладить". Серверное приложение не остановишь и не погоняешь в пошаговом отладчике, потому что Вася не владеет базовой техникой, зато умеет "Думать".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 09:27 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
... тренировать технику надо. Вот и всё, что можно сказать.
Думаю, не всегда обезьянка-кодер, натренированная нажимать на определённые кнопки, что бы выдать определённый шаблон кода, сможет решить какую-нибудь нетривиальную задачу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 09:58 

Зарегистрирован: Вторник, 20 Ноябрь, 2007 10:45
Сообщения: 28
Цитата:
Криэйторы, Вава, криэйторы, творцы нам тут нах. не нужны

(c) Пелевин, Generation Pi


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 12:21 

Зарегистрирован: Четверг, 04 Февраль, 2010 09:31
Сообщения: 263
Geniepro писал(а):
Илья Ермаков писал(а):
... тренировать технику надо. Вот и всё, что можно сказать.
Думаю, не всегда обезьянка-кодер, натренированная нажимать на определённые кнопки, что бы выдать определённый шаблон кода, сможет решить какую-нибудь нетривиальную задачу.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 13:00 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
dizer писал(а):
Давать такого рода задачи кодеру еще большая глупость чем заставлять программировать менеджера (рук. группы)


Разрешите подписаться. Если кодер тащится от того, что решает нетривиальные задачи, то это говорит не столько об его интеллекте, а скорее о том, что он делает не своё дело.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 15:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Как-то плоско всё видится у людей...

"Кодеры-программёры-менеджеры..."

Всё развивается постепенно.

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

Чтобы стать путёвым системным архитектором, надо не один год поизучать существующие системы, поработать в их рамках... Для большинства бывших студентов самый уверенный путь к карьере ведущих разработчиков - приходить в коллектив, который делает "с нуля" крупные системы, работать под руководством хорошего архитектора. Учиться сначала воплощать в жизнь чужие проекты, постепенно учась проектировать мелкие части самостоятельно. Через 2-3 года будет хороший руководитель небольшого проекта. И дальше по нарастающей...
Пример постепенного роста в плане способности к проектированию и руководству соисполнителями - парнишки - выпускника нашего СПО - у меня перед глазами.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 15:37 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Geniepro писал(а):
Думаю, не всегда обезьянка-кодер, натренированная нажимать на определённые кнопки, что бы выдать определённый шаблон кода, сможет решить какую-нибудь нетривиальную задачу.


Вы ничего не поняли, вот всё, что могу сказать.

Не бывает эффективного, уверенного, из раза в раз успешного проектирования без опоры на базу конструктивных схем, без знания их свойств и возможностей.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 17:52 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Galkov писал(а):
Но никогда не изготавливалась документация, чтобы ее понимал "любой дурак". Нетривиальные идеи имеют право (и всегда имели) на нешаблонное изложение. Имели на релюхах, на аналоговых микросхемах, на цифровой рассыпухе, на гибридах микроконтроллера с аналоговыми микросхемами и мультиплексорами... И сейчас имеют, именно такова инженерная культура.
Если устройство на печатной плате работает без наводок (то есть корректно), и для достижения такого результата сначала использовались стандартные методы, а когда их оказалось мало - нестандарнтые, то техника у данного разработчика поставлена. Если конструктор не пытается создать новый вид полупроводниковых приборов, а пользуется уже существющими классами, то это допустимо.

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

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

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

P.P.S. Вы постоянно пишите Думать с большой буквы. Ну так вот: многие из тех, кто сейчас программирует, даже не думают, и Вы защищаете не тех. А Илья не выступает против тех, кто Думает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 17:59 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
dizer писал(а):
Вас нормальному человеку очень трудно понять - поскольку смысл буковок которые вы выписываете скачет как блоха в блошином цирке.


Значит, у Вас нет того понимания объективной реальности, чтобы за буковками увидеть её. Вы вообще когда-нибудь руководили командой? Делали из зелёных студентов разработчиков для этой команды? Тянули проекты "с нуля" больше года длиной? Наверное, нет. Тогда "сытый голодному не товарищ" - Вам действительно трудно понять, о чём речь.
И наоборот - мне очень трудно взглянуть на мир глазами программиста-одиночки, индивидуала.

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

Глупа сама попытка рассуждать о каких-то сложных вопросах (гуманитарного характера, потому что любой вопрос образования и развития личности - это уже гуманитарный вопрос) в терминах статичных ярлыков - "кодер", "его функционал"... Люди, вообще говоря, развиваются. Как и организации, и их проекты, и их потребности. Для меня нет "кодера", для меня есть начинающий участник работ, которому предстоит развиваться. Но начинать с основ - конкретного опыта и конкретной техники. (Признаюсь честно - врождённым "гениальностям" и эффективности "самородных талантов" я не очень доверяю - хотя бывает, что они оправдывают доверие. А вот возможности постепенного, упорного развития - доверяю. Мозгу нужна хорошая пища, которой его нужно кормить, остальное - эволюционный процесс).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 17:59 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Valery Solovey писал(а):
И нынешнее образование зачастую старается разделить всех желающих стать программистами на две группы: очень тупых и очень сильных.
А само программирование остаётся в тени, и выпускники могут как быть нормальными программистами, так и не быть вне зависимости от аттестата.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 21:08 

Зарегистрирован: Воскресенье, 08 Март, 2009 17:54
Сообщения: 372
Да, бесконечная тема.
Илья и Ко утверждают очевидные вещи:
1. Во всех сферах чел. деятельности есть стандартные наборы правил, техники, шаблоны. Без изучения оных быть профессионалом - практически невозможно, только если ты Настоящий гений, а таких мало.
2. Все великие используют эти техники для решения низко- и средне- уровневых задач. Своё величие они проявляют на высоких уровнях.
3. Илья ратует за определённые техники, за их минималистичность. Goto в них он не включает.
Спорить с 1 и 2 ну совсем незачем, хотя дискуссия уже и по этому пути пошла.
Спорить с 3, судя по количеству страниц, бесполезно. Илья имеет и опыт программирования, и опыт преподавания и опыт разработки. Совершенно очевидно, что его точка зрения выстрадана, и он её не поменяет.

И не надоело вам, господа, обсуждать эту тему?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Август, 2010 10:22 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Флейм с dizer-ом отделен сюда:
viewtopic.php?f=70&t=2761


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Август, 2010 22:04 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Valery Solovey писал(а):
А такой разработчик своими опасными действиями лишил устройство этой возможности, да и вообще сильно добавил "ненадёжности". Вам-то такое и в голову не придёт, потому что техника поставлена.

Valery, все правильно Вы говорите. Почти со всем я полностью согласен. Почти... Поэтому кое-что уточню.
1) Вообще-то, в голову приходит. И тут надо помнить одну важную вещь - ответственность теперь полностью на тебе. Если можешь нести эту ответственность - в добрый путь.
Скажем, когда мы делали образцовое средство измерения ОКСИД-О, нам необходимо было коммутировать газовые потоки так, чтобы измерительный канал "отмылся" за разумное время (мы остановились на 1-й минуте) до тысячных долей процента. Негерметичность должна быть исключена на любом уровне... Потому как в ТУ на клапана, в методах измерений - герметичность проверяется только после 15 минут после перекоммутации (не спроста ведь, однако).
Ну вот, таки мы реально пошли на доработку усэповского клапана (П1ПР.5 по памяти): мембрана перекрывает не одно сопло, а два. При этом "средняя" между двумя соплами область оказывается под давлением ниже, чем в перекрытом рабочем канале (ну, скажем, давление сбрасывается через очень тоненький дроссель на выход). Поэтому гипотетическая негерметичность направлена не в рабочий канал, а из него. Следовательно, не оказывает метрологического воздействия даже теоретически.
Справедливости ради, следует отметить, что данная идея (которая уже нешаблонна) реализуется и стандартными средствами: вместо одного клапана ставишь два последовательно, и делаешь аналогичный сброс давления "в ноль" из соединения. Но мы решили, что ответственность за доработку штатного изделия - меньшая головная боль, чем технические и метрологические проблемы (увеличение габаритов изделия, объема "с закоулками" рабочего канала) шаблонного решения.
Да, дебатов было выше крыши, и решение было не простым. Такие решения действительно уникальны. Пожалуй, это единственный пример из моей практики.
Но это вовсе не слова, не чье-то "патологическое мнение", а реальное изделие. Доведенное до литеры И ((btw: более высокой серийности для образцовых средств измерений не бывает, и каждый экземпляр атестуется в Госстандарте. В России это Питерский ВНИИМ, на Украине - УкрЦСМ))

Тут Илья говорил, что не шаблонные решения крайне редки. Он не очень прав, мягко говоря.
Это, как говорится - КТО НА ЧТО УЧИЛСЯ. Так будет, если обучение программированию построено на заучивании шаблонов (высокопарно называемое "постановкой техники"), обучение физике - на заучивании формул, и т.д., и т.п..
А у меня - так почти все проекты имеют некие нетривиальные решения... Почему-то.

2) Вот Вы, Valery, очень справедливо говорили, что в аналоговой схемотехнике на ОУ практически типовым является шаблонное проектирование. Ну да: суммирующий усилитель, дифференциальный, интегрирующий, дифференцирующий, фильтр 2-го порядка наконец...
Поэтому я поясню, чем отличается шаблонное проектирование от нешаблонного на абсолютно реальном примере.
((btw: я специально оперирую примерами из собственной практики, чтобы любому, сказавшему, что это не более чем "слова" - мог привести в ответ название проекта, фамилии авторов, и где можно купить изделие. Ибо, навешивание ярлыков в качестве аргументации - уже достало несколько))
Скажем, разрабатывали мы магнитомеханический газоанализатор на кислород. На самом деле это просто измеритель магнитной восприимчивости газа - она у кислорода, оказывается, превышает остальные газы в несколько сотен раз. В общем, самый селективний метод из всех известных.
Чувствительный элемент - это просто махонькие крутильные весы, помещенные в магнитное поле. Ну типа, если вокруг газ парамагнитный, то "гантельки" выталкиваются из магнитного поля, что регистрируется оптикой (на крутильных весах есть и маленькое зеркальце). Когда-то давным-давно Капица усовершенствовал эту измерительную схему, сделав ее компенсационной - добавил на крутильные весы виточек с током, который взаимодействует с магнитным полем, из которого и пытается его вытолкнуть окружающий парамагнитный газ.
Это по быстрому и "на пальцах", чтобы была понятна задача электроники.
А с оптикой все просто - ИК-изучатель фокусируется на двух фотоприемниках, которые принимают отклонение крутильных весов по дифференциальной схеме. В этой оптике самым нестабильным элементом является светодиод, поэтому задача электронной схемы формулируется так:
  • Сформировать такой ток излучателя, чтобы суммарный фототок приемников оставался постоянным (обозначим эту константу как А)
  • Сформировать такой ток в рамочку крутильных весов, чтобы разностный фототок приемников оставался нулевым
  • Напряжение, пропорциональное компенсационному току крутильных весов и является выходным сигналом Первичного Преобразователя
Какая схема у нас получается методами шаблонного проектирования. Два каскада на ОУ - преобразователи фототок/напряжение. Один интегрирующий усилитель, питающий светодиод (он же выполняет ф-ю суммирующего усилителя от двух преобразователей и константы сравнения -А). Дифференциальный усилитель, к выходу которого подключены дифференцирующий, просто инвертирующий, и интегрирующие усилители. Наконец итоговый суммирующий усилитель, смешивающий в нужных пропорциях сигналы последних трех, для формирования итогового сигнала PID-регулятора.
Получается довольно мухобойная схема об восьми каскадах. Времена еще были советские, тогда и 140УД14 внести в перечень разрешенных к применению - не так просто было. Да и резисторы в метрологических цепях у нас было принято применять типа С2-29, а не мелкое барахло всякое... В общем, оно еще и на одну печатную плату не поместилось, а это и дополнительные наладочные, и пультовое оборудование, и много-много чего еще, о чем народу, именуемому "радиолюбителями" - и не ведомо вовсе.
И это было сделано на опытном образце. И работало, естественно.
А вот в Архив окончательно сдавали (и, само-собой - выпускали) нечто значительно более простое
((собственно, это была первая схема, сданная мной в Архив - приносят мне коллеги иэ отдела электроники схему типа на подпись, и заставляют расписываться в графе "Разработчик". И радостно сообщают: "ну а дальше - сам. Технологи, нормоконтроль... Хлебни-ка нашего хлебушка"))
А идея упрощения была очень простой: задача одновременного слежения за суммой двух сигналов =А, и за их же нулевой разностью - полностью эквивалентна слежению по отдельности, чтобы каждый из сигналов был равен А/2. Без дурацких заморочек с суммированием, вычитанием...
Сигнал одного фотоприемника сравнивается с А/2 интегирующим усилителем, и прямым ходом - на излучатель
Аналогично, сигнал второго сравнивается с той же величиной - и на компенсационную рамку крутильных весов. Правда цепь обратной связи у второго - немножко замороченная (можно сказать, что и нешаблонная) оказалась, для формирования закона PID-регулирования.
Ну вот и все, делов-то - на два ОУ

3) Можете себе представить, а я ведь интересовался у коллег - за каким лядом вы лепите схему максимальной сложности (какие-то упрощения, хоть и не столь фундаментальные - были видны сразу). В курилке, естественно...
Вы думаете, это от того, что более шаблонная схема - более читаема ???
Да ни в жисть!!! Все банальнее и проще - у людей впереди появляется понятно обоснованный фронт работ, которую понятно как делать. Просто обыкновенный совок.
Почеркну еще, что это отношение инженеров, которым вовсе не надо объяснять, что это в первую очередь рисуется для людей. Это как раз они мне эти вещи объясняли в те времена-то.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Август, 2010 23:23 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Galkov писал(а):
Тут Илья говорил, что не шаблонные решения крайне редки. Он не очень прав, мягко говоря.
Это, как говорится - КТО НА ЧТО УЧИЛСЯ. Так будет, если обучение программированию построено на заучивании шаблонов (высокопарно называемое "постановкой техники"), обучение физике - на заучивании формул, и т.д., и т.п..


Я этого не говорил.

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

У меня вот по текущей тематике архитектурные решения сплошь нешаблонные (так вообще никто не делает), а реализация - тупее некуда.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Август, 2010 04:46 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
На сообщение: viewtopic.php?p=50114#p50114
Илья Ермаков писал(а):
Люди, вообще говоря, развиваются. Как и организации, и их проекты, и их потребности. Для меня нет "кодера", для меня есть начинающий участник работ, которому предстоит развиваться. Но начинать с основ - конкретного опыта и конкретной техники. (Признаюсь честно - врождённым "гениальностям" и эффективности "самородных талантов" я не очень доверяю - хотя бывает, что они оправдывают доверие. А вот возможности постепенного, упорного развития - доверяю. Мозгу нужна хорошая пища, которой его нужно кормить, остальное - эволюционный процесс).


Согласен, как и с большинством суждений Ильи. Вообще "кодера" можно рассматривать как рабочего в сфере производства инфопрогизделий... а снисходительное отношение к рабочим, как учит нас (м.б. не всех? :)) история, неоправдано... если он не может просто кодировать, а начинает изобретать - пожалуй, ему пора и правда на более высокий уровень, скорее всего после доподготовки соответствующей. Этот уровень - в традиционных терминах техника-программиста - а если нынешняя система организации данной предметки не предусматривает этого (тут и Valery Solovey говорил о том же - что делают крайности - либо "сильных", либо тупых) - то надо просто подтягивать предметку до уровня организации материального производства. Конечно, это дело сложное, но суть его ясна. Тогда смотря диалектически - если некое принципиальное противоречие инфопрогпроизводства сегодня не в этом, то в чём? Думаю, одно из противоречий просматривается опять-таки из замечательной работы о Model Checking, если взглянуть на неё с организационно-экономической точки зрения.

Итак, в работе фактически предлагается реальный выход в практику того самого доказательного программирования, которое активно пропагандируется и на этой конференции. Какой же практический результат достижим на сегодня данным методом?
Высокая сложность ModelChecking-процесса требует его автоматизации для обеспечения широкого применения, и уже есть соответствующие среды. Автор (Ю.Г. Карпов) указывает по крайней мере одно очевидное ограничение в представлении реальных алгоритмов и программ для автоматизированной ModelChecking-верификации (на примере системы Spin и её входного импер-ЯПЗ Promela) - используются только простые типы величин, чтобы избежать текстуально неограниченной области их определения (которая обретает конечность только по результатам исполнения). Невозможно специфицировать ни типы последовательные, ни произвольные структуры с указателями, ни даже вещественно-числовые (последнее, кстати, вызывает вопрос - а что, у них не конечная, заранее фиксированная разрядная сетка мантиссы и порядка и соответственно множество возможных значений? ну да ладно м.б. здесь какая-то математическая тонкость, вроде выявленного Петровым влияния ошибок вычислений на корректность метода вычислений, сформулированного без учёта этих ошибок :|). Т.о. будущая программа должна оперировать этими типами величин, т.к. для них она была верифицирована (полагаем, что в конце концов успешно, т.е. контрпримеры после неоднократного их осмысления и внесения нужных изменений в спецификацию наконец перестали возникать :)). А если по принципиальным соображениям необходимы иные типы? Получается, тут мы пока входим в область работы ума, основанной подчас и на интуиции - изменятся ли верифицируемые свойства от введения качественно иных типов величин или нет?
Атомизация операторов - по сути дела, это их укрупнение, когда несколько действий совершаются в одном неделимом операторном ("иконном") цикле. Понятно, что в полноценной РДП-среде это делается "на раз" тем же "областным методом", о котором говорил в этом сообщении.
Видимо, следствием ограничения типов является и отсутствие файловых операций в Promela, т.к. они применимы к последовательному типу, а это опять из числа текстуально не конечных. Очевидно, надо моделировать операциями ввода-вывода в порты файловых устройств :?:

Что же мы имеем? Получается, описание, на котором сегодня можно доказать формально и автоматизируемо правильность программы (системы программ), является упрощённым, идеализированным (чего не скрывает и Карпов). Между ним и реальным изделием, по сути, устанавливаются такие же отношения, как в материальном производстве между реальной деталью (узлом, изделием) и её чертежом. И точно так же конструктор проводит всё расчёты для идеальной модели, заданной в его документации. А при изготовлении неизбежно возникают отклонения от идеала - особенности реализации операторов на прогязыке разработки, детализация кода (снятие ModelChecking-атомизации, которое д.б. корректным), ну и т.п. И техник, и рабочий должны не допускать брака в изготовлении. А значит, каждого из них никто не освобождает от необходимости думать, правильно ли он изготавливает - в аспекте своего уровня, разумеется. А готовят ли их именно к такой интеллектуальной деятельности? Вот здесь, по-моему, и лежит пока ещё не преодолённое противоречие. И то, что говорит Илья о постановке техники - это именно путь к его преодолению - надо только сформулировать цель приложения техник не только для инженерно-конструкторского, но и для последующих уровней данной сферы производства. Можно это показать на примере, затронутом в данной ветке:
Galkov писал(а):
В моем понимании, если у кого-то очень хорошо поставлена "техника укладки кирпичей", то это вовсе не означает, что он уже Строитель. Т.е. сможет построить Дом (надежный, имеется в виду).

Илья Ермаков писал(а):
Без техники нет выхода на более высокие уровни.

Ну, давайте поговорим о кирпичной кладке целостно :D Да, в практике обычный мастер-кладчик может класть, допустим, русскую печь или камин. Делает ли он это как попало? Нет, он пользуется т.н. "порядовками" - схемами кладочных слоёв, отражающими правильное с т.зр. назначения и одновременно физически реализуемое размещение кирпичей (ясно, что нельзя положить кирпич совершенно произвольно, напр. без опоры на другой в предыдущем слое :lol:). Когда-то он изучал эти схемы по чертежам или по работе мастера-учителя, постепенно освоил и кладёт автоматически, только сверяясь с источником (а часто наиболее употребительные держит в голове). При этих условиях для достижения результата ему достаточно хорошей техники укладки кирпичей во всех возможных связках (скажем, положить кирпич в текущем слое с частичной опорой на предыдущий слой нужно обычно в консольное защемление с кирпичом из слоя выше текущего :)).
Однако откуда взялись эти порядовки? Из результатов труда проектировщика. Согласимся, что это качественно иной труд. При этом возможно (и на самом деле изначально так и было), что результаты получались эмпирическим путём, как обобщение опыта эксплуатации печей, сложенных без первоначального проекта, интуитивно. А что было необходимо для накопления этого опыта? Дык ведь хорошая техника кладки - чтобы всё, что пришло в голову, не развалилось сразу после постройки, и можно было бы понаблюдать за его работой :wink: Вот и выходит, что на качественно иной уровень, чем кладка - оптимальное проектирование выкладываемого - не выйти без освоения более низкого уровня собственно кладки... Так что классический случай когда "каждый по-своему прав" :) - просто Galkov выделяет одну составляющую, а Илья другую


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

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


Последний раз редактировалось Владислав Жаринов Суббота, 03 Декабрь, 2011 05:37, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Август, 2010 16:23 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Galkov писал(а):
4) Зачем я все это говорил... Ну надо же как-то объяснить, что я понимаю под нешаблонным проектированием.
Коротко не получается.
Надеюсь я таки объяснил, что моя нешаблонность не имеет ничего общего с рукосуйством тех рационализаторов (опять же - разные бывают по жизни, в т.ч. и такие, что лучше тебя в теме), которых следует убивать при встрече
А как раз в точности наоборот
Ничего против сказать не могу. Хорошее проектирование я себе именно так и представлял.
Но опять же, ОУ использовался как ОУ. Насверлить дырочек и вывести оттуда дополнительных выводов никому в голову не приходило. Я назвал это поставленной техникой, а Вы считаете это чем-то другим? Ну пусть так. Но тогда и все мои предыдущие сообщения тоже нужно будет трактовать несколько иначе.

Galkov писал(а):
3) Можете себе представить, а я ведь интересовался у коллег - за каким лядом вы лепите схему максимальной сложности (какие-то упрощения, хоть и не столь фундаментальные - были видны сразу). В курилке, естественно...
Вы думаете, это от того, что более шаблонная схема - более читаема ???
Да ни в жисть!!! Все банальнее и проще - у людей впереди появляется понятно обоснованный фронт работ, которую понятно как делать.
А вот эти умеют быстро скомпоновать шар с кубической полостью. А раз это у них получается быстро, то развиваться дальше они зачастую не хотят. Хотя понимают, что перспективы есть; просто нет мотивации.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB