Anatoly Levenchuk (ailev) wrote,
2015-01-10 22:21:00
Никто не хочет учиться играть на XYZ.Сегодня я некоторое время размышлял про одну и ту же проблему усиления человеческого интеллекта, обсуждаемую самыми разными людьми в самых разных формулировках.
Суть проблемы в том, что усиливать человеческий интеллект оказывается невыгодно и это развлечение для немногих эээ... пассионариев интеллекта, человеческий интеллект выгодно разгружать и это даёт массовость, что понимается как "успех".
Наиболее часто обсуждается это в программистских кругах -- ибо в случае софта это наиболее очевидно. Вот несколько примеров этой одной и той же истории в разных её исполнениях.
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/librar ... 8Demo.html).
Он создавал инструмент для пытливого ума, желающего учиться и критерием была максимальная производительность профессионала.
Его метафора была -- бульдозер/экскаватор, в кабине которого было много-много органов управления, позволяющих лихо этим инструментом управляться и подчинять его власти человека (
http://www.youtube.com/watch?v=doNmniQrhBU,
http://www.youtube.com/watch?v=9M_FnVvbJsE) против метафоры тепловоза, где человеку предоставлялось поучаствовать в настройке параметров того, что происходит и без него (
http://www.contemporary-home-computing. ... analogies/).
Невзирая на огромный потенциал всех его новинок и изобретение им основ современного компьютерного интерфейса ещё в конце 60-х, в целом дело Doug Engelbart провалилось. Например, аккордовая клавиатура (вместо клавиатуры пишущей машинки).
Alan Kay сказал об этом просто "Энгельбарт, к лучшему или худшему, пытался сделать скрипку, но большинство людей не хотят учиться играть на скрипке" (
http://com2710.dedalon.net/S_11_files/B ... r_User.rtf).
Какой критерий вместо "инструмент повышает производительность профессионала" приводил к успеху? Критерий "даже дурак сможет этим инструментом овладеть".
Наиболее красочный и известный рассказ о провале аккордовой клавиатуры в Сети, со множеством ссылок и фотографий, так и называется -- "Скрипка Энгельбарта" Станислава Дацковского:
http://www.loper-os.org/?p=8612. При создании языков программирования всегда стоит дилемма: должен ли быть этот язык мощным или лёгким. Иногда их даже называют 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.pdf3. Закон стандартов John Sowa 1991 года (
http://en.wikipedia.org/wiki/John_F._So ... _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/ ... ts-vision/. Atul Varma говорит о полностью автономной кофеварке, которая отлично справляется с задачей -- но в тот момент, когда что-то идёт не так, "кофеварка для тупых" терпит полное фиаско.
Если бы у человека был шанс вмешаться и человек был бы достаточно умён, то можно было бы что-то ещё сделать --
http://www.toolness.com/wp/2012/03/coff ... community/ (но для этого нужно бы "научиться играть на кофеварке", а люди не любят "учиться играть на XYZ". Но некоторые всё-таки будут учиться!).
Впрочем, и с "что-то идёт не так" тоже много чего по пути происходит: happy path становится всё разнообразнее и разнообразнее, плюс появляются resilience systems, задача которых быстро обнаруживать, что что-то идёт не так и пытаться выжить в этих условиях -- вплоть до полной перестройки того, что осталось от системы после поломки "изнутри системы".
* * *
C .15926 Editor мы сделали то же самое -- скрипку, на которой никто не хочет учиться играть. Это же относится не только к инструменту, но и к дисциплине: занятие онтологией требует времени для освоения, в каком-то смысле это освоение нового языка-основы и языка-библиотеки, как об этом говорил М.Донской (там ведь и обширная библиотека справочных данных).
Эффективно ли решать задачи интеграции данных, построения концептуальных моделей данных освоившему этот инструментарий человеку? Да, эффективно. Прост ли редактор (и заодно дисциплина, которую он поддерживает) в освоении? Нет, ибо там и 4D extensionalism, и RDL, и Python и много чего ещё. Люди не любят "учиться играть на XYZ", иструменты и языки для smart people не имеют шансов вне рамок выращивания их в каком-то узком комьюнити какого-то многолетнего проекта.
И к системной инженерии это тоже вполне относится. Знаниевые инструменты -- они такие же, как и любые другие. Играть на системноинженерой скрипке нужно долго учиться, но кто-то всё-таки научается. И это не мейнстрим!
Мейнстрим -- это автоматизация системной инженерии, а системные инженеры будущего это те, кто программирует системноинженерный софт, системноинженерную скрипку-самоиграйку, системноинженерную кофе-машинку с одной кнопкой "сделай мне красиво".
Smart people выжимаются в автоматизацию и делают автоматические скрипки с одной кнопкой Start (используя для этого профессиональные инструменты с огромным временем освоения и доработки до надлежащего уровня), оставшиеся наедине с одной кнопкой masses потом в среднем тупеют, как рабочие на конвейере -- будь то конвейер по сборке автомобилей, разработке софта или созданию ракет для покорения Марса.
И это всё растянуто на длиииинную цепочку творцов-программистов-кодеров-быдлокодеров-операторов-быдлооператоров-роботов.
POST A NEW COMMENT 28 comments
Вход
FAQ
Поиск
