?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

На теологию кода [24 Jun 2014|04:57pm]
В коммент не помещается, поэтому помещу ответ для kusha по поводу его работы("Генезис графического пользовательского интерфейса. К теологии кода" https://www.academia.edu/7410230/, 39 страниц) прямо тут:

К сожалению, у меня сейчас не так много времени на то, чтобы грызть известняк науки в направлении философии кода, и уж тем более теологии оного. Хотя я и признаю, что регулярно касаюсь этих тем у себя в блоге (многое из того, что у меня тут было раскидано за много лет по кусочкам, как-то помянуто вами буквально на четырёх десятках страниц).

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

2. Неявно принято предположение о программировании-в-малом. В то же время сегодня на передний план вышло программирование-в-большом. Как презрительно говорят о "птолемеевской модели человека" (изучающей отдельного человека, и по большому счёту отрицающему социальность самой природы человека), так у вас просвечивает "птолемеевская модель кода" (по большому счёту отрицающая природу кодов как взаимодействия кодов -- в пределе в процедурной алгоритмике взаимодействие кода выполнителя с кодом исполнителя). И вообще, у вас computer science, информатика и алгоритмика получаются чуть ли не синонимами. А ведь это не так (как минимум, большой кусок по моделированию данных/онтологиям в информатику IMHO входит, а вот в computer science и алгоритмику -- нет).

3. С другой стороны, вы не проходите по онтологической линии, которая намечена в той же группе "Аттик" (выполнение программы -- это физический эксперимент: работающая программа это представленный компьютерным "железом" физический объект с какими-то вполне определёнными характеристиками, потом мы ждём некоторое время, в течение которого идут переходные процессы в веществе и полях компьютера, потом по окончанию этих переходных процессов смотрим конечное состояние, т.е. результат работы программы) и поддержана в ISO 15926 (исходный код это только описание программы, её репрезентация. А вот сама программа в момент работы -- темпоральная часть компьютера, физический объект). И дальше можно уже думать про дуализм программы и данных, кода-исходного и кода-исполняемого и т.д..

4. Там и тогда, где и когда вы говорите про переход внимания от объектов к отношениям, странно отсутствие отсылок к Витгенштейну ("мир дан нам как факты: отношения между объектами, ибо про сами объекты мы ничего сказать не можем") и прочим философским людям по линии модели Bunge--Wand--Weber. Более того, вся работа с семантическими моделями выросла по этой линии: факт-ориентированный подход ставится уже въявную в оппозицию объект-ориентированному.

5. А когда пишете про код-как-основу-всего, то там ведь Wolfram с его новой наукой -- http://en.wikipedia.org/wiki/A_New_Kind_of_Science (а вы только про его новый язык пишете), и подобных авторов про "код это наше всё" ещё ой-ой сколько.

6. Когда-то (в 1987г.) я приехал в Москву делать замечание людям с мехмата МГУ (группа "Аттик"), что они пропустили один из режимов выполнения кода: кроме компиляции и интерпретации можно выполнять код ещё и в режиме "непосредственного исполнения" (т.е. кроме интерпретации и компиляции команды "передвинуть курсор в редакторе на клеточку влево" можно ещё двинуть курсор командой, исполняемой путём нажатия на кнопочку "стрелка влево" на клавиатуре). Потом, после долгой теоретической дискуссии на эту тему, переделку программ для того, чтобы на равных (с возможностью перемешивания) включить режим исполнения кода и режим непосредственного исполнения на мехмате МГУ назвали "левенчукизация программы". В принципе, в .15926 Editor всё то же самое -- консоль с языком торчит на видном месте на передней панели, и можно либо выполнить действие прямо в окне редактора, либо выполнить команду языка для того же.

Обратите внимание на поворот внимания к этому в современном программировании, наиболее явно прописанный Chris Granger (http://www.chris-granger.com/2014/03/27/toward-a-better-programming/) и показанный им в демо https://www.youtube.com/watch?v=L6iUm_Cqx2s -- я сейчас с изумлением обнаружил, что хотел написать об этом всплеске внимания к важности "непосредственного манипулирования" у себя в блоге, но как-то расслабился и не написал.

7. Я лично не думаю, что теология кода как-то осмысленна: не думаю, что программисты вдохновятся новыми идеями на основе божественных метафор, а теологи будут развивать свою мысль, приводя примеры из программирования. Как "упражнение по поиску аналогий" -- да, а как "мощный механизм поиска абстракций" -- нет. Я считаю более продуктивным подход по философско-логической линии. И я неоднократно высказывал мысль, что уж скорее современное программирование и computer science дадут идеи для философов, чем наоборот (я и у англоязычных авторов встречал такое же мнение, так что я тут не одинок. Пруфлинки лень искать, правда).

8. С одной стороны, наука прирастает метафорами и блендингом, куда ж без них. С другой стороны, "бойся чертей и аналогий". "Маятник Фуко" Эко показывает, как опасно двигаться по найденным случайным рифмам природы: при специальном поиске эти рифмы находятся всё легче и легче, а сознание становится всё безумней и безумней -- особенно, если забредать в теологические и смежные с ними оккультные дебри. У меня ведь тоже была работа по "теологии кода", но сразу предупрежу (ибо встречал людей, принимавших этот текст за чистую монету): это было опубликовано в первоапрельском номере "Компьютерры" за 1999г., "Хакер Рама, Хакер Кришна" -- http://old.computerra.ru/print/3498/
64 comments|post comment

Системный язык: ты знаешь, всё ещё будет! [24 Jun 2014|10:08pm]
Кратенький апдейт состояния работ по языку системного моделирования (постановка задачи в http://ailev.livejournal.com/1061167.html, какие-то требования к моделеру http://ailev.livejournal.com/1041274.html):

1. То, что хочется уметь выражать по-минимуму, зафиксировано в материалах курса системноинженерного мышления (http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf). Собственно, появление формального языка для этого курса -- это и крупный шаг в развитии самого курса. Всё дальше от метафор и аналогий в рассказах о системной инженерии, всё больше моделирования. Model-based (model-driven) systems engineering, но также и model-based system thinking.

До сих пор нет нормального факт-ориентированного языка, на котором выражаются потребности системного архитектора (сейчас это условные SysML+AADL+Modelica+ArchiMate+Essence), а также ведётся задача поддержки справочных данных для обеспечения связности данных жизненного цикла для всех инженерных дисциплин проекта в целом -- условный ISO 15926. "Условность" тут в том, что я говорю не о самом языке, а о тех задачах, для которых он хорошо нацелен. SysML нужен для описания модульной структуры и интерфейсов, AADL хорош для описания киберфизики, Modelica для принципиальных схем и связанных с ними расчётов, ArchiMate для выражения архитектуры предпринятия, Essence для описания вида жизненного цикла (помним, что системная инженерия наполовину состоит из системноинженерного менеджмента).

В CAD/PLM это всё не поддерживается (а если и поддерживается, то не слишком хорошо по сравнению со специализированными моделерами), это специализированные продукты для системных инженеров.

2. По-прежнему онтологически ориентируемся на ISO 15926 (абстрактный синтаксис), в котором должны быть решены несколько задач:
-- моделирование альф (несколько заходов на их моделирование кончилось пока бесславно). Как минимум, архитектурное моделирование (принципиальная схема -- порты и соединения, модули и их интерфейсы и протоколы, размещения -- геометрия и топология)
-- моделирование деятельности (старый подход к ОргЛану дан в http://incose-ru.livejournal.com/35570.html, а пунктирно намётки к новому подходу я дал в разделе 8 книжки по системноинженерному мышлению).
-- какая-то онтология информатики, в том числе software agents (с этим пока полная беда)
-- расчётный блок: аналог "семантической Modelica"
-- требования, а хоть и в объеме i*

Это "широкий язык", в котором много всего разного, и каждый использует своё, т.е. проективный способ задания viewpoints. Главной фишкой тут может быть одновременная доступность логического и численного моделирования (что сегодня доступно только в виде связки AADL/SysML+Modelica). В части киберфизики вполне возможен выход на кодогенерацию, что обычно сейчас для архитектурных языков.

3. Текстовый синтаксис: функциональный паттерновый язык запросов (работа потихоньку началась, хотя подробности ещё не публиковались). Моделером будет .15926 Editor version 2 (.15926 System Modeler), так что тут явное продвижение (заодно будут архитектурно решаться вопросы по списку критериев для современного моделера http://ailev.livejournal.com/1041274.html).

Библиотеки, накопление знаний.

Моделирование инженерных справочных данных будет просто по умолчанию, то есть моделер этого языка будет ещё и немножко MDM и ещё сильно липким по отношению к PLM и САПР разных других вендоров (ибо там по факту будет встроенный мэппер-на-паттернах, то бишь "генератор адаптеров к другим системам").

4. Графический язык выражает топологию лучше, чем текстовый -- поэтому без него не обойтись. Тут пока идей по-прежнему нет, но уже понятно, что в основе будут паттерны ISO 15926, а не темплейты и не семантическая сетка.
7 comments|post comment

navigation
[ viewing | June 24th, 2014 ]
[ go | previous day|next day ]