1. Doug Engelbart считал делом своей жизни усиление/дополнение/приращение/пополнение (augment) человеческого интеллекта, и вычислительная техника подходила для этого наилучшим образом. Под "усилением человеческого интеллекта" он понимал усиление возможностей человека взаимодейстовать со сложной проблемной ситуацией, понимать её для удовлетворения собственных потребностей, а также получать в рассуждении решение проблемы. "Усилить" -- это быстрее по времени и лучше по качеству (http://www.dougengelbart.org/pubs/augment-3906.html).
В его лаборатории было придумано много всякого, чем мы пользуемся до сих пор (мышка, гипертекст и т.д., а демонстрация всего этого в далёком 1968 году называется ни больше ни меньше как The Mother of All Demos -- вполне заслуженно, http://en.wikipedia.org/wiki/The_Mother_of_All_Demos, http://web.stanford.edu/dept/SUL/library/extra4/sloan/mousesite/1968Demo.html). Он создавал инструмент для пытливого ума, желающего учиться и критерием была максимальная производительность профессионала. Его метафора была -- бульдозер/экскаватор, в кабине которого было много-много органов управления, позволяющих лихо этим инструментом управляться и подчинять его власти человека (, ) против метафоры тепловоза, где человеку предоставлялось поучаствовать в настройке параметров того, что происходит и без него (http://www.contemporary-home-computing.org/car-metaphors/douglas-engelbart-the-automobile-and-other-analogies/). 
Невзирая на огромный потенциал всех его новинок и изобретение им основ современного компьютерного интерфейса ещё в конце 60-х, в целом дело Doug Engelbart провалилось. Например, аккордовая клавиатура (вместо клавиатуры пишущей машинки). Alan Kay сказал об этом просто "Энгельбарт, к лучшему или худшему, пытался сделать скрипку, но большинство людей не хотят учиться играть на скрипке" (http://com2710.dedalon.net/S_11_files/BARDINI1995_Social_Constr_User.rtf). Какой критерий вместо "инструмент повышает производительность профессионала" приводил к успеху? Критерий "даже дурак сможет этим инструментом овладеть".

Наиболее красочный и известный рассказ о провале аккордовой клавиатуры в Сети, со множеством ссылок и фотографий, так и называется -- "Скрипка Энгельбарта" Станислава Дацковского: http://www.loper-os.org/?p=861

2. При создании языков программирования всегда стоит дилемма: должен ли быть этот язык мощным или лёгким. Иногда их даже называют LFSP (languages designed for smart peope), навроде Lisp, и LFM (languages designed for masses), навроде C++ -- http://paulgraham.com/vanlfsp.html. Дальше подставляйте сюда любые пары -- Haskell и Java, например. Заканчивайте каким-нибудь Coq.

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

Эта же дискуссия про "стильные языки" против "агглютинативных" в изложении того же Alan Kay (который сам всю жизнь изобретал скрипки, хоть и ругал за это Энгельбарта): "Стильные языки (APL, Lisp, Smalltalk) и агглютинативные ("клейкие") языки типа PL/1. Стильные языки -- для людей, у кторых есть математическая ленивость, они окупаются через год после начала проекта -- когда у вас появляется сильная идея, и вам быстро-быстро нужно все переделать. Агглютинативные языки сопротивляются этой переделке. Кроме того, стильные языки обычно позднего связывания, а агглютинативные языки -- раннего, что приводит к совершенно разным процессам отладки, дает абсолютно разные типы ошибок. И для стильных языков не нужно беспокоиться об архитектуре фон Неймана. Это раздел двух культур, через эти различия в стилях невозможно общаться" -- пункт 8 из http://ailev.livejournal.com/469995.html.

И тут же дискуссия про bootstraping и взаимозаменяемость программистов , про разворачивание собственных подходов и инструментальных сред (Steps Toward Expressive Programming Systems тут: http://vpri.org/html/writings.php, сага о создании офисного пакета на 20тыс. строк), мемуар Михаила Донского, который описывает, что сильный программистский коллектив сам себе разрабатывает фреймворк -- чуть ли не от уровня железа. Создает себе стиль, не обращая внимания на язык. И затем на этом фреймворке получает удивительные результаты -- прирученный тобой язык становится могучим и великим, программирование выдерживает стиль от самого верхнего уровня до самого дна (железа). Похоже, что дело не столько только в языке (когда речь идёт о языке), сколько в стиле его использования в части прихвата чужих библиотек и той самой "заменяемости программистов" -- "голенький" язык подразумевает совершенно другой подход к наращиванию его возможностей. И тот же Донской мне рассказал, что язык программирования только по недоразумению называют языком, настоящий язык -- это собственноручно созданные библиотеки и фреймоворки, на которых и создаётся большая система, и только если у тебя есть такой "свой язык", то безопасно входить в большие проекты, которые идут больше года (http://ailev.livejournal.com/613067.html).

И отчаянный крик души Алана Кея про то, что компьютерная наука не идёт по пути развития эффективных и мощных средств, а сваливается в предложение всё более и более убогих "для масс" -- и массы тупеют. С его точки зрения, люди должны (но не хотят, и нужно что-то с этим делать!) учиться, чтобы осваивать трудные языки -- вкладывать много-много часов, чтобы добиться беглости чтения и говорения на этих языках. И когда софт будет поддерживать таких людей, то в этот момент и будет компьютерная революция -- http://www.vpri.org/pdf/future_of_reading.pdf

3. Закон стандартов John Sowa 1991 года (http://en.wikipedia.org/wiki/John_F._Sowa#Sowa.27s_law_of_standards) -- успешен становится не предлагаемый официальный проработанный до мелочей стандарт, а широко распространённая его упрощённая недоспецифицированная версия, она становится стандартом де-факто. Сложность со всей её мощью проигрывает простоте и недоспецифицированности.

4. Интересно, что этот же подход "мощь для профи против лёгкости для масс" может быть применён к целым отраслям знания. Так, ван Бентем вообще договаривается до того, что вся логика -- это "наука, цель которой в значительной мере определяется поиском определенного балансамежду выразительной силой формальных языков и многосложностью их использования при решении таких задач как осуществление контроля за согласованностью, адекватностью моделирования и правильностью вывода" (http://ailev.livejournal.com/915253.html). 

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

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

"Профессиональный автомобиль" -- это возможность газовать каждым отдельным колесом, 8 передних передач и 20 задних. Автомобиль для тупых -- с автоматической коробкой передач и ABS, а в пределе так и вообще с автопилотом. Профессиональная функция отпадает.

Это же всё относится к роботам любого вида: изобретение конвейера не столько "усилило" человека и сделало его более обученным и способным, сколько привело к резкому снижению требуемой квалификации рабочего, "деградация работы в двадцатом веке": http://www.amazon.com/gp/product/0853459401/. Хорошо обобщено это (с поминанием той же скрипки Энгельбарта и призывом не забывать о программе что-то делать и для умных людей, а не только тупых -- делать интерфейс между машиной и человеком более сложным, чтобы у человека был шанс вмешаться в работу машины) в рассказе http://www.macroresilience.com/2013/07/08/explaining-the-neglect-of-doug-engelbarts-vision/. Atul Varma говорит о полностью автономной кофеварке, которая отлично справляется с задачей -- но в тот момент, когда что-то идёт не так, "кофеварка для тупых" терпит полное фиаско. Если бы у человека был шанс вмешаться и человек был бы достаточно умён, то можно было бы что-то ещё сделать -- http://www.toolness.com/wp/2012/03/coffee-machines-and-community/ (но для этого нужно бы "научиться играть на кофеварке", а люди не любят "учиться играть на XYZ". Но некоторые всё-таки будут учиться!).

Впрочем, и с "что-то идёт не так" тоже много чего по пути происходит: happy path становится всё разнообразнее и разнообразнее, плюс появляются resilience systems, задача которых быстро обнаруживать, что что-то идёт не так и пытаться выжить в этих условиях -- вплоть до полной перестройки того, что осталось от системы после поломки "изнутри системы".
* * *
C .15926 Editor мы сделали то же самое -- скрипку, на которой никто не хочет учиться играть. Это же относится не только к инструменту, но и к дисциплине: занятие онтологией требует времени для освоения, в каком-то смысле это освоение нового языка-основы и языка-библиотеки, как об этом говорил М.Донской (там ведь и обширная библиотека справочных данных). Эффективно ли решать задачи интеграции данных, построения концептуальных моделей данных освоившему этот инструментарий человеку? Да, эффективно. Прост ли редактор (и заодно дисциплина, которую он поддерживает) в освоении? Нет, ибо там и 4D extensionalism, и RDL, и Python и много чего ещё. Люди не любят "учиться играть на XYZ", иструменты и языки для smart people не имеют шансов вне рамок выращивания их в каком-то узком комьюнити какого-то многолетнего проекта.

И к системной инженерии это тоже вполне относится. Знаниевые инструменты -- они такие же, как и любые другие. Играть на системноинженерой скрипке нужно долго учиться, но кто-то всё-таки научается. И это не мейнстрим! Мейнстрим -- это автоматизация системной инженерии, а системные инженеры будущего это те, кто программирует системноинженерный софт, системноинженерную скрипку-самоиграйку, системноинженерную кофе-машинку с одной кнопкой "сделай мне красиво". Smart people выжимаются в автоматизацию и делают автоматические скрипки с одной кнопкой Start (используя для этого профессиональные инструменты с огромным временем освоения и доработки до надлежащего уровня), оставшиеся наедине с одной кнопкой masses потом в среднем тупеют, как рабочие на конвейере -- будь то конвейер по сборке автомобилей, разработке софта или созданию ракет для покорения Марса. 

И это всё растянуто на длиииинную цепочку творцов-программистов-кодеров-быдлокодеров-операторов-быдлооператоров-роботов.