Не для житейского волненья,
Не для корысти, не для битв,
Мы рождены для вдохновенья,
Для звуков сладких и молитв.

Николай Некрасов: «ПОЭТ И ГРАЖДАНИН»  1856

@  С музыкальным сопровождением.      

 

 

 

Реферат

« Технологии творчества в программировании»

 

адрес документа : http://www.shabronov.narod.ru/temp/f_referat_v2/f_referat_v2.doc

 

 

Оглавление

 

 

 

 

 

 

Новосибирск – 2015 г.

Вступление

В строках поэта 18-го века декларируется  интересный постулат -  человек рожден для вдохновенья. Далее идет «звуков сладких»  и «молитв».

 

 

В данном реферате автор постарался отразить «творчество», «вдохновение», «технологии» и «методы», в новом явлении человечества – компьютерное программирование.

За примерный период в 200 лет  резко увеличилась новая область в жизни человечества -  информационная. Творчество было и осталось.  Появились программы и программисты. В реферате   «программирование»  понимается в плоскости «конструирование» «создание».  Автор постарался отразить свое видение в «создании» и  «творения» программ.

 

Земледельческий подход к творчеству в программировании

 

Рассмотрим «земледельческий» подход в программировании. Ниже на рисунке автор попытался отразить это понятие.

 

Вывод:

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

 

Творчество это добро? Зло тоже может быть творческим? Или кто пишет вирусы?

 

Представьте себе инженера. Добросовестного, честного, патриота своей страны,  перед которым поставлена инженерная задача  – довести выпуск продукции до максимально возможного.  Ну и что?  - Да только дело в том, что продукция – эта – «умервщление»  людей в  Освенциме. Инженер подумал, проявил творчество, и появился газ «циклон», объем продукции резко увеличился.  И кто он после этого?  Личность творческая или нет? 

Вывод.   Творчество не имеет понятия добра и зла. Но существует понятие ПРАВО!  Существуют государственные судебные инстанции, а так же Высший Суд. Высший Суд в смысле  понятия добра и зла. Заповеди «не убий», «не укради и т.д.   Важно, понимать, что кроме творчества, у творца (программиста)  обязательно должна быть и оценка своего творчества. И оценка творчества должна быть независимой. Не забывать классику «А судьи кто?»

В чем посчитать  «кпд» творчества?   

 

Вернемся к анализу творчества программиста. Как узнать коэффициент полезного действия. Вот он работает, написал программу.  Полезная программа  или нет?  

Приведем пример на основе авторской работы по введению системы АСТУЭ на одном из Новосибирских промышленных объектов  под названием ОАО «ВиммБильДанн» .

Задача: - создать Автоматизированную Систему Технического Учета Электроэнергии – АСТУЭ

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

Программная часть: - программа сбора данных и учет расходуемой энергии; Ниже структурная схема

 

  

 

 

 

 

 

 

 

 

План завода и расположение основных  элементов и узлов ТП РП.

 

 

·        2012-2014гг. – смонтированы счетчики и удаленный доступ;

·        2015г - программное обеспечение – автоматический доступ к любому счетчику их более 80шт;

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

 

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

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

Выше, приведенный пример, лишь  ожидаемый вариант. И может быть, он реализуется. А, может и нет!

Вывод. КПД считать надо в классическом понятии, сколько затратили и сколько получили. Если для электромашин или двигателей это понятное действие.  Например, мощность на моторе расходуется в 1000 ватт, а крутит и поднимает на 100 ватт, вот и кпд в 10%.  Для КПД программиста, это те же понятия, но разнесенные по времени, на больший срок.

Затратили на программиста электроэнергию, кормили его, поили, и он за период сделал нам программу.

А эта программа за такой же период, нам уменьшила расходы на производстве. Вот и КПД.    

Пифагор утверждал  «Истина есть число». Оценка программиста и его КДП должен оцениваться числом.

Если утверждать: это блестящая, отличная, мощная программа. С отличным дизайном и великолепным интерфейсом. То это все не  истина, а только лишь слова. Проверить можно только число. 

 

Пример языка программирования для творчества.

В этом разделе автор пытается доказать, что существует язык оптимальных программ – Форт (Forth).  И он наиболее подходит под творчество. В электронной версии реферата, ссылки  «кликабельны» на сайты по форту.

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

 

Как бы, такое 'яйцо', которое бы содержало в себе ВСЕ ДЛЯ РАБОТЫ и РАЗВИТИЯ.

 

Данный подход не приветствуется из-за своей НЕ ВЫГОДНОСТИ в финансовом понимании. Все программные продукты, стараются делать так, что бы затем вновь приходилось обращаться к программистам или посредникам от программистов.

Но есть и другая сторона. Как такую оптимальную программу сделать? На каком языке программирования.  Для таких условий подходит язык программирования Форт.  Покажем на конкретной программе, как это делается.

 

Рассмотрим объект и авторскую программу – автоматизация сканера штрих-кода. Программа skaner_dx6400_kmk_v1.exe  она имеет размер до 11 мб. Содержит в себе выше перечисленные элементы, доступна для модификации и имеет полное описание работы.   

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

 

 

 

Если Вы пользователь, то выполняете  нажатие клавиши 2 и восстанавливаете файл инициализации. Повторный запуск использует данные и программа работает.

Если Вы программист, и планируете модифицировать программу, то выполняете нажатие клавиши 3 и получаете каталог с текстом программы, с файлами описания и компилятором текстов.

Алгоритм  изменения программы приведен ниже на рисунке. Нормальный режим – это пользовательский. Режим новой программы – это модификация исполняемого кода.

 

  Небольшие аналогии и замечания на подход  «все в одном файле» - при поставке программного обеспечения заказчикам:

1.        Как известно Бил Гейтс – основатель фирмы «Maйкрософт»  принципиально отказался от передачи исходных кодов своей системы Windows. И нажил достаточно много денег. А сколько он нажил себе врагов-недображелателей? Кто не ругал «Винды»? А исправить то и нельзя. Исходных кодов нет. Получается вроде красивой машины, которую тебе продают, но, о ее недостатках и изъянах умалчивают. С машинами проще, это железо – разбирай и чини. Или обращайся с поломанной запчастью к поставщику. А самое главное – можно и самому починить, заменить то, что сломалось. А вот с программой так не получиться! Даже если и знаешь что, у тебя не идет в работе. Нет исходных кодов! Нет этого языка программирования!

 

2.        Программы на ZX-Spectrum, на ДВК, Электронику-60 – очень много затрачено труда, а воспользоваться сейчас этим трудом НЕВОЗМОЖНО, БЫСТРЕЕ НАПИСАТЬ ПО НОВОЙ. Есть, например, эммулятор под ZX-Spectrum и программы. Пожалуйста, попробуй что-либо перевести на современную технику. И вновь столкнешься с составляющими программного продукта: текст программы, описание программы, компилятор программы. И если это было все в одном файле, перевод на новую платформу был бы значительно проще.

 

 

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

 

4.        Но 'продвинутые' пользователи скажут – а на это есть архиваторы и упаковщики. Поставляйте все компоненты в одном файле, и все будет в порядке. Они не правы. Почему? К сожалению, ни один из известных мне архиваторов не смог выполнить поставленную задачу. Сделать такой единый файл, что бы и работал и распаковывался.  И кроме того, сам Форт – архиватор. Коды приведенной программы сжать – более сильно не получиться. Попробуйте сделать из приведенной exe-программы, одновременно  «самораспаковывающийся» и «самозапускающийся» файл.

 

 

5.        А что же с пожизненной рентой  программиста на свои программы? К сожалению – ничего. «Доить» пользователей «улучшательством» и «продвинутостью» будет сложнее. Но, зато спокойней будет жить. Сделал программу. Она работает - получи свои «бабки». И при всех раскладах обратиться ли пользователь или нет, работать можно уже начинать не с нуля. И самое главное искать ничего не надо, все есть у пользователя в одном файле.

 

6.        Достаточно просто доказать АВТОРСКОЕ ПРАВО. Один файл, значит, есть его контрольная сумма или просто количество байт. Один файл быстро проверить или даже найти на компьютере. Свой продукт очень просто отличить от подделки по той же контрольной сумме или количеству байт.

7.        И противоположная проблема -  ответственность программиста за свои программы. Можно всегда сказать пользователю. Вам дан один файл, с такой то, контрольной суммой и количеством байт. Вот он и должен работать. Любые изменения не допускаются.

Выводы - творчество это потребность, такая же, как потребность в еде и питье

 

Вывод по теме реферата:

1.           Сформировалась целая область человеческих потребностей – программирование. Можно ли отказаться от программирования, наверное, можно – но тогда, надо отказываться и от всех возможностей интеллектуальной обработки информации.  «Процесс пошел» - сначала резко, по экспоненте. А теперь он вошел в русло технологии.  Дальше он придет к пределу. По типу предела скорости звука, или скорости света. Как бы, не старались увеличить скорость написания программ, все равно не увеличишь. Требуется менять принципы. Наверное, скорость программирования увеличится при появлении разумных и интеллектуальных систем на другой, не биологической основе.  

 

2.          Программирование и технология творчество в написании программ упирается в объект, с которым работает программа. Если этот объект «тяжелый», «перевернуть» программой  и получаемыми данными его не получиться.    

 

3.          Приведем  аналогии и видим  вывод по «тяжести» объектов для информации.  Исторический пример на 1941 год. Какие бы данные не давали Сталину о том, что Гитлер готовиться к войне и будет нападение. Действий не последовало.  Промышленный пример на 2015 год. Какие бы данные по расходу электроэнергии  на ОАО «ВиммБилльДанн» не давали генеральному директору. Действий не последовало. Оговоримся, что это текущие данные. Подтверждение или опровержение еще окончательно утверждать рано.

 

4.          Автор пессимист в области новаций. Он считает, что сделать новое, придумать технологии можно, но мышление человека вторично. Все новое воспринимается человеком, как враждебное, и он инстинктивно борется с этим. Победить творческое может, если только есть аналогии  и конкуренция. В монополиях творчества мало. Опираться можно только на то, что сопротивляется (Блез Паскаль). Или как в анекдоте: … Сверху дали «Добро»!  Внизу чертыхнулись и начали выполнять. Вот так добро побеждает зло!

 

5.          Автор считает подход в новациях, в  технологиях творчества возможен только в совокупности с объектами творчества. Нельзя отрывать обработку данных от самих данных. Только постепенный, плановый, анализаторский подход в программирование позволяет получить максимальный кпд программ.

 

6.         Врачи не рекомендуют переедать, но тогда и в творчестве, тоже должен быть разумный плановый и расчетливый подход. Если Вы намерены получить результаты и реальный КПД.

 

Литература и источники информации

В электронной версии все ссылки текста «кликабельны»

· ТЕХНОЛОГИЯ ТВОРЧЕСТВА. Авторский курс. к.т.н. профессора Теребило Г.И. Новосибирск - 2010. I. Организационно-методический раздел 1...  URL: http://www.irso.ru/about/staff/detail/64    См

·                    Обзор: Историк Борис Юлин про индустриализацию    URL:http://www.youtube.com/watch?v=4g5RtR6eMHM

· Обзор:  Письмецо в конверте будит ум – поверьте http://nnm.me/blogs/botanic22/pismeco-v-konverte-budit-um-poverte/

·                      Теория решения изобретательских задач   URL: http://books.rusf.ru/unzip/add-on/xussr_av/altovg28.htm?1/5

·                     Генри Форд – Организовавший конвейер  URL: http://100grp.ru/xx-vek/genri-ford-organizovavshij-konvejer/

·                     Винер об информации и энтропии  URL: http://dalido.narod.ru/NW/NW-quotr3.html

·                     Губарев В. В.  Основы многоцелевых многофункциональных методов и средств  http://kekmir.ru/members/person_513.html

·                    Губарев В. В.  Введение в теоретическую информатику : учебное пособие URL: http://elibrary.nstu.ru/source?id=44362

 

09-4-2015  

Подготовил аспирант кафедры ТЭ  Шабронов Андрей Анатольевич.

 тс +7-913-905-8839 shabronov@ngs.ru