автоматизация программирования это создание исходного кода
Автоматизация программирования
Смотреть что такое «Автоматизация программирования» в других словарях:
автоматизация программирования — Выполнение на компьютере операций, приведенных в составленном человеком алгоритме решения определенной задачи. К таким операциям относятся: составление структуры программы, точная формулировка каждой операции, получение программы и проверка ее… … Справочник технического переводчика
АВТОМАТИЗАЦИЯ ПРОГРАММИРОВАНИЯ — 4.5. АВТОМАТИЗАЦИЯ ПРОГРАММИРОВАНИЯ Раздел программирования, занимающийся разработкой методов автоматического составления программ и решение задач на ЭВМ по спецификациям, представленным на некотором формальном языке ² Источник: РМ 4 239 91:… … Словарь-справочник терминов нормативно-технической документации
АВТОМАТИЗАЦИЯ ПРОГРАММИРОВАНИЯ — использование вычислительных машин для автоматич. получения машинной программы по нек рой исходной записи, более близкой к начальной формулировке задачи. Содержание А. п. меняется со временем, отражая общее развитие средств общения человека с… … Математическая энциклопедия
АВТОМАТИЗАЦИЯ ПРОГРАММИРОВАНИЯ — автоматич. составление программ ЭВМ по заданному алгоритму с помощью самих ЭВМ. При А. п. ЭВМ выполняет следующие осн. ф ции: составление программы, реализующей заданный алгоритм, и её описание на выбранном языке программирования; проверка… … Большой энциклопедический политехнический словарь
АВТОМАТИЗАЦИЯ — 4.2. АВТОМАТИЗАЦИЯ 1. Внедрение автоматических средств для реализации процессов СТИСО 2382/1 Источник: РМ 4 239 91: Системы автоматизации. Словарь справочник по терминам. Пособие к СНиП 3.05.07 85 Смотри также родственные термины: 6.… … Словарь-справочник терминов нормативно-технической документации
Автоматизация — Автоматизация одно из направлений научно технического прогресса, использующее саморегулирующие технические средства и математические методы с целью освобождения человека от участия в процессах получения, преобразования, передачи и… … Википедия
АВТОМАТИЗАЦИЯ ПРОЦЕССА ПРОГРАММИРОВАНИЯ — Отстранение человека от процесса написания программного кода, как полностью, так и частично. Достигается путём: 1. Разработки инструментария для формулировки и постановки задачи от человека машине (человеко машинный язык). 2. Представлением… … Словарь бизнес-терминов
АВТОМАТИЗАЦИЯ ПСИХОЛОГИЧЕСКОГО ЭКСПЕРИМЕНТА — применение автоматических устройств (и прежде всего ЭВМ) для решения задач экспериментального исследования. К числу таких задач, прежде всего, относятся: планирование (в соответствии с замыслом экспериментатора) и определение нужной стратегии… … Энциклопедический словарь по психологии и педагогике
Автоматизация процесса программирования — Автоматизация процесса программирования отстранение человека от процесса написания программного кода, как полностью, так и частично. Достигается путём: разработки инструментария для формулировки и постановки задачи от человека машине… … Википедия
АВТОМАТИЗАЦИЯ ПРОЕКТИРОВАНИЯ — применение средств вычислительной техники и оргтехники при проектировании приборов, машин, систем, сооружений и т. п. (от расчёта хар к проектируемого изделия до изготовления технич. документации и анализа результатов испытаний готового образца) … Большой энциклопедический политехнический словарь
Как автоматизировать процесс программирования
В статье рассмотрены принципы функционирования IPGS (Intellectual Program Generation System) — отечественной интеллектуальной системы автоматизированного программирования, качественно отличающейся от большинства аналогов.
Применение естественного языка для постановки задач
Если кратко проследить эволюцию алгоритмических языков программирования, то станет очевидным, что прогресс их развития направлен в сторону «очеловечивания» первоначального машинного языка. Круг современных языков непрерывно сужается и стабилизируется. Видоизменяется также и процесс программирования, причем наблюдается переход от привязки к какому-то конкретному языку (когда он применяется как инструмент для написания программы) к зависимости от конкретной среды программирования (когда в ней с учетом специфики решаемой задачи и используемых данных может быть применен тот или иной язык).
Думается, что вскоре произойдет окончательный переход на универсальные компиляторы, благодаря чему разработчик ПО сможет сосредоточиться на логике алгоритма своей программы и не заботиться о синтаксисе конкретного алгоритмического языка программирования. Тогда можно будет автоматизировать построение алгоритма. Все это в конечном итоге приведет к новому этапу взаимодействия между пользователем и компьютером. Сегодняшний компьютер из инструмента для создания и воплощения программных продуктов превратится в разумного электронного помощника, способного общаться с человеком на естественном языке в процессе совместной работы. Причем пользователь будет формулировать свои задачи перед компьютером на естественном языке без «посредника», т. е. без прикладного программиста, место которого займет эксперт в данной области знаний, необходимый для постоянного пополнения банка знаний машины.
Поэтому представляется актуальной полная автоматизация процесса программирования. Сейчас уже появились как зарубежные, так и отечественные разработки, способные в той или иной степени автоматизировать процесс программирования, т. е. обеспечить построение программы из заранее предложенного набора элементов на основе формального описания алгоритма задачи и т.д. При этом значительная часть предлагаемых программных комплексов узко специализированы, значит, и исходные задачи для них, как правило, формулируются на специализированных формализованных языках, а иногда — на ограниченных естественных или построенных в виде графических объектов.
Принципы работы системы IPGS
В нашей системе IPGS сделана попытка освободить пользователя от изучения каких-либо исходных специфических языков описания и сформулировать задачу на естественном языке. Но поскольку такой язык очень противоречив и многообразен, то пришлось ввести определенные ограничения. В чем же они заключаются? Во-первых, установлен строгий порядок слов в предложении: подлежащее — сказуемое — остальные члены предложения. Причем программа проверки порядка следования слов при формулировке любой задачи исключительно сложна. Во-вторых, необходимо привязать текст к определенной предметной области. В-третьих, следует составлять научные тексты на естественном языке с использованием деловой лексики.
В связи с последними двумя ограничениями базы данных (БД) и базы знаний (БЗ) требуют соответствующего информационного наполнения. При этом действия должны выполняться в следующей последовательности:
Каким же образом данные процессы взаимодействуют? Из каждого процесса, исключая первый, можно возвращаться на предыдущие. Взаимосвязь происходит через БД, информация в которых создается на основе исходных данных, БЗ и взаимодействия с пользователем. Полные сведения о предметной области в БЗ, естественно, содержаться не могут, они накапливаются постепенно в результате решения множества задач. В создаваемом комплексе программ поставлена цель добиться его самообучения в процессе взаимодействия с пользователем при решении конкретной задачи. Необходимый минимум знаний о предметной области формируется заранее.
Рассмотрим на примере простейшей задачи, как работают перечисленные выше процессы, конкретнее определим, является ли натуральное число совершенным. При анализе текста задачи, составленного на ограниченном естественном языке, выполняются морфологический, синтаксический и семантический анализ. В целом работа первого процесса основана на хорошо известных теоретических принципах анализа естественного языка и методах построения семантических сетей на базе полученной в ходе анализа морфологической и синтаксической информации. Отметим, что в результате семантического анализа создается семантическая сеть задачи, где укрупняются словосочетания в соответствии с существующими понятиями в предметной области, а также синтаксические связи заменяются объектно-целевыми (семантическими). В нашем примере семантическая сеть показана на рис. 1.
Остановимся на работе последующих двух процессов, основанных на совершенно новых теоретических подходах. По информации, находящейся в семантической сети задачи, происходит поиск соответствующих обозначений в классификационной семантической сети (рис. 2) и соответствующих понятий в семантической сети понятий (рис. 3). Если понятие отсутствует, то оно либо будет оставлено в виде обозначения, чтобы впоследствии уточнить его у пользователя или экспертной системы, либо будет задействовано напрямую (как в данном случае) при логических преобразованиях семантической сети в сеть, представляющую план решения задачи.
Понятия могут определяться функционально — в виде закона, правила, алгоритма или формулы. Они представляют собой заранее заложенный минимум знаний (встроенные справочники), постоянно пополняющийся в процессе работы системы. Понятия также определяются через другие понятия, которые, в свою очередь, рано или поздно либо будут заданы логически или функционально, либо станут неопределяемыми (первичными), например «точка», «прямая» и т. п., для которых вводятся функциональные правила. В рассматриваемой задаче используются понятия, описанные во встроенном справочнике арифметических операций, т. е. простые арифметические операции или совокупность таковых (табл. 1).
 |
| Таблица 1. Фрагмент встроенного справочника арифметических операций *0 — описание арифметической операции, состоящее только из группы операторов; 1 — описание арифметической операции, включающее имена других арифметических операций; ПР — арифметическая операция в виде отдельной процедуры; Ф — стандартная арифметическая функция. |
В результате получается функциональная семантическая сеть, в которой хранятся обозначения, законы, правила, алгоритмы и формулы, необходимые для последующего построения плана решения исходной задачи. Они соответствуют понятиям или совокупности понятий в семантической сети понятий. Здесь имеется в виду, что могут быть такие понятия в семантической сети понятий, которым соответствуют некоторые фрагменты функциональной семантической сети. Причем отдельным фрагментам функциональной сети могут соответствовать несколько понятий в сети понятий. В сложных случаях некоторые вершины функциональной семантической сети могут также являться фрагментами функциональной семантической сети более низкого уровня. Процесс построения функциональной семантической сети для нашего случая более простой (рис. 4—6).
«Наложение» полученной функциональной семантической сети на семантическую сеть задачи с одновременной заменой целевых и указательных слов из таблицы целевых слов определенными символами (табл. 2) в целом дает первоначальную семантическую сеть плана решения задачи. При применении правил сопоставления, содержащихся в базе знаний, она преобразуется в конечную сеть плана решения.
Описание фрагментов этой сети в определенной последовательности дает план решения задачи. Таким образом, к выходной информации процесса построения плана решения задачи относятся файл с планом решения задачи, дополненные семантические сети в БЗ и семантическая сеть плана решения. Она представляет собой модифицированную семантическую сеть задачи с замененными на определенные символы целевыми и указательными словами, дополненную законами, правилами, алгоритмами, формулами, которые должны использоваться в процессе решения задачи. Выходная информация для представленного примера приведена на рис. 7 и в листинге 1.
Автоматическое порождение алгоритма и программы
Цель процесса порождения алгоритма по плану решения задачи — создание алгоритма на языке описания алгоритмов (ЯОА) на основе правил, содержащихся в плане решения задачи. Этот ЯОА разработан на основе языка схем программ В. Е. Котова и В. К. Сабельфельда. Он представляет собой формализованный язык с элементами естественного. Алгоритм, написанный на ЯОА, достаточно детально отображает устройство программы, а точнее, ее логическую структуру. При проектировании такого алгоритма применяется элементарный (по сравнению с алгоритмическими языками программирования) синтаксис ЯОА, исключающий описание структуры (типов) данных, которые при этом используются. Следует отметить, что несмотря на свой довольно простой синтаксис, ЯОА позволяет строить логически сложные, вложенные конструкции.
Таким образом, процесс порождения алгоритма в основном заключается в перекодировании символьного обозначения вершин и дуг простых фрагментов или отдельных составляющих сложных фрагментов семантической сети плана решения задачи в операторы или группы операторов ЯОА. Для формул во встроенных справочниках, а также для ряда целевых слов в соответствующей таблице приведены уже готовые алгоритмические конструкции операторов, используемые в процессе перекодировки. Выходная информация — текст алгоритма на ЯОА в виде файла. В рассматриваемом примере содержимое файла будет выглядеть следующим образом (см. листинг 2).
На основе полученного алгоритма решения задачи реализуется процесс построения готовой программы на целевом процедурном языке программирования. Данный процесс выполняет заключительный программный блок, построенный по классической схеме обычного однопроходного компилятора, рассмотрение принципов работы которого не представляет особого интереса. В результате на выходе получается эффективный код псевдопрограммы, легко переводимый на любой процедурный язык программирования с заранее известным для него синтаксисом.
В заключение следует отметить, что в последнее время усилились стимулы для изучения семантической проблематики вследствие развития машинного перевода, появления новых логических и математических методов изучения естественных языков, проведения анализа отношений естественных и так называемых формализованных языков и т. п. Потому-то разработка IPGS, в процессе которой была сделана попытка перейти от естественного языка к алгоритмическим, и представляет значительный практический и научный интерес.
ОБ АВТОРАХ: А.А. Аленкин — аспирант, В.П. Зубков — к. т. н., доцент кафедры ПОКС Ивановского государственного энергетического университета.
Автоматизация разработки ПО: сможет ли «программист» превратиться в «оператора ЭВМ»
К чему ведет нас прогресс в области производства программного обеспечения? Средства разработки ПО становятся все более совершенными, некоторые этапы разработки полностью или частично автоматизированы. Консерваторы, конечно же, скажут, что программист в настоящее время – уже не торт, что подобная автоматизация ведет к упрощению задач и потере квалификации инженера-программиста. По их мнению, на фоне развития инструментария происходит деградация кадров.
Но если копнуть глубже, возникнут вопросы. О каких именно программистах речь? О тех, кто проектирует ПО? О тех, кто разрабатывает алгоритмы? О ведущих разработчиках или простых «кодерах»? В любом случае, одного мнения здесь быть не может.
Поэтому, прежде чем делать какие-то выводы, стоит хотя бы вспомнить, как мы пришли к этому.
Точка отсчета
В самом начале у компьютеров не было даже клавиатуры! То есть всё было очень плохо — у них не было ни клавиатуры, ни экрана, были перфокарты (это такие штучечки с дырочками или с отсутствием дырочек).
И программы в то время писали с помощью машинных кодов — у каждой операции в компьютере (сложение, умножение, какие-то более сложные операции) был код. Люди сами по табличке выбирали этот код, всякие адреса в памяти, всё это выбивали руками и засовывали в считыватель — и оно всё считалось. Конечно, работа программиста была, наверное, тогда не особо интересной — проделывать дырочки — и с развитием науки и техники, конечно, начали придумывать всякие более «интересные» штуки.
Например, ассемблер (Assembler), который уже несколько облегчал жизнь. Ну, как он облегчал жизнь? Вместо запоминания того, что там какой-то «волшебный» код у команды, использовались всякие слова, похожие на «человеческий» английский язык — какие-нибудь add или mov — ну и затем перечислялись регистры или области памяти, переменные, с которыми нужно эти операции производить. Но понятное дело, что это в общем-то тоже требовало достаточно большого напряжения ума, чтобы держать у себя в голове, в каком регистре у нас что лежит, где какие переменные и что вообще происходит. Почему так происходило? Потому что компьютеры были «глупые» и ничего более «умного» понять не могли.
Изображение с сайта devdelphi.ru
На этом этапе порог вхождения в программирование был чрезвычайно высок.
Производительность программиста в этих командах была предельно низкой — то есть он писал несколько строк в день (осмысленных), и каждая строка ничего особо и не делала — какие-нибудь простые арифметические действия. И людям хотелось сделать языки гораздо более похожими на человеческий язык, на английский в частности, чтобы писать программы было легче и удобнее.
Уровень выше — порог ниже
С появлением языков программирования высокого уровня жизнь программистов становилась легче, а производительность – выше. Программы не нужно было переписывать для каждой машины. Появились компиляторы, среды разработки. Fortran, Algol, а позже BASIC, PASCAL, C действительно были больше похожи на «человеческий» язык.
Конечно, по-прежнему требовалось значительное время на их изучение, но это было более выгодное вложение времени и сил. В процессе работы компилятор указывал программисту на синтаксические ошибки в его коде, что в особенности облегчало разработку начинающим специалистам. С появлением модульности и переносимости кода проекты стали больше, а программисты начали широко использовать в проектах сторонние библиотеки, больше работать в командах. Это избавило их от необходимости подробно разбираться в том, как работает весь проект.
С появлением объектно-ориентированного программирования (С++, Object Pascal и так далее) тенденция повторного использования кода усилилась. Кроме того, со временем среды разработки становились более дружественными, и желающих освоить азы программирования становилось больше.
Программирование — в массы
Постепенно программирование перестало быть прерогативой хардкорных инженеров и математиков. Число проектов стремительно росло, программное обеспечение проникало в разнообразные сферы производства. Этому также способствовало и развитие систем управления базами данных. Появились даже такие специализации как «оператор СУБД».
Постепенно понятие «инженер-программист» стало многогранным: кто-то занимался алгоритмами, кто-то проектировал интерфейсы, кто-то просто занимался кодированием – то есть реализовывал в коде готовые алгоритмы своих коллег. Само программирование стали делить на две крупные группы – системное и прикладное: кто-то разрабатывал операционные системы и драйверы, а кто-то писал приложения для автоматизации бизнес-процессов на овощной базе.
Для каждой из специализаций требовались индивидуальные компетенции, поэтому переход от одной специализации к другой был затруднителен. Но минимальный порог вхождения в разработку ПО стремительно снижался.
Появление языков (Java, C#) и соответствующих фреймворков еще больше способствовало этому снижению, а также дифференциации специалистов по направлениям и уровням подготовки.
В результате у программистов закрепилась градация наподобие [Junior-разработчик, Senior/Middle, Team Lead, Software Architect]. С одной стороны, продвинутый инструментарий разработки позволял менее квалифицированным программистам успешно справляться с относительно простыми задачами, не имея глубоких знаний и серьезных навыков. С другой стороны, с каждой последующей ступенью карьерной лестницы порог вхождения также становился выше.
Изображение с сайта
Но если специалист задерживался в статусе начинающего, он мог заметить одну особенность: бурно развивающиеся технологии разработки ПО еще сильнее снижали порог вхождения, и среднестатистический Junior урожая N-го года знал и умел еще меньше, чем его старший товарищ — Junior (N — k)-го года.
Веб-разработка методом «тяп-ляп»
С развитием веб-разработки программистам потребовалось встать на другие рельсы (ассоциация с Ruby On Rails здесь тоже уместна), чтобы освоить новые языки и стек интернет-технологий разработки в целом.
После того как веб-разработка, начавшая набирать обороты только в 90-х годах, совершила огромный скачок в развитии, Михаил Густокашин может свободно пускаться в подобные рассуждения:
Допустим, вы хотите написать новый Facebook (социальную сеть). На чем вы будете это писать? HTML, CSS — это дизайн, а мы хотим, чтобы там можно было фотографии добавлять, друзей, комментарии оставлять.
Для скриптовой части — то есть то, что будет происходит на стороне клиента, — это JavaScript.
На удивление, он написан на PHP — и Facebook, и многие другие большие проекты. Пришлось, конечно, написать свои какие-то вещи, чтобы это всё-таки работало нормально, а не так как «тяп-ляп» было сделано, но они справились.
Здесь и сейчас, понятное дело, с нуля уже для веба никто ничего не пишет. Все ищут какой-нибудь фреймворк или ещё чего-то. Интернет-магазин? Скачали фреймворк для интернет-магазина — ну и всё, написали интернет-магазин.
Стоит отметить, что и поначалу порог вхождения в веб-разработку был ниже, чем в Desktop. После появления фреймворков он снизился еще сильнее.
На волне автоматизации
Получается, что раньше сайты писали «руками», а теперь это стало необязательно во многих случаях. Более того, для создания тех же интернет-магазинов уже нет надобности даже в использовании фреймворков: теперь есть конструкторы сайтов. Теперь веб-программисты, не обремененные квалификацией, которые раньше получали легкие деньги, создавая однотипные сайты, могут превратиться в операторов-конфигураторов.
Все потому, что в чьи-то светлые головы пришла идея автоматизировать процесс веб-разработки. Хотя, на самом деле, идея не нова, так как она уже частично была реализована во многих инструментах разработки ПО под Desktop-платформы в виде автогенерации форм и целых слоев приложения – например, генерация классов по структуре базы данных.
Если индустрия будет развиваться в том же русле, то все больше кодеров (программистов, находящихся в начале пути либо имеющих невысокую квалификацию) получат возможность превратиться в операторов-конфигураторов. Использовать такую возможность или нет, каждый решит для себя сам.
Мы выяснили, что по этому поводу думают эксперты, представители ИТ-индустрии:
Алексей Бычко, старший релиз-менеджер (Percona), разработчик проектов Percona Server for MySQL, Percona XtraDB Cluster, Percona XtraBackup, Percona Server for MongoDB, PQuery, преподаватель курса «Системное администрирование» в ИТ- Академии Алексея Сухорукова:
Появляется всё больше и больше сред для автоматизации рутинных вещей – это помогает лишний раз не писать что-то вручную, не изобретать велосипедов. Многое уже предусмотрено в интегрированных средах разработки, из которых можно вызывать нужные библиотеки и так решать стандартные задачи. Для тех, кто умеет и привык думать, это хорошо – можно сконцентрироваться на основном, на логике приложения. (Это люди «старой школы», которым для написания качественного кода хватит и простейшего текстового редактора).
Плохо, что растёт число быдлокодеров, которые, в принципе, могут решить поставленную задачу, собрать что-то из имеющихся «кубиков», но не представляют, как что работает внутри, и не могут оценить, насколько оптимален чужой готовый код. По этой причине я бы хорошего программиста именно «кодером» называть не стал – код сейчас пишут даже младшие школьники, его и машина сгенерировать может. Программист думает, изобретает, устанавливает зависимости, задаёт пути, проектирует архитектуру – а потом он всё это может отдать кодеру на реализацию.
По сути, это два подхода, которые выросли из факта наличия проективных Unix-подобных систем и процедурных Windows-подобных. Огромной корпорации, где всё разбито на мельчайшие подзадачки, важна воспроизводимость результата, а не оптимальное решение – если оператор ушёл, нужно, чтобы новый по инструкции делал то же самое и не хуже.
Но если у нас есть задача, которая конкретной процедурной системой, библиотекой или средой решается плохо или не решается вовсе (коллеги постарше помнят, что бывает, когда в написанный в C++ Builder или Delphi текстовый редактор попадает большой файл – ничего не листается и всё тормозит, и это никак не поправить), то нам нужно взять «чистую» систему, которая даёт больше свободы, и позвать программиста, который согласен не просто гуглить, а писать адекватное решение самостоятельно с нуля.
Как организатор крупнейших в России конференций для разработчиков я вижу специализацию, упрощение рутинных процедур, но мозги и глубокое понимание происходящего востребованы не меньше, а даже больше, чем раньше.
С появлением автоматизирующих разработку инструментов ценность людей, которые понимают, что происходит под капотом таких инструментов, растёт. Требования, которые к ним предъявляются, растут. Объём знаний, который нужно освоить, растёт.
Конечно, речь идёт не о создании лендингов, а о разработке мало-мальски серьёзного проекта.
Макс Лапшин, создатель ErlyVideo, создатель Flussonic, разработчик многих известных решений в области стриминга видео.
Первый раз сообщения о том, что всё, что надо было написать, уже в целом написали, и теперь программисты просто будут собирать кубики из готовых компонент, и вообще, наверное, программировать мышкой, я услышал году примерно в 1995. Как несложно догадаться, с 1995 года по сегодня было написано безумное количество адского хардкорного системного кода, и возникло и умерло немало больших бизнес-платформ, на которых даже что-то было напрогано «мышкой».
Честно говоря, я даже ни разу не встречался с задачей, которую можно было бы напрогать «мышкой», не влезая до дна, но я не имею ровным счетом никакой связи с энтерпрайзной аутсорс-разработкой в стиле «Люксофта», поэтому не знаю, как оно у «них».
Всё дело в том, что индустрия идет вперед. Да, на компьютерах больше не 640 КБ памяти, и программисту под Windows больше можно не волноваться о памяти вообще. Но на замену большим компьютерам пришли маленькие, и их много.
Сегодня всё равно приходится думать, как записать на прошивку IP-камеры софт, упихнувшись в 200 КБ на диске. Приходится думать, как упихнуть код в маленький IOT-сенсор, который должен на своей крохотной батареечке прожить год с радиообменом.
Индустрия очень стремительно расширяется, и в ней появляется место людям, которые не очень глубоко разбираются в деталях работы ЭВМ, но безусловно: сегодня людей, которые знают, как работает, например, DMA, нужно больше, чем 10 лет назад просто потому, что индустрия до сих пор растет.
Александр Лямин, основатель и CEO компании Qrator Labs, одного из ведущих мировых поставщиков в области защиты от DDoS-атак.
Есть такая шутка: отдел программирования — это такой завод по производству холодильников, в котором работает 10 человек, один из которых может делать звездолёты, а остальные девять человек умеют клепать скворечники.
Так вот, программисты нужны в компаниях совершенно разного толка. Какие-то компании производят холодильники, какие-то — клепают скворечники, а некоторые, как SpaceX, действительно разрабатывают звездолёты. Поэтому пропорция 1:9, естественно, не догма, она везде будет своя. Где-то, действительно, достаточно нескольких кодеров в штате. Где-то нужны уже хорошие прикладные программисты — люди, обладающие алгоритмическим багажом и способные грамотно его применять.
В ряде случаев требуется уже даже не столько программист, сколько computer scientist — человек способный не только, как минимум, грамотно модифицировать алгоритмы под нужды конкретной ситуации и задачи. Следующий уровень — это data scientist, хороший прикладной математик. Продолжая аналогию, скворечник можно склепать из общедоступных стройматериалов, но сплавы для ракеты на строительном рынке уже не купишь. На этом уровне задача уже начинает выглядеть примерно так: вот проблема, вот массив данных, нужны гипотезы-алгоритмы-PoC и, как следствие, постановка задачи для реализации. И в процессе создания действительно хороших продуктов — рано или поздно, так или иначе — задачи нетривиальной обработки данных возникают неизбежно.
То есть человек-«кодер» решает лишь часть проблем, стоящих перед разработкой.
Естественно, действительно высококлассных программистов на рынке труда мало, а задач для них много, поэтому очень давно возникла идея: разработать инструментарий, с помощью которого специально обученный оператор ЭВМ сможет справиться с задачами высокой сложности. Но все попытки сделать это, можно сказать, провалились. Язык SQL был разработан изначально для того, чтобы им мог воспользоваться любой пользователь, даже не имеющий навыков программирования. Сейчас этим языком пользуются программисты, а операторы ЭВМ даже после тренингов не в состоянии написать даже более-менее простой запрос.
Другой пример — всевозможные среды визуального программирования, предназначенные, грубо говоря, для того, чтобы оператор мог не писать код, а нарисовать адекватную задаче блок-схему, на основе которой компилятор выберет нужные алгоритмы. Ни одна из таких сред (а их было много) в конечном счёте не получила распространения. Это говорит о том, что изначальная задача, возможно, поставлена неправильно или не имеет решения в такой постановке.
Закон дырявых абстракций свидетельствует: рано или поздно в процессе добросовестного решения прикладной задачи приходится опускаться на уровень ниже, чем позволяет практически любой прикладной инструмент.
Поэтому вряд ли когда-нибудь кому-нибудь удастся превратить программиста в оператора ЭВМ окончательно.