Проблема перевода для киборгов, компиляции для людей
Для человечьей речи используется слово "перевод" -- при этом лингвистическая традиция уклончива относительно того, является ли порождаемый текст программой (про которую можно говорить в терминах "выполнения" -- вся традиция обсуждения речевых актов -- обещания, просьбы, согласия и отказы, по большому счёту именно про аспект "выполнения". Можно говорить про заход со стороны "нейролингвистического программирования", который вообще про исполнение программ бессознательным. В общем, есть над чем подумать, если задаваться вопросом, что именно за текст переводится), или просто декларациями (которые нужно "понимать", то есть исполнять с ними какие-то действия собственного ума, не порождающие видимых внешних деятельных эффектов).
Для разговора с компьютерами используется слово "компиляция" -- опять же, с многочисленными вариантами (та же "трансляция" это ведь "ихний перевод", как и "наши баксы -- это ведь ихние доллары!").
Если вам нужно перевести или откомпилировать данные (про которые непонятно, как их "исполнять"), то ни "перевести" ни "компилировать" не используется. Говорят только про "мэппинг" (соотнесение одних данных с другими).
Впрочем, и про выполнение тоже много разных слов. Выполнение одних текстов называют "исполнением", других -- "оценкой", третьих -- "выводом", четвертых -- "моделированием", и т.д.
Тут у меня несколько соображений.
1. Онтологизирование, моделирование, программирование, синтез текстов на естественном языке -- это одно.
2. Задача перевода онтологий, моделей, программ и текстов на естественном языке -- это одна и та же задача (а поскольку мы стремительно входим в эпоху мультипарадигмальности, то разные типы "выполнений" нужно признать таковыми, при всём уважении к специализациям типа reasoning или "я просто выполнял приказ"). Есть и множество других похожих задач (например, задача поиска -- это тоже перевод текста вопроса в развернутый текст ответа. Отчёт по базам данных -- перевод текста базы данных и поискового запроса в текст отчёта. Ну, и так далее).
3. Нужно срочно строить онтологию, в терминах которой можно все эти тексты-данные-программы с их исполнениями и переводами можно обсуждать. Меня в нежном программистском детстве учили, что "компиляция -- это такое особое исполнение. Процессор читает текст, и строит в соответствии с этим текстом какой-то другой текст -- выходной, будь то результат традиционного исполнения программы, или результат нетрадиционного исполнения -- откомпилированный входной текст". Такая онтология должна быть основана на лучших известных, контринтуитивных, а не расхожих идеях -- revisionary, а не descriptive (мы ведь ревизионисты, чего и не скрываем -- см. пункт 1 http://ailev.livejournal.com/521610.html, это еще 2007г.. Я, кстати, с тех пор определился -- я ревизионист "справа", конечно. Моя онтология будет радикальной, а в "народную онтологию" я буду мэппить -- и, скорее всего, мэппить в нее уже буду не я, а те самые "критики слева").
Если построить такую общую для разных областей информатики-логики-лингвистики онтологию, то можно пробовать:
а) перенести знания из одних областей в другие. Ибо даже спецы лингвисты и спецы логики по поводу иллокутивности имеют разные представления -- ибо им эта иллокутивность нужна для разного. Вот и нужно договориться как обозначать это разное (выполнение/вычисление в разных смыслах выполнителями/решателями разных видов, перевод с одного языка на другой -- включая "понимание" как перевод с чужого языка на свой собственный с попутным пополнением своего словаря и belief revision, и т.д.). После этого "мэппирования" (перевода, компиляции и т.д.) может появиться идея, как проблемы одной предметной области решать при помощи знаний, найденных в другой предметной области -- несмотря, что формулировки этих проблем и знаний даны в разной терминологии, и сообщества экспертов в этих предметных областях никогда не пересекаются.
б) найти более компактные способы описания многообразия информатики, и за счёт повторноиспользуемости (например, выноса общего для всех этих областей на мета-уровень. Или прописывании операций, которые применимы ко многим типам их операндов) можно резко поднять компактность описания. Алан Кей любит говорить об этом, как "найти тут математику". В других дисциплинах говорят о паттернах, эвристиках, логиках -- неважно, важна цель компактификации знания, чтобы знание принципов освобождало от знания мириадов фактов.
в) учить людей ("компиляции знаний в мозговой код") по времени меньше, а давать знаний больше, как раз за счет компактизации описания многообразия информатики. Я глубоко благодарен Гарегину Карапетовичу Тер-Григорянцу, который когда-то давным-давно в исследовательском ВЦ РГУ учил меня разнообразию вариантов, как можно исполнить одну и ту же программу (макрокомпилировать в машинный код, компилировать традиционно, интерпретировать спецпроцессором именно этого языка -- и т.д., причём всё это на большом стеке языков/выполнителей, включая микропрограммный уровень процессора -- ибо на тогдашних EC ЭВМ уровень микропрограмм был вполне себе еще одним уровнем программирования выполнителя исходной программы), не забывая подсовывать программы с существенной декларативной компонентой и объясняя, что вся эта "декларативность" должна обсуждаться не в связи с текстом программы, а в связи со свойствами ее выполнителя. Мне это до сих пор помогает соображать быстрее в сложных архитектурных ситуациях.
г) переходить от бесплодных споров про "всё должно описываться логическими языками", против "всё должно моделироваться, и потом только будем говорить о коде", против "всё равно естественный язык никто не отменял", против "придётся тяжело вздохнуть и написать программу на универсальном языке программирования", и т.д., к работе с аккуратным представлением мира в виде какого-то текста (программы ли, данных ли, семантической сети ли, набора полнотекстовых документов и данных ли -- это уже будет вопрос второй, и ответом тут может быть -- представлений множество!), с работой над этим текстом множества специализированных выполнителей (опять же -- агентов ли, или просто "спецпроцессоров", или "решателей" -- это вопрос третий). Главное, чтобы не было зацикливания на какой-то моноархитектуре одной из дисциплин, одной терминологии, одной области знаний.
Что мы делаем в этом направлении?
1. регулярно думаем, что уже немало. Пытаемся общаться с командами, представляющими разные парадигмы (например, вот наши попытки общения с computational ontologists -- см. мои мартовские письма в списке рассылки Ontology Summit 2012: http://ontolog.cim3.net/forum/ontology-summit/2012-03/index.html, или разговоры с лингвистами -- http://incose-ru.livejournal.com/32524.html, или разговоры с логиками про "интеракцию" -- http://minski-gaon.livejournal.com/26627.html?thread=362755#t362755 и http://ailev.livejournal.com/915253.html, а последний раз я на заседании логико-философского кружка в ВШЭ, где обсуждалось логическое моделирование текстов был буквально вчера).
2. Разрабатываем методики работы и поддерживающий их софт, отражающий эти идеи общности программистского, моделирующего, онтологического подходов (dot15926 -- это как раз оно). Надеюсь, общность с лингвистическим мы к этому компоту добавим уже в очень скором времени.
3. Пишем такие постинги, как этот -- чтобы в какой-то момент обнаружить, что и слова правильные уже найдены и собраны в одном месте, и объяснение целей нашего поиска сформулировано и записано, и потенциальные партнёры прочли, что-то поняли, и готовы помогать.
Для разговора с компьютерами используется слово "компиляция" -- опять же, с многочисленными вариантами (та же "трансляция" это ведь "ихний перевод", как и "наши баксы -- это ведь ихние доллары!").
Если вам нужно перевести или откомпилировать данные (про которые непонятно, как их "исполнять"), то ни "перевести" ни "компилировать" не используется. Говорят только про "мэппинг" (соотнесение одних данных с другими).
Впрочем, и про выполнение тоже много разных слов. Выполнение одних текстов называют "исполнением", других -- "оценкой", третьих -- "выводом", четвертых -- "моделированием", и т.д.
Тут у меня несколько соображений.
1. Онтологизирование, моделирование, программирование, синтез текстов на естественном языке -- это одно.
2. Задача перевода онтологий, моделей, программ и текстов на естественном языке -- это одна и та же задача (а поскольку мы стремительно входим в эпоху мультипарадигмальности, то разные типы "выполнений" нужно признать таковыми, при всём уважении к специализациям типа reasoning или "я просто выполнял приказ"). Есть и множество других похожих задач (например, задача поиска -- это тоже перевод текста вопроса в развернутый текст ответа. Отчёт по базам данных -- перевод текста базы данных и поискового запроса в текст отчёта. Ну, и так далее).
3. Нужно срочно строить онтологию, в терминах которой можно все эти тексты-данные-программы с их исполнениями и переводами можно обсуждать. Меня в нежном программистском детстве учили, что "компиляция -- это такое особое исполнение. Процессор читает текст, и строит в соответствии с этим текстом какой-то другой текст -- выходной, будь то результат традиционного исполнения программы, или результат нетрадиционного исполнения -- откомпилированный входной текст". Такая онтология должна быть основана на лучших известных, контринтуитивных, а не расхожих идеях -- revisionary, а не descriptive (мы ведь ревизионисты, чего и не скрываем -- см. пункт 1 http://ailev.livejournal.com/521610.html, это еще 2007г.. Я, кстати, с тех пор определился -- я ревизионист "справа", конечно. Моя онтология будет радикальной, а в "народную онтологию" я буду мэппить -- и, скорее всего, мэппить в нее уже буду не я, а те самые "критики слева").
Если построить такую общую для разных областей информатики-логики-лингвистики онтологию, то можно пробовать:
а) перенести знания из одних областей в другие. Ибо даже спецы лингвисты и спецы логики по поводу иллокутивности имеют разные представления -- ибо им эта иллокутивность нужна для разного. Вот и нужно договориться как обозначать это разное (выполнение/вычисление в разных смыслах выполнителями/решателями разных видов, перевод с одного языка на другой -- включая "понимание" как перевод с чужого языка на свой собственный с попутным пополнением своего словаря и belief revision, и т.д.). После этого "мэппирования" (перевода, компиляции и т.д.) может появиться идея, как проблемы одной предметной области решать при помощи знаний, найденных в другой предметной области -- несмотря, что формулировки этих проблем и знаний даны в разной терминологии, и сообщества экспертов в этих предметных областях никогда не пересекаются.
б) найти более компактные способы описания многообразия информатики, и за счёт повторноиспользуемости (например, выноса общего для всех этих областей на мета-уровень. Или прописывании операций, которые применимы ко многим типам их операндов) можно резко поднять компактность описания. Алан Кей любит говорить об этом, как "найти тут математику". В других дисциплинах говорят о паттернах, эвристиках, логиках -- неважно, важна цель компактификации знания, чтобы знание принципов освобождало от знания мириадов фактов.
в) учить людей ("компиляции знаний в мозговой код") по времени меньше, а давать знаний больше, как раз за счет компактизации описания многообразия информатики. Я глубоко благодарен Гарегину Карапетовичу Тер-Григорянцу, который когда-то давным-давно в исследовательском ВЦ РГУ учил меня разнообразию вариантов, как можно исполнить одну и ту же программу (макрокомпилировать в машинный код, компилировать традиционно, интерпретировать спецпроцессором именно этого языка -- и т.д., причём всё это на большом стеке языков/выполнителей, включая микропрограммный уровень процессора -- ибо на тогдашних EC ЭВМ уровень микропрограмм был вполне себе еще одним уровнем программирования выполнителя исходной программы), не забывая подсовывать программы с существенной декларативной компонентой и объясняя, что вся эта "декларативность" должна обсуждаться не в связи с текстом программы, а в связи со свойствами ее выполнителя. Мне это до сих пор помогает соображать быстрее в сложных архитектурных ситуациях.
г) переходить от бесплодных споров про "всё должно описываться логическими языками", против "всё должно моделироваться, и потом только будем говорить о коде", против "всё равно естественный язык никто не отменял", против "придётся тяжело вздохнуть и написать программу на универсальном языке программирования", и т.д., к работе с аккуратным представлением мира в виде какого-то текста (программы ли, данных ли, семантической сети ли, набора полнотекстовых документов и данных ли -- это уже будет вопрос второй, и ответом тут может быть -- представлений множество!), с работой над этим текстом множества специализированных выполнителей (опять же -- агентов ли, или просто "спецпроцессоров", или "решателей" -- это вопрос третий). Главное, чтобы не было зацикливания на какой-то моноархитектуре одной из дисциплин, одной терминологии, одной области знаний.
Что мы делаем в этом направлении?
1. регулярно думаем, что уже немало. Пытаемся общаться с командами, представляющими разные парадигмы (например, вот наши попытки общения с computational ontologists -- см. мои мартовские письма в списке рассылки Ontology Summit 2012: http://ontolog.cim3.net/forum/ontology-summit/2012-03/index.html, или разговоры с лингвистами -- http://incose-ru.livejournal.com/32524.html, или разговоры с логиками про "интеракцию" -- http://minski-gaon.livejournal.com/26627.html?thread=362755#t362755 и http://ailev.livejournal.com/915253.html, а последний раз я на заседании логико-философского кружка в ВШЭ, где обсуждалось логическое моделирование текстов был буквально вчера).
2. Разрабатываем методики работы и поддерживающий их софт, отражающий эти идеи общности программистского, моделирующего, онтологического подходов (dot15926 -- это как раз оно). Надеюсь, общность с лингвистическим мы к этому компоту добавим уже в очень скором времени.
3. Пишем такие постинги, как этот -- чтобы в какой-то момент обнаружить, что и слова правильные уже найдены и собраны в одном месте, и объяснение целей нашего поиска сформулировано и записано, и потенциальные партнёры прочли, что-то поняли, и готовы помогать.