Программирование виртуальных предметов

[ermouth]

Прочитал недавно интерактив Алана Кея на HN и наткнулся там на такой вопрос/ответ:

– Do you think we'll ever have a programming language that isn't fully text based and gets closer to a direct mapping of our own thoughts than current systems? If so any ideas what properties this language would have?

–A few years ago I asked another visionary, Marvin Minsky, if he thought that, in the future, we'd do our programming in something other than plain text. He said, "If it's good enough for Aristotle and Plato, it's good enough for me." RIP, Professor.

Я неделю в картинках размышлял, так ли enough это good. Мне кажется, не так уж он и good, можно придумать и получше.

Размышлял я примерно таким образом: коль скоро сам по себе texting, то-есть концепция письменного языка, является ограничителем, надо просто попробовать выбросить эту концепцию.

Звучит диковато – но только на первый взгляд. В самом деле очень многие артефакты реальности либо плохо помещаются в язык, либо вовсе им невыразимы в таком виде, чтобы человек (Homo sapiens) смог адекватно воспринять.

Попробуйте языком – каким угодно – описать движения тай-цзы, например. Физические аспекты ещё можно как-то попытаться, а вот что при этом в голове происходит – вообще в человеческий язык не помещается. Дальше, под катом, суровый гон.

Завязывание шнурков

Тай-цзы (или, там, наркотический приход, или религиозное озарение) – это метафизика, есть и попроще примеры. Попробуйте языком описать, как именно вы завязываете шнурки или распутываете клубок проводов. Эти простейшие и естественные действия помещаются в язык с огромнейшим трудом.

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

Язык, а особенно texting, почти не располагает механикой, позволяющей проделывать трюки с суперпозицией термов. Вы не можете говорить хором, вы даже слушать одновременно нескольких людей не можете.

В лучшем случае вторым потоком информации к тексту будет интонирование, а третьим – мимика и жесты, но они пригодны для расстановки акцентов, а не для передачи смыслов вообще (кроме самых простых). Закон Ома одним интонированием не объяснить (или, если угодно, на скрипке не сыграть). И не воспринять.

Хоровое восприятие и инструментальный рефлекс

Зато мы прекрасно воспринимаем “хором” мир предметов, а если быть точным – мир их взаимного расположения и свойств. После недавней истории с перчатками я склонен думать, что инструментальный рефлекс в нас – штука весьма низкоуровневая.

В самом деле, наверняка у вас есть знакомые механики, у которых чрезвычайно бедная и малосвязная речь, но которые разбираются в любых железяках и вообще комбинациях предметов с умопомрачительной скоростью и точностью.

Им речь низачем вообще не нужна для этого, они словами не думают. Они строят в голове модель кусочка реальности, там же в голове его трансформируют, и воспроизводят трансформации обратно в реальности. К таким ментальным моделям слова не просто не нужны, они противопоказаны – фокус теряется.

Hacky code

Между прочим, короткий непонятно как работающий код (hacky) – это вот очень близкое явление. Это артефакты, которые находятся на границах возможностей языка. Нередко объяснение к действительно hacky-коду (или даже тот-же код в не-hacky стиле) занимает многократно больше места и всё равно с большим трудом воспринимается.

Тут дело не в сложности конструкции, а в самом языке, он в этой истории лишний. Зато hacky-код нередко весьма компактно объясняется на простой аналогии из предметного мира, если вы, конечно, в состоянии её представить в необходимой полноте.

Виртуальные предметы

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

2Д и зрения/пальцев для этого очевидно мало. Плоского экрана, даже большого, едва хватает на разработку только texting-ом и немножко деревьями. Именно поэтому все попытки сделать программирование из графических схем не прижились – простынь линий охватывать нисколько не легче, чем stream текста.

С виртуальным пространством другое дело. На нём доступны быстрый шифт, зум, огрубление и снятие оболочек (“углубление” в предмет), тактильное восприятие, температура и тп.

Плюс на этом пространстве работают наши естественные рефлексы. Плюс можно менять геометрию пространства – 3Д-пространства разной кривизны чрезвычайно любопытно выглядят, изменяется восприятие локальности и расстояния.

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

Итого

В общем, полагаю, что будущее программироваия не за языком, а за появлением всамделишней среды разработки. Пока в ИТ нет ничего нет даже отдалённо похожего, в лучшем случае в виртуальных мирах производят манипуляции с данными, насколько я знаю.

Что интересно, вот в обычном инжиниринге (мира атомов) системы конструирования, построенные на виртуальных мирах, вполне себе есть. Стало быть, должны и в ИТ появиться.

Что думаете?

Comments

[morfizm.livejournal.com]

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

Несколько разрозненных мыслей, к которым я пришёл so far:

1. Язык первичен, мышление вторично (!).

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

Я считаю, что то, что мы уже имеем, что мы умеем делать в голове - это РЕЗУЛЬТАТ языка, который мы уже освоили (если включать естественные языки - напр., русский, формальные языки, напр., C++, языки жестов, всевозможные контекстно-зависимые таксономии терминов и т.п.). Там в голове есть какое-то низкоуровневое "железо", но мыслительный процесс - это следствие языка. Просто есть некоторый gap между языком как таковым и средствами его выражения (куда более узкое подмножество).

У нас с тобой одинаковый вывод - чтобы поднять ограничение, нужен язык получше. Но ты этот язык ищешь как более лучшее выражение существующих мыслительных процессов, я же считаю, что этот язык нужно искать глубже/шире, независимо от мыслительных процессов, а уже мыслительные процессы под него подстроятся, если язык будет УДАЧНЫМ.

2. Средства разработки это значительный ограничитель.

(Тут мы сходимся).
Может быть даже искать новый язык нужно через поиск нового концепта для IDE (3D, whatever).

* * *

Есть ещё куча мелочей, о которых я думал, но я сейчас не готов связно изложить. Да и многое устарело, нужно подумать обо всём заново. Есть разные приложения и промежуточные решения, о которых я думал. Некоторые из них могут превратиться в standalone startup project, если бы были силы и время делать (или какая-то обозримая коммерциализация, чтобы дали баблосик на пропитание, пока разрабатываешь).

[ermouth.livejournal.com]

> если хочешь думать вместе

Хочу )

> Язык первичен, мышление вторично

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

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

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

Моторику можно существенно лучше использовать даже саму по себе, а уж со зрением вместе – и подавно.

> этот язык нужно искать глубже/шире, независимо от мыслительных процессов

Это инструмент, их надо делать такими, чтобы под них не надо было подстраиваться. Это они должны подстраиваться, бро )

[morfizm.livejournal.com]

Пост написал для тебя. http://morfizm.livejournal.com/1031820.html

[morfizm.livejournal.com]

Кстати, завязывание шнурков, очевидно, куда проще было бы описать в терминах топологии. Но переносимость топологии на существующие более конкретные языки (и на естественные, и на языки программирования) очень низкая :) Скорее, топология близка к алгебраическим абстракциям, чем к конкретике (PutPixel...).

[ermouth.livejournal.com]

> очевидно, куда проще было бы описать в терминах топологии

😝 Oh really? Что есть «проще»?

Вот тебе начало таблички атласа узлов http://katlas.org/wiki/The_Rolfsen_Knot_Table, воспринимай каждое вхождение как символ алфавита. Теория узлов – это дичайший ад.

Так тебе её и не хватит ещё, потому что когда ты шнурок завязываешь, есть не только шнурок (одномерный объект) вложенный в R3, а ещё и ботинок, который топологически – поверхность, обычно чётного рода, в том же R3, и есть ты, который топологически 2-сфера, и есть непрерывно изменяющаяся конфигурация объединений.

И даже этого будет мало – потому что тебя представлять как 2-сферу в этом случае будет не совсем корректно, потому что смыкая пальцы ты образуешь тор или крендель. Да и шнурок – не совсем одномерный объект, когда ты его держишь хотя бы за один конец, а если ты его держишь в нескольких местах, у него вообще, кажется, нецелая размерность о_О

[ermouth.livejournal.com]

Вот ещё хорошая картинка, почему топология не очень подходит )

[morfizm.livejournal.com]

omfg! :) Ладно, I take back RE "it's much simpler with topology"

[kavnik.livejournal.com]

Идея виртуальных предметов и пространства была интересно показана в фильме "Теорема Зеро". Правда там, насколько я помню, не программировали в таком пространстве, а доказывали что-то из математики.

[ermouth.livejournal.com]

Ага, такой смешной панк и всё решилось молотком в конце концов )

Есть ещё старый-престарый The Lawnmower Man. Там в конце разум, запертый в мэйнфрейме, сканирует порты в цилиндрическом пространстве, замощёном шестиугольниками. Я когда пересматривал, даже на паузу поставил, чтобы подумать, а что потенциально может дать такая организация данных.

[tupicc.livejournal.com]

фильмы -- плохой аргумент, и вообще их лучше не вспоминать http://lesswrong.com/lw/k9/the_logical_fallacy_of_generalization_from/

[archaicos.livejournal.com]

Мы думаем следующее... Основная проблема нынче - понять существующий/чужой код чтобы потом можно было его использовать, изменить (и потом использовать) или исправить (и потом использовать). Версию нумер адын всегда писать здорово (нет legacy/compatibility, есть все знания и они свои). Работать с версией сто один уже не так приятно, особенно если ты с предыдущими не работал вовсе. У серьёзных софтин версий аки годовых колец на пне.

Проблема имеет несколько аспектов: сложность/плохая очевидность языковых конструкций (когда мы язык знаем херовенько, с большими пробелами тут и там), прочая йопнутость языка, сложность решаемых задач / объём кода.

С объёмами и сложностью можно бороться только автоматизацией и абстракциями. В голове одного программиста можно уместить много чего, но жонглирование больше чем тремя (или у кого сколько) фиговинами одновременно приводит к ошибкам. Отсюда прямо следует, что нужны инструменты (IDE или что ты там подразумеваешь под «средой разработки»), способные удобно визуализировать код (zoom in/out по абстракциям; отвязать код на экране от его положения в файле относительно другого кода в том же файле) и по нему ходить, способные безошибочно отвечать на вопросы типа где и кем используется или изменяется некий X (а в спорных местах так и говорить, что может использоваться/меняться, но не факт - исследуй сам), способные делать или помогать делать рефакторинг (тупой поиск с заменой не канает), т.е. способные работать не с текстом, а со структурой программы. Тут как-то гугловская презенташка пробегала, где народ делился радостями изменения популярных API в проектах всей компании. Счёт на десятки и сотни тысяч употреблений, кучи проектов/репозиториев, ревью/тесты... Запилили решение на clang.

Йопнутости языка бывают разные. Слишком сложный, неоднородный и т.п. язык плохо усваивается программистом (раскидистые ветви undefined behavior в C++ - сущее зло). Бывают йопнутости, мешающие не человеку, а инструментам. Если IDE должна в себе содержать полный front end компилятора (и даже не только front end, а вообще весь компилятор) только чтобы правильно понять структуру кода и его отобразить, то это ппц (давнишняя и до сих пор насущная бяда C++). А, ещё завязки на build систему сбоку от самого кода. :)

Не думаю, что язык человеческий, какие-то колебания электронов в мозгу или многомерная визуализация (не обязательно визу-; кстати, откуда она возьмётся из груды данных без прямой помощи пользователя, если только он может решить, что ему нужно и в каком виде понятно/удобно?), не думаю, что всё это может как-то помочь, т.к. вносит либо неоднозначности, либо слишком много информации (либо она становится не очень достоверной во время «фильтрации»).

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

[ermouth.livejournal.com]

> способные удобно визуализировать код

Всё что ты дальше пишешь, появится совсем вот-вот, дело пяти лет максимум имхо. Первые ласточки уже есть, корявые.

https://www.youtube.com/watch?v=db-7J5OaSag

http://store.steampowered.com/app/382110

Пока беда с соотношением разрешение/масса у очков, и это единственная проблема, других нет.

[archaicos.livejournal.com]

Корявое существует с испокон веков, и его не хватает. Ждёмс. Никто не хочет потратить мильён-другой, спонсировать работу для приближения светлого дня? :)
Ролики прикольные, но они о другом. И тут, кстати, тоже есть свои проблемы. Куча софта живёт состояниями, в т.ч. распределёнными. Менять что-то в реальном времени, а тем более откатывать в прошлое, - крутая штука, но она не вписывается в такой софт. Либо нельзя сделать (нужно выкинуть и переделать, если возможно в принципе), либо слишком медленно (Компилируецца!), либо нужны хаки вокруг всякого (типа сторонних библиотек).
И я вообще может не хочу глазами работать, они какие-то не железные. :)

[morfizm.livejournal.com]

Мне кажется, это тупиковое направление. У тебя есть код, в котором мегатонна корявости, но там всего лишь одна мегатонна, просто потому что все предыдущие maintenance инженеры с двумя мегатоннами бы уже не справились - оттого система достигла saturation по сложности, потолок. Ты дашь инструменты, упрощающие работу с этим всем говном в 10 раз, и получишь ровно такое же состояние, от которого будет тошнить, только говна в типичном проекте будет не одна мегатонна, а 10. Оно разрастётся ровно до лимитов очередного инструмента.

По-моему, нужно что-то другое, что концептуально меняет процесс разработки. Нужно чтобы корявый код был не нужен или невозможен, или чтобы корявости перестали быть корявостями. Нужно приблизиться к энтропии обычного объяснения у доски. Вот, скажем, сколько надо, чтобы систему в миллион строк кода (15 MB ascii) детальнейшим образом объяснить новичку? Недели-двух хватит с головой. Две недели это (оцениваем сверху!!!) 80 часов, 288000 секунд, слово в секунду (5 символов) = 1 MB. Ну т.е. как минимум в 15 раз должно быть можно уменьшить, сохранив информационную плотность примерно как у обычного разговора (а там дохрена избыточности). Но должно быть ещё лучше. Должна быть возможность проектировать и реализовывать системы таким образом, чтобы даже объяснять их было быстрее, чем за две недели.

[archaicos.livejournal.com]

Выправление C++ не решит проблем сложности решаемых задач и не решит всех проблем больших кодобаз, но сузит спектр возможных ошибок и позволит улучшить инструменты, работающие с кодобазами, написанными на этом языке. Это ж хорошо. А идеального кода в природе не бывает. :)

[tonsky.livejournal.com]

Как-то неочевиден переход именно к 3D. В 2D доступно всё то же самое, плюс ориентироваться на плоскости у человека лучше получается. Во всей истории игр, вроде бы, была только одна игра с честным 3D вращением по трем осям (Descent), все остальное так или иначе тяготеет к плоскости (см. интерфейс Homeworld, например).

[ermouth.livejournal.com]

> Как-то неочевиден переход именно к 3D. В 2D доступно всё то же самое

У них, прости, даже название разное. Я почему-то уверен, что тебе не довелось толком попробовать ни очки, ни перчатки – это настолько круче чем любая проекция на 2Д, что я не могу их даже сравнивать.

> все остальное так или иначе тяготеет к плоскости

Ключевое слово «тяготеет». Находясь на Земле, у тебя не получится обмануть вестибулярный аппарат даже будучи в очках, поэтому большинство 3Д миров всё таки с тяготением или вводится какая-то локальная плоскость отсчёта.

[tonsky.livejournal.com]

А чем круче, кстати? Ты же там ходить толком не можешь? Получается что ты внутри полусферы, а она плоская. Нет?

[grayscaler.livejournal.com]

По-моему мы уже в одном шаге, если даже не половине его, от такого уровня ИИ, при котором программирование как некое внешнее составление инструкций для машины, умрёт полностью.

[ermouth.livejournal.com]

Думаю, мы от этого далеко – нет даже предпосылок, даже намёков на технологии.

[morfizm.livejournal.com]

Намёки есть. Есть Machine Learning.

Например, ranking functions в поисковиках (Гугл, Амазон) на моих глазах превратились из формул, которые составлял человек (и вручную tweak'ал параметры) в machine-learned ranking, которая тренируется на тех же исходных данных, формирует какое-то внутреннее представление (с на порядки большим количеством степеней свободы, и это представление совершенно невозможно разобрать, осмыслить и как-то перевести на человеческий язык), но при этом perform'ит значительно лучше вручную составленных формул.

[morfizm.livejournal.com]

Мне не очень трудно представить себе будущее (не очень отдалённое), в котором ты даёшь набор end-to-end тестов, пишешь где-то в коде "отправить платёж p на обработку", а система сама разберётся, куда и какой API call нужно вызывать, какие дата конвертеры использовать для преобразования типов, где добавить логгинг и метрики, т.п. Простым сочетанием из service discovery и эвристик, возможно, machine learned.

[gineer.livejournal.com]

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

Пруф: просто попробуйте прочесть вслух код программы (дословно), и что-то понять ;)

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

А по остальному -- алтенативный вариант это "язык схем",
но с ним та известная проблема, что он вообще нечитаем, и необсуждаем.
То есть, даже имея перед глазами схему (а иначе работать вообще невозможно), сложно описать чего и как в ней делать.

Зато вот идея, чтобы код программы/проекта
можно было легко представить в виде схемы,
и наглядно оценть чего в нем и как... это уже идея.

К сожалению, мого раз уже опробованная,
и пока как-то без результата. %(

[ermouth.livejournal.com]

> Пруф: просто попробуйте прочесть вслух код программы

Ещё можно попытаться спеть. Тоже ничего будет пруф.

«Таджикские мультики выгодно отличаются от немецкой порнухи песнями и плясками», ога

[tupicc.livejournal.com]

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

--

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

ну вот eusesconsortium.org работают, а вот ещё http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html сделали

капля в море

а текст это вчерашний день, потому уже 100% ясно, что иерархический текст строго лучше линейного research.microsoft.com/en-us/um/people/lamport/pubs/proof.pdf

ну и майнд маппинги там всякие https://www.yworks.com/products/yed