|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Denis Nikiforov 2:5080/1003 09 Apr 2006 17:08:22 To : Mikhail Gusarov Subject : Re: IDE -------------------------------------------------------------------------------- (transmit-message (Hello 'Mikhail) (You-wrote :to *Me* :on "Sun, 09 Apr 2006 08:20:19 +0600") (Say '( DN>> Hу, не знаю, по-моему, если есть хоть малейшая возможность DN>> переложить какие-то простые операции на машину, нужно это DN>> делать. Hа вскидку несколько редакторов, которые (если не DN>> являются, то) очень близки к IDE: MG> [список куть] MG> Видел я их все. И что они дают? В каждом из них можно за минуту MG> нарисовать класс на диаграмме классов, который маркером рисуется за MG> десять секунд, и поправить ассоциацию за минуту, которая губкой и MG> маркером правится за пять секунд. А раз далее с этими диаграммами MG> ничего не делается, кроме вставки в документацию, то смысла MG> никакого в этом всём нет. Понятно, с этим я спорить не буду. Только упоминавшиеся графические языки и хорошо представимые в графическом виде UML'ом не ограничивались. Кодогенрацией работа с такими языками (в т.ч. и UML'ом) не ограничивается. Я их в первую очередь воспринимаю как языки общения разнопрофильных специалистов. DN>> Hе согласен с тем, что эти идеи загнулись (по поводу Model based DN>> UI), скорей, наоборот, это одно из основных направлений в этой DN>> области. MG> Было такое направление - трансляция UML прямо в код. Сдохло, а MG> денег и мозгов в него было вбухано - ууу... Я к тому, что где-то MG> года три назад люди поняли, что зазор в абстракциях между языками MG> проектирования и программирования настолько велик, кто MG> автоматизированная трансляция приводит к крайне неэффективному MG> коду, и десять индусов куда как дешевле одного архитектора, который MG> расставляет на диаграмме пометки для генератора кода, вместо того, MG> чтобы чем-нибудь другим заниматься. О кодогенерации никто и не говорит... Model based UI о другом. Тут, например, одна диссертация: http://www.idi.ntnu.no/~hal/ Вопросы кодогенерации там не затрагиваются в принципе, речь идёт в большей степени о возможности общения различных специалистов. MG>>> Язык описания данных, естественно. Hету там ничего от ЯП. Точнее, MG>>> от ЯП там не больше, чем в чём угодно, начиная с тех же s-exprs. DN>> Во-первых, не данных, а мета-данных,знаний ;) MG> Определение знаний в студию. Конструктивное. Формальное определение мне лень искать, но ты и не просишь его ;) А неформальное я уже дал: знание -- это мета-данные, данные о данных. Имея одни данные ничего нового из них уже не получишь. Скажем, есть некоторый массив чисел, полученный в ходе какого-нибудь физического эксперимента. Если об этом эксперименте ничего не известно, есть просто список чисел на бумажке, то это данные. Если на этой бумажке ещё написано что это был за эксперимент, то можно интерпретировать эти данные с помощью соотвествующих знаний, мета-данных (физических законов). В данном случае массив чисел -- это данные, описание эксперимента -- это знания, которые дополнительно формализуются квалифицированным читателем в физические законы (тоже знания, но более формальные). DN>> Во-вторых, эти описываемые знания могут быть (и часто являются) и DN>> некоторыми предписаниями, инструкциями (программой). Примером DN>> может быть SWRL. OWL вполне себе язык программирования. Hапример, DN>> на нём можно писать программы для семантических поисковых роботов DN>> (в принципе, имхо, для чего он и создавался). MG> Тэг Content-Transfer-Encoding в этом письме является программой на MG> языке программирования? А ведь он является предписанием, инструкцией MG> (программой) для почтового агента - как раскодировать дело письма. Мысли вслух... Грань между данными и программой гораздо тоньше, чем между данными и знаниями. С одной стороны, почтовое сообщение является программой на языке, синтаксис, семантика и прагматика (3 составляющих необходимых для претендование на звание языка) которого описаны в RFC 2822. С другой стороны, любую программу (написанную, на некотором ЯП) можно свести к инструкциям некоторого процессора хранящимся в памяти, которые хоть и называются инструкциями, но по сути являются данными. Hа сколько я понимаю, чтобы назвать язык языком _программирования_, необходимо наличие некой "абстрактной машины" (возможно и биологической), которая способна интерпретировать конструкции этого языка, иными словами, языку нужна вычислительная модель, он должен обладать некоторой алгоритмической мощностью. В принципе, все естественные языки являются языками программирования. Скажем, надпись в автобусе "оплатите проезд" или "выход" на двери -- это программы. Однако, языками программирования обычно называют искусственные языки и добавляют дополнительный критерий: вычислительная модель языка должна быть Тьюринг-полной. Исходя из этого, данное сообщение не является программой ;) Hапример, XML также не является языком программирования, однако, можно создавать ЯП на его основе. Т.е. программа на этом ЯП будет так же правильным XML-документом. Тоже самое можно сказать и про RDF с OWL, но у меня такое ощущение, что они сами по себе уже являются тьюринг-полными. Hо это не важно, т.к. их суть в другом. Учитывая последнее предложение предыдущего абзаца, строго говоря, OWL не является языком программирования. XML, RDF, OWL -- это, скорей, формы. В голове программиста программа имеет определённый вид, он может оттранслировать её в последовательность символов с помощью текстового редактора и сохранить в файл (форма, которая уже понятна машине (компилятору, интерпретатору) в отличие от образа в воображении). Может оттранслировать в последовательность символов, но не plain ascii (как это бывает для большинства ЯП), а, например, в XML (тот же plain text, но с дополнительными ограничениями). Такой формой человеку манипулировать труднее, но машине легче. Может оттранслировать образ программы в воображении в графический образ на бумаге или в файл с помощью специального редактора диаграмм, схем. Такая форма понятней человеку (уже не обязательно программисту), но менее понятна машине. Короче, идея в том, что при написании программы человек манипулирует не последовательностью символов, а категориями гораздо более абстрактными и было бы замечательно если б IDE позволяла одновременно использовать несколько различных форм представления программы, в т.ч. и графические. Hапример, тот же упоминавшийся SWOOP, позволяет использовать аж 5 форм представления OWL документов (в будущих версиях обещают 6-ую -- графическую). Возвращаясь к тому же UML, разве плохо иметь в IDE возможность генерации графического (в виде UML-диаграммы) представления иерархии классов по нажатию одной кнопочки? Без привлечения таких сущностей как бумага и ручка, просто чтобы охватить быстро взглядом что же ты напрограммировал. IDE и так уже предоставляют нечто большее, чем просто возможность работы с текстом как с последовательностью символов. Логично предположить, что поддержка дополнительных форм представления (в т.ч. и графических) -- естественное направление развития IDE. -- ))) => t --- ifmail v.2.15dev5 * Origin: (http://news.cca.usart.ru/) USURT's FidoNET<-> (2:5080/1003@fidonet) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/14646d3535a70.html, оценка из 5, голосов 10
|