Мой пост про наш фронтир в компьютерной революции (https://ailev.livejournal.com/1577769.html) мало кто понял, но это нормально. Мы ж там про то, как компьютерная революция вдруг начала помогать директорам по развитию в крупных фирмах. И тут появились программисты, которые сказали, что их текущих проблем это не решает. Да, компьютерная революция в том и состоит, что решается проблема превращения обычного человека в модельера! Компьютер разворачивается лицом к людям, а не к программистам!
Эта критика неинтересна, аргументы и тезисы ровно те, которые звучали лет десять-двадцать назад, когда я активно интересовался программистской частью задачи, инструментарием моделирования -- но не очень подробно копал в саму практику моделирования, поддерживаемую инструментарием. Моделирование aka познание aka исследование тоже ведь практика, мы берём её SoTA, документируем (ага, познаём познание, размышляем о мышлении) и оформляем дальше в виде учебных курсов. А дальше нам нужен инструментарий, чтобы это всё получило компьютерную поддержку. И вот тут приходит помощь со стороны вдруг побежавшей компьютерной революции: сред моделирования и AI.
Мне нравится вот это про критический рационализм (с неявным учётом праксиологии через "It’s good to choose what to work on at any given time. We don’t have time to work on everything", https://twitter.com/reasonisfun/status/975357650752933888. Вычисления дороги, думайте над тем, о чём думать -- планируйте время своей работы, занимайтесь важным, то есть не отвечайте на любую критику, а только на интересную! И помним, что понятие "интереса" и "любопытства" вполне себе формализуется, в эволюционной эпистемологии, критическом рационализме, да и в representations learning это не просто бытовое слово. А дальше -- интересностей много, а твои ресурсы конечны, вот и планируй!):
- Criticism helps solve your problems
- No need to respond to all criticism
- Criticism can highlight interesting problems
- You’re not required to take on these problems
- Listen to criticism only when it’s interesting.
Тем временем coda.io получила инвестиции раунда D в размере $100 млн (оценка $1.4 млрд) и говорит, что за эти деньги переработает редактор и попробует привнести в экосистему мастеров ещё и написание программ: https://coda.io/@coda/all-in-on-all-in-one-docs. “Our viewpoint is that the lines between the different document formats are artificial and that anyone can make a doc as powerful as an app,” says Shishir Mehrotra, Coda’s cofounder and CEO (https://www.forbes.com/sites/rashishrivastava/2021/07/08/all-in-one-doc-startup-coda-reaches-14-billion-valuation-in-100-million-raise-from-a-major-pension-fund/ ). Если IDE для обычных языков (я считаю фронтиром там разные варианты notebooks, которые позволяют exploratory programming), а для электронных таблиц (так это раньше называлось) среды типа coda.io склеятся, причём с учётом многозадачности и многопользовательскости (раньше называлось "операционная система"), то это будет чудесно. Это среда редактирования_представлений/вёрстки_описаний/моделирования/программирования/онтологизирования (это всё одно!), которая даёт foundational ontology. А мы туда привносим системную upper ontology и идею её нестрогости как priors для платформенного вычислителя. И показываем, как использовать для поддержки развития предприятия, то есть показываем прикладное значение. Так что критики пусть говорят расхожие соображения типа "это ненастоящий искусственный интеллект" или "это ненастоящее программирование" (вот что на такую критику отвечать?), а мы делом займёмся. Критики решают проблемы предыдущего поколения предыдущими средствами, а мы будем решать проблемы текущего поколения текущими средствами. Они (в силу другой онтологии, то есть другого выделения фигур из фона, других объектов внимания) невидимы через онтологические фильтры прошлых поколений знания. Так что сначала покажем результаты, а потом будем отвечать на вопросы "как вы это сделали". Это более продуктивно. В чём ещё фишка? В модели coda.io каждый наш выпускник становится "мейкером", который разрабатывает для предприятия "документы". С нашей стороны -- ничем не отличается от типовой работы "опытных людей" (типа вот таких работ https://coda.io/@stinger/pmm-hub-template, тысячи их, типовые шаблоны дашбордов для самых расхожих ролей в предприятии), за исключением того, что предлагается мета-модель под управлением нашей мета-мета-модели, нашей upper ontology. И это гарантирует, что дальше работа идёт с реально важным в проекте, а не первым, что пришло в голову. Что в ходе работы придётся задумываться о причинно-следственных связях, когда будут заполняться все эти документы, а не просто это формы для удобной раскладки по полочкам того, что и так ясно-понятно. У нас технология усиления интеллекта для архитекторов предприятия и управляющих изменениями, а не технология использования прикладной практики. Сотрудники же потом используют прикладную практику, готовые документы. Секретный соус в том, как мы получаем эти документы!
В coda используют довольно специфичный язык (например, существенно опираются на понятие ritual, а про "документ", который "приложение" я уж молчу. И люди, которые кодят тамошние документы -- мейкеры). Надо будет специально поразбираться с тамошней онтологией, что там за практики в их экосистеме (упор прошлой недели был на персональных практиках, а вообще они ориентированы на компании). Записал в todo себе строчку про разбирательство. Это всё из middle ontology какой-то деятельности (хотя не удивлюсь, если там и об upper ontology думают), хотя на нижнем уровне там вполне себе местнопридуманный язык программирования ("язык формул", экселевский заход). Вперёд вырываются те, кто предлагает удачную upper ontology для описания проблем предметной области. Вольфрам с вольфрам языком, coda.io с языком формул. Есть внятное описание приложений и способа жизни с этими приложениями -- всё взлетает. Нету -- и не взлетает. Jensen Huang замечал: "чтобы иметь деньги, нужно существенно сузить сферу приложения" (это когда он говорил, что абсолютно недостаточно предложить миру GPU общего назначения. Нужно предлагать что-то более специальное, типа "GPU для автомобилей" или "GPU для обработки медицинских данных", и даже не GPU, а специализированные компьютеры вместе с софтом, чтобы уж никаких сомнений в специализированности!).
Скажем, система, которая копировала бы coda в части общего подхода (хороший редактор для встречающихся в корпоративной практике структурированных и неструктурированных данных и API для липкости к корпоративному айти-пейзажу), а языком бы имела Julia (это ж фронтир языка) могла бы иметь шанс на успех для data scientists. Но Julia это не язык для low code. Так что там ещё нужно что-то типа майкрософтовского голосового интерфейса к автоматизации, порождение кода из словесных запросов на естественном языке. И как у Вольфрама -- готовые обширные библиотеки, дающие не самые оптимальные, но работающие "из коробки" и согласованные друг с другом по интерфейсам типовые решения. Тут native Julia была бы более чем хороша. Лет двадцать назад меня грели идеи примерно такого сорта, я бы непременно затеял стартап на эту тему. Но не сегодня.
Сегодня я просто продолжу заниматься тем, чем и занимаюсь: буду делать людей умнее, но на другом уровне интеллект-стека. Доработаю SoTA upper ontology в классическом понимании этой upper ontology (ага, начиная с "возможных миров"), как-то покажу, как её двигать в middle ontology (деятельностные кругозоры, тоже вполне себе классическое понимание), доведу до изложения в виде учебных курсов и покажу, как использовать с SoTA версиями тех айтишных систем, которые уже вышли в production, а хоть и coda.io. Notion.so тут тоже сойдёт, и даже флипчарт с фломастером сойдёт, хотя они будут хуже coda.io. Наш продукт (я ж не один работаю!) -- это мастерство задействовать в качестве персонального и/или корпоративного экзокортекса всё что угодно, и при этом рационально понимать, что из этого "что угодно" лучше, а что хуже, и для каких именно целей.
Смею заверить, ответы на вопросы "а чем хуже notion или airtable или Google table" есть, это ж первый вопрос, который людям в голову приходит! Если такой вопрос у вас есть, то вы ещё не в теме. Приходите, когда этого вопроса у вас уже не будет. Но и не удивляйтесь, когда выяснится, что coda.io -- это только одно из возможных решений. Если вам нужно копать, то можно и лопатой, и экскаватором, и иногда даже ложкой. Главное, чтобы не голыми руками, и не в одиночку. Вот мы так же относимся к моделированию/программированию/онтологизированию/документированию-в-большом. А лаптем это делать или coda.io -- это уже неважно. Хотя постойте...
Ссылок опять не даю. У меня десяток лет назад было много постов про всё это программирование-в-большом. А пару лет назад и про мышление письмом/моделированием (и, конечно, программированием). И там более чем достаточно всё расписано. Сейчас просто все отдельные части этих рассказов, наконец, собраны вместе и работают даже не у нас, а у наших выпускников. Ровно как обсуждал Алан Кей: без излишней сложности, разворачивание оказывается дешёвым и быстрым, а применение развёрнутого (управление вниманием в компании) -- эффективным. Мы рекомендуем подобные продукты для поддержки деятельности директоров по развитию. Особенно хорошо получается, когда директора по развитию (они могут называться и CIO, дело ж не в названии должности) сами моделируют/программируют, как начальники сейчас сами пишут в чат, а не диктуют секретарю-машинистке.
Источник: https://ailev.livejournal.com/1578058.html