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

на сервере автора 2018-3-17 инд. 2-65-1

Вступление;
Земледельческий подход к творчеству в программировании;
Творчество это добро? Зло тоже может быть творческим? Или кто пишет вирусы?
В чем посчитать «кпд» творчества?
Пример языка программирования для творчества.
Выводы - творчество это потребность, такая же, как потребность в еде и питье.
Литература и источники информации.

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

Вступление

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

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

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

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

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

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

Формируем условия для получения результата – программы. Даем свет – цель программы, обеспечиваем ствол пространством. Рабочее место у программиста. И запускаем процесс по кругу.
В начале плоды, т.е. программы, будут маленькие и не вкусные. Но путем селекции, «подкармливания» нужных задач, и удаления не нужных получим требуемые результаты.
Есть ли тут творчество? И да, и нет. С точки зрения создания программ – это творчество. С точки зрения организации – это обычное земледелие. Бросаем зерно (идею для программы) и начинаем ее растить.
Пример из современности. Случайный не подготовленный бомж, и научили его программировать. Однако, все равно он остался в личности – бомжом.
Из прилагаемого подхода нужно выделить главное. А на взгляд автора главное - это результат. Это плоды. Плоды – это программа! Программа далее создает новое рабочее место, новый «ствол» новое «дерево».
Есть пословица «вилами по воде писать». К программированию это очень подходит. Оценить работу программиста по количеству кодов, или по каким то, сложным вычислениям невозможно. Есть только один способ, сформулировать задачу таким образом, что бы был ожидаемый ответ: да или нет. Программа задачу выполняет – программист написал программу и достоин оплаты.

Вывод:

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

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

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

Страшная историческая преамбула дана с целью доказать, что творчество не имеет понятия добра или зла. Это критерии человеческого социума. Творчество – это создание нового. А вот применение этого нового уже может быть разным.
Известная ситуация с писателями вирусов. Автор предлагает оценить свою программу по контролю за уровнем wi-fi Почти все антивирусные программы сообщат, что это опасная программа, которая требует ресурсов администратора, и может сделать что – либо плохое. Но встречный вопрос, для контрольных программ, как можно контролировать что то, не имея доступ к этому?
Анекдот в тему: … Товарищ прапорщик, а можно я посмотрю телевизор? – Можно, смотри – но не включай!
Все существующие программы, могут иметь «злое» намерение! Это зависит только от намерения их использовать. Классический пример программа format.
Анекдот в тему: На заре игровой эпохи, и DOS. Вечером компьютерный администратор остается в офисе с целью познакомиться с новой игрой. Утром его видят за клавиатурой с нажатыми клавишами и выпученными глазами. – Ребята! Она сказал (программа) – отпустишь клавиатуру – отформатирую диск!
Для формирования «злой» программы используется, известный метод разделяй и властвуй. Формируем программисту цель – ближнюю, а дальнюю ему не рассказываем. Например, вот тут у нас протокол обмена данных. Надо написать такой - же, но с большим объемом условий обмена. И честный добросовестный программист, разбирается в предложенном протоколе, и дальше его усовершенствует. Он проявляет творчество и смекалку. Но его труд, может быть использован в «злом» умысле. Например, с целью кражи (кража – это тайное похищение чужого имущества ст158 УК.)
Этот подход использования творчества в злых умыслах, хорошо сейчас отображается и в кинематографе. Много фильмов где нанимают «умных» студентов или «ученых», которые создают или наркотики, или забираются в закрытые базы данных и т.п.

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

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

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

Ранее в этой теме отмечался такой постулат - сформулировать задачу на программирование таким образом, что бы был ожидаемый ответ: да или нет.
Но это, как бы черно-белый вариант ответа. Значит надо приблизить задачу программиста к задачи объекта, с которым работает его программа.
Чем больше пользы от программы у объекта, тем больше кпд программиста.

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

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

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

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

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

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

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

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

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

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

Получается, что система сбора данных есть, а КПД от программ по сбору, «красота» и эффективность системы низкая.
Посчитать кпд программы и данной системы можно рублях. Например: без системы мы тратили за период в один месяц 1 000 000 рублей, а с системой учета мы тратим 900 000 рублей. Т.е. в месяц экономии 100 000 рублей. Затратили на ввод системы 500 000 рублей, значит, за 5 месяцев она окупилась, и после приносит нам пользу по 100 000 рублей ежемесячно.

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

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

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

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

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

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

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

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

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

Программу в одном файле с минимальным размером. Чем меньше файлов и меньше размер, тем меньше шансов, что - то потерять, забыть;
Описание программы. Чем оно подробнее тем, конечно же лучше;
Текст программы на языке программирования. Для того, что бы можно было, что-то исправить в эксплуатации программы;
Компилятор текста программы. Для того, что бы из текста получить исполняемую программу.

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

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

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

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

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

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

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

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

Таким образом, у пользователя все есть. И очень Важный момент, работающая программа содержит в себе все необходимые компоненты для развития и исправления.
Опыт подсказывает, что возвращаться и исправлять старые программы для программиста очень тяжело. Он многое забыл. Он забыл: где находятся эти тексты, где тот компилятор, на котором эти тексты делались. Он забыл задачу программы ее алгоритм и т.д.
В данной программе все и текст и компилятор и задача. И самое главное, тот первичный программист уже и не нужен. Можно ставить задачу другому программисту. Дело конечно за малым – знать язык программирования Forth.
Данную программу можно, конечно же, написать и на других языках программирования. Но основная задача именно – ВСЕ В ОДНОМ МИНИМАЛЬНОМ ФАЙЛЕ решается, по мнению автора наиболее удобно, на форте.

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

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

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

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

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

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

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

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

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

Существует классификация производство для производства и производство для потребления. Группа А- производство средств производства, группа Б – производство средств потребления. Программирование это что? Это производство средств производства.
Анализ творчества позволяет предположить, что это потребность человека. Если человека не кормить, не поить, - произойдет физическая гибель. А если человека ограничить в творчестве – произойдет духовная, нравственная гибель.
Существует очень много примеров, когда ограничение в творчестве приводит к уничтожению человека как личность.
Тема технологии творчества, похожа на технологию питания. Можно питаться плохо, без витаминов и без всяких изысков. Организм ослабнет. Аналогично и с творчеством. Не давать возможности проявить возможностей индивидуальности, ограничивать в письменности, в искусстве – и духовный мир человека окажется низким. Сформируется только физиологическое существование.
Технология творчества пересекается с темой теории решения изобретательских задач. Основателем теории являлся Г.С. Альтшуллер (15.10.1926 - 24.09.1998) – писатель-фантаст, инженер, изобретатель. Не вдаваясь в суть, кратко, в ТРИЗ, творчество поставлено на промышленную основу.
Исторический пример: Любой грамотный человек, прочитав теорию, может научиться по углу и расстоянию до объекта определять высоту объекта. Но в 17 веке, это была целая тайная наука и специально ее изучали, что бы водить корабли. Но всем ли надо водить корабли? Нечто подобное и с ТРИЗ, все ли у нас творцы и занимаются изобретательством?
Программирование, по мнению автора, это верх абстрактного творчества. Требуется ввести очень много понятий, обучить всяким приемам и даже просто печатать на клавиатуре. Но все равно это обычная работа по созданию продукта, который должен использоваться. Нет использования программ, нет и творчества.
Придуманы различные приемы для увеличения программисткой производительности. А если посмотреть аналогии в промышленности, такие же приемы и в программировании. Генри Форд придумал использовать конвейер. А была задача увеличить производительность труда. В программировании так же есть метод конвейера. Группа программистов разбивается на задачи, и делает свои задачи, а затем это складывается в единую программу. Самое важное, это уметь программировать программистов. Опять возвращаемся к ситуации - задача на программирование. И оценка достижения результата.

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

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

10-6-2015 получены замечания от руководителя Губарева Василия Васильевича

Замечания планируется учесть в дальнейшей работе.
Реферат зачтен с записью в ведомости учета обучения.