From chci!deity!deity.chci.chuvashia.su!gamma.srcc.msu.su!sedov!sedov-a.msk.ru!Alexey Mon Mar 24 11:47:00 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 24 Mar 1997 11:47:00 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA15718; Sat, 22 Mar 1997 07:34:12 +0300 Received: from gw-srcc.gamma.ru by deity.chci.chuvashia.su with ESMTP id XAA26563; (8.6.12/vak/1dot9) Fri, 21 Mar 1997 23:32:06 +0300 Received: from srcc.UUCP (uucp@localhost) by gw-srcc.gamma.ru (8.8.4/8.8.4) with UUCP id XAA08759 for alek@chavb.chuvashia.su; Fri, 21 Mar 1997 23:17:17 +0300 (MSK) Received: by gamma.srcc.msu.su; Fri, 21 Mar 1997 23:17:10 +0300 Received: by sedov-a.msk.ru (UUPC/@ v5.09gamma, 14Mar93); Fri, 21 Mar 1997 23:17:12 +0300 To: alek@chavb.chuvashia.su References: Message-Id: Organization: Private site From: "Alexey A. Sedov" Date: Fri, 21 Mar 97 23:17:11 +0300 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Машина теорий (часть 1) Lines: 218 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 13297 Status: RO Уважаемые Господа! Хочу предложить Вам (в сокращении) фрагмент моей старой статьи по ряду проблем построения программ. Статья была написана по другому поводу, чем предлагавшиеся мною ранее материалы, но, надеюсь, она немного прояснит то, что я понимаю под введенными ранее понятиями. Полагаю, ее чтение не оставит сомнений в том, что я НЕ СЧИТАЮ, будто люди мыслят многомерными матрицами. В настоящий момент мне трудно предложить какой-либо иной способ ответить на возникавшие здесь вопросы, чем пересылка в конференцию фрагмента моего архива. Ниже почти не дается ответов, скорее -- проясняются исходные вопросы. Но в структуре знания ВОПРОС ВАЖНЕЕ ОТВЕТА! Правильно поставив вопросы, полнее осознав ситуацию и проблему, мы приближаемся к ИСТИННОМУ ответу больше, чем пытаясь нащупать его "по наитию". Найти ЧТО-ТО можно, только если знаешь, ЧТО ИСКАТЬ. С уважением, A.S. ТЕЗИС 1. Ограничения и законы познания -------------------------------------- 1.1. Человеческая способность одновременного оперирования понятиями ограничена в среднем 4-7 чанками (до 12 чанков -- у наиболее выдающихся особей Homo sapiens). Для простоты положим, что чанк - это ровно одно понятие с минимальным контекстом, в котором оно используется. Понятно, откуда родились призывы (наиболее знакомые "обычным" программистам по языку С): разбивайте программу на множество МАЛЕНЬКИХ подпрограмм -- из стихийного осознания того физиологического факта, что человек не в состоянии воспринять КАК ЦЕЛОСТНОСТЬ текст объемом более половины обычной книжной страницы. 1.2. Разработка программы - это всегда ПРОЦЕСС ПОСТИЖЕНИЯ разработчиком проблемы, решаемой программой (я не пишу "программистом" только потому, что нанюхавшиеся забугорных веяний снобы теперь нагло обзывают трудягу- программиста "кодировщиком" :-(). Процесс постижения задачи в основном и обслуживают широко распространенные на заграницах CASE-технологии, весьма мало используемые в exСССР. Наши крутые программисты либо слишком умны, либо слишком ленивы, чтобы отделять фиксацию собственного понимания задачи от порождения соответствующего кода на языках программирования. Да и необходимость разбираться в мудреных диаграммах, языках и схемах CASE (а тем более - использовать их самому!) не привлекает. Поэтому большинство отечественных проектов настолько неструктурировано, что нельзя отделить СЕМАНТИЧЕСКИЙ СЛОЙ РЕШЕНИЯ ЗАДАЧИ от чисто кодового средства реализации решения. Народ ваяет прямо на C++ или Delphi и уверен, что держит Бога за бороду... Компании типа Borland и Microsoft услиленно поддерживают в несчастных эти самодовольные иллюзии... :-)) Из чувства патриотизма (и справедливости) должен заметить, что забугорным программерам тоже не слишком помогают их CASE-технологии в работе с ПРОЦЕССОМ ПОЗНАНИЯ задачи, поскольку предназначены они не для этого, а для создание разнообразных frameworks по исходной постановке. Так что обозначенная проблема не знает границ. 1.3. Ввязавшись в процесс постижения чего-либо - ВСЕГДА ИТЕРАЦИОННУЮ ПРОЦЕДУРУ! - проектировщик не все постигает сразу в окончательном виде. Понимание приходит постепенно, шаг за шагом, слой за слоем. Если проект делается сразу в коде, то это означает регулярное перепрограммирование задачи (хорошо, если частичное!). При этом понятия, казавшиеся поначалу очень важными, постепенно "отходят на второй план", вытесняясь из сознания другими понятиями, более отражающими истинную природу задачи. Но ни в языках программирования, ни в средах разработки программ нет адекватных инструментов как для отражения ЭВОЛЮЦИИ понятий, так и ОБСЛУЖИ- ВАНИЯ этой эволюции. Нельзя считать слишком серьезными претензии на это ООП, так как смена одной иерархии классов на другую - это КАТАСТРОФА проекта (или, мягче выражаясь, его перепрограммирование). Максимум, даваемый ООП в руках НАСТОЯЩЕГО профессионала - это четкая фиксация в виде иерархии классов ИТОГА процесса постижения НА ТЕКУЩИЙ МОМЕНТ. Продолжение процесса постижения ЗАВТРА сделает сегоднящнюю иерархию классов процентов на 75 (скажем так) "неактуальной". Да и в самой иерархии классов нет четкого деления на "уровни понимания" и нет способа указать, "маршрут познания", вне следования которому постижение чужих иерархий часто превращается в мучительную задачу, которая вполне сродни постижению чужого текста программы на Forth, написанного человеком с отличным от "стандартного" мышлением. 1.4. Основной парадокс программирования: конечным продуктом разработки программной системы является ИСЧЕРПЫВАЮЩЕЕ и ТОЧНОЕ (в идеале) ПОНИМАНИЕ решаемой задачи, которое как раз и НЕ записывается в каком-либо виде и никак не фиксируется. Записывается и фиксируется совсем другая вещь: порожденное пониманием ЧАСТНОЕ РЕШЕНИЕ задачи. Восстановить по решению исходное понимание бывает ВСЕГДА просто невозможно! ТЕЗИС 2. Основная проблема программирования ------------------------------------------- 2.1. Сложность есть МЕРА НЕОДНОРОДНОСТИ. Чем более разнообразны составляющие нечто части, чем более разнообразны образуемые между частями связи - тем выше сложность этого нечто. Сложность вселенной, состоящей из одинаковым образом сложенных одинаковых кирпичей равна сложности одного кирпича и образуемых им с соседями связей (теорема редукции сложности). Таким образом, сложность выражает не масс-энергетические характеристики мира (см. E=m*c**2), а СТРУКТУРНЫЕ его свойства, причем весьма емкО и общО. 2.2. Все разработчики программ имеют дело ИСКЛЮЧИТЕЛЬНО со сложностью. Программы не имеют ни массы, ни энергии (если отвлечься от параметров исполняющего их hardware). Программы - это ЧИСТЫЕ СТРУКТУРЫ, и сложность является одним из основных интегральных параметров этих структур. Борьбе со сложностью и посвящают программисты свою жизнь. Эта борьба обычно вполне безнадежна для программистов, поскольку они не понимают законов мира, в котором пытаются оперировать структурными конструкциями, иерар- хиями классов или словарями. Программисты - герои "невидимого фронта" боев с колоссальными объемами незнания; герои, которых вооружают негоднымы погремушками вместо настоящих инструментов постижения истины. Настоящие профессионалы быстро понимают, что разработчики языков программирования типа C/C++ или Pascal/Modula/Oberon и фирмы-производители таких инструментов просто морочат им голову, предлагая вместо серьезных средств всего-лишь генераторы случайных блужданий в пространстве состояний задачи. В поисках выхода некоторые пытаются создавать собственные инстру- менты (обычно - безуспешно), но большинство открывают для себя НЕязыковые (в смысле ЯВУ) средства программирования типа Forth. Само по себе это уже хорошо, поскольку глупости вроде приоритета значка ++ не застилают теперь им глаза на СУЩЕСТВО дела. Хотя даже Forth сам по себе (и он - прежде всего!) не дает поначалу никаких преимуществ в работе, кроме реального осознания "размеров бедствия". Но осознание проблемы - уже половина решения... 2.3. А существо дело крайне просто сформулировать: основная проблема программирования -- это проблема управления сложностью программы; это проблема "размазывания" сложности вдоль текста программы "ровным слоем" (не слишком толстым, но и не очень тонким - как масло на бутерброде); не допускать "сгущений" сложности важно просто потому, что именно в таких местах сложность легко "перепрыгивает" ограниченные человеческие способности к одновременному восприятию множества взаимосвязанных вещей и в программе появляются не описки, а настоящие ошибки (ограниченность НА ЛЮБОМ УРОВНЕ ПОЗНАНИЯ понимания задачи НЕЛЬЗЯ считать ошибкой - это просто ИМАНЕНТНАЯ особенность познания, процесс которого, как известно, бесконечен). 2.4. Если попробовать пересказать "своими словами" (без формул) учебник матанализа, то можно обнаружить, что пересказ занимает на порядки больший объем текста, чем "первоисточник", а также НЕПРИГОДЕН к использованию на практике по причине неспособности дать краткие и внятные РЕЦЕПТЫ действий в типовых ситуациях. Этот феномен объясняется с помощью понятия "метрика текста", в которое здесь не хотелось бы углубляться. Достаточно отметить, что современные средства программирования являются КВАЗИматематическими, поскольку метрики порождаемых ими текстов по мощности не слишком серьезны по сравнению с метриками обычных математических текстов. В чем причина? Причина в том, что математический текст всегда строится В ТЕРМИНАХ РЕШАЕМОЙ ЗАДАЧИ. А вот средства програм- мирования представляют собой всегда некую жесткую "систему команд", в рамках ограниченной и жесткой семантики которой приходится записывать постановки и решения задач. Процесс "трансляции" содержательной постановки задачи в тексты средств программирования выполняется в подавляющем числе случаев "вручную" и состоит в переводе терминов исходной задачи в термины целевого языка. Этот процесс и есть первопричина всех проблем, а его исключение -- цель НОВОЙ технологии программирования. 2.5. Не вдаваясь в детали реализации инструмента, решающего эту задачу, можно отметить лишь одно непременное условие: новая технология должна представлять собой формализм, НЕМАШИННЫЙ АЛГОРИТМ (но понятный и простой для человека!), позволяющий ВСЕГДА записывать постановку задачи и методЫ ее решения в терминах ТОЛЬКО самой задачи с привлечением одного-единственного автоматизма: АВТОМАТИЗМА РАЗДЕЛЕНИЯ И КОНТРОЛЯ СЛОЖНОСТИ. Цель такого автоматизма -- дать ПОЛНЫЙ контроль над любой частью постановки или решения задачи НЕПРОГРАММИСТУ, "активное поле внимания" которого может не превышать обычных 4-7 чанков. 2.6. Сегодня уже известно много способов реализации автоматического разделения сложности. В частности, это логико-матричные методы (например, расширенные таблицы решений), специальные логики (темпоральные, нечеткие и т.п.), методы факторизации, событийно-ориентированные протоколы взаимодействия процессов и т.д. Вопрос представляет не ВОЗМОЖНОСТЬ реализации такой системы, а ее ФОРМА и конкретный набор используемых средств. -------------------------------------------------- ФРАГМЕНТ МОЕГО ОТВЕТА ПО SUBJ ИЗ ЛИЧНОЙ ПЕРЕПИСКИ: -------------------------------------------------- К сожалению, моя книжка "Машины теорий" (рабочее название: "Структура линейного текста и ее альтернативы") находится частично в рукописи, частично -- в голове. Subj занимает меня примерно 15 последних лет. По этому поводу я сам не читал ничего связного: так, разные детали. Боюсь, что в предложенном виде теория эта -- собственно моя. Разумеется, идеи там частично мои, а частично -- чужие. Например, идею таблиц решений (у меня они используются в качестве матриц связей между параметрами процессов) я вычитал у Хамби ("Программирование таблиц решений", М., "Мир", 1976), а потом "закрепил" статьями из Communication of the ASM за 1976-1985 гг. Идею использовать внутри матрицы связей (да и везде в системе) "словный" синтаксис подсказало мне знакомство с языком Forth (Чарльз Мур), книг по которому вышло очень много. Идея многомерных переменных (включающих в себя всегда одновременно: логическое, арифметическое, графическое, звуковое, текстовое и т.д. значения) в общем-то моя, но ее отголоски можно встретить в ООП и языке C++. Теория сложности (сложность есть мера разнообразия), вероятно, собственно моя, как и представления о метрике текстов (линейные и нелинейные тексты, плоские тексты...), логика по основанию больше двух широко известна в современной математике (см., например, Белнап, Стил, "Логика вопросов и ответов", "Мир", 198?.). И т.д. Попробуйте почитать книжку Хамби и познакомиться с языком Forth. Примерную, весьма неполную, но технически наглядную аналогию моей системы можно получить так: представить себе язык Forth, у которого все управляющие слова выброшены и заменены модернизированными таблицами решений. Плюс специальная среда для записи текстов. Плюс специальная транспортная структура этих текстов и БД, используемая при их динамической интерпретации. К сожалению, плюс еще много всего, о чем в одном абзаце не напишешь. Аналогично можно сделать, используя вместо Forth языки C/C++/(Object)Pascal, но тогда нужно отказаться от их собственного синтаксиса, приняв, что программа есть многомерная таблица из слов, а уже определения слов строятся по правилам C/C++/(Object)Pascal. И т.п. Из новых книжек попробуйте почитать: Шлеер, Майер, "Моделирование мира в пространствах состояний", она недавно переводилась, кажется, в киевской "Диалектике". Кстати, если найдете лишнюю книгу и Вам это будет несложно, пришлите и мне по обычной почте экземпляр -- я вышлю Вам деньги, как только потребуется. Здесь тоже есть жаждущие читатели. В общем-то, порадовать мне Вас пока особенно нечем. Я занимаюсь своей технологией урывками, между зарабатыванием хлеба насущного, и поэтому теория, родившаяся у меня в теперешнем виде несколько лет назад воплощена только частично в рукописи и комплекте соответствующих программ. Правда, я использую некоторые элементы в бизнес-разработках. Получается довольно занятно: произ- водительность труда подскакивает примерно на порядок. Надеюсь, я сумею в будущем завершить эту работу, приведя ее к "публикабельному" виду. A.S. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Feb 17 15:57:56 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 17 Feb 1997 15:57:56 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA10250; Sun, 16 Feb 1997 02:52:28 +0300 Received: by deity.chci.chuvashia.su id CAA05897; (8.6.12/vak/1dot9) Sun, 16 Feb 1997 02:13:33 +0300 To: alek@chavb.chuvashia.su From: "RS-Bank CIB" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Дизайн операционных систем Date: Sat, 15 Feb 97 11:24:35 +0300 Organization: CreditImpex Bank Distribution: su Message-ID: References: Reply-To: bnk@info.cib.msk.su NNTP-Posting-Host: news.gamma.ru Mime-Version: 1.0 X-Return-Path: kiae!infcib!info.cib.msk.su!bnk@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 72 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 3561 Status: RO >From: "Alexey A. Sedov" >Date: Thu, 13 Feb 97 10:54:34 +0300 Позволю себе высказать сугубо частное мнение сугубо негениального прикладного программиста, делающего не ОС, а финансовый софт, использующего все эти "кружочки, облачка и стрелочки" на практике, а не для теоретизирования. > Я писал совсем о другом. Одно из последствий роковой ошибки 60-х, -- > массового распространения ЯВУ, -- было то, что общепринятыми стали > системы, фиксирующие не "маршрут познания" решаемой задачи, не > содержание понимания проблемы, достигнутое в процессе мучительного > движения ума из тьмы незнания к свету истины, а наборы значков, > позволяющие записывать частную интерпретацию одного из вариантов Самый выразительый набор значков, позволяющий передать другому "путь познания" - естественный язык. И ничего лучше документации, написанной автором придумать нельзя. > решения. Ужас положения состоит в том, что при завершении работы > над программой разработчик ТЕРЯЕТ (обычно -- невозвратимо) ОСНОВНОЙ > РЕЗУЛЬТАТ СВОЕЙ РАБОТЫ -- ПОНИМАНИЕ ПРОБЛЕМЫ! Оно просто НИГДЕ не > фиксируется (разве что частично и плохо -- в комментариях). Иногда -- > частично, но довольно сносно, -- в документации, если разработчик сам Однако, действительно путь документирования годится постфактум, т.к. одновременно думать над проблемой и описанием думанья над ней невозможно. А по окончании работ многое забудется. Да и не только по окончании - на другой день можно тщетно пытаться вспомнить блестящюю идею, осенившую тебя вчера. > ее пишет. И уж тем более ПОНИМАНИЕ не фиксируется в коде программы! Там > застревают крупицы смысла, след погасшей звезды. Западное решение > проблемы: вводить "уровни проектирования", на которых выполнять > специфицирование задачи с помощью разнообразных PDL. Действительно, > в "сетях" текстов на PDL (включая сюда IDEF* и SDT) застревает часть А вот одновременно думать и рисовать IDEF'овские прямоугольнички, стрелочки или бучевские облачка очень даже можно. Неважно, что в этих диаграммах застревает часть идеи - эти диаграммы очень хороший стимулятор вспоминательных процессов. > исходной семантики задачи. К сожалению, только часть. Причем, не > самая существенная. Обычно это та часть, которая ОБЩА разработчику и > пользователю. "Под водой" остаются, например, мотивы принятия решений > по основным алгоритмам и структурам данных. И посмотрев на диаграмки разработчик вытащит "из-под воды" все что забыл. Правда у другого человека будут другие ассоциации, но они будут в правильном направлении. > > ПОЛНОСТЬЮ понимание проблемы не фиксируется НИГДЕ! Между тем, это > понимание -- ИСТИННЫЙ итог работы, к.п.д. которой при потере результата > упадет почти до нуля: другой разработчик НИКОГДА не сможет продолжить > работу первого, поскольку НИГДЕ не сможет пройти "маршрут познания", > пройденный первым. Да, другой разработчик, решающий ту же задачу, будет > думать, что продолжает дело первого. На самом деле он будет строить > ДРУГУЮ систему. Рано или поздно обе системы придут к противоречию. > И программа перестанет работать. > > Новая технология программирования должна фиксировать не ИТОГ, > а процесс работы ума разработчика, являясь ИСЧЕРПЫВАЮЩИМ источником ^^^^^^^^^^^^^^^^^^^это технология не програмирования и не ближайшего будущего. А сейчас - пишите все что придумали, а чтобы не забыть быстренько рисуйте. -- Stas Selitsky From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Feb 17 15:57:56 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 17 Feb 1997 15:57:56 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA10254; Sun, 16 Feb 1997 02:52:29 +0300 Received: by deity.chci.chuvashia.su id CAA05902; (8.6.12/vak/1dot9) Sun, 16 Feb 1997 02:13:34 +0300 To: alek@chavb.chuvashia.su From: "Uri V. Hnykin" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Дизайн операционных систем Date: Sat, 15 Feb 97 13:26:06 +0400 Organization: unknown Distribution: su Message-ID: <199702151705.NAA00450@itk.udmurtia.su> Reply-To: uri@itk.udmurtia.su NNTP-Posting-Host: localhost X-Return-Path: uri@itk.udmurtia.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 130 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 7252 Status: RO Hi, "Alexey A. Sedov" все остальные ! Слушал я слушал и решил внести свою лепту. Может это уже будет не по тематики данной эхи, но все равно выскажусь, потому что подобных разговоров больше нигде не наблюдается. u> > u> > > В изделиях типа Юникса нет ни грамма "дизайна". В них есть совсем другое - u> > > УМОПОСТИГАЕМАЯ ЛОГИКА ПОВЕДЕНИЯ как на уровне пользователя, так и на уровне u> > > кода. "Дизайн" сам по себе НЕ СУЩЕСТВУЕТ и НЕ СТОИТ РОВНО НИЧЕГО вне головы u> > > человека, только и способного эту логику вложить в "дизайн". u> > u> > Хорошо, "УМОПОСТИГАЕМАЯ ЛОГИКА ПОВЕДЕНИЯ", u> > "концептуальное единство" - как хотите называйте. Можем мы как- u> > нибудь зафиксировать, в виде, отличном от реализации, то есть u> > кода, зафиксировать эту логику и единство? u> u> Тут у меня есть описка. Давайте заменим "УМОПОСТИГАЕМУЮ ЛОГИКА ПОВЕДЕНИЯ" u> на "ИНТУИТИВНО ОЧЕВИДНУЮ, НО НЕФОРМАЛИЗУЕМУЮ ЛОГИКУ ПОВЕДЕНИЯ". Тогда все u> встанет на свои места. Мне кажется что появлению ОС юникс предшествовало появления языка, способного справится с подобной задачей т.е. Си ! И это немаловажный фактор в подобных вещах. Всем известно что для решения задачи надо подбирать соотвествующий инструмент. u> > u> > Ну, и с чего нужно начинать - не с высненния ли достоинств юникса? u> u> Не-а. Сейчас Юникс уже не может оказать НИКАКОГО серьезного влияния u> на рынок пользователей MS Windows. Революцией было бы появление ОС, прекрасно u> исполняющей все software MS Windows, имеющей MS Windows в качестве небольшого u> своего подмножества. Но какой MS Windows? БЕЗ ошибок, работающий раз в 10 Ну например Linux пытается занять это место, причем неплохо старается. u> быстрее и требующий в несколько раз меньше ресурсов. А кроме того, новая ОС u> могла бы иметь такие "мелочи" как встроенную СУБД вместо ФС, РЕАЛЬНУЮ мульти- u> процессность и мультипроцессорность, многотерминальность, встроенную u> подсистему разработки, документирования и распространения visual software, u> базовое средство visual/internet/intranet программирования сочетающее u> логические возможности LISP/PROLOG с вычислительно-аналитическими u> средствами Pascal/C++. В сорцах. При минимальной цене! И т.п., и т.д. А не кажется ли вам господа, что сначала должен появится инструмент, соответсвующий данной задаче ? попробуйте перебрать в голове известные вам языки и приложить их к данной проблеме. У меня ничего не получается ! Единственно возможный путь - путь мелкомягких - посадить толпу, всучить им CASE и состряпать очередное ....... На самом деле толпой ничего толкового не выйдет, в данном случае требуется очередной гений или небольшая хорошо слаженная команда в о главе с гением_не_руководителем и хороший инстремент, позволяющий малыми затратами создавать серьезные проекты. u> Помните историю появления Turbo Pascal? Тогда интегральных сред было u> почти так же мало, как хороших компиляторов. И то, и другое было страшно u> дорогим. И вдруг появился отличный компилятор Pascal, да еще в сочетании u> с IDE! Все удовольствие за 30-40 баксов! Мне так видится, что в течение u> нескольких следующих лет примерно то же самое должно произойти и с ОС. u> До появления Вынь'95 я в этом не был уверен. После знакомства с оным u> шедевром сомнения исчезли -- голубчиков накроют в ближайшее время. u> Причем прямым попаданием. Они заигрались... Жду недождусь когда это произойдет ! u> > кружочки и квадратики могут соответствовать u> > пространству состояний в STD, и другим вещам в других методиках. u> u> Извините, но меня интересуют не системы обозначений, а средства u> моделирования сущностей и связей реального мира. Со средствами записи ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - это твой мозг, вот и применяй его в нужном направлении. u> Я писал совсем о другом. Одно из последствий роковой ошибки 60-х, -- u> массового распространения ЯВУ, -- было то, что общепринятыми стали u> системы, фиксирующие не "маршрут познания" решаемой задачи, не u> содержание понимания проблемы, достигнутое в процессе мучительного u> движения ума из тьмы незнания к свету истины, а наборы значков, u> позволяющие записывать частную интерпретацию одного из вариантов u> решения. Ужас положения состоит в том, что при завершении работы u> над программой разработчик ТЕРЯЕТ (обычно -- невозвратимо) ОСНОВНОЙ u> РЕЗУЛЬТАТ СВОЕЙ РАБОТЫ -- ПОНИМАНИЕ ПРОБЛЕМЫ! Оно просто НИГДЕ не u> фиксируется (разве что частично и плохо -- в комментариях). Иногда -- u> u> Новая технология программирования должна фиксировать не ИТОГ, u> а процесс работы ума разработчика, являясь ИСЧЕРПЫВАЮЩИМ источником u> сведений по СОДЕРЖАНИЮ решаемой задачи на ВСЕХ этапах ее решения, u> во всех деталях ее понимания автором. Это, собственно, не software, u> а authorware. Да еще снабженное средством регистрации "дао познания". u> Дабы следующий разработчик мог действительно ПРОДОЛЖИТЬ работу, u> пройдя для начала (с ускорением) тернистый путь постижения истины, u> записанный первым. Например, с помощью подсистемы history film. u> u> Это "что ли" -- знак пренебрежения? Напрасно. На самом деле программисты u> в современном понимании никому не нужны. Нужны совсем другие люди: u> способные накапливать, развивать и использовать конкретные знания, u> процедуры и навыки в конкретных профессиях. Нужны пользователи, u> которые бы БЕЗ ПРОГРАММИСТОВ могли спокойно заниматься собственным u> делом. u> u> Понятно, что такой "пользовательский рай" сейчас невозможен по ряду u> причин. Но основной причиной является то, что существующие системы u> разработки программ есть не ИНСТРУМЕНТЫ ПОЗНАНИЯ, а процессоры u> команд (пусть даже "высокого уровня" или "ООП"). Опять проблема приходит туда же - языки кодирования, какую схему ни нарисуй все равно она будет не сложнее возможностей кодировщиков/инструментария/ языка. Да и при создании самой схемы ограниченность языков так и иначе (даже на уровне подсознания) мешает. Приходится учитывать возможности инструментария кодировщиков. u> u> Поэтому речь идет о МАШИНАХ ТЕОРИЙ: программных системах, предоставляющих u> пользователю (непрограммисту) средства построения моделей в области u> его профессиональных интересов. Этакий "универсальный CAD". Из построенной u> модели программа получается АВТОМАТИЧЕСКИ, компиляцией модели. Причем u> можно получать разные программы: можно экспертную систему, а можно u> систему управления или менеджмента. Хочу посмотреть на живую машину теорий. А еще хочу посмотреть на модель мира. Но видимо оба этих хотения ....... лучше удовлетворить вручную. Мужики/Народ/Господа/Джентельмены/......... Кто-нибудь занимался созданием языков ? Может потреплемся. Есть куча мыслей, но увы собеседников на эту тему так мало. К черту DOS! Uri. P.S И вындоз туда-же. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Feb 24 09:46:25 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 24 Feb 1997 09:46:25 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA05689; Sun, 23 Feb 1997 22:00:46 +0300 Received: by deity.chci.chuvashia.su id OAA00710; (8.6.12/vak/1dot9) Sun, 23 Feb 1997 14:10:20 +0300 To: alek@chavb.chuvashia.su From: "Alexander Drugov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Дизайн языков Re: Дизайн систем Date: Sun, 23 Feb 97 01:23:31 +0600 Distribution: su Organization: Softex. Message-ID: Reply-To: dan@softex.nsk.su References: X-Return-Path: vega.nsk.su!softex!softex.nsk.su!dan Mime-Version: 1.0 Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 81 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 3642 Status: RO Здравствуйте, Alexey A. Sedov С большим удовольствием прочитал, Ваше послание. Практически все, изложенные Вами, идеи мне очень близки, особенно теретические посылки Вашей теории. Но я, к сожалению, не знаком с концепцией языка Forth и, видимо, в связи с этим, у меня не сложилось окончательного понятия об, описанной Вами, технической модели. > Примерную, > весьма неполную, но технически наглядную аналогию моей системы можно > получить так: представить себе язык Forth, у которого все управляющие слова > выброшены и заменены модернизированными таблицами решений. Вот в этом месте, мне не понятно. Что Вы понимаете под "модернизированными таблицами решений"? Это имеет отношение к "таблицам переходов в состояния" (State Transition Table) ? Или я не смогу понять без знакомства с языком Forth ? > Плюс специальная > среда для записи текстов. Плюс специальная транспортная структура этих > текстов и БД, используемая при их динамической интерпретации. К сожалению, Вот это уже более понятно. Но почему текстов ? Мне всегда казалось, что плоский текст только с очень большими усилиями можно применять для борьбы со сложностью. (А к сожалению, большинство современых языков программирования только этим представлением и ограничены. 8-(( ) Гораздо больше для этого подходит гипер-текст, как таковой и его проявления. (диаграммное представление мне тоже очень нравится). > плюс еще много всего, о чем в одном абзаце не напишешь. Аналогично можно > сделать, используя вместо Forth языки C/C++/(Object)Pascal, но тогда нужно > отказаться от их собственного синтаксиса, приняв, что программа есть > многомерная таблица из слов, а уже определения слов строятся по правилам > C/C++/(Object)Pascal. И т.п. Опять таблица. :((. Не понимаю. Может быть ... некая иерархическая структура? Я не большой знаток конкретных реализаций современных средств автоматизации проектирования. Но у меня сложилось впечатление, что некоторые из них работают похоже с изложенной Вами технической моделью. И отлична только форма изложения понимания человеком(коллективом) сути задачи. Упомянутые средства. Ваша модель. (Если я правильно понял) -------------------------------------------------------------------------- Фиксируют частное решение Аналогично. задачи, в ее терминах. Предлагаются, как инсрументы Аналогично. борьбы со сложностью. Постоения словаря проекта. Замена управляющих слов модернизирванными таблицами решений. Представление в виде диаграмм и Выбрасывание управляющих слов или других формальных форм, и потом принятие допущения, что программа кодогенерация во внутренний, есть многомерная таблица слов. не являющийся предметом приложения усилий язык. Представление на языке диаграмм Представление программ в виде и пр. формальных форм, а не на текста на естественном языке языке программирования. (формально ограниченным имеющимся в распоряжении словарем) --------------------------------------------------------------------------- Или я ошибаюсь? Я сделал эту таблицу не с целью обидеть Вас и низложить Вашу теорию, а в надежде на Ваши опровержения, которые наверное помогли бы мне лучше понять Вас. С Уважением. --- Alexander Drugov. Russia, Berdsk. E-mail: dan@softex.nsk.su Phone: (38341) 474 45 From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Feb 24 09:46:30 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 24 Feb 1997 09:46:30 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA11939; Mon, 24 Feb 1997 02:00:25 +0300 Received: by deity.chci.chuvashia.su id SAA03933; (8.6.12/vak/1dot9) Sun, 23 Feb 1997 18:10:01 +0300 To: subscribers@deity.chci.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Дизайн языков Re: Дизайн систем Date: Sun, 23 Feb 97 16:44:22 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 258 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 15015 Status: RO Alexander Drugov Feb 22 wrote to Alexey Sedov: > > Примерную, > > весьма неполную, но технически наглядную аналогию моей системы можно > > получить так: представить себе язык Forth, у которого все управляющие слова > > выброшены и заменены модернизированными таблицами решений. > > Вот в этом месте, мне не понятно. > Что Вы понимаете под "модернизированными таблицами решений"? > Это имеет отношение к "таблицам переходов в состояния" > (State Transition Table) ? > > Или я не смогу понять без знакомства с языком Forth ? Да, конечно можете, Forth всего лишь ЛУЧШЕЕ средство, но не единственное. Достоинство Forth заключается в том, что синтаксис языка описывается единственным предложением: программа состоит из слов, разделенных пробелами. Это дескрипция ПРОИЗВОЛЬНОГО ТЕКСТА. Избавившись от синтаксических наворотов, так свойствен- ных языкам типа C++, Forth в умелых руках становится ЧИСТЫМ ИНТЕРПРЕТАТОРОМ СЕМАНТИКИ ЗАДАЧИ. Единственное, что МЕШАЕТ использованию языка в этом направ- лении -- дубовые "управляющие структуры", так знакомые всем по "традиционным" языкам: циклы, условия, переключатели, переходы. Одна из центральных идей моей работы -- ПОЛНОЕ ИСКЛЮЧЕНИЕ этих "управляющих структур" из текстов, описывающих модели и частные алгоритмы их интерпретаций на уровне работы пользователей (поскольку чесотка Дейкстры глубоко въелась в аппаратную архитектуру современных ЭВМ и языков низкого уровня, ВОВСЕ избавить- ся от нее сейчас невозможно). Одним из альтернативных способов замены управляю- щих структур являются многомерные логические матрицы, в частности, ТР (таблицы решений). ТР являются ГОРАЗДО БОЛЕЕ ОБЩИМ средством выражения логики, и, например, содержат в себе все средства вышеперечисленных "управляющих структур". Но что гораздо важднее, ТР являются АВТОМАТИЗМОМ ДЕЛЕНИЯ СЛОЖНОСТИ, так что составив подходящую ТР, всегда имеешь ГАРАНТИЮ того, что на текущем уровне организации модели сложность распределена равномерно-минимально (лемма, следующая из закона сохранения сложности, согласно которому сложность любой модели постоянна, и лишь распределяется по тексту разными способами -- в зависимости от принятой системы обозначений)! Модернизированные мною ТР довольно сложны и их обсуждение весьма объемно, поскольку связано с другими важными элементами используемой мною нотации (нотации, а не языка, поскольку, в отличие от языка, нотация хотя и очевидна человеку, но не выражается формальной грамматикой). Скажу только, что функция таблицы переходов МОЖЕТ быть "нагружена" на ТР, как и множество СОВСЕМ ДРУГИХ функций, например, функция "разделения вариантов", реализуемая в ООП известными механизмами инкапсуляции/наследования/полиморфизма. Но!!! ОСНОВНОЙ ФУНКЦИЕЙ МОДЕРНИЗИРОВАННОЙ ТР является то, что это АВТОМАТИЗМ ДЕКОМПОЗИЦИИ СЛОЖНОСТИ. Это формальный аппарат, позволяющий "дробить", делить, "раскладывать по полочкам" семантику задачи автоматически, сразу после формулировки постановки! Конечно, само АВТОДЕЛЕНИЕ не значит и автоответа (известная заманка ИИ), но отвечать на множество хорошо поставленных простых вопросов, будучи уверенным в их СОВОКУПНОЙ ПОЛНОТЕ, сравнительно просто. К тому же, не обязательно отвечать СРАЗУ на ВСЕ вопросы, описывать реакции на ВСЕ следующие из постановки ситуации. Пропущенные Вами при наполнении модели ответами варианты будут впоследствии интерпретироваться либо по заданному Вами умолчанию, либо как ошибки неполноты модели. Но согласитесь, что получить сообщение "Ситуация не предусмотрена!" от программы гораздо лучше, чем днями искать хитрую логическую ошибку. Тем более, что свой отказ интерпретатор моделей (машина теорий) сопроводит и действием -- ткнет Вас носом в ситуацию, не заполненную Вам ранее. Никто не помешает ТУТ ЖЕ заполнить пустую клеточку требуемым заклинанием и продолжить исполнение программы. Поэтому отладки как таковой здесь просто не существует. Хотя и сохранеется редуцированное тестирование. > > Плюс специальная > > среда для записи текстов. Плюс специальная транспортная структура этих > > текстов и БД, используемая при их динамической интерпретации. К сожалению, > > Вот это уже более понятно. Но почему текстов ? > Мне всегда казалось, что плоский текст только с очень большими усилиями > можно применять для борьбы со сложностью. > (А к сожалению, большинство современых языков > программирования только этим представлением и ограничены. 8-(( ) Вы совершенно правы в своих подозрениях насчет плоского текста. Но дело обстоит еще хуже! Традиционные ЯВУ порождают даже НЕ плоские, а с ЛИНЕЙНЫЕ тексты (т.е. такие, для записи которых используется парадигма непрерывной строки (столбца) команд, которые могут быть линейно пронумерованы от начала текста одной координатой). Знаменитые "структурные конструкции" и советы по выписыванию текста программы "лесенкой" являются ЖУЛЬНИЧЕСТВОМ, скрывающим от программистов этот убийственный факт. Запишите В СТРОКУ оператор ЕСЛИ-ТО-ИНАЧЕ, вложив его в самого себя 50 раз. НЕ ДЕЛАЙТЕ ОТСТУПОВ -- они НЕ НУЖНЫ ПО СИНТАКСИСУ ни языку Pascal, ни языку C! Поймете ли Вы смысл того, что Вы написали? Наверняка нет! Теперь попытайтесь выписать эту же структуру из 50-ти вложений "лесенкой". Помогло? Не слишком -- не видно, где что кончается. "Лесенка" начнет "помогать", когда уровень вложенности не будет больше 3-5 раз и ВЕСЬ ТЕКСТ попадет в ФИЗИОЛОГИЧЕСКИ ограниченное поле Вашего зрения (и активного внимания)! После чего прочитайте про ТР хотя бы по книжке Хамби. И Вы поймете, что 50 вложенных друг в друга операторов IF выражают МНОГОМЕРНУЮ ЛОГИКУ МИРА, которую программисты КАЖДЫЙ ДЕНЬ, на работе, пытаются спроецировать ДАЖЕ НЕ НА ПЛОСКОСТЬ, а в ЛИНИЮ! Задайте себе вопрос: сколько проекций В ЛИНИЮ реально N-мерного объекта нужно сделать, чтобы получить его более-менее приличную модель? Как организовать СВЯЗИ этого огромного числа проекций, чтобы они "ужи- вались" в теле программы? Попытайтесь ответить, и Вы поймете, почему мы сидим вместе с современными средствами проектирования программ в такой глухой технологической заднице. Здесь зарыт ТРИВИАЛЬНЫЙ ответ на все сегодняшние технологические муки программистов: они имеют никуда не годные иструменты. Вынужденные действовать в абстрактных мирах, размерность которых редко падает до N*M, несчастные программеры снабжены ОДНОМЕРНЫМИ инструментами, которые В ОЧЕНЬ УЗКИХ ПРЕДЕЛАХ (ИНОГДА!) позволяют получать НЕ ПРОЕКЦИИ -- НЕТ! -- ДВУМЕРНЫЕ АНАЛОГИИ интересующей их реальности! Лично я в существующей ситуации утешаюсь только одним: какова же должна быть ИСТИННАЯ МОЩЬ человеческого гения, если даже этими погремушками мы способны писать РАБОТАЮЩИЕ программы! Не устаю поражаться этому чуду... Ведь граф Монте-Кристо, рывший ложкой тоннель из темницы, имел по сравнению с нами просто божественный рабочий инструмент: его ложка имела метрику, АУТЕНТИЧНУЮ реальности, там не хватало только КОЛИЧЕСТВА. Поэтому заботы графа лично мне смешны. Счастливец! Ты попробуй НИТКОЙ вырыть свой тоннель! > Гораздо больше для этого подходит гипер-текст, как таковой > и его проявления. > (диаграммное представление мне тоже очень нравится). Не могу с Вами согласиться. Гипертекст -- это ничем не ограниченный хаос связей с неконтролируемой сложностью любого фрагмента. Диаграмма обычно еще более бесполезна, поскольку не выражает НИЧЕГО (просто не может этого делать!), кроме АНАЛОГИЙ реальности. Лично мне аналогии не интересны. Интереснее методы ТОЧНОГО, ЯСНОГО, ПОЛНОГО, НЕДВУСМЫСЛЕННОГО описания САМОЙ РЕАЛЬНОСТИ. По врожденной любознательности меня интересует ГЕНЕТИЧЕСКИЙ КОД реального мира. Методом аналогий его не постичь. > > плюс еще много всего, о чем в одном абзаце не напишешь. Аналогично можно > > сделать, используя вместо Forth языки C/C++/(Object)Pascal, но тогда нужно > > отказаться от их собственного синтаксиса, приняв, что программа есть > > многомерная таблица из слов, а уже определения слов строятся по правилам > > C/C++/(Object)Pascal. И т.п. > > Опять таблица. :((. Не понимаю. > Может быть ... некая иерархическая структура? Например, иерархия многомерных таблиц. Хотя -- НЕ ТОЛЬКО иерархия. С иерархической структурностью все сравнительно просто. Но вот "боковая", "соседская" организация объектов модели, разная степень взаимодействия "соседей" -- это именно та область, где ООП становится ПРАКТИЧЕСКИ БЕСПОЛЕЗНЫМ, (вместе с парадигмой иерархии), а вот парадигма МНОГОМЕРНОГО ПРОСТРАНСТВА СОСТОЯНИЙ, где ВСЕ СВЯЗАНО СО ВСЕМ, но КАЖДУЮ связь можно отделить от других и проанализировать независимо, прекрасно справляется с делом. Выражается ли такое пространство состояний ИЕРАРХИЕЙ, ОТНОШЕНИЕМ СОСЕДСТВА И ВЗАИМОВЛИЯНИЯ или НАБОРОМ НЕЗАВИСИМЫХ ПОДСИСТЕМ -- второстепенно. > Я не большой знаток конкретных реализаций современных средств автоматизации > проектирования. Но у меня сложилось впечатление, что некоторые из них > работают похоже с изложенной Вами технической моделью. > И отлична только форма изложения понимания человеком(коллективом) > сути задачи. > > Упомянутые средства. Ваша модель. (Если я правильно понял) > -------------------------------------------------------------------------- > Фиксируют частное решение Аналогично. > задачи, в ее терминах. Фиксируются РАЗЛИЧНЫЕ ПОСТАНОВКИ задачи, а также любые варианты решений по любой постановке. > Предлагаются, как инсрументы Аналогично. > борьбы со сложностью. Предлагается как инструмент для универсального моделирования процессов произвольной природы на компьютере, исключающий традиционное программирование. > Постоения словаря проекта. Замена управляющих слов > модернизирванными таблицами решений. Для каждой модели из конкретной предметной области строится специальный тезаурус (словарь). > Представление в виде диаграмм и Выбрасывание управляющих слов или > других формальных форм, и потом принятие допущения, что программа > кодогенерация во внутренний, есть многомерная таблица слов. > не являющийся предметом приложения > усилий язык. Механизм модернизированных ТР позволяет представить модель как иерархию, коллекцию или другую организованную совокупность многомерных матриц-ТР, состоящих из слов тезауруса. В реальной работе часто используются двумерные (плос- кие) проекции ТР, хотя это и приводит к ряду проблем при неаккуратной работе. Многомерные матрицы просто ТРУДНЕЕ воспринимаются ПОНАЧАЛУ, но они точнее и не провоцируют логические ошибки. > Представление на языке диаграмм Представление программ в виде > и пр. формальных форм, а не на текста на естественном языке > языке программирования. (формально ограниченным имеющимся > в распоряжении словарем) Итогом работы является модель (="разложенная по полочкам" полная совокупность представлений по конкретному вопросу). Модель содер- жит в себе теории (=логически непро- тиворечивые ЧАСТИЧНЫЕ построения в рамках модели, не являющиеся полными, освещающие ОДНУ ИЗ ВОЗМОЖНЫХ ТОЧЕК ЗРЕНИЯ на вопрос). Модель может быть итерпретирована специальным интерпретатором моделей (машиной теорий) с целью получения ответов на вопросы в соответствии с одной или всеми содержащимися в модели теориями. Поэтому характерно получение БОЛЕЕ ЧЕМ ОДНОГО ПРАВИЛЬНОГО ответа (степень различия ответов может быть разной). Модель может быть откомпилирована специ- альным компилятором моделей, превратившись в текст на одном из существующих языков программирования (VB или С++), и став после второй компиляции обычной программой: экспертной системой, диалоговой системой, пакетной задачей -- в зависимости от способа компиляции модели. > --------------------------------------------------------------------------- > Или я ошибаюсь? > > Я сделал эту таблицу не с целью обидеть Вас и низложить > Вашу теорию, а в надежде на Ваши опровержения, которые наверное > помогли бы мне лучше понять Вас. Меня ОЧЕНЬ сложно обидеть обсуждением ИДЕЙ! Даже если это МОИ идеи и их сильно ругают. :-)) Вы РОВНО НИЧЕМ не рискуете, не переходя на личности (мою или чью-то еще). Изложенные элементы теории относятся примерно к 1984-88 году, когда ряд моих знакомых имели несчастье выслушивать от меня пространные изложения теории куда более подробно, чем я сейчас могу позволить себе это сделать. Мою теорию трудно "низложить", поскольку она изрядной частью давно уже стала практикой и дает довольно приличные результаты. Кроме того, я не излагал СОВЕРШЕННО ряда ключевых аспектов, составляющих мое маленькое know how. Любой, кто попытается "быстренько слепить" что-то подобное, столь же быстро поймет характер проблем, на которые я потратил так много времени. > С Уважением. > --- > Alexander Drugov. Russia, Berdsk. > E-mail: dan@softex.nsk.su Phone: (38341) 474 45 Надеюсь, что помог. A.S. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Feb 24 12:15:20 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 24 Feb 1997 12:15:20 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA18490; Mon, 24 Feb 1997 18:05:27 +0300 Received: by deity.chci.chuvashia.su id KAA10831; (8.6.12/vak/1dot9) Mon, 24 Feb 1997 10:14:32 +0300 To: subscribers@deity.chci.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Машина теорий (часть 2) Date: Sun, 23 Feb 97 20:53:21 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 139 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 8579 Status: RO Уважаемые Господа! Если не возражаете, я продолжу посылать сюда небольшие выдержки из своего архива, поясняющие отдельные вопросы, затронутые мною ранее. Надеюсь, это поможет прояснить мой "птичий язык", который стал мне уже привычен, но, наверное, не является общепринятым. С уважением, A.S. ТЕЗИС 3. Тупик языков программирования -------------------------------------- 3.0. В начале 60-х в технологии программирования был совершен тяжелый просчет - были введены и массово распространились современные языки высокого уровня (ЯВУ). Последующее печальное развитие событий (прогресс скорости CPU составил более чем шесть порядков, тогда как производительность труда программистов возросла едва ли на порядок) было следствием ряда характерных черт ЯВУ, не преодоленных по сей день. 3.1. Можно выделить много второстепенных черт ЯВУ, затеяв дискуссии о преимуществах C над Pascal, Java над C++, или наоборот, но все это будут бесполезные споры. ПОРОЧЕН САМ ПРИНЦИП современных ЯВУ: вместо инструментов познания, записи, накопления и расширения человеческого опыта в конкретных предметных областях, ЯВУ представляют собой громоздкие, противоречивые, нелепые и ограниченные СИСТЕМЫ ОБОЗНАЧЕНИЙ, придуманные, в основном, для удобства разработчиков компиляторов. :-)) Вся многотрудная деятельность ANSI и ISO, в принципе, почти бесполезна, так как является полным аналогом кампаний по наведению порядка в мире молекулярного хаоса идей, подходов и принципов разработки ЯВУ, основной смысл которых состоит не в том, чтобы ГАРАНТИРОВАТЬ решение реальных задач в желаемые сроки, а построить очередную систему для обеспечения СЛУЧАЙНОГО блуждания программиста в пространстве состояний решаемой задачи. Все существующие ЯВУ были построены в результате логически не обоснованного "озарения" их разработчиков разными видами титанических идей. При этом разработчики ЯВУ ПОЛНОСТЬЮ игнорировали суть проблем, возникающих при решении мало-мальски серьезных задач. 3.2. Даже если не обращать внимания на темноты, провалы и лакуны, неортогональность и противоречивость СЕМАНТИКИ ЯВУ, есть еще одна печальная закономерность, свойственная почти всем им: они имеют СИНТАКСИС и этот синтаксис - УЖАСЕН! Мы так привыкли к хитрым значками и их сочетаниям типа ((((((((())))))))) - Lisp, *++->+= - С/С++, :=@= - Pascal и т.д., - что даже не задаемся вопросом: а ЗАЧЕМ все это нагорожено? Ведь, несмотря на все хитросплетения, Pascal и C, например, СЕМАНТИЧЕСКИ ТОЖДЕСТВЕННЫ в 95% своих возможностей и не имеют НИКАКИХ преимуществ друг перед другом, являясь оба ОДИНАКОВО ПЛОХИМИ (или одинаково хорошими :-) языками... ЯВУ уже 30 лет водят программистов по одному и тому же порочному кругу проблем, ничуть не приближая решение ни одной из них. Более того, проблема ошибок в программах с появлением ООП просто УСУГУБИЛАСЬ, и любой знающий человек сразу скажет, что отлаживать объектные программы куда труднее, чем обычные процедурные. 3.3. Осознание этих истин побудило меня в свое время заняться поисками истинных причин возникновения проблем, являющихся в ЯВУ хроническими, и ничуть не решаемыми НИ ОДНИМ новым ЯВУ - будь то Java, Oberon или C++++... ТЕЗИС 4. Процессы и параметры, пространство состояний ----------------------------------------------------- 4.0. Одной из идей, все поставившей на ноги, стало представление о пространстве состояний решаемой задачи. Вкратце это вот что. В мире нет ничего "твердого", мир - это ансамбль взаимодействующих динамических процессов, иногда иерархически связанных, но очень часто - НЕТ (вот причина провала ООП). Каждый процесс интересен нам в конкретном случае проявлением ряда своих пара- метров. Каждый параметр характеризуется дискретным перечислимым набором зна- чений (например, {мир, война}, {горячий, теплый, холодный}, {киты, тюлени, олени} и т.п.). Каждому значению можно сопоставить числовое множество, иногда просто нумерующее значения по порядку (при слабой математической подоплеке изучаемой области), иногда представляющее собой участок числового континиума (температура для физики, например), а иногда - числовое гиперпространство с законами много сложнее аксиом матанализа (алгебры элементарных частиц). 4.1. Выбирая "квант наблюдения" интересующего нас суперпроцесса (среды), содержащего все остальные микропроцессы, мы имеем МНОЖЕСТВО характерных НЕСОВПАДАЮЩИХ периодов стабильности для подпроцессов рассматриваемого суперпроцесса, при переходе между которыми РАДИКАЛЬНО может меняться не только модель отдельного микропроцесса, но и модель суперпроцесса, пред- ставляющего для микропроцессов СРЕДУ СУЩЕСТВОВАНИЯ. Вне пределов конкретного периода стабильности данного микропроцесса его описание может меняться самым причудливым способом, становясь прямо противоположным текущему. Практически НЕВОЗМОЖНО иметь ОДНО И ТО ЖЕ описание для каждого подпроцесса на все интересующее нас время решения задачи. И здесь не поможет никакая иерархия классов. Требуется для каждого "объекта" иметь БОЛЕЕ ЧЕМ ОДНО ОПИСАНИЕ и свободно переходить между ними в требуемые моменты исполнения модели. 4.2. Каждый микропроцесс интересует нас как набор определенных параметров. Некоторые из них являются внешними для микропроцесса (параметры среды или па- раметры других, связанных ЛЮБЫМ способом с данным микропроцессов), некоторые - внутренние (параметры микропроцесса). Связи между ВСЕМИ параметрами микро- процесса (внешними и внутренними) задаются матрицами связей, описывающими правила перехода между значениями любого параметра при заданных значениях всех других связанных параметров. В простейшем (и наиболее общем случае) матрица связей имеет размерность алгебраического произведения всех значений всех собственных параметров микропроцесса и внешних связанных параметров. ТЕЗИС 5. Многомерность параметров модели ---------------------------------------- 5.0. Правила перехода между значениями параметров в матрице связей процесса ("функции/подпрограммы" в обычном программировании или "методы" в объектном) ОБЯЗАТЕЛЬНО должны иметь ДВА представления: логическое - оперирующее "словесными" обозначениями значений параметра типа {горячий, теплый, холодный} и числовое - оперирующее соответствующими числовыми значениями (для температуры это могут быть соответственно величины {3E+5C, 42.3C, -70C}). "Словесно-логическое рассуждение", понятное даже непрограммисту-специалисту в данной предметной области, должно "подкрепляться" числовыми вычислениями, идущими (")параллельно(") логическому процессированию модели. Наличие только одного (логического или числового) представления модели изучаемого явления делает модель заведомо ущербной, а споры по поводу того, какие языки - "логические" (типа Lisp) или "вычислительные" (типа C/Pascal) "лучше", являются полными аналогами глупых споров о том, что важнее для организма - сердце или желудок. Тогда как без любого из органов обычно быстро наступает смерть, а ОБА упомянутых типа языков способны породить ПОРОЗНЬ только заведомо неполноценные модели, либо лишенные серьезных логических оснований, либо адекватного и эффективного аппарата количественного анализа. 5.1. МНОГОМЕРНОСТЬ значений таким образом введенных "переменных" (параметров процессов) позволяет выполнять ВСЮ постановку задачи в терминах СЕМАНТИКИ этой задачи, создавая тезаурус (словарь) предметной области, и оставляя детализацию "вычислительного" аспекта постановки либо на "потом", либо на работу профессионального математика, либо выполняя эту работу немедленно, если человек, создающий модель, владеет предметно-ориентированной математикой, принятой в данной профессиональной области. Обычно дело тут сводится просто к вызовам стандартных подпрограмм, правда ЛОГИКА МОДЕЛИ может привести к тому, что будут вызываться НЕСКОЛЬКО методов (скажем, решения дифуравнений), но каждый -- либо на ЛОГИЧЕСКОМ участке, где его исполь- зование будет осмысленным, либо ПАРАЛЛЕЛЬНО, если модель включает в себя несколько альтернативных теорий. 5.2. Аналогично логико-цифровому представлению параметров, они могут иметь параллельно и ряды других значений: графических, звуковых, интерфейсных, тексто-комментирующих и т.д. Соответственно, модель является многомерной и по другим аспектам, а поэтому ее исполнение может быть сведено к показу мультфильма, генерации звукового ряда или рассказу (совету, консультации) на естественном языке. Подчеркну, что все это не имеет НИЧЕГО общего со спекуляциями ИИ! A.S. From chci!deity!deity.chci.chuvashia.su!L-relcom Tue Feb 25 18:58:09 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Tue, 25 Feb 1997 18:58:09 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA11410; Wed, 26 Feb 1997 01:44:23 +0200 Received: by deity.chci.chuvashia.su id SAA02978; (8.6.12/vak/1dot9) Tue, 25 Feb 1997 18:50:34 +0300 To: alek@chavb.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Дизайн языков Re: Дизайн систем Date: Fri, 21 Feb 97 20:21:51 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 218 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 13299 Status: RO Уважаемые Господа! Хочу предложить Вам (в сокращении) фрагмент моей старой статьи по ряду проблем построения программ. Статья была написана по другому поводу, чем предлагавшиеся мною ранее материалы, но, надеюсь, она немного прояснит то, что я понимаю под введенными ранее понятиями. Полагаю, ее чтение не оставит сомнений в том, что я НЕ СЧИТАЮ, будто люди мыслят многомерными матрицами. В настоящий момент мне трудно предложить какой-либо иной способ ответить на возникавшие здесь вопросы, чем пересылка в конференцию фрагмента моего архива. Ниже почти не дается ответов, скорее -- проясняются исходные вопросы. Но в структуре знания ВОПРОС ВАЖНЕЕ ОТВЕТА! Правильно поставив вопросы, полнее осознав ситуацию и проблему, мы приближаемся к ИСТИННОМУ ответу больше, чем пытаясь нащупать его "по наитию". Найти ЧТО-ТО можно, только если знаешь, ЧТО ИСКАТЬ. С уважением, A.S. ТЕЗИС 1. Ограничения и законы познания -------------------------------------- 1.1. Человеческая способность одновременного оперирования понятиями ограничена в среднем 4-7 чанками (до 12 чанков -- у наиболее выдающихся особей Homo sapiens). Для простоты положим, что чанк - это ровно одно понятие с минимальным контекстом, в котором оно используется. Понятно, откуда родились призывы (наиболее знакомые "обычным" программистам по языку С): разбивайте программу на множество МАЛЕНЬКИХ подпрограмм -- из стихийного осознания того физиологического факта, что человек не в состоянии воспринять КАК ЦЕЛОСТНОСТЬ текст объемом более половины обычной книжной страницы. 1.2. Разработка программы - это всегда ПРОЦЕСС ПОСТИЖЕНИЯ разработчиком проблемы, решаемой программой (я не пишу "программистом" только потому, что нанюхавшиеся забугорных веяний снобы теперь нагло обзывают трудягу- программиста "кодировщиком" :-(). Процесс постижения задачи в основном и обслуживают широко распространенные на заграницах CASE-технологии, весьма мало используемые в exСССР. Наши крутые программисты либо слишком умны, либо слишком ленивы, чтобы отделять фиксацию собственного понимания задачи от порождения соответствующего кода на языках программирования. Да и необходимость разбираться в мудреных диаграммах, языках и схемах CASE (а тем более - использовать их самому!) не привлекает. Поэтому большинство отечественных проектов настолько неструктурировано, что нельзя отделить СЕМАНТИЧЕСКИЙ СЛОЙ РЕШЕНИЯ ЗАДАЧИ от чисто кодового средства реализации решения. Народ ваяет прямо на C++ или Delphi и уверен, что держит Бога за бороду... Компании типа Borland и Microsoft услиленно поддерживают в несчастных эти самодовольные иллюзии... :-)) Из чувства патриотизма (и справедливости) должен заметить, что забугорным программерам тоже не слишком помогают их CASE-технологии в работе с ПРОЦЕССОМ ПОЗНАНИЯ задачи, поскольку предназначены они не для этого, а для создание разнообразных frameworks по исходной постановке. Так что обозначенная проблема не знает границ. 1.3. Ввязавшись в процесс постижения чего-либо - ВСЕГДА ИТЕРАЦИОННУЮ ПРОЦЕДУРУ! - проектировщик не все постигает сразу в окончательном виде. Понимание приходит постепенно, шаг за шагом, слой за слоем. Если проект делается сразу в коде, то это означает регулярное перепрограммирование задачи (хорошо, если частичное!). При этом понятия, казавшиеся поначалу очень важными, постепенно "отходят на второй план", вытесняясь из сознания другими понятиями, более отражающими истинную природу задачи. Но ни в языках программирования, ни в средах разработки программ нет адекватных инструментов как для отражения ЭВОЛЮЦИИ понятий, так и ОБСЛУЖИ- ВАНИЯ этой эволюции. Нельзя считать слишком серьезными претензии на это ООП, так как смена одной иерархии классов на другую - это КАТАСТРОФА проекта (или, мягче выражаясь, его перепрограммирование). Максимум, даваемый ООП в руках НАСТОЯЩЕГО профессионала - это четкая фиксация в виде иерархии классов ИТОГА процесса постижения НА ТЕКУЩИЙ МОМЕНТ. Продолжение процесса постижения ЗАВТРА сделает сегоднящнюю иерархию классов процентов на 75 (скажем так) "неактуальной". Да и в самой иерархии классов нет четкого деления на "уровни понимания" и нет способа указать, "маршрут познания", вне следования которому постижение чужих иерархий часто превращается в мучительную задачу, которая вполне сродни постижению чужого текста программы на Forth, написанного человеком с отличным от "стандартного" мышлением. 1.4. Основной парадокс программирования: конечным продуктом разработки программной системы является ИСЧЕРПЫВАЮЩЕЕ и ТОЧНОЕ (в идеале) ПОНИМАНИЕ решаемой задачи, которое как раз и НЕ записывается в каком-либо виде и никак не фиксируется. Записывается и фиксируется совсем другая вещь: порожденное пониманием ЧАСТНОЕ РЕШЕНИЕ задачи. Восстановить по решению исходное понимание бывает ВСЕГДА просто невозможно! ТЕЗИС 2. Основная проблема программирования ------------------------------------------- 2.1. Сложность есть МЕРА НЕОДНОРОДНОСТИ. Чем более разнообразны составляющие нечто части, чем более разнообразны образуемые между частями связи - тем выше сложность этого нечто. Сложность вселенной, состоящей из одинаковым образом сложенных одинаковых кирпичей равна сложности одного кирпича и образуемых им с соседями связей (теорема редукции сложности). Таким образом, сложность выражает не масс-энергетические характеристики мира (см. E=m*c**2), а СТРУКТУРНЫЕ его свойства, причем весьма емкО и общО. 2.2. Все разработчики программ имеют дело ИСКЛЮЧИТЕЛЬНО со сложностью. Программы не имеют ни массы, ни энергии (если отвлечься от параметров исполняющего их hardware). Программы - это ЧИСТЫЕ СТРУКТУРЫ, и сложность является одним из основных интегральных параметров этих структур. Борьбе со сложностью и посвящают программисты свою жизнь. Эта борьба обычно вполне безнадежна для программистов, поскольку они не понимают законов мира, в котором пытаются оперировать структурными конструкциями, иерар- хиями классов или словарями. Программисты - герои "невидимого фронта" боев с колоссальными объемами незнания; герои, которых вооружают негоднымы погремушками вместо настоящих инструментов постижения истины. Настоящие профессионалы быстро понимают, что разработчики языков программирования типа C/C++ или Pascal/Modula/Oberon и фирмы-производители таких инструментов просто морочат им голову, предлагая вместо серьезных средств всего-лишь генераторы случайных блужданий в пространстве состояний задачи. В поисках выхода некоторые пытаются создавать собственные инстру- менты (обычно - безуспешно), но большинство открывают для себя НЕязыковые (в смысле ЯВУ) средства программирования типа Forth. Само по себе это уже хорошо, поскольку глупости вроде приоритета значка ++ не застилают теперь им глаза на СУЩЕСТВО дела. Хотя даже Forth сам по себе (и он - прежде всего!) не дает поначалу никаких преимуществ в работе, кроме реального осознания "размеров бедствия". Но осознание проблемы - уже половина решения... 2.3. А существо дело крайне просто сформулировать: основная проблема программирования -- это проблема управления сложностью программы; это проблема "размазывания" сложности вдоль текста программы "ровным слоем" (не слишком толстым, но и не очень тонким - как масло на бутерброде); не допускать "сгущений" сложности важно просто потому, что именно в таких местах сложность легко "перепрыгивает" ограниченные человеческие способности к одновременному восприятию множества взаимосвязанных вещей и в программе появляются не описки, а настоящие ошибки (ограниченность НА ЛЮБОМ УРОВНЕ ПОЗНАНИЯ понимания задачи НЕЛЬЗЯ считать ошибкой - это просто ИМАНЕНТНАЯ особенность познания, процесс которого, как известно, бесконечен). 2.4. Если попробовать пересказать "своими словами" (без формул) учебник матанализа, то можно обнаружить, что пересказ занимает на порядки больший объем текста, чем "первоисточник", а также НЕПРИГОДЕН к использованию на практике по причине неспособности дать краткие и внятные РЕЦЕПТЫ действий в типовых ситуациях. Этот феномен объясняется с помощью понятия "метрика текста", в которое здесь не хотелось бы углубляться. Достаточно отметить, что современные средства программирования являются КВАЗИматематическими, поскольку метрики порождаемых ими текстов по мощности не слишком серьезны по сравнению с метриками обычных математических текстов. В чем причина? Причина в том, что математический текст всегда строится В ТЕРМИНАХ РЕШАЕМОЙ ЗАДАЧИ. А вот средства програм- мирования представляют собой всегда некую жесткую "систему команд", в рамках ограниченной и жесткой семантики которой приходится записывать постановки и решения задач. Процесс "трансляции" содержательной постановки задачи в тексты средств программирования выполняется в подавляющем числе случаев "вручную" и состоит в переводе терминов исходной задачи в термины целевого языка. Этот процесс и есть первопричина всех проблем, а его исключение -- цель НОВОЙ технологии программирования. 2.5. Не вдаваясь в детали реализации инструмента, решающего эту задачу, можно отметить лишь одно непременное условие: новая технология должна представлять собой формализм, НЕМАШИННЫЙ АЛГОРИТМ (но понятный и простой для человека!), позволяющий ВСЕГДА записывать постановку задачи и методЫ ее решения в терминах ТОЛЬКО самой задачи с привлечением одного-единственного автоматизма: АВТОМАТИЗМА РАЗДЕЛЕНИЯ И КОНТРОЛЯ СЛОЖНОСТИ. Цель такого автоматизма -- дать ПОЛНЫЙ контроль над любой частью постановки или решения задачи НЕПРОГРАММИСТУ, "активное поле внимания" которого может не превышать обычных 4-7 чанков. 2.6. Сегодня уже известно много способов реализации автоматического разделения сложности. В частности, это логико-матричные методы (например, расширенные таблицы решений), специальные логики (темпоральные, нечеткие и т.п.), методы факторизации, событийно-ориентированные протоколы взаимодействия процессов и т.д. Вопрос представляет не ВОЗМОЖНОСТЬ реализации такой системы, а ее ФОРМА и конкретный набор используемых средств. -------------------------------------------------- ФРАГМЕНТ МОЕГО ОТВЕТА ПО SUBJ ИЗ ЛИЧНОЙ ПЕРЕПИСКИ: -------------------------------------------------- К сожалению, моя книжка "Машины теорий" (рабочее название: "Структура линейного текста и ее альтернативы") находится частично в рукописи, частично -- в голове. Subj занимает меня примерно 15 последних лет. По этому поводу я сам не читал ничего связного: так, разные детали. Боюсь, что в предложенном виде теория эта -- собственно моя. Разумеется, идеи там частично мои, а частично -- чужие. Например, идею таблиц решений (у меня они используются в качестве матриц связей между параметрами процессов) я вычитал у Хамби ("Программирование таблиц решений", М., "Мир", 1976), а потом "закрепил" статьями из Communication of the ASM за 1976-1985 гг. Идею использовать внутри матрицы связей (да и везде в системе) "словный" синтаксис подсказало мне знакомство с языком Forth (Чарльз Мур), книг по которому вышло очень много. Идея многомерных переменных (включающих в себя всегда одновременно: логическое, арифметическое, графическое, звуковое, текстовое и т.д. значения) в общем-то моя, но ее отголоски можно встретить в ООП и языке C++. Теория сложности (сложность есть мера разнообразия), вероятно, собственно моя, как и представления о метрике текстов (линейные и нелинейные тексты, плоские тексты...), логика по основанию больше двух широко известна в современной математике (см., например, Белнап, Стил, "Логика вопросов и ответов", "Мир", 198?.). И т.д. Попробуйте почитать книжку Хамби и познакомиться с языком Forth. Примерную, весьма неполную, но технически наглядную аналогию моей системы можно получить так: представить себе язык Forth, у которого все управляющие слова выброшены и заменены модернизированными таблицами решений. Плюс специальная среда для записи текстов. Плюс специальная транспортная структура этих текстов и БД, используемая при их динамической интерпретации. К сожалению, плюс еще много всего, о чем в одном абзаце не напишешь. Аналогично можно сделать, используя вместо Forth языки C/C++/(Object)Pascal, но тогда нужно отказаться от их собственного синтаксиса, приняв, что программа есть многомерная таблица из слов, а уже определения слов строятся по правилам C/C++/(Object)Pascal. И т.п. Из новых книжек попробуйте почитать: Шлеер, Майер, "Моделирование мира в пространствах состояний", она недавно переводилась, кажется, в киевской "Диалектике". Кстати, если найдете лишнюю книгу и Вам это будет несложно, пришлите и мне по обычной почте экземпляр -- я вышлю Вам деньги, как только потребуется. Здесь тоже есть жаждущие читатели. В общем-то, порадовать мне Вас пока особенно нечем. Я занимаюсь своей технологией урывками, между зарабатыванием хлеба насущного, и поэтому теория, родившаяся у меня в теперешнем виде несколько лет назад воплощена только частично в рукописи и комплекте соответствующих программ. Правда, я использую некоторые элементы в бизнес-разработках. Получается довольно занятно: произ- водительность труда подскакивает примерно на порядок. Надеюсь, я сумею в будущем завершить эту работу, приведя ее к "публикабельному" виду. A.S. From chci!deity!deity.chci.chuvashia.su!L-relcom Tue Feb 25 18:58:07 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Tue, 25 Feb 1997 18:58:07 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA11406; Wed, 26 Feb 1997 01:44:23 +0200 Received: by deity.chci.chuvashia.su id SAA02973; (8.6.12/vak/1dot9) Tue, 25 Feb 1997 18:50:33 +0300 To: alek@chavb.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Дизайн языков Re: Дизайн систем Date: Fri, 21 Feb 97 20:25:04 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 230 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 11598 Status: RO Diamon A. Solodky wrote (sometimes & somewhere) to ALL: > Hi all Не очень много написал, не слишком внятно, но смысл писания вполне понятен. Чтобы все поняли, я удалил из текста его письма чужие цитаты, дабы проявить истинное глубокомыслие этого автора. Получилось так: ПРОЛОГ: > После душещипательных пассажей в исполнении Алексея Седова & Co как - то > опасно высовываться в конфу - завалят еще :) текстом > (это дань искреннего уважения к интеллектуальной мощи ...) > А не сводится ли это абстрактным рассуждениям вокруг > 1. Как нас, гуру, достали чайники > (стыдливо, но не без кокетства, опуская очи) > 2. unix is rulez > 2. Кто бы мелкомягких завалил - а там ногами затопчем ((с)цитата из анекдота) > 3. Что есть кодирование ? да это ... (полагается писать с пафосом, > как можно более навороченными словами и не менее чем на 3 абзаца :) СОДЕРЖАТЕЛЬНАЯ ЧАСТЬ: > Да, наболело - понимаю :( и сочувствую. Хочется, как лучше - получается, > как обычно (что я сейчас и продемонстрирую). А ЭТО -- ДЕМОНСТРАЦИЯ ТОГО, ЧТО "КАК ОБЫЧНО": > А можно и с шашкой наголо - ежели гуровость позволяет :)) > или НЕ люди, а компьютерно-человековые системы ?!! > или ... > Ага ! > А может, попробовать просто сваять _живую_машину ? Чтобы она была не > средством, а дизайнером (хотя бы частично). > Тафай ;) ПРЕДЛОЖЕНИЕ: > Язык строится на основе идей. Голых и привлекательных. > > Например. Червячок, копающийся в груде информации и извлекающий из > оной структурированную (объектную ?) модель. Ту, что в человеках > называется мета-моделью, с обобщениями и умолчаниями. > // Можно - с сорцами (например, для дебужжинга). > Этакий хрумкающий живой машин. > > Проблемы. > 1. Формат входа > 2. Формат модели > 3. Стратегии построения (дедукция, индукция, аналогия ...). > Можно для начала что-то вроде интеллектуального боровзера. > > Что потом с мета-моделью делать - придумаем. Чего тут можно комментировать? Человеку интересен спор ради спора, ему на весь хай вокруг "программной инженерии" глубоко наплевать, он просто самоутверждается, НИЧЕГО не написав сам по существу дела. Весь контент его "комментариев" можно свести к одному междометию: "ГЫ-ГЫ!". Впрочем, удивляться тут нечему. Подобное "блистание умом" -- любимое дело "неттеров" -- профессиональных сетевых трепачей. Вместо выяснения истины (или хотя бы подобия ее) эти господа повсеместно интенсивно выясняют личные отношения с незнакомыми им людьми, самоутверждаясь там, где им бы приличнее было помолчать, поскольку ничего связного САМИ они сказать по subj не в сос- тоянии. И при отсутствия интеллектуальной потенции их ручки проворно шлепают по клавишам что-нибудь вполне злобное, бессодержательное и хамское, вроде вышеприведенного опуса г-на Diamon A. Solodky. Большинство конференций ЗАБИТО шелухонью на темы, не имеющие ничего общего с их объявленным содержанием. И это -- ОДНИ И ТЕ ЖЕ ТЕМЫ: вместо обсуждения реальных вещей обсуждаются ЛИЧНОСТИ авторов статей. Самозванцы сами назначают себя в ПЕРСОНАЛЬНЫЕ ОЦЕНЩИКИ мнящихся им качеств и способностей других людей, им лично незнакомых, чтобы раздавать эпитеты и навешивать ярлыки. Дабы это не сошло с рук г-ну Solodky, я (так и быть!) слегка обсужу и его самого, и его "ГЫ-ГЫ!", чтобы все видели, как этот г-н потешается ИСКЛЮЧИТЕЛЬНО над самим собой. I: > А может, попробовать просто сваять _живую_машину ? Чтобы она была не > средством, а дизайнером (хотя бы частично). Я не психолог, но подозреваю, что г-н Solodky испытывает что-то вроде оргазма, когда смело и дерзновенно ПЕРЕВИРАЕТ чужие мысли, рекомендуя построить "живую машину", тогда как в оригинале речь велась только об "усилителях интеллекта". Вероятно, он дает этот совет на основании собственного опыта. Чувствуется, много раз он этим занимался, используя в качестве инструмента конечно же НЕ компилятор, а совсем другую ШТУКУ. К сожалению, его здоровый фрейдистский юмор неуместен на фоне понятий типа "технология", "методы проектирования", "модель" и "интерпретатор моделей (машина теорий)". Впрочем, у кого что болит... "Что вы думаете, глядя на этот кирпич?" Помните ответ? Да-да, о ней он думает, о родной... О чем с гоготом и пишет... II: Г-н Solodky явно думает, что держит Бога за бороду, когда формулирует свои "великие проблемы" (прямо списанные с бесплодных идеологем ИИ): > Проблемы. > 1. Формат входа > 2. Формат модели > 3. Стратегии построения (дедукция, индукция, аналогия ...). Прежде чем давать с высокомерным видом безграмотные советы и руссуждать о том, у кого там что наболело, нужно хотя бы представлять себе СОДЕРЖАНИЕ работы разработчиков программных систем, основные проблемы, с которыми они имеют дело на работе каждый день, а также ПРИЧИНЫ их проблем. После чего и в голову не придет выдавать за проблемы ТРЕТЬЕСТЕПЕННЫЕ, да еще и неверно сформулированные детали реализации частных решений. Неверные уже потому, что вместо единственного числа должно стоять множественное (форматЫ входа, форматЫ модели). И смешно утверждать, что дедукция или индукция есть "стратегия" ПОСТРОЕНИЯ модели (тогда как это всего лишь два из возможных способов ее ИНТЕРПРЕТАЦИИ). Идеологемами Пролога вовсе не исчерпываются способы построения/интерпретации моделей, более того, наиболее крупные проекты, построенные на Прологе, с шумом провалились, не достигнув своих целей (см. японский проект ЭВМ 5-го поколения). Модель строится не на индукции или дедукции, которые есть способы ответа на вопросы по ГОТОВОЙ модели, а на простом перечислении входящих в модель сущностей и интересующих вас их параметров. После чего остается ответить еще и на нетривиальный вопрос: а как это все взаимосвязано? На всех этапах ПОСТРОЕНИЯ модели нет ни грамма дедукции или аналогии. Здесь требуются КОНКРЕТНЫЕ ЗНАНИЯ в той области, для которой строится модель (на чем бы она ни строилась): для того, чтобы перечислить элементы модели и указать правила связи их параметров. При интерпретации моделей вовсе не требуется непременно какой-то "дедукции", если все связи параметров заданы явно и их не нужно "выводить". Более того, использование "механизмов вывода" при интерпретации моделей есть один из способов случайного блуждания в пространстве состояний модели, а суть дела состоит именно в том, чтобы такого блуждания избежать. III: А чего стоят "идеи" г-на Solodky о построении "языков программирования": > Червячок, копающийся в груде информации и извлекающий из > оной структурированную (объектную ?) модель. Ту, что в человеках > называется мета-моделью, с обобщениями и умолчаниями. > // Можно - с сорцами (например, для дебужжинга). > Этакий хрумкающий живой машин. Написанное выше -- с кривляниями и ужимками изложенная "светлая мечта" ИИ и всех "конвейерных технологий": удалить ИНДИВИДУАЛЬНОГО человека из процесса разработки программной системы. Эта "идея" ПРЯМО ПРОТИВОПОЛОЖНА излагавшейся мною: удалить из процесса разработки программных систем РУТИНУ (кодирование, отладку, тестирование), снабдив ЧЕЛОВЕКА-разработчика более мощными инструментами синтеза и анализа моделей. Что "накопает" "червячок" г-на Solodky можно сказать сразу -- дырку от бублика. Он не зря проигнорировал мои рассуждения об уровнях сложности, он-то думает, что между мышлением человека и исполнением команд в процессоре НЕТ РАЗНИЦЫ. Поэтому ему и мерещится "хрумкающий живой машин", так и не построенный за 30 лет НИКЕМ, кто об этом грезил! Этот "машин" будет ДУМАТЬ за г-на Solodky! А если его скрестить с другим "машином", который умеет ковшом ворочать, до думатель будет думать, ковш -- грузить, а Емеля (виноват, Solodky) сидеть на печи да поплевывать. Эта "голая и привлекательная" "идея" конечно всегда затмит в глазах невежды идею УСИЛИТЕЛЯ ЧЕЛОВЕЧЕСКИХ СПОСОБНОСТЕЙ, которая на печи лежать не даст, а заставит БОЛЕЕ ИНТЕНСИВНО и ЭФФЕКТИВНО РАБОТАТЬ. Лодыря не заманишь такой перспективой, он будет браниться, как и делает г-н Solodky. IV: > 2. Кто бы мелкомягких завалил - а там ногами затопчем > ((с)цитата из анекдота). Самое неприятное состоит в том, что они САМИ СЕБЯ "заваливают", загоняют в угол странными и плохо реализованными решениями. А все мы, использующие их изделия, рискуем за чужое головотяпство заплатить МИЛЛИОНАМИ СУММАРНЫХ ЛЕТ нашей жизни, которые придется потратить на УХОД из-под Microsoft в случае, если на рынке произойдет КАТАСТРОФА: появится дешевая и общедоступная НАСТОЯЩАЯ ОС для PC. Это может быть забавно только человеку, который свои 100 строк на Паскале всегда перепишет, как бы не обернулись дела. Лично мне это вовсе не смешно, поскольку под "мелкомягких" у меня написано куда больше. V: > 3. Что есть кодирование ? да это ... (полагается писать с пафосом, > как можно более навороченными словами и не менее чем на 3 абзаца :) Можно про кодирование сказать и двумя словами: ОНО ИЗЛИШНЕ! При одном условии: произойдет отказ от странной и порочной практики "полиинструментального проектирования", за счет появления инструментов, позволяющих ПОЛНОСТЬЮ выполнить проект ТОЛЬКО В ТЕРМИНАХ РЕШАЕМОЙ ЗАДАЧИ, без использования "ЯВУ", "диаграмм" или "CASE-технологий". Как это сделать? Лично я знаю ответ на этот вопрос. Но его нельзя изложить в двух словах первому попавшемуся самоуверенному склочнику, который не в состоянии прочесть даже тот краткий фрагмент теории, который попал сюда, без того, чтобы не заорать про "не менее чем 3 абзаца". Коротко, г-н Solodky, в области subj можно только выругаться. Для "неттеров" (профессиональных склочников) объем чужого текста раздражителен и неприятен. Он МЕШАЕТ ругаться. Поэтому и стоит вой про "объемы". Тогда как действительная проблема сетевого общения состоит не в том, чтобы коротко обменяться бранью и разбежаться, а в том, чтобы обменяться СВЕДЕНИЯМИ, ЗНАНИЯМИ, ОПЫТОМ. И если это происходит, то может вызвать неудовольствие только у того, кому НЕЧЕГО предложить на этом поприще. А когда обмен получается, и рядом, в "конфе" кто-то говорит что-то, чего "великий ВЫ" просто не понимаете, не нужно задавать вопросов: нужно просто облить окружающих помоями. Я правильно понял ваш опус? И еще, пока они все будут отмываться, покрасоваться в белом фраке... Как в анекдоте ((с) ваш). Не жмет ли вам ТЕПЕРЬ фрачок-с, г-н Diamon A.Solodky? > --- > Best, -- Diamon A.Solodky > // sol@asrvuz.msk.su A.S. P.S. Я написал ответ сразу, но задержал его на несколько дней: хотел посмотреть, не ошибся ли в оценке поведения моего "героя". Нет, не ошибся. Он весьма "лихо" общается так со всеми оппонентами, раздавая ЛИЧНЫЕ ОЦЕНКИ направо и налево (см. совершенно возмутительную по тону его филиппику "Дизайн языков программирования", где г-н Solodky научает своего оппонента жизни "советами" типа: ты ДОЛЖЕН объяснить заказчику, что он неправ и НЕ ДОЛЖЕН ХОТЕТЬ ТОГО, ЧТО ХОЧЕТ; что "заказчик ВСЕГДА прав" этому "гуру" неизвестно; в этом послании г-н Solodky представляет себя вообще как глубокого и тонкого знатока "правильной жизни", правда умудряется о создании языков не сказать НИЧЕГО, кроме пары благоглупостей). Лично для себя я полагаю дискуссию с этим г-ном полностью завершенной. Не вижу в его посланиях никаких предметов для обсуждения, кроме установ- ленного им самим себе самому статуса "авторитета" и "знатока". Я, правда, не понял, В КАКОЙ ОБЛАСТИ. From chci!deity!deity.chci.chuvashia.su!L-relcom Tue Feb 25 18:58:16 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Tue, 25 Feb 1997 18:58:16 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA11444; Wed, 26 Feb 1997 01:44:33 +0200 Received: by deity.chci.chuvashia.su id SAA02938; (8.6.12/vak/1dot9) Tue, 25 Feb 1997 18:50:28 +0300 To: alek@chavb.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Дизайн языков Re: Дизайн систем Date: Sun, 23 Feb 97 16:44:22 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 258 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 15015 Status: RO Alexander Drugov Feb 22 wrote to Alexey Sedov: > > Примерную, > > весьма неполную, но технически наглядную аналогию моей системы можно > > получить так: представить себе язык Forth, у которого все управляющие слова > > выброшены и заменены модернизированными таблицами решений. > > Вот в этом месте, мне не понятно. > Что Вы понимаете под "модернизированными таблицами решений"? > Это имеет отношение к "таблицам переходов в состояния" > (State Transition Table) ? > > Или я не смогу понять без знакомства с языком Forth ? Да, конечно можете, Forth всего лишь ЛУЧШЕЕ средство, но не единственное. Достоинство Forth заключается в том, что синтаксис языка описывается единственным предложением: программа состоит из слов, разделенных пробелами. Это дескрипция ПРОИЗВОЛЬНОГО ТЕКСТА. Избавившись от синтаксических наворотов, так свойствен- ных языкам типа C++, Forth в умелых руках становится ЧИСТЫМ ИНТЕРПРЕТАТОРОМ СЕМАНТИКИ ЗАДАЧИ. Единственное, что МЕШАЕТ использованию языка в этом направ- лении -- дубовые "управляющие структуры", так знакомые всем по "традиционным" языкам: циклы, условия, переключатели, переходы. Одна из центральных идей моей работы -- ПОЛНОЕ ИСКЛЮЧЕНИЕ этих "управляющих структур" из текстов, описывающих модели и частные алгоритмы их интерпретаций на уровне работы пользователей (поскольку чесотка Дейкстры глубоко въелась в аппаратную архитектуру современных ЭВМ и языков низкого уровня, ВОВСЕ избавить- ся от нее сейчас невозможно). Одним из альтернативных способов замены управляю- щих структур являются многомерные логические матрицы, в частности, ТР (таблицы решений). ТР являются ГОРАЗДО БОЛЕЕ ОБЩИМ средством выражения логики, и, например, содержат в себе все средства вышеперечисленных "управляющих структур". Но что гораздо важднее, ТР являются АВТОМАТИЗМОМ ДЕЛЕНИЯ СЛОЖНОСТИ, так что составив подходящую ТР, всегда имеешь ГАРАНТИЮ того, что на текущем уровне организации модели сложность распределена равномерно-минимально (лемма, следующая из закона сохранения сложности, согласно которому сложность любой модели постоянна, и лишь распределяется по тексту разными способами -- в зависимости от принятой системы обозначений)! Модернизированные мною ТР довольно сложны и их обсуждение весьма объемно, поскольку связано с другими важными элементами используемой мною нотации (нотации, а не языка, поскольку, в отличие от языка, нотация хотя и очевидна человеку, но не выражается формальной грамматикой). Скажу только, что функция таблицы переходов МОЖЕТ быть "нагружена" на ТР, как и множество СОВСЕМ ДРУГИХ функций, например, функция "разделения вариантов", реализуемая в ООП известными механизмами инкапсуляции/наследования/полиморфизма. Но!!! ОСНОВНОЙ ФУНКЦИЕЙ МОДЕРНИЗИРОВАННОЙ ТР является то, что это АВТОМАТИЗМ ДЕКОМПОЗИЦИИ СЛОЖНОСТИ. Это формальный аппарат, позволяющий "дробить", делить, "раскладывать по полочкам" семантику задачи автоматически, сразу после формулировки постановки! Конечно, само АВТОДЕЛЕНИЕ не значит и автоответа (известная заманка ИИ), но отвечать на множество хорошо поставленных простых вопросов, будучи уверенным в их СОВОКУПНОЙ ПОЛНОТЕ, сравнительно просто. К тому же, не обязательно отвечать СРАЗУ на ВСЕ вопросы, описывать реакции на ВСЕ следующие из постановки ситуации. Пропущенные Вами при наполнении модели ответами варианты будут впоследствии интерпретироваться либо по заданному Вами умолчанию, либо как ошибки неполноты модели. Но согласитесь, что получить сообщение "Ситуация не предусмотрена!" от программы гораздо лучше, чем днями искать хитрую логическую ошибку. Тем более, что свой отказ интерпретатор моделей (машина теорий) сопроводит и действием -- ткнет Вас носом в ситуацию, не заполненную Вам ранее. Никто не помешает ТУТ ЖЕ заполнить пустую клеточку требуемым заклинанием и продолжить исполнение программы. Поэтому отладки как таковой здесь просто не существует. Хотя и сохранеется редуцированное тестирование. > > Плюс специальная > > среда для записи текстов. Плюс специальная транспортная структура этих > > текстов и БД, используемая при их динамической интерпретации. К сожалению, > > Вот это уже более понятно. Но почему текстов ? > Мне всегда казалось, что плоский текст только с очень большими усилиями > можно применять для борьбы со сложностью. > (А к сожалению, большинство современых языков > программирования только этим представлением и ограничены. 8-(( ) Вы совершенно правы в своих подозрениях насчет плоского текста. Но дело обстоит еще хуже! Традиционные ЯВУ порождают даже НЕ плоские, а с ЛИНЕЙНЫЕ тексты (т.е. такие, для записи которых используется парадигма непрерывной строки (столбца) команд, которые могут быть линейно пронумерованы от начала текста одной координатой). Знаменитые "структурные конструкции" и советы по выписыванию текста программы "лесенкой" являются ЖУЛЬНИЧЕСТВОМ, скрывающим от программистов этот убийственный факт. Запишите В СТРОКУ оператор ЕСЛИ-ТО-ИНАЧЕ, вложив его в самого себя 50 раз. НЕ ДЕЛАЙТЕ ОТСТУПОВ -- они НЕ НУЖНЫ ПО СИНТАКСИСУ ни языку Pascal, ни языку C! Поймете ли Вы смысл того, что Вы написали? Наверняка нет! Теперь попытайтесь выписать эту же структуру из 50-ти вложений "лесенкой". Помогло? Не слишком -- не видно, где что кончается. "Лесенка" начнет "помогать", когда уровень вложенности не будет больше 3-5 раз и ВЕСЬ ТЕКСТ попадет в ФИЗИОЛОГИЧЕСКИ ограниченное поле Вашего зрения (и активного внимания)! После чего прочитайте про ТР хотя бы по книжке Хамби. И Вы поймете, что 50 вложенных друг в друга операторов IF выражают МНОГОМЕРНУЮ ЛОГИКУ МИРА, которую программисты КАЖДЫЙ ДЕНЬ, на работе, пытаются спроецировать ДАЖЕ НЕ НА ПЛОСКОСТЬ, а в ЛИНИЮ! Задайте себе вопрос: сколько проекций В ЛИНИЮ реально N-мерного объекта нужно сделать, чтобы получить его более-менее приличную модель? Как организовать СВЯЗИ этого огромного числа проекций, чтобы они "ужи- вались" в теле программы? Попытайтесь ответить, и Вы поймете, почему мы сидим вместе с современными средствами проектирования программ в такой глухой технологической заднице. Здесь зарыт ТРИВИАЛЬНЫЙ ответ на все сегодняшние технологические муки программистов: они имеют никуда не годные иструменты. Вынужденные действовать в абстрактных мирах, размерность которых редко падает до N*M, несчастные программеры снабжены ОДНОМЕРНЫМИ инструментами, которые В ОЧЕНЬ УЗКИХ ПРЕДЕЛАХ (ИНОГДА!) позволяют получать НЕ ПРОЕКЦИИ -- НЕТ! -- ДВУМЕРНЫЕ АНАЛОГИИ интересующей их реальности! Лично я в существующей ситуации утешаюсь только одним: какова же должна быть ИСТИННАЯ МОЩЬ человеческого гения, если даже этими погремушками мы способны писать РАБОТАЮЩИЕ программы! Не устаю поражаться этому чуду... Ведь граф Монте-Кристо, рывший ложкой тоннель из темницы, имел по сравнению с нами просто божественный рабочий инструмент: его ложка имела метрику, АУТЕНТИЧНУЮ реальности, там не хватало только КОЛИЧЕСТВА. Поэтому заботы графа лично мне смешны. Счастливец! Ты попробуй НИТКОЙ вырыть свой тоннель! > Гораздо больше для этого подходит гипер-текст, как таковой > и его проявления. > (диаграммное представление мне тоже очень нравится). Не могу с Вами согласиться. Гипертекст -- это ничем не ограниченный хаос связей с неконтролируемой сложностью любого фрагмента. Диаграмма обычно еще более бесполезна, поскольку не выражает НИЧЕГО (просто не может этого делать!), кроме АНАЛОГИЙ реальности. Лично мне аналогии не интересны. Интереснее методы ТОЧНОГО, ЯСНОГО, ПОЛНОГО, НЕДВУСМЫСЛЕННОГО описания САМОЙ РЕАЛЬНОСТИ. По врожденной любознательности меня интересует ГЕНЕТИЧЕСКИЙ КОД реального мира. Методом аналогий его не постичь. > > плюс еще много всего, о чем в одном абзаце не напишешь. Аналогично можно > > сделать, используя вместо Forth языки C/C++/(Object)Pascal, но тогда нужно > > отказаться от их собственного синтаксиса, приняв, что программа есть > > многомерная таблица из слов, а уже определения слов строятся по правилам > > C/C++/(Object)Pascal. И т.п. > > Опять таблица. :((. Не понимаю. > Может быть ... некая иерархическая структура? Например, иерархия многомерных таблиц. Хотя -- НЕ ТОЛЬКО иерархия. С иерархической структурностью все сравнительно просто. Но вот "боковая", "соседская" организация объектов модели, разная степень взаимодействия "соседей" -- это именно та область, где ООП становится ПРАКТИЧЕСКИ БЕСПОЛЕЗНЫМ, (вместе с парадигмой иерархии), а вот парадигма МНОГОМЕРНОГО ПРОСТРАНСТВА СОСТОЯНИЙ, где ВСЕ СВЯЗАНО СО ВСЕМ, но КАЖДУЮ связь можно отделить от других и проанализировать независимо, прекрасно справляется с делом. Выражается ли такое пространство состояний ИЕРАРХИЕЙ, ОТНОШЕНИЕМ СОСЕДСТВА И ВЗАИМОВЛИЯНИЯ или НАБОРОМ НЕЗАВИСИМЫХ ПОДСИСТЕМ -- второстепенно. > Я не большой знаток конкретных реализаций современных средств автоматизации > проектирования. Но у меня сложилось впечатление, что некоторые из них > работают похоже с изложенной Вами технической моделью. > И отлична только форма изложения понимания человеком(коллективом) > сути задачи. > > Упомянутые средства. Ваша модель. (Если я правильно понял) > -------------------------------------------------------------------------- > Фиксируют частное решение Аналогично. > задачи, в ее терминах. Фиксируются РАЗЛИЧНЫЕ ПОСТАНОВКИ задачи, а также любые варианты решений по любой постановке. > Предлагаются, как инсрументы Аналогично. > борьбы со сложностью. Предлагается как инструмент для универсального моделирования процессов произвольной природы на компьютере, исключающий традиционное программирование. > Постоения словаря проекта. Замена управляющих слов > модернизирванными таблицами решений. Для каждой модели из конкретной предметной области строится специальный тезаурус (словарь). > Представление в виде диаграмм и Выбрасывание управляющих слов или > других формальных форм, и потом принятие допущения, что программа > кодогенерация во внутренний, есть многомерная таблица слов. > не являющийся предметом приложения > усилий язык. Механизм модернизированных ТР позволяет представить модель как иерархию, коллекцию или другую организованную совокупность многомерных матриц-ТР, состоящих из слов тезауруса. В реальной работе часто используются двумерные (плос- кие) проекции ТР, хотя это и приводит к ряду проблем при неаккуратной работе. Многомерные матрицы просто ТРУДНЕЕ воспринимаются ПОНАЧАЛУ, но они точнее и не провоцируют логические ошибки. > Представление на языке диаграмм Представление программ в виде > и пр. формальных форм, а не на текста на естественном языке > языке программирования. (формально ограниченным имеющимся > в распоряжении словарем) Итогом работы является модель (="разложенная по полочкам" полная совокупность представлений по конкретному вопросу). Модель содер- жит в себе теории (=логически непро- тиворечивые ЧАСТИЧНЫЕ построения в рамках модели, не являющиеся полными, освещающие ОДНУ ИЗ ВОЗМОЖНЫХ ТОЧЕК ЗРЕНИЯ на вопрос). Модель может быть итерпретирована специальным интерпретатором моделей (машиной теорий) с целью получения ответов на вопросы в соответствии с одной или всеми содержащимися в модели теориями. Поэтому характерно получение БОЛЕЕ ЧЕМ ОДНОГО ПРАВИЛЬНОГО ответа (степень различия ответов может быть разной). Модель может быть откомпилирована специ- альным компилятором моделей, превратившись в текст на одном из существующих языков программирования (VB или С++), и став после второй компиляции обычной программой: экспертной системой, диалоговой системой, пакетной задачей -- в зависимости от способа компиляции модели. > --------------------------------------------------------------------------- > Или я ошибаюсь? > > Я сделал эту таблицу не с целью обидеть Вас и низложить > Вашу теорию, а в надежде на Ваши опровержения, которые наверное > помогли бы мне лучше понять Вас. Меня ОЧЕНЬ сложно обидеть обсуждением ИДЕЙ! Даже если это МОИ идеи и их сильно ругают. :-)) Вы РОВНО НИЧЕМ не рискуете, не переходя на личности (мою или чью-то еще). Изложенные элементы теории относятся примерно к 1984-88 году, когда ряд моих знакомых имели несчастье выслушивать от меня пространные изложения теории куда более подробно, чем я сейчас могу позволить себе это сделать. Мою теорию трудно "низложить", поскольку она изрядной частью давно уже стала практикой и дает довольно приличные результаты. Кроме того, я не излагал СОВЕРШЕННО ряда ключевых аспектов, составляющих мое маленькое know how. Любой, кто попытается "быстренько слепить" что-то подобное, столь же быстро поймет характер проблем, на которые я потратил так много времени. > С Уважением. > --- > Alexander Drugov. Russia, Berdsk. > E-mail: dan@softex.nsk.su Phone: (38341) 474 45 Надеюсь, что помог. A.S. From chci!deity!deity.chci.chuvashia.su!L-relcom Tue Feb 25 18:58:15 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Tue, 25 Feb 1997 18:58:15 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA11438; Wed, 26 Feb 1997 01:44:32 +0200 Received: by deity.chci.chuvashia.su id SAA02927; (8.6.12/vak/1dot9) Tue, 25 Feb 1997 18:50:25 +0300 To: alek@chavb.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Машина теорий (Re: Дизайн языков) Date: Mon, 24 Feb 97 12:50:19 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 183 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 10502 Status: RO Alexander Drugov wrote to Alexey Sedov: > В последнее время, практически во всех моих проектах, бизнес логика > опирается не на сeмантику языка, а на разного рода внешние > структуры, которые должны быть заполняемы в процессе наполнения > ситемы поведением. > А кодирование задачи на ЯВУ ограничивается построением > интерпретирующего ядра и необходимого словаря функциональности. Попробуйте все же познакомиться с языком Forth. Там примерно те же идеи. Forth можно рассматривать не как обычный язык, а, скорее, как "стандартный эмбрион" программы пользователя, из которого можно вырастить "расширением" любые потребные возможности. При этом есть три момента: 1) автоматически (в виде системы словарей) возникает СПЕЦИАЛИЗИРОВАННЫЙ ЯЗЫК ПРОГРАММИРОВАНИЯ, в рамках которого удобно решать поставленную задачу; 2) БАЗОВЫЙ интерпретатор/компилятор Forth (по сравнению с тем же C) ОЧЕНЬ МАЛ, известен во множестве исходных текстов и легко модифицируется КАК ИНСТРУМЕНТАЛЬНАЯ СИСТЕМА; 3) Forth сверхмобилен, ОЧЕНЬ легко реализуется и переносится, способен работать ВЕЗДЕ -- от встроенного чипа до суперЭВМ. Конечно, "стандартный" Forth поначалу может показаться Вам СЛИШКОМ простой системой, но это ощущение обманчиво. Этот язык -- чрезвычайно удобная отправная точка для реализации собственных идей в области создания инструментов. И с этой точки зрения, пожалуй, имеет мало конкурентов. Вторым (не менее эффективным ПОНАЧАЛУ) способом попробовать свои собственные инструменты является построение препроцессоров к стандарт- ным системам: BC++, VB, VC++, (Object)Pascal и т.д. На этом пути можно быстро убедиться в (не)продуктивности своих идей, а дальше уже (не)выполнять их более "глубокую" реализацию. > До сих пор меня не покидало тайное ощущения неправильности моих действий. > Ведь Все вокруг борются со сложностью методами ООП и _говорят_, > что получается очень эффективно и удобно. > А я не ощущаю особого удобства от необходимости сводить все к иерархии, > и ООП применяю только для построения интерпретирующей системы. > А остальные проблемы пытаюсь свалить на неязыковые средства. Подобные ощущения посещают многих людей, обладающих "стихийно-системным" типом мышления. Их, естественно, удивляют очевидные несообразности ООП, СТЕРЖНЕВОЙ идеей которого является ИЕРАРХИЯ ВАРИАНТОВ. К иерархиям вариантов весьма часто НЕВОЗМОЖНО свести многие явления реальной жизни, имеющие характер "сродства, соседства, взаимовлияния". Так в языке С++ появляются "дружествен- ные классы", идея которых ПРОТИВОРЕЧИТ основной идее ООП. Совсем не зря в ранних реализациях Borland Pascal (<= v.6.0) не было "дружественных классов", поскольку эта идея разрушает концептуальное единство ООП-системы. Совсем не зря в MS VB вводится объектное программирование, весьма отличающееся от программирования под C++. Совсем не зря Microsoft рассуждает о том, что Windows 3.1/3.11 -- объектная система, хотя и реализованная НЕОБЪЕКТНЫМИ срествами (вроде pure C). Потому что РЕАЛЬНО никакого ООП как ЕДИНОЙ методологии НЕ СУЩЕСТВУЕТ. Есть группа разнородных, противоречивых, малосвязанных подходов к разделению сложности, основной порок которых состоит в том, что ни в одном из вариантов эти методы не являются АВТОМАТИЗМАМИ! ЧАСТИЧНОЕ осознание этой проблемы породило язык Java, который, к сожалению, как средство управления сложностью (вместе с идеологией WEB) есть ПРЯМОЙ ШАГ НАЗАД, к модульному (точнее, КОМПОНЕНТНОМУ) программированию. Тогда как, IMHO, представляется, что C++ и ООП нужно критиковать не за ИЗБЫТОК "объектности" и "структурности", а за НЕДОСТАТОК и НЕПОСЛЕДОВАТЕЛЬНОСТЬ реализации свойств разделения и управления сложностью! > Только вот со структурами у меня не все в порядке. > Вот здесь у меня дырка. ;( > Каждый раз их приходится проектировать заново, > ну и еще ... эхехехе - Фуф ... новые средства автоматизации их подготовки. > Потому-что в предидушем варианте обязательно вылезла какая-нибудь > непредусмотренная гадость, которую приходилось лечить > специальным кодированием, изменением формата структур и т.п. ... Так будет происходить ВСЕГДА! Родовое свойство человеческого понимания -- невозможность охватить все сразу, ИТЕРАЦИОННЫЙ характер приближения к истине. Поэтому и требуется от системы программирования ПОДДЕРЖКА НЕИЗБЕЖНОЙ ЭВОЛЮЦИИ ПРЕДСТАВЛЕНИЙ. Существующие системы просто игнорируют этот важнейший момент, даже введенные в Unix понятия о поколениях текстов (программ) НЕ ИСПОЛЬЗУЮТСЯ под MSDOS/Windows СОВЕРШЕННО! Наряду с автоматизмом управления сложностью важнейшим требованием к системе программирования должно быть требование поддержки эволюции, должен существовать РЕГУЛЯРНЫЙ (НЕавтоматический) механизм перехода от одной системы понятий к другой. В моей системе этой цели служит парадигма "теории", и переходы от более простых (очевидных) теорий к более сложным, изощренным, на базе общего тезауруса (включающего в качестве своих слов как "атомы действия" (подпрограммы), так и "атомы данных" (структуры БД)) являются очевидным эволюционным механизмом, позволяющим (вместе с системой history film) затем проследить эволюцию теорий в рамках модели для "введения" в контекст любого человека, не являющегося исходно разработчиком модели. Так удается выполнить РЕАЛЬНУЮ передачу ИДЕОЛОГИИ и РЕАЛИЗАЦИИ системы другим людям так, чтобы они ДЕЙСТВИТЕЛЬНО ПРОДОЛЖАЛИ разработку, а не пороли отсебятину, повторяя "на своем горбу" уже пройденную изначально "историю мысли". > Хотя нет! Был один вариант, с которым не было проблем. > Но тогда это был не только мой проект. > Тогда мы моделировали замкнутое пространство коммутации обьектов. > Это был вариант гипер-куба. :) Многомерная матрица !? > Надо-же! > Вот действительно было приятно иметь дело с красивой структурой. Гиперкубические структуры являются вариантом многомерных логических структур, реализующих идею "все связано со всем". У меня используются их близкие подобия, но не обязательно КУБИЧЕСКИЕ (требование одинакового числа N для всех граней логического пространства является реально невы- полнимым, либо ведет к большой избыточности, если N принимается по максимальному измерению). Да и НЕ НУЖНО мне об этом особо думать, поскольку ЛОГИЧЕСКОЕ ГИПЕРПРОСТРАНСТВО возникает ЕСТЕСТВЕННО, САМО ПО СЕБЕ, как только я полностью определил логические значения всех параметров модели. Так же ЕСТЕСТВЕННО оно АВТОМАТИЧЕСКИ делится ТР-матрицами на ВАРИАНТЫ. Меня просто "не колышет" реальная размерность гиперпространства; какое получилось -- с тем и работаешь. Благо редактор вариантов автомати- чески их листает, предлагая заполнять еще не описанные случаи. > Вы используете многомерные матрицы только на этапе моделирования, > или у Вас есть опыт предложения коммерческих систем на базе "машины теорий". Несколько раз я использовал варианты "машины теорий" для логического прототипирования бизнес-задач. При этом (естественно!) заказчик не слышал даже таких слов, он просто получал обычную программу на языках C/C++ или VB, ЛОГИЧЕСКИЙ КАРКАС которой был сгенерирован из соответствующей модели. К сожалению, затем, в процессе правок, этот каркас "размывался", "оплывал", превращаясь постепенно в обычную программную систему. Но изначальный мощный логический "пинок" радикально продвигал проект из "ранней" стадии разработки сразу в "среднюю" или "продвинутую". Существующая у меня версия моих инстру- ментов сегодня не поддерживает ПОЛНЫЙ ЦИКЛ работ, поскольку никогда для этого не предназначалась. Это -- мои "подопытные кролики", на которых пробовались разные варианты технологических идей для отбора окончательных решений. Поэтому, как только слегка разбогатею ;)), я сразу сяду за реализацию ПРОМЫШЛЕННОЙ версии системы, которой сможет пользоваться любой человек, а не только я сам как ее автор. > Многомерная матрица достаточно тяжелая структура. > Она заведомо содержит некоторое избыточное количество > невостребованных связей. > Насколько я понял в момент фиксации определенного состояния модели > и происходит избавление от них, ... ну практически строится цифровой автомат, > текущего состояния за счет синтаксиса Forth. Не за счет синтаксиса Forth, а за счет интерпретации/компиляции ТР из модели. При этом воможна РЕДУКЦИЯ, но не невостребованных связей, а ПОВТОРЕНИЙ, когда несколько ситуаций "сливаются" в одну по формальному признаку -- реакция на них задается одним и тем же словом тезауруса. Это общий механизм работы с ТР, довольно ясно описанный у Хамби. Что же касается "тяжести" многомерной матрицы, то не так страшен черт... Если, конечно, делать работу с таким объектом не руками, а с помощью компьютера, используя набор специализированных редакторов: редактор вариантов, редактор моделей, редактор теорий, редактор процессов, редактор параметров... В большинстве случаев можно получать АУТЕНТИЧНЫЕ ПЛОСКИЕ проекции матрицы связей, и тогда работать с таким объектом не сложнее, чем со СТОПКОЙ электронных таблиц в Excel. > Не побовали ли Вы, эту проблему решать не интерпретацией значаших > дуг и/или узлов в исходный текст ЯВУ, а преобразованием их в более легкие > структуры, интерпретируемые одним и тем-же ядром? Мне не хочется до завершения ЭКСПЕРИМЕНТОВ с технологией заниматься самому построением специального компилятора или интерпретатора системы, скажем, для РС. Использовать как "объектный" код тексты на языках VB/C++ гораздо удобнее по множеству причин. Например, не нужно самому писать арифметику или интерфейсы к Windows. Хотя я прекрасно понимаю, что модель можно ОЧЕНЬ эффективно скомпилировать сразу в ассемблер или исполняемый код, выиграв и скорость, и размеры. Но сейчас у меня достаточно других, более интересных проблем. Мне хочется оптимизировать не время работы ЦП, а ВРЕМЯ РАБОТЫ ЧЕЛОВЕКА. Что ГОРАЗДО сложнее... > PS. Идеи Ваши достаточно интересны и близки мне. > Вы не будете против, если я кое-что из них попробую? Буду только рад. Изложенная мною отрывочно теория -- это НЕПАХАННАЯ ЦЕЛИНА. Там такие дебри, в которых с легкостью потеряются целые институты. Что бы Вы ни делали, все равно получится что-то свое, сугубо Ваше. Будет другой опыт, тем более ценный, что ВОТ ТАК сегодня программные системы не делают. Попробуйте. А вдруг понравится? > С Уважением > --- > Alexander Drugov. Russia, Berdsk. > E-mail: dan@softex.nsk.su Phone: (38341) 474 45 Всего наилучшего, A.S. From chci!deity!deity.chci.chuvashia.su!L-relcom Tue Feb 25 09:53:12 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Tue, 25 Feb 1997 09:53:11 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA00382; Tue, 25 Feb 1997 09:56:49 +0300 Received: by deity.chci.chuvashia.su id UAA18028; (8.6.12/vak/1dot9) Mon, 24 Feb 1997 20:16:40 +0300 To: subscribers@deity.chci.chuvashia.su From: "Michael V. Tokarev" Newsgroups: relcom.comp.software-eng Subject: [News] Forth (Was Re: Дизайн языков Re: Дизайн систем) Date: Mon, 24 Feb 97 15:23:56 +0300 Distribution: su Organization: Private Domain Message-ID: Reply-To: michael@tokareff.pgu.karelia.su References: X-Return-Path: michael@tokareff.pgu.karelia.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 34 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 1675 Status: RO Hi! > Sedov изобразил следующее: > > Да, конечно можете, Forth всего лишь ЛУЧШЕЕ средство, но не единственное. > Достоинство Forth заключается в том, что синтаксис языка описывается единственным > предложением: программа состоит из слов, разделенных пробелами. Это дескрипция > ПРОИЗВОЛЬНОГО ТЕКСТА. Избавившись от синтаксических наворотов, так свойствен- > ных языкам типа C++, Forth в умелых руках становится ЧИСТЫМ ИНТЕРПРЕТАТОРОМ > СЕМАНТИКИ ЗАДАЧИ. Я достаточно поработал с интерпретатором Форта, реализованным Барановым С.Н. из ЛИИ АН. Он, кстати доктор и большой спец в этих вопросах. Могу сказать только, что Алексей сильно прав. Мало того в СПбГТУ, на кафедре ИУС также писалась в течение почти 10 лет подобная система, называемая КОМФОРТ. Часть подобных средств, насколько мне известно, была использована на спутниках, запускаемых с Байконура. Это говорит само за себя. Но там чисто встроенные применения -- здесь Форт-ориентированные системы, пожалуй, единственно возможные. Ведь стандартное ядро Форта занимает всего несколько десядков килобайт. Любая процедурка, реализованная в нем занимает порядка сотен байт. Такое применение Форта очевидно дает свои преимущества (как интерпретатора). Если реализовать систему автоматической сборки модулей из репозитория, и использовать полученный (мизерный) код на быстрых процессорах, то Юникс, ИМХО, отойдет на второй план несмотря на своих почитателей. Но для распространенного ПО надо еще долго думать, насколько хорош этот интерпретатор. Я с подобными вещами работал более 5 лет и немного представляю себе все плюсы и минусы существующих реализаций. Michael. From chci!deity!deity.chci.chuvashia.su!L-relcom Tue Feb 25 09:53:25 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Tue, 25 Feb 1997 09:53:25 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA01852; Tue, 25 Feb 1997 10:11:36 +0300 Received: by deity.chci.chuvashia.su id JAA25516; (8.6.12/vak/1dot9) Tue, 25 Feb 1997 09:19:21 +0300 To: subscribers@deity.chci.chuvashia.su From: "RS-Bank CIB" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Машина теорий (часть 2) Date: Tue, 25 Feb 97 08:14:33 +0300 Organization: CreditImpex Bank Distribution: su Message-ID: References: Reply-To: bnk@info.cib.msk.su NNTP-Posting-Host: news.gamma.ru Mime-Version: 1.0 X-Return-Path: kiae!infcib!info.cib.msk.su!bnk@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 109 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 5821 Status: RO >From: "Alexey A. Sedov" >Date: Sun, 23 Feb 97 20:53:21 +0300 Алексей, заранее извиняюсь за возможно резкую критику, но тема действительно задевающая за живое. >бесполезные споры. ПОРОЧЕН САМ ПРИНЦИП современных ЯВУ: вместо инструментов >познания, записи, накопления и расширения человеческого опыта в конкретных >предметных областях, ЯВУ представляют собой громоздкие, противоречивые, Не предназначены ЯВУ для таких громких целей как познание и накопление опыта. Для этих целей есть язык математики или, если хотите обычные языки, нотная грамота, палитра художника. Но если рассматривать только рациональное познание, то там где нет математики, нет и познания. Зачем придумывать избыточную сущность? >систему для обеспечения СЛУЧАЙНОГО блуждания программиста в пространстве >состояний решаемой задачи. Все существующие ЯВУ были построены в результате Не нужно ни по чему бродить программисту - ему надо только закодировать матмодель. Грубо говоря, нужна "теория всего сущего". Будет она, да хоть на бэйсике можно будет все закодировать. > ТЕЗИС 4. Процессы и параметры, пространство состояний > ----------------------------------------------------- > > 4.0. Одной из идей, все поставившей на ноги, стало представление о >пространстве состояний решаемой задачи. Вкратце это вот что. В мире нет >ничего "твердого", мир - это ансамбль взаимодействующих динамических процессов, Понятно - та же формула сущего, единая теория поля и т.д. Но основная задача как раз в том и состоит, чтобы отсечь незначительные процессы и сосредоточиться на определяющих, а не вводить в расчет учет местоположения планет на небосводе. >иногда иерархически связанных, но очень часто - НЕТ (вот причина провала ООП). А вот о иерархии природа действительно ничего не знает - это наш инструмент управления сложностью. Считая деформацию конструкции негоже лезть на молекулярный уровень - надо открыть учебник сопромата. > 4.1. Выбирая "квант наблюдения" интересующего нас суперпроцесса (среды), >содержащего все остальные микропроцессы, мы имеем МНОЖЕСТВО характерных >НЕСОВПАДАЮЩИХ периодов стабильности для подпроцессов рассматриваемого >суперпроцесса, при переходе между которыми РАДИКАЛЬНО может меняться не >только модель отдельного микропроцесса, но и модель суперпроцесса, пред- Естественно наши простенькие модели работают в своих пределах. На баллистическом участке нам нужна масса и скорость материальной точки, при входе в атмосферу - аэродинамика изделия, при встрече с целью- энергитические параметры ВВ. >причудливым способом, становясь прямо противоположным текущему. Практически >НЕВОЗМОЖНО иметь ОДНО И ТО ЖЕ описание для каждого подпроцесса на все >интересующее нас время решения задачи. И здесь не поможет никакая иерархия >классов. Требуется для каждого "объекта" иметь БОЛЕЕ ЧЕМ ОДНО ОПИСАНИЕ >и свободно переходить между ними в требуемые моменты исполнения модели. Скорее здесь нужна иерархия обьектов-моделей данного изделия и экспертная система, определяющая какую из этих моделей задействовать в данных условиях. > 4.2. Каждый микропроцесс интересует нас как набор определенных параметров. >Некоторые из них являются внешними для микропроцесса (параметры среды или па- >раметры других, связанных ЛЮБЫМ способом с данным микропроцессов), некоторые - >внутренние (параметры микропроцесса). Связи между ВСЕМИ параметрами микро- >процесса (внешними и внутренними) задаются матрицами связей, описывающими >правила перехода между значениями любого параметра при заданных значениях >всех других связанных параметров. В простейшем (и наиболее общем случае) >матрица связей имеет размерность алгебраического произведения всех значений >всех собственных параметров микропроцесса и внешних связанных параметров. Ага, многомерное пространство, где каждая переменная - орт, и по начальной точке и n-1 координат конечной получаем n-ую. И что здесь нового, зачем нам матрица. Чем плоха система n уравнений? > 5.0. Правила перехода между значениями параметров в матрице связей >процесса ("функции/подпрограммы" в обычном программировании или "методы" в >объектном) ОБЯЗАТЕЛЬНО должны иметь ДВА представления: логическое - >оперирующее "словесными" обозначениями значений параметра типа {горячий, >теплый, холодный} и числовое - оперирующее соответствующими числовыми значениями >(для температуры это могут быть соответственно величины {3E+5C, 42.3C, -70C}). Ну зачем нам логика - она насквозь субьективна (горячо,холодно). Она имеет смысл при введении субьекта в модель - зачем он нам? > 5.1. МНОГОМЕРНОСТЬ значений таким образом введенных "переменных" >(параметров процессов) позволяет выполнять ВСЮ постановку задачи в терминах >СЕМАНТИКИ этой задачи, создавая тезаурус (словарь) предметной области, >и оставляя детализацию "вычислительного" аспекта постановки либо на "потом", >либо на работу профессионального математика, либо выполняя эту работу >немедленно, если человек, создающий модель, владеет предметно-ориентированной >Каждый процесс интересен нам в конкретном случае проявлением ряда своих пара- >метров. Каждый параметр характеризуется дискретным перечислимым набором зна- >чений (например, {мир, война}, {горячий, теплый, холодный}, {киты, тюлени, >олени} и т.п.). Каждому значению можно сопоставить числовое множество, иногда Представляю себе подобную постановку задачи: "Определить (качественно) температуру большинства оленей в условиях военных действий". После чего профессиональный математик начинает вычислять вероятность поражения оленя в условиях плотности огня современных военных действий. Причем для тюленей картина будет качественно иной :) Извини - не удержался - такая подставка. -- Stas Selitsky From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Mar 03 09:47:51 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 3 Mar 1997 09:47:51 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA10346; Sat, 1 Mar 1997 13:12:05 +0300 Received: by deity.chci.chuvashia.su id FAA05467; (8.6.12/vak/1dot9) Sat, 1 Mar 1997 05:16:27 +0300 To: subscribers@deity.chci.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Машина теорий (ответы) Часть 1. Date: Sat, 01 Mar 97 00:54:53 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 206 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 11793 Status: RO Многоуважаемые оппоненты! Прошу прощения за задержку с ответами -- у меня цейтнот. :-( Но я попытаюсь ответить всем, кто писал отзывы на мои статьи. Правда, получится не сразу. Постараюсь при этом избежать дублирования мыслей. Прошу прощения за объем: я стараюсь писать понятно - в смысле: чтобы быть ОДНОЗНАЧНО понятым. Тем, кто не любит длинных писем, приношу свои извинения. A.S. ------------------------------------------------------------------------- Ответы: Часть 1. ------------------------------------------------------------------------- Alexey Donskoy 24 Feb 1997 wrote to All: > "Alexey A. Sedov" пишет вещи безусловно интересные. > Однако слишком общие. Я рискнул бы всказать свое понимание программирования > как решения прикладных задач (или почему сегодня "Машины теорий" неприменима). > Если кто-то будет сильно не согласен, прошу не наезжать, а объяснить, как Вы > это понимаете. Я тоже рискну ответить. Поскольку не согласен, что писал СЛИШКОМ "общие", вещи -- скорее, ДОСТАТОЧНО общие, чтобы было понятно, откуда "растут ноги". Тем более не согласен, что "сегодня машина теорий неприменима" -- под разными названиями аналогичные системы (несколько более слабые по функциям) и "перекошенные" под CASE-технологии куда больше, чем следует, используются на Западе уже лет 10-ть. Только вот стоят 20-30 тысяч баксов. Например, я слышал ссылки на OBJECT TEAM фирмы CADRE TECHNOLOGIES. И насчет "наездов": вообще-то я стараюсь никому не хамить ПЕРВЫМ. > 1. В силу ограниченности аппаратных ресурсов (как функционально, так и > количественно), одной из основных задач программиста пока является борьба > с аппаратной частью в частности и с концепцией КОМПЬЮТЕРА в более общем смысле. > Лет 20 назад удельный вес этой задачи был 98%, сейчас унификация интерфейса > и появление средств RAD существенно упростили проектирования интерфейса, > СУБД почти избавили от забот о физической работе с файловой системой, > а CASE-средства проектирования избавили Проектировщика вообще от забот о > борьбе с компьютером как таковым, позволяя сосредоточиться на структурах данных > и бизнес-процессах. Так что прогресс все-таки есть. Эта картина заражает меня оптимизмом. Сразу хочется жить и работать. :-)) Но при попытке реализовать желание обнаруживаются небольшие проблемы: 1. Визуальное программирование, бесспорно, самое выдающееся достижение в технологии за последние 10 лет. Рисование интерфейсов действительно упростилось. ПРОЕКТИРОВАНИЕ -- ВОВСЕ НЕТ! Поскольку это все та же ИТЕРАЦИОННАЯ процедура, где проблема не в том, чтобы показать КАКИЕ-ТО данные в нужном формате на экране, а в том, чтобы ПОНЯТЬ, КАКИЕ данные, КАК и КОГДА показывать. 2. Использование СУБД действительно освобождает от работы с файлами (иногда). Но платой за это является необходимость ПРОЕКТИРОВАТЬ БД! Если кто-то скажет, что это ОЧЕНЬ ПРОСТО, или будет утверждать, что ПОИСК архитектуры БД -- НЕ итерационная процедура (даже с использование соотв. CASE) -- я первым брошу в него камень. Работа с СУБД НЕ УПРО- ЩАЕТ, а УСЛОЖНЯЕТ разработку системы. Это просто не хочется обсуждать. Погрузить модель данных в СУБД -- просто! Но сначала Вы должны ее ПОЛУЧИТЬ! Поэтому проблема ПРОЕКТИРОВАНИЯ здесь осталась и УСУГУБИЛАСЬ. 3. До сих пор НЕ СУЩЕСТВУЕТ промышленных систем, позволяющих полностью выполнить бизнес-разработку без кодирования, тестирования, отладки. Современный CASE создает вовсе не программу, а FRAMEWORK соответствующего вида, который еще надо НАПОЛНЯТЬ, ТЕСТИРОВАТЬ и ОТЛАЖИВАТЬ РУКАМИ! Т.е., по-прежнему крутить шарманку компилятор-компоновщик-отладчик. При этом ПРЕДПОЛАГАЕТСЯ вполне традиционнная разработка БОЛЬШОЙ части системы, вне framework, традиционными методами, "как всегда". Кто хором догадается, что получится в результате? Правильно! ОНО, родное! Если Вы изменили постановку, то все (или почти все), что Вы делали до этого, запросто мажет помахать Вам ручкой -- будете делать заново. :( Не стоит говорить, что CASE ОЧЕНЬ УЗКО специализирован, и CASE для строительства линий фасовки пшеничной муки может неожиданно сломаться на гречневой. А какие там ЦЕНЫ!!! Это надо просто рассказывать шепотом... Поэтому "прогресс" если и есть, носит "случайный", "непреднамеренный" характер. Его получили не в результате осмысленных усилий, а -- как в случае визуального программирования, -- чуть ли не в качестве "побоч- ного следствия", под шум-гром торжества совсем других, ООП-методик (вполне провалившихся по существу). Лично меня интересует не сам по себе т.н. "прогресс", а ситуация, когда я смогу работать быстрее и лучше в 10, 100, 1000 раз, чем сейчас. И пусть это назовут даже "регрессом". Я согласен ТАК регрессировать. Жаль, но вот как раз этого НЕ ПОЛУЧАЕТСЯ! > Другой вопрос в том, что где-то вырос удельный вес обучения (освоения > методик и новых средств проектирования), а недостаток финансовых ресурсов > заставляет либо воровать, либо "рисовать диаграммки руками". Чтобы обучиться современному проектированию, ничего воровать не нужно. Нужно заплатить $40-$60 и купить книжку с CD-ROM впридачу, где будут РАЗЖЕВАНЫ на сотнях страниц и SDT, и IDEF*, и CASE-методы. Да вот беда-то какая: НЕ НАЙДЕТЕ Вы там серьезных ответов на самые кондовые (они же и посконные) вопросы постылого программерского бытия: 1. Как писать программы БЕЗ хотя бы логических ошибок? 2. Как делать это ОЧЕНЬ быстро? 3. Как получать ЭКСТРЕМАЛЬНЫЕ по оптимальности решения? 4. Можно ли писать программы БЕЗ программирования? 5. И т.п., и т.д. И будет это совсем не случайно. Как можно отвечать на такие вопросы, НЕ ИМЕЯ ТЕОРИИ ПОСТРОЕНИЯ ПРОГРАММНЫХ СИСТЕМ? Есть хорошие работы по частным аспектам, масса инсайтов, догадок, гипотез, а теории - НЕТ. Теория ЕСТЬ, когда можно подставить в нее параметры своей задачи, слегка напрячь мозги и получить РУТИННЫЙ результат. Теории нет, когда программы пишут потом и кровью (если учесть, сколько лет жизни КРАДЕТ фонящая-излучающая аппаратура компьютера у своего хозяина), срывая все мыслимые и немыслимые сроки, вылезая из самых оптимистичных смет, и сплошь и рядом НЕ МОГУТ довести работу до конца. Когда Microsoft (!) СРЫВАЕТ выпуск Вынь'95 НА ГОД! И выпускает полуработающего урода! Что еще нужно, чтобы Вы поверили -- НЕТ теории?!! О чем же поведает Вам тогда "процесс обучения"? Когда безнадежному больному нужно что-то сказать, его ОБОДРЯЮТ. Ему рассказывают о чудесном исцелении полупокойного Х., или о том, как долго жил на искусственной почке счастливец Y. Больной просветляется, дышит надеждой, встает на указанный путь... Вскоре родственники обсуждают, почему он умер с улыбкой на устах. Вот и книжки про разные чудеса (с CD-ROMами) построены по той же примерно методе. "Идеологи программирования" уже лет 30 ТОРГУЮТ НАДЕЖДАМИ. За что Вы платите большие деньги, покупая очередную версию любимой системы? За надежду на лучшее. За что Вы заплатите ОЧЕНЬ большие деньги, если решите КУПИТЬ CASE? За ОЧЕНЬ БОЛЬШУЮ надежду. А теперь вспомните, когда последний раз СБЫЛИСЬ Ваши надежды? И ничего не крадите... Оно того не стоит. :-(( > 2. Подавляющее большинство программ, за которые сегодня платят деньги, > есть не просто "решение бухгалтерских задач, которые можно описать той > или иной методикой", а есть > а) ПОСТОЯННО ДЕЙСТВУЮЩИЕ, > б) СПЕЦИАЛИЗИРОВАННЫЕ > в) ПРОГРАММЫ, ХРАНЯЩИЕ И ОБРАБАТЫВАЮЩИЕ ДАННЫЕ > г) НА ОГРАНИЧЕННЫХ РЕСУРСАХ КОМПЬЮТЕРА > итак по пунктам, > а) никак не противоречит предлагаемой модели реальности и переходу по ТР > из одного состояния в другое. Ok! > б) никто не требует от холодильника функций кофемолки и не забивает рубанком > гвозди (хотя можно в принципе). Т.е. и инструмент, и соответствующая технология > должны быть специализированными. Мне кажется, применение ТР удобно в одних > случаях (например, моделирование сложного устройства или экономического > процесса) и совершенно неудобно в других (см, например, ниже). Кроме того, если > я правильно понимаю, ТР все-таки предполагают полный предварительный анализ > задачи, что обычно невозможно, т.к. постановка задачи имеет тенденцию меняться > в процессе эксплуатации программы под действием внешних условий > (законодательство, изменение потребностей заказчика и понимания подрядчика) 1. Целочисленный (или интервальный) анализ есть универсальный формализм, пригодный для описания работы и холодильников, и кофемолок. БЕЗ ТР (или аналогичного другого логического механизма) Вы будете делать то же самое, но ВСЛЕПУЮ, НАОЩУПЬ. Я не понимаю, почему применение логических моделей пространства состояний можно сравнивать с забиванием гвоздей рубанком. Эта аналогия здесь надуманная, и проблемы совсем не в том, что ТР -- НЕ "универсальный" механизм. Как раз вполне "универсальный", эквивалентный, например, таким механизмам как конечные автоматы, формальные грамматики, графы, алгебры и др. 2. В математике давно известно "проклятие размерности", которое подстерегает дискретные системы при попытках ПРЯМОГО КОМБИНАТОРНОГО представления их пространства состояний. Что СОВЕРШЕННО НЕ МЕШАЕТ работать с такими системами на практике, получая сплошь и рядом ОТЛИЧНЫЕ результаты. Например, проектирование компьютеров без подобных моделей было бы просто невозможно. Дело в том, что КОМБИНАТОРНО ПОЛНОЕ пространство состояний на практике можно: а) не получать полностью, б) не хранить полностью, в) подвергнуть делению на части (декомпозиция); г) уменьшить его размерность исключением ненужного (редукция). Методы декомпозиции/редукции могут оказаться настолько эффективными, что понижают размеры задачи на ДЕСЯТКИ порядков! Умело введенная дискретизация модели приводит к весьма скромным размерностям для ПОДАВЛЯЮЩЕГО числа современных задач: от проектирования компиляторов (см. системы типа LEX/YACC) до создания компьютрных игр (типа шашек, которые ПОЛНОСТЬЮ разрешимы на сегодняшних машинах). При решении методами РЕДУКЦИИ возникает нехватка единственного ресурса -- ЧЕЛОВЕЧЕСКОГО УМА, тогда как компьютерных ресурсов наблюдается ИЗБЫТОК. В МЕТОДАХ ПОДДЕРЖКИ ДЕКОМПОЗИЦИИ/РЕДУКЦИИ и заключен ответ на вызов "проклятия размерности". Эти методы позволяют В КАЖДОМ КОНКРЕТНОМ СЛУЧАЕ получать очень хорошие решения на СОВРЕМЕННЫХ машинах, хотя "теоретически" такие задачи решаться не должны. Это говорит только о том, что за "теорию" принимается нечто совсем иное -- догматические предубеждения... 3. В одном из моих писем я уже писал, что дискретные модели ВОВСЕ НЕ предполагают якобы "изначально полного" задания. Отнюдь! Моя парадигма "теории" как логически непротиворечивого, но частного взгляда на задачу полностью решает эти проблемы. Разрешите в рамках логической модели МНОГО РАЗНЫХ теорий на ОБЩЕМ тезаурусе -- и Вы получите ЭВОЛЮЦИЮ усложняющихся теорий, охватывающих все большее число факторов или изменяющих их перечень и "емкость" в процессе постижения проблемы и соотвествующих расширений модели. Отличие от существующих систем здесь вот какое: Вы храните ВСЕ варианты представлений о задаче, начиная с исходного; Вы можете ВЕРНУТЬСЯ к любому из предыдущих представлений, при этом либо вся "супермодель" синхронно "шагнет назад", либо возникнут ДВА альтернативных решения в рамках модели -- новое и старое. И ВСЕ! Такой подход позволяет не то что эволюцию, он позволяет ПРОТИВОРЕЧИВЫЕ, ВЗАИМОИСКЛЮЧАЮЩИЕ теории хранить вместе. Как? Ключевое слово ответа: полиморфизм. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Mar 03 09:48:14 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 3 Mar 1997 09:48:14 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA12578; Mon, 3 Mar 1997 00:09:39 +0300 Received: by deity.chci.chuvashia.su id XAA00595; (8.6.12/vak/1dot9) Sun, 2 Mar 1997 23:16:09 +0300 To: subscribers@deity.chci.chuvashia.su Newsgroups: relcom.comp.software-eng From: David Tolpin Message-ID: <5f9ibj$bru@mida.fe.msk.ru> References: <3314080b@p30.f146.n5020.z2.fidonet.org> Distribution: fido7 Subject: [News] Re: Дизайн операционных систем Date: Sat, 01 Mar 97 18:35:15 +0300 X-Gate: U1 2.11c [OS/2,C++ Set] Organization: Peritus AI Lab, Moscow, Russia (Gid:fidonet.org) X-FTN-MsgId: mida.fe.msk.ru ead4886f X-FTN-Reply: 2:5020/146.30 3314080b Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 31 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 1254 Status: RO RFC-References: <3298441391@f128.n50.z2.fidonet.ftn> <856950795@p30.f146.n5020.z2.ftn> From: dvd@mida.fe.msk.ru (David Tolpin) Pavel Senatorov (Pavel.Senatorov@p30.f146.n5020.z2.fidonet.org) wrote: > Привет, > Пятница Февpаль 21 1997, письмо michael@tokareff.pgu.karelia.su к All: > ms> Уважаемый Кика, а не лучше ли сравнить время, за которое был > ms> изобретен бумеранг (сотни лет, как минимум, я думаю) и время, за > ms> которое его можно бы было спроектировать используя современные > ms> научные методы в аэродинамике? > Время разработки аэродинамики прошу учесть в подсчете. Получится пара тысяч лет > против пары тысяч лет. У современной аэродинамики _HЕТ_ методов изобретения бумеранга. Эта наука может объяснить, как он летает, но в отсутствие идеи бумеранга аэродинамика бесполезна. Я даже готов представить, что эту проблему можно попробовать решать на каком-нибудь крэе как безумно сложную вариационную задачу, но все равно эргономические ограничения учесть почти невозможно. К сожалению, ни одна современная наука не позволяет изобретать новое. Изобретение нового по-прежнему производится ненаучными методами. Давид --- ifmail v.2.7 * Origin: Peritus AI Lab, Moscow, Russia (2:5020/73@fidonet) From chci!deity!deity.chci.chuvashia.su!L-relcom Wed Mar 05 11:20:10 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Wed, 5 Mar 1997 11:20:10 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA24074; Wed, 5 Mar 1997 11:19:37 +0300 Received: by deity.chci.chuvashia.su id DAA08769; (8.6.12/vak/1dot9) Wed, 5 Mar 1997 03:26:35 +0300 To: subscribers@deity.chci.chuvashia.su Newsgroups: relcom.comp.software-eng From: Vyacheslav Baryshnikov Message-ID: <331c1773@p0.f4.n5032.z2.fidonet.org> References: Subject: [News] Forth Date: Tue, 04 Mar 97 12:37:06 +0300 X-Gate: U1 2.11c [OS/2,C++ Set] Organization: Walrus BBS, Novgorod The Great, Russia +7(816)227-2586 (Gid:fidonet.org) X-FTN-To: michael@tokareff.pgu.karelia.su X-FTN-MsgId: 2:5032/4 331c1773 X-FTN-Reply: 2:50/128.0@fidonet C510BBDA Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 28 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 1356 Status: RO Hello michael@tokareff.pgu.karelia.su! Replying to a message of michael@tokareff.pgu.karelia.su to All: m> Если есть лишние деньги и их много, тогда (я боюсь), Форт -- не лyчший m> выбор. И не из-за своих минyсов, а из-за того, что надо бы изобрести m> что посвежее. Hасчет выбоpа может это и так. Hо не из-за своих минусов и _не_ из-за того, что надо изобpести что то посвежее. Почему тогда Фоpтpан настолько живуч - он же тоже не очень "свеж"? m> К сожалению, развитие природы (и техники) происходит революционно (в m> слyчае с природой -- взрыв -- это сотни лет). Поэтомy, как кто-то yже m> высказывался -- надо отбросить все наносное и изобрести новый m> инстрyмент. Hичего себе "взpыв" - на сотни лет. И все бы так пpосто - отбpосить и изобpести. А Фоpт чем не изобpетение - отбpошено все наносное и изобpетен новый инстpумент. Только вот отсутствие наносного называют в нем "минусами". И благополучно все это наносное возвpащают обpатно. После этого он становится тем, чем его многие и видят. Пугает он сильно как pаз своей идеологией. Или отсутствием таковой. Слишком много свободы. А для pаботы в гpуппе это хуже чего не бывает. Вот одиночки в основном его и используют. Best wishes, Vyacheslav --- FleetStreet 1.18+ * Origin: Walrus BBS, Novgorod The Great, Russia +7(816)227-2586 (2:5032/4) From chci!deity!deity.chci.chuvashia.su!L-relcom Wed Mar 05 11:20:10 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Wed, 5 Mar 1997 11:20:10 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA24071; Wed, 5 Mar 1997 11:19:36 +0300 Received: by deity.chci.chuvashia.su id DAA08763; (8.6.12/vak/1dot9) Wed, 5 Mar 1997 03:26:34 +0300 To: subscribers@deity.chci.chuvashia.su Newsgroups: relcom.comp.software-eng From: Vyacheslav Baryshnikov Message-ID: <331c179d@p0.f4.n5032.z2.fidonet.org> References: Subject: [News] Машина теорий (часть 2) Date: Tue, 04 Mar 97 12:37:48 +0300 X-Gate: U1 2.11c [OS/2,C++ Set] Organization: Walrus BBS, Novgorod The Great, Russia +7(816)227-2586 (Gid:fidonet.org) X-FTN-To: bnk@info.cib.msk.su X-FTN-MsgId: 2:5032/4 331c179d X-FTN-Reply: 2:50/128.0@fidonet C5341A2D Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 50 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 2469 Status: RO Hello bnk@info.cib.msk.su! Replying to a message of bnk@info.cib.msk.su to All: >> бесполезные споры. ПОРОЧЕH САМ ПРИHЦИП современных ЯВУ: вместо >> инстрyментов познания, записи, накопления и расширения человеческого >> опыта в конкретных предметных областях, ЯВУ представляют собой b> Hе предназначены ЯВУ для таких громких целей как познание и накопление b> опыта. Для этих целей есть язык математики или, если хотите обычные А как тогда насчет библиотек - это же и есть накопление опыта, только на самом пpимитивном уpовне и без возможности использовать этот опыт _человеку_, а не машине. Hу а без познания pазвитие невозможно. И что же тогда получается с ЯВУ? Пpавильно. То что мы и имеем. b> языки, нотная грамота, палитра хyдожника. Hо если рассматривать только b> рациональное познание, то там где нет математики, нет и познания. b> Зачем придyмывать избыточнyю сyщность? Hу pусский-то, конечно, совсем не избыточная сущность. ;-) Действительно, зачем пpидумывать - есть уже. Я ни в коей меpе не пpизываю использовать его для пpогpаммиpования - это как pаз плохо. Hо на каком языке фоpмулиpовались математические задачи века так 2 назад? Математическая запись всего-то ;) упpощение того, что можно описать словами. Как geek code или смайлики :) И если эти дpугие "языки" (математическая запись, нотная гpамота, палитpа художника) как pаз и есть то, что используется для отобpажения pеального миpа, его познания и накопления опыта, то зачем нам то, пеpед чем мы сейчас сидим? Компьютеpы ведь ими не владеют! Далеко ли ушла в pеальных pаботах технология обpаботки хотя бы такой избыточной вещи, как обычный текст? Поиск и замена. Все. Пpо остальное я уже не говоpю. b> Hе нyжно ни по чемy бродить программистy - емy надо только закодировать b> матмодель. А матмодель это ли не закодиpованное? b> Грyбо говоря, нyжна "теория всего сyщего". Бyдет она, да b> хоть на бэйсике можно бyдет все закодировать. Так и поле можно вспахать спицей, но никто так не делает. b> Hо основная задача как раз в том и состоит, чтобы отсечь незначительные b> процессы и сосредоточиться на определяющих, а не вводить в расчет yчет b> местоположения планет на небосводе. А если это все же потpебовалось - то ЯВУ пpедоставит вам отличный шанс "начать жить сначала" ;-) Best wishes, Vyacheslav --- FleetStreet 1.18+ * Origin: Walrus BBS, Novgorod The Great, Russia +7(816)227-2586 (2:5032/4) From chci!deity!deity.chci.chuvashia.su!L-relcom Thu Mar 06 15:45:55 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Thu, 6 Mar 1997 15:45:55 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA29892; Wed, 5 Mar 1997 20:19:25 +0300 Received: by deity.chci.chuvashia.su id MAA13611; (8.6.12/vak/1dot9) Wed, 5 Mar 1997 12:28:40 +0300 To: subscribers@deity.chci.chuvashia.su From: "RS-Bank CIB" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Машина теорий (часть 2) Date: Wed, 05 Mar 97 11:24:24 +0300 Organization: CreditImpex Bank Distribution: su Message-ID: References: <331c179d@p0.f4.n5032.z2.fidonet.org> Reply-To: bnk@info.cib.msk.su NNTP-Posting-Host: news.gamma.ru Mime-Version: 1.0 X-Return-Path: kiae!infcib!info.cib.msk.su!bnk@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 52 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 2841 Status: RO Hello Vyachesllav ! In <331c179d@p0.f4.n5032.z2.fidonet.org> Vyacheslav Baryshnikov (Vyacheslav_Baryshnikov@p0.f4.n5032.z2.fidonet.org) wrote: > b> Hе предназначены ЯВУ для таких громких целей как познание и накопление > b> опыта. Для этих целей есть язык математики или, если хотите обычные >А как тогда насчет библиотек - это же и есть накопление опыта, только на самом >пpимитивном уpовне и без возможности использовать этот опыт _человеку_, а не Если то, что мы называем опытом недоступно человеку - это не опыт. Опыт - свойство субьекта. Не может быть опыта у булыжника, хотя за миллион лет своего существования он многому был свидетелем. Библиотеки не предназначены для передачи знания, а только для использования в течении ограниченного времени (в связи с бурным развитием компьютерной индустрии - _очень_ ограниченного времени). У кого-то это может вызывать скорбь. Я сам видел эти кладбища программ на ЕСах и СМах. Но идеи, модели, по которым это все кодировалось никуда не делись. Когда мы выбрасываем старое кресло не помойку - мы не переживаем по поводу безвременной кончины технологии изготовления таких удобных кресел. Почему мы должны проливать слезы над выброшенным кодом? Другое дело, когда то, что прекрасно было решено 20 лет назад сейчас перекодируется заново другими людьми криво-косо. Но это беда не кодирования, а преемственности знания. Просто сегодняшние разработчики мало читали книжек. > b> языки, нотная грамота, палитра хyдожника. Hо если рассматривать только > b> рациональное познание, то там где нет математики, нет и познания. > b> Зачем придyмывать избыточнyю сyщность? >Hу pусский-то, конечно, совсем не избыточная сущность. ;-) Действительно, зачем >пpидумывать - есть уже. Я ни в коей меpе не пpизываю использовать его для >пpогpаммиpования - это как pаз плохо. Hо на каком языке фоpмулиpовались >математические задачи века так 2 назад? Математическая запись всего-то ;) >упpощение того, что можно описать словами. Как geek code или смайлики :) > >И если эти дpугие "языки" (математическая запись, нотная гpамота, палитpа >художника) как pаз и есть то, что используется для отобpажения pеального миpа, >его познания и накопления опыта, то зачем нам то, пеpед чем мы сейчас сидим? >Компьютеpы ведь ими не владеют! Далеко ли ушла в pеальных pаботах технология Вот, вот. Нет нужды закладывать в код понимание задачи - компьютер его не поймет, а человеку удобнее прочитать книгу на нормальном (русском, английском, мумба-юмбском) языке. Никто не требует с каждым холодильником или стиральной машиной выпускать тома технологии их производства и физики их функционирования, да еще так интегрированных в эти изделия, что добавление страниц о какой-нибудь пузырьковой стирке добавило бы и физическую реализацию описанного процесса. -- Stas Selitsky From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Mar 03 09:47:52 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 3 Mar 1997 09:47:52 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA10349; Sat, 1 Mar 1997 13:12:05 +0300 Received: by deity.chci.chuvashia.su id FAA05472; (8.6.12/vak/1dot9) Sat, 1 Mar 1997 05:16:28 +0300 To: subscribers@deity.chci.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Машина теорий (Ответы -- Часть 2) Date: Sat, 01 Mar 97 00:54:59 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 272 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 15843 Status: RO ------------------------------------------------------------------------- Ответы: Часть 2. ------------------------------------------------------------------------- Alexey Donskoy 24 Feb 1997 wrote to All: > в) очень хотел бы посмотреть пример описания задачи того же бухучета > в предлагаемой методике. Как ТР учитывают вопросы оптимального хранения данных, > например (или опять все решается в общем, а основные частности остаются > неграм-кодировщикам)? Я тоже хотел бы посмотреть пример ТАКОГО бухучета, поскольку сам эту задачу не моделировал. Я строил модель банковской деятельности, там от бухучета только проводки остались. Ну, это ВААЩЕ ТРИВИАЛЬНО! Делать нечего! Только здесь писать ну-у-у ОЧЕНЬ ДОЛГО. :-)) Кстати, "вопросы оптимального хранения данных" -- забота ВОВСЕ НЕ ТР, а используемой СУБД. И негров тут тоже не надо. Строится ОБЩАЯ модель, затем часть ее (а чаще - она вся) превращается в БД: происходит компиляция процессов используемой теории в ПАРНЫЕ таблицы базы. При этом имена параметров становятся именами доменов таблицы. Поскольку процесс есть АБСТРАКТНЫЙ ТИП ДАННЫХ (в смысле С++), а все параметры его имеют "логико-арифметический" дуализм, то столь же автоматически выявляются и типы соответствующих полей базы для хранения значений. А затем любая запись таблиц БД воспринимается как РЕАЛИЗАЦИЯ соответствующего процесса. Действия с нею происходят по задаваемым ТР алгоритмам. Поэтому с БД тут как раз меньше всего проблем. Разве что нормализацию БД иногда НЕЛЬЗЯ выполнять без риска развалить модель. Но если хочется непременно 3-ю нормальную форму, то процедура нормали- зации может быть использована для большей "ортогонализации" процессов модели, БОЛЕЕ ТОГО, данные БД можно использовать для автоматического ЗАПОЛНЕНИЯ логически соответствующих ТР! Но это -- совсем другая песня: как АЛГОРИТМ ТР восстанавливается по данным... АВТОМАТИЧЕСКИ! :-)) Например, по БД шахматных партий... ;-)) > г) плавно перерастает в ОСНОВНОЙ ВЫВОД: > > > Программирование еще долго будет оставаться по сути борьбой за выживание > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > как а) во внешней, так и б) во внутренней среде (на ограниченных ресурсах > компьютера). Не вижу НИКАКИХ ОСНОВАНИЙ для этого ошеломляющего вывода 8-(). Выше я старался показать, что разговоры об ограничениях использования методов логических моделей НЕУБЕДИТЕЛЬНЫ. Причины, по которым Вы пришли к столь удивительному выводу для меня темны и загадочны. Если Вас не устраивает шесть порядков прироста производительности hardware за 30 лет, то, боюсь, дело не в недостатках существующего hardware, а в свойствах лично Вашей ТОЧКИ ЗРЕНИЯ. Для сравнения -- автомобили и самолеты за это время не стали ездить и летать быстрее. Но давайте с этим разберемся чуть ниже. > > а) изменение внешней среды превращают программирование в основном в делание > ИНТЕРФЕЙСА. Hапример, бухгалтерские задачи по сути весьма просты, но требуют > постоянного сопровождения в части генерации новых отчетов; что может также > привести к существенному изменению постановки задачи. Если для получения нового отчета приходится изменять постановку задачи, значит программную систему делали люди, совершенно не ведавшие, что творят... Можно понять эту ситуацию в единственном случае: когда прототипов нет и все делается заново, с нуля. И первый блин вышел не очень... Но если речь идет о бухучете, то эту область нельзя заподозрить в отсутствии прототипов. Скорее, очень мало удачных МОДЕЛЕЙ экономической деятельности, опираясь на которые только и можно писать программы, работа с которыми действительно сведется к генерации новых справок и рисованию форм. Так о том и речь, что нужно таких МОДЕЛЕЙ делать больше, разных и лучших! Чтобы был выбор. Но таковые модели, будучи ПОГРЕБЕННЫМИ НАВЕК в кодах языка C/C++, Delphi или VB, не представляют собой НИКАКОЙ САМОСТОЯТЕЛЬНОЙ ценности НИ ДЛЯ КОГО, кроме разработчиков данной системы. Они не являются знаниями в собственном смысле, поскольку, как в обсуждавшемся ранее случае с Юниксом, это ЗНАНИЕ НЕОТДЕЛИМО ОТ КОДА! И УМРЕТ ВМЕСТЕ С НИМ! Если посмотреть назад, на программные системы (Algol-60, PL/1, COBOL, ...), куда закладывались знания 20-30 лет назад, мы увидим ужасную картину КЛАДБИЩА ИДЕЙ! Многие из этих идей, умерших или умирающих сейчас вместе с реализующим их кодом, могли бы составить сильнейшую конкуренцию потугам вчерашних студентов на свежую мысль в экономике, математике, схемотехнике, истории или филологии. Но они уйдут навсегда. А современные "колумбы" ВЫНУЖДЕНЫ будут в 1001 раз открывать ЗАЕЗЖЕННУЮ "америку" вчерашних прописных истин. Когда нет механизма передачи знаний между поколениями, то фактически нет и развития. Это тупик. Ничтожные крупицы РЕАЛЬНЫХ ЗНАНИЙ будут переписаны в учебники -- остальное будет утрачено... до времени. До того времени, когда придется заново все это "переоткрывать". Так вот и пишем мы всю жизнь ОДНИ И ТЕ ЖЕ программы, и наши отцы ИХ ЖЕ писали, а наши дети уже готовы начать свой путь познания того, как пишутся редакторы, компи- ляторы, СУБД, измерительные или бухгалтерские системы -- СНОВА С ТОЙ ЖЕ ТОЧКИ! Только наивные люди думают, что книжки вроде Ахо-Ульмана по построению компиляторов действительно способны показать, КАК ДЕЛАТЬ НАСТОЯЩИЙ КОМПИЛЯТОР. Это, как и многое другое, можно узнать только разобравшись в РЕАЛЬНО существующем компиляторе. А много ли найдется людей, способных разобрать ричевский С по текстам в Юниксе? Или хотя бы компилятор Джонсона? Или компилятор DECUS C на ассемблере PDP-11 (блестяще написанный!). А софтвер БЭСМ-6?!!! Я не фанатик разрушения, кричащий о вредоносности языков программирования от желания быть оригинальным и модным. Мне ДЕЙСТВИТЕЛЬНО БОЛЬНО видеть, как ГИБНУТ великие идеи, принципы, подходы, выраженные на языках-однодневках, которым и ISO, и ANSI когда-то прочили бессмертие. Люди! Поймите! Сегодня уже начали умирать Ваши любимые Pascal и Си++! А вместе с ними умрет и все, что Вы успели сделать за такую короткую жизнь... Неужели наша работа действительно выражается ТОЛЬКО в человеко-часах и тонно-рублях? > б) решительно не вижу, что в ближайшее время ситуация улучшится. Прогресс > техники не настолько быстр. В результате большой удельный вес в > программировании имеет и будет иметь БОРЬБА ЗА ЭФФЕКТИВНОСТЬ, которая никак > не решается с помощью ТР, а требует тяжелой черновой работы (кодирования, > в частности). Примеры: Если прочесть небольшую книжку Хамби (меньше 100 страниц), то можно узнать, что ТР ЧУТЬ ЛИ НЕ ЕДИНСТВЕННАЯ ФОРМА ЗАПИСИ АЛГОРИТМОВ, гаранти- рующая их ПРЕДЕЛЬНО-ЭФФЕКТИВНУЮ реализацию! Так что никак нельзя согла- ситься с тем, что "борьба за эффективность" отрицает использование ТР. Дело обстоит прямо обратным образом. :-)) Да, использование ТР не избавляет от "тяжелой черновой работы". Только это вовсе не "ручная" работа кодировщика! Это КАТОРЖНЫЙ труд АНАЛИТИКА! Это работа для головы, а не для задницы. :-)) Всего-то и разница... И я опять не понимаю сетований на "медленный прогресс техники". Эта техника уже имеет дело с релятивистскими ограничениями скорости передачи сигналов! Какого "прогресса" еще следует ожидать? Неужели "суперЭВМ", способной по быстродействию моделировать поведение молекул во Вселенной? Такая "ЭВМ" уже есть -- это САМА Вселенная... Тут у Вас не случайное недопонимание. Тут Вы отрицаете наличие ПРИНЦИПОВ ЗАПРЕТА: законов природы, ЗАПРЕЩАЮЩИХ надеяться на то, например, что компьютерный перебор когда-нибудь станет эффективнее человеческого мышле- ния (НЕПЕРЕБОРНОГО, ИНТЕГРАЛЬНОГО, ИНСАЙТНОГО в принципе). Компьютеры еще могут УБИТЬ ПЕРЕБОРОМ шахматы за счет роста производительности. Но ДУМАТЬ они не смогут НИКОГДА. В такой ситуации я предлагаю заняться строительством инструментов, помо- гающих человеку накапливать, классифицировать и использовать конкретные знания. При этом компьютер ПОМОЖЕТ человеку как инструмент прежде всего классификации, хранения, передачи ЗНАНИЙ, как ЭЛЕКТРОННАЯ АКТИВНАЯ БУМАГА, СПОСОБНАЯ ИСПОЛНЯТЬ ЗАПИСАННЫЙ НА НЕЙ ТЕКСТ! И форма такой записи -- ТР или другая подобная, -- это всего-лишь способ для ЧЕЛОВЕКА передать знания ДРУГОМУ ЧЕЛОВЕКУ в специальной ИСПОЛНЯЕМОЙ форме, поскольку иначе их передать НЕВОЗМОЖНО! По идее, этим следовало заняться еще ПОЗАВЧЕРА, вместо дебатов о преимуществах Cи над Паскалем и скромном обаянии отказа от GOTO. Вы предлагаете, как я понял, ожидать некоего "роста производительности оборудования", дабы с позиций ЧУДОВИЩНЫХ МУСКУЛОВ можно было БЕЗ НАПРЯ- ЖЕНИЯ УМА решать известные проблемы. Боюсь, это несбыточные надежды... > - базы данных успешно решают задачу хранения и доступа к данным, но требуют > жертв в виде определенной парадигмы, терминологии, инструментов и алгоритмов. > Любое повышение универсальности оборачивается ростом на порядок как требований > к аппаратным ресурсам, так и стоимости продукта. Это, мне кажется, общий закон, > а вовсе не недостаток современных ЯВУ или парадигмы процедурного (ОО и т.п.) > программирования; Но я вовсе не предлагал НИЧЕГО "слишком универсального" В ЭТОМ СМЫСЛЕ. Идея ТР появилась десятки лет назад, использовалась чуть ли не на первых компью- терах и никто никогда не жаловался на "аппаратные проблемы" с такими методами. Здесь очевидное недопонимание моих слов (вероятно, я сам тому виной :(, точнее, отрывочность моих заметок сюда). Предлагаемые методы НЕ есть методы СОБСТВЕННО "автоматического" поиска решений в пространстве состояний. Эти методы состоят в: 1) "достаточно полном" (но не обязательно алгебраически полном!) описании пространства состояний задачи; 2) в полуавтоматическом "разложении" этого пространства на "пространство ситуаций", и в заполнении данными тех ситуаций, которые ИЗВЕСТНЫ с различной степенью детальности ЛЮДЯМ сегодня, и понимание которых может измениться завтра; 3) в поддержке альтернативных ответов на одни и те же ситуации, в допущении альтернативных вариантов построения как самого пространства состояний, так и вариантов его декомпозиции на ситуации; 4) в интерпретации/компиляции полученной формальной модели БЕЗ (!) привлечения "машин логического вывода" и т.п. механизмов, действи- тельно требующих серьезных аппаратных ресурсов; 5) в построении подобных моделей максимально простым для их пользователей образом, что достигается на уровне интерфейса моей системы набором специализированных редакторов для ввода/коррекции данных и парадигмами "плоских таблиц" для новичков, использовать которые не более сложно, чем электронные таблицы в Excel. Предлагаемая форма записи позволяет фиксировать ИДЕИ, АЛГОРИТМЫ, ПРЕДСТАВЛЕНИЯ, ТЕОРИИ в их ЕСТЕСТВЕННОЙ форме: в форме вопросов и ответов, где роль вопросов играют структура логического пространства и набор АКТИВНЫХ вариантов. Модель не содержит в себе НИКАКОГО иного "знания", кроме того, что в нее вложили ЛЮДИ. И САМА не пытается ничего "автоматически выводить" (каковое занятие, IMHO, есть нонсенс). Для работы с такими пред- ставлениями в свое время я ПРЕКРАСНО обходился суперЭВМ EC-1840 (БЕЗ ВИНЧЕСТЕРА!), т.е. IBM PC XT... И чего Вам далась эти "аппаратные ресурсы"... Не понимаю. > - управление технологическими процессами (успеет/не успеет, + надежность); > - мультимедиа (яркий пример, задачи аудио/видео хорошо описываются ТР, > каковые таким путем и реализуются. Спецпроцессорами. Что ограничивает > применимость и увеличивает стоимость); С чего бы увеличивалась стоимость спецпроцессоров от того, реализуют они ТР или алгоритмы C++? Их стоимость РЕАЛЬНО зависит от одного фактора -- ТИРАЖА! > - любые нетривиальные задачи, требующие выжать от оборудования больше, > чем оно способно. Игры, например, DOOM всякий и т.п. Или вот, все заказчики, > с которыми приходилось мне иметь дело, в техзадании оговаривают первым пунктом, > что все должно работать на имеющихся 286/386 под ДОС. Посоветуйте же что-нибудь! > Какие уж тут кейсы! ТЕ САМЫЕ! См. чуть выше! Во времена, когда я РЕАЛЬНО делал первые модели, IBM PC AT/286 (не говоря о 386!) были СВЕТЛЫМ ПРЕКРАСНЫМ ЗАВТРА! У них же были ВИНЧЕСТЕРЫ (об этом устройстве я когда-то грезил четыре года!). Вы сами надеваете себе на глаза шоры и не хотите видеть того, что в противном случае уже давно бы заметили: любые нетривиальные задачи требуют для решения ПРЕЖДЕ ВСЕГО глубокого нетривиального их ПОНИМАНИЯ -- в дета- лях, в общей сути, в альтернативах. Я предлагаю Вам обратить внимание на механизм представления этих вариантов и сути. Вы отказываетесь, говоря, что слишком это сложно. А что, УГАДАТЬ ПРОЩЕ? Методом попадания пальцем в небо, в самую середку? Я не в силах В ЭТОМ Вам поверить... Потому как на собственном профессиональном горбу давно постиг разницу между ТОЧНЫМ ЗНАНИЕМ и "романтическим программным квестом" по принципу: а напишу-ка я тут оператор, а добавлю-ка я к нему другой. Люблю, понимаешь ли, писать команды... > Если программист пытается избавиться от извращений - забот об эффективности > (например, путем автоматического кодирования из CASE), результат а) не влезает > в оборудование заказчика; б) работает там неудовлетворительно медленно. Если программист не бузумец-оптимист, он всегда предпочтет ЛОГИЧЕСКОЕ ЗРЕНИЕ ЛОГИЧЕСКОЙ СЛЕПОТЕ ЯВУ и ОО! Если этот программист к тому же почитывает на досуге литературу по КЛАССИЧЕСКИМ методам системного анализа, он не будет думать, что ПОЛНОЕ и ПРАВИЛЬНОЕ решение неоптимально. Неоптимальны как раз хаос и ошибки СЛУЧАЙНОГО КОДИРОВАНИЯ ВСЛЕПУЮ, да еще выполняемого обычно не слишком грамотно. > Вот так, несколько сумбурно, но суть вроде видна. Т.е., нет пока объективной > материальной базы для хороших теоретических методик. Про ТР сразу можно сказать, > что: а) за свою многомерность любая мало-мальски сложная задача потребует > нереальных объемов памяти, б) если компактизировать все эти таблицы, то > накладные расходы на их хранение и обработку потребуют лет компьютерного счета. Для появления теории нужна НЕ фантастическая "материальная база", делающая подобную теорию НЕНУЖНОЙ! ХОРОШО РАБОТАЮЩИЕ МОЗГИ, способные анализировать существующий опыт и делать выводы -- вот что нужно для появления теории. Короче, нужны ТЕОРЕТИКИ! Всего-то делов... ;-))) > Еще один яркий пример - шахматы. Полностью определенная задача, идеально > решается методом ТР, но - слишком долго. А нам (программистам) требуется > заставить компьютер делать ход по часам, и для этого вступать на скользкую > тропу сомнительных эвристик, и долго извращаться для того, чтобы побыстрее. Она НЕ решается методами ТР, а только СТАВИТСЯ! Насколько я знаю, до сих пор не изобретен универсальный алгоритм шахматной игры. А значит существуют всего две возможности: -- тупо перебирать варианты на компьютере (что глупо и неэффективно); -- накапливать в форме ТР БД по сыгранным людьми партиям -- для исполь- зования ЛЮДЬМИ же в качестве АКТИВНОГО справочника, ассистента; об этом пути и идет речь; как я понимаю, именно на нем и были достигнуты последние успехи BigBlue в поединке с Каспаровым (который, как я слышал, быстро раскусил такой принцип работы и начал безостановочно выигрывать просто применяя малоизвестные варианты). P.S. > Еще по тексту (до меня не дошла часть 1) Могу выслать ее Вам на адрес. > С уважением, Алексей Донской Искренне Ваш, A.S. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Mar 03 09:48:14 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 3 Mar 1997 09:48:14 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA12581; Mon, 3 Mar 1997 00:09:40 +0300 Received: by deity.chci.chuvashia.su id XAA00600; (8.6.12/vak/1dot9) Sun, 2 Mar 1997 23:16:09 +0300 To: subscribers@deity.chci.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Машина теорий (ответы) - часть 3 Date: Sun, 02 Mar 97 15:46:59 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 205 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 12825 Status: RO ------------------------------------------------------------------------- Машина теорий. Ответы: Часть 3. ------------------------------------------------------------------------- Stas Selitsky (RS Bank CIB) 25-Feb-1997 написал to All (и мне тоже): > >From: "Alexey A. Sedov" > >Date: Sun, 23 Feb 97 20:53:21 +0300 > >AS>бесполезные споры. ПОРОЧЕН САМ ПРИНЦИП современных ЯВУ: вместо инструментов >>познания, записи, накопления и расширения человеческого опыта в конкретных >>предметных областях, ЯВУ представляют собой громоздкие, противоречивые, > SS> Не предназначены ЯВУ для таких громких целей как познание и накопление опыта. > Для этих целей есть язык математики или, если хотите обычные языки, нотная грамота, > палитра художника. Но если рассматривать только рациональное познание, то > там где нет математики, нет и познания. Зачем придумывать избыточную сущность? 1. Вот и я говорю: не предназначены ЯВУ для обслуживания процесса познания. Можно встречный вопрос? А зачем они тогда ВООБЩЕ нужны? Ответ: для маскировки нашего ВАРВАРСКОГО СПОСОБА использования отличных устройств классификации, ввода и поиска данных, ситуационного планирования, мониторинга и контроля, называемых в просторечии компьютерами. Идеи БЭББИДЖА о сущности компьютеров выдержали проверку временем. ВСЕ ОСТАЛЬНЫЕ ГИПОТЕЗЫ о способах использования таких машин с треском провалились: не пишут они ни стихов, ни музыки, НЕ ПРИНИМАЮТ РЕШЕНИЙ, не ГОВОРЯТ на естественном языке, НЕ ИМЕЮТ ничего схожего с "интеллектом" и т.д. Хотя ОТЛИЧНО ПОМОГАЮТ ЛЮДЯМ делать все это! 2. Никакого "языка математики" В ДЕЙСТВИТЕЛЬНОСТИ НЕ СУЩЕСТВУЕТ! По простой причине: на сегодня существует НЕСКОЛЬКО "математик" с СОВЕРШЕННО РАЗНЫМИ подходами к делу: интуиционисткая, конструктивная, "конкретная" и пр. То, что Вы принимаете за "язык математики", есть МЕТОД ФОРМАЛЬНЫХ МОДЕЛЕЙ. В основании любой математической теории лежит одна или более формальная модель (математическая структура), описав которую, Вы, по принятым В ДАННОЙ ВЕРСИИ математики правилам логики (а они РАЗЛИЧНЫ), получаете развертку "генотипа" модели (аксиоматики) в логическую структуру, выявляя "по дороге" ее "законы строения", "следствия", "ограничения". 3. Для применимости таких построений требуется выполнить два простых условия: а) Вы должны СРАЗУ сформулировать "генотип" модели: набор данных, набор операций и аксиомы, ограничивающие исследуемое логическое пространство. б) Ваши построения будут иметь хоть какой-то смысл, если Ваша система не содержит внутренних противоречий (скажем, Вы неверно выбрали аксиомы и сталкиваетесь с тем, что логическое пространство, ограниченное аксиомами, не отражает всего набора значений данных, возникающего при "логической развертке" модели; и т.д., и т.п.). 4. Теперь посмотрите вокруг и скажите, как много Вы найдете областей челове- ческой деятельности, где можно строить ТОЛЬКО ТАКИЕ модели? Ответ: ничтожно мало. Даже физика -- самая "математизированная" дисциплина использует вовсе не "математику" КАК ТАКОВУЮ. Она использует ИСКЛЮЧИТЕЛЬНО наряженные в математические одежды СОБСТВЕННЫЕ ФОРМАЛЬНЫЕ МОДЕЛИ. Эти модели сплошь и рядом НЕ ЯВЛЯЮТСЯ "математическими" просто потому, что ДОПУСКАЮТ отступления от логических канонов ЛЮБОЙ ИЗ "математик", если математический формализм противоречит корректному опыту. Помнится, Ландау говорил, что если число из теоретической формулы меньше числа, полученного из опыта, в 2 раза, то формулу нужно просто умножить на 2! И это -- НОРМАЛЬНО! Для физики. НЕ для математики, где за такие действия Вам на первом курсе универа поставят также 2: тот самый коэффициент, который будет БЕССПОРЕН в физике (где кри- терий ценности теории -- соответствие опыту), но негоден в математике (где критерий ценности теории -- как минимум, непротиворечивость) :-))). 5. Представления о математике как о ПАНАЦЕЕ точного знания, а тем более, как о ЕДИНСТВЕННОМ способе познания ("нет математики - нет познания") являются НАИВНЫМ ЭКСТРЕМИЗМОМ, если угодно, "математическим шовинизмом". Ни один серьезный математик никогда не станет соваться со своими "рецептами", например, в то же самое искусство, языки которого Вы (не замечая, что противоречите себе сами) зачислили в "обычные языки" (что бы это могло быть? неужели Вы думаете, что художественные средства или музыкальная грамота имеют ХОТЬ КАКОЕ-ТО отношение к "обычным" русскому или английскому? доднесь я считал человеческие языки средствами психической обороны/нападения, крайне скверно выполняющими функции передачи сведений, а потому и нуждаю- щимися для этого в СПЕЦИАЛЬНЫХ НЕЯЗЫКОВЫХ ФОРМАЛИЗМАХ типа математических)... 6. Аналогичные физическим СПЕЦИАЛЬНЫЕ формализмы (нарушающие "строгие" математические принципы и правила там, где это требуется, заменяя их "содержательными рассуждениями" и "физическим смыслом") используются во ВСЕХ технических дисциплинах, которые, естественно, пользуются РАЗРАБОТАННЫМИ формализмами самой математики, не забывая их дополнять и "курочить" собственной "семантикой". Результатом такого использования математики является типичная "кусочно-линейная" логическая структура прикладных теорий, куда с великой непринужденностью из математики "с кровью" "забриваются" подходящие куски и из них составляется ЛОГИЧЕСКИЙ УРОД, сплошь и рядом ПОТРЯСАЮЩЕ ЭФФЕКТИВНЫЙ на практике. Всякий, кто изучал сопромат, хорошо про это знает. Иногда, по прошествии изрядного времени с момента появления "прикладной теории", развитие специальной дисциплины достигает уровня зрелости, на котором ОНА САМА выявляет, наконец, собственную "аксиоматику" и в ее рамках появляется возможность создания ЛОГИЧЕСКИ ГЛАДКОГО представления о предмете. Вот тогда-то и появляется новая версия специальной теории, ВНЕШНЕ облаченная в более "непрерывный" математический формализм, но ВНУТРЕННЕ по прежнему не имеющая к математике НИКАКОГО ОТНОШЕНИЯ. Если завтра данная дисциплина столкнется с явлениями, описание которых потребует от нее потерять обретенную "математическую невинность", прикладная теория немедленно пустится во все тяжкие, наплевав на матема- тические критерии целостности и истинности ради ЕГО ВЕЛИЧЕСТВА РЕЗУЛЬТАТА. 7. МЕТОД ФОРМАЛЬНЫХ МОДЕЛЕЙ (МФМ) является ОБЩИМ методом постижения истины во ВСЕХ развитых науках, включая сюда (да-да, в "общую очередь") и (одно время бывшую вместе с философией законодательницей мод) математику. Но трактовать МФМ как якобы чисто математический нельзя просто потому, что он изобретен не в математике, а (как и вся парадигма античной науки) в философии. Математику интересуют структурные свойства формальных моделей, физику -- физический смысл, который можно туда нагрузить. Это значит всего лишь, что математика и физика могут рассматривать разные аспекты одной и той же модели, но это ВОВСЕ НЕ значит, что все физические модели -- математические. 8. Суть лично моих предложений крайне проста: а) прекратить муссировать слова Гаусса "о королеве наук" -- старик жил во времена, когда всю математику можно было освоить за несколько лет, а еще лет за 10 изучить и остальные "технические" науки; б) осознать, что метод формальных моделей не является МОНОПОЛИЕЙ математики, а есть общеприменимый способ развитого описания в любой предметной области, отличающейся от математической "кусочно- линейной" прерывностью логики, а также характерной динамичной эволюцией исходных понятий, часто не позволящей "зафиксировать" математичекую структуру модели на более-менее длительный срок, и (страшно сказать) допускающую БОЛЕЕ ОДНОГО правильного взгляда на предмет в рамках одной системы понятий; в) искать методы работы с подобными "кусочно-прерывными" логическими пространствами, желательно, позволяющие выражать описание моделей способом, допускающим машинную интерпретацию; для каждого участка "непрерывности" модели иметь возможность использовать так много традиционной математики, как это требуется (благо, есть уже и MathCAD, и Mathematica, и MathLAB, и пр.). Занятно то, что одним из первых опытов излагавшейся ранее моей методики была попытка построить модель архитектуры математики по версии Бурбаки. На этом пути я не слишком преуспел по ряду причин: не имел в наличие ряда книг Бурбаки, не имел времени разбираться в массе ньюансов и деталей, не имел достаточных знаний в ряде важных областей, например, в топологии, и т.д. Но даже тот эскиз архитектуры, который у меня получился, включал в себя основные алгебраические структуры, классический анализ и метрические пространства. После чего стало понятно, что просто не хватает конкретных знаний, а метод позволяет-таки наращивать модель и дальше... Модель была, естественно, логически-прерывная, но давала представление о том, что, чем и от чего отличается. 9. Нужно отметить, что и "чистые" математики прекрасно осознают характер описанных проблем. А потому и появились такие новые области математики, как "нечеткие множества", "темпоральные логики", теории моделей и категорий и пр. Общий вектор математических устремлений сегодня состоит в попытках "собрать заново, в целостном виде всю математику", обрести утерянное "математическое единство" описаний, критериев, методов. Будущее покажет, насколько это получится. Но сегодня этого ПРОСТО НЕТ! 10. Как видно из вышесказанного, размахивать логической бритвой Оккама нужно С ВЕЛИКОЙ ОСТОРОЖНОСТЬЮ, дабы не уязвить вместо оппонента самого себя ;-). Монах Оккам не предполагал, что его тезис об избыточных сущностях будет СЛИШКОМ ЧАСТО являться основанием для ЗАПРЕТА не логической избыточ- ности, а просто "неудобного вопроса", понимать истинную природу которого либо трудно, либо лениво, а значит -- не обязательно. >систему для обеспечения СЛУЧАЙНОГО блуждания программиста в пространстве >состояний решаемой задачи. Все существующие ЯВУ были построены в результате > Не нужно ни по чему бродить программисту - ему надо только закодировать > матмодель. Грубо говоря, нужна "теория всего сущего". > Будет она, да хоть на бэйсике можно будет все закодировать. В простейшем случае. А ести НЕТ матмодели? ЛИЧНО ВЫ много пишите программ по матмоделям? Подозреваю, что почти не пишите. Разве что, компилятор с RSL... ;-) Думаю, > 90% современных программ пишутся БЕЗ КАКОЙ-ЛИБО модели вообще (не говоря уже о математической). Это не только упрек разработчикам, плохо знающим математику. Это в еще большей степени свидетельство СЛАБОСТИ математики и проблем с применением ее в существующем виде для решения большинства практических задач. Так что я предлагаю реально общепринятый "метод проб и ошибок" заменить на метод "сокращенных проб и ошибок" (в логических моделях), не теша себя иллюзиями, что вот проснусь завтра, а математика уже изменилась и программисты -- тоже. >> ТЕЗИС 4. Процессы и параметры, пространство состояний >> ----------------------------------------------------- >> >> 4.0. Одной из идей, все поставившей на ноги, стало представление о >>пространстве состояний решаемой задачи. Вкратце это вот что. В мире нет >>ничего "твердого", мир - это ансамбль взаимодействующих динамических процессов, > > Понятно - та же формула сущего, единая теория поля и т.д. > Но основная задача как раз в том и состоит, чтобы отсечь незначительные процессы > и сосредоточиться на определяющих, а не вводить в расчет учет местоположения > планет на небосводе. Приведу ответ Вашего воображаемого оппонента, который Вам заявит: -- Хорошо, не будем учитывать положение планет на небосводе. А почему? Вот до Чижевского не учитывали наличие пятен на Солнце. Оказалось, они ДИКТУЮТ глобальные земные процессы. Как Вам такой оборот? Кто будет решать, ЧТО ИМЕННО Вы собираетесь учесть в своей модели? Ландау с Лифшицем? А если у меня есть основания считать, что в моей ситуации их теория врет или неприменима? Прикажете переписывать единую теорию поля? А это вовсе и не нужно В МОЕЙ уникальной системе представлений, называемой астрологией. Я МОДЕЛИРУЮ ТО, ЧТО ХОЧУ, И ТАК, КАК ХОЧУ! Не нужно навязывать мне фитюлек, получивших статус икон. Я знаю только одно: в реальном мире все связано со всем, и характер этих связей НЕВОЗМОЖНО описать раз и навсегда какой бы то ни было теорией, хотя бы и со штампом "Одобрямс!" самого Господа Бога! Дайте мне МЕХАНИЗМ ЗАПИСИ моих идей, а уж ЧТО ИМЕННО я буду записывать -- это мое личное дело. Может, мои теории Дьявол визирует... Боюсь, что вот это крыть будет просто нечем... При всем моем уважении к единой теории поля и формуле сущего :-))... From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Mar 03 09:48:15 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 3 Mar 1997 09:48:15 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA12584; Mon, 3 Mar 1997 00:09:40 +0300 Received: by deity.chci.chuvashia.su id XAA00605; (8.6.12/vak/1dot9) Sun, 2 Mar 1997 23:16:10 +0300 To: subscribers@deity.chci.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Машина теорий (ответы) - часть 4 Date: Sun, 02 Mar 97 15:47:03 +0300 Organization: Private site Distribution: su Message-ID: References: Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 210 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 12421 Status: RO ------------------------------------------------------------------------- Машина теорий. Ответы: Часть 4. ------------------------------------------------------------------------- Stas Selitsky (RS Bank CIB) 25-Feb-1997 написал to All (и мне тоже): >>иногда иерархически связанных, но очень часто - НЕТ (вот причина провала ООП). > > А вот о иерархии природа действительно ничего не знает - это наш инструмент > управления сложностью. Считая деформацию конструкции негоже > лезть на молекулярный уровень - надо открыть учебник сопромата. Про сопромат: см. выше. И насчет молекулярного уровня: в связи с достижением ракетами и самолетами сверхзвуковых скоростей (и соответствующих нагрузок на конструкции) возник ряд эффектов текучести обычно "твердых" материалов, для учета которых ПРИШЛОСЬ-ТАКИ лезть на молекулярный уровень, чтобы ПОПРАВИТЬ формулы сопромата. Весь вопрос в том, КТО ИСПОЛЬЗУЕТ соотвествующую модель: студент, вожделеющий тройки на зачете, или исследователь, занимающийся теорией прочности. Во втором случае просто не станут слушать предложений про учебник сопромата, поскольку любой специалист с ходу перечислит Вам десяток глупостей, написанных в этом учебнике. Кстати, то же самое произойдет и в других случаях, вне пределов любимого сопромата. Модель (в идеале) должна учитывать ВСЕ уровни детализации представлений, но иметь механизм выбора масштаба использования. Когда Вы крутите винт на микроскопе, Вы просто устанавливаете видимость того, что Вам интересно. Хорош был бы микроскоп, который позволял бы видеть только объекты 1:100. И все! А 1:99 или 1:101 уже нельзя! ;-( Модель -- это (в идеале) АБСТРАКТНЫЙ НАУЧНЫЙ ПРИБОР, позволяющий исследовать явление с такой степенью глубины и детальности, как это вообще возможно. Теории (напр., макро- и микротеории прочности) -- это регулировочные винты сего прибора, позволяющие установить требуемые масштаб и избиратель- ность. Состояние, в котором находятся эти "запчасти" сегодня слишком часто напоминают результат деятельности маньяка-разрушителя, разобравшего единый механизм и разбросавшего его детали по углам. Это состояние логического хаоса, вполне естественного на следующее утро после "информационного взрыва". >> 4.1. Выбирая "квант наблюдения" интересующего нас суперпроцесса (среды), >>содержащего все остальные микропроцессы, мы имеем МНОЖЕСТВО характерных >>НЕСОВПАДАЮЩИХ периодов стабильности для подпроцессов рассматриваемого >>суперпроцесса, при переходе между которыми РАДИКАЛЬНО может меняться не >>только модель отдельного микропроцесса, но и модель суперпроцесса, пред- > > Естественно наши простенькие модели работают в своих пределах. > На баллистическом участке нам нужна масса и скорость материальной точки, > при входе в атмосферу - аэродинамика изделия, при встрече с целью- > энергитические параметры ВВ. А как Вы ПЕРЕКЛЮЧАЕТЕСЬ между "логическими участкми"? И переключатесь ли??? Вы слышали о причине катастрофы самолета под Хабаровском? Система управления была рассчитана на определенные пределы и не имела АЛЬТЕРНАТИВНОГО представления о том, что нужно делать ВНЕ этих пределов. Результат: погибли люди. Большинство техногенных катастроф имеют причиной использование "простеньких моделей", возникших в "простеньких мозгах" проектировавших эти системы "простеньких людей". Это ТА САМАЯ "простота", что ХУЖЕ ВОРОВСТВА (т.е. просто ОГРАНИЧЕННОСТЬ и ГЛУПОСТЬ). Распространение компь- терных систем управления сулит нам перспективы роста подобных катастроф в чудовищных масштабах: одни "простенькие модели" в политике ведут к чеченской войне, другие, в экономике, -- к банковскому кризису, третьи, в авиации, -- к дождю из самолетов, четвертые, в энергетике, -- к Чернобылям, а в комонавтике -- срывам полетов спутников к Марсу... Может, пора ЗАПРЕТИТЬ подобную простоту в Уголовном кодексе (что уже частично и сделано)? И ПОТРЕБОВАТЬ от критических по надежности систем БЕЗУСЛОВНОЙ ЛОГИЧЕСКОЙ ПОЛНОТЫ? Попробуйте объяснить родственникам погибших в том самолете, что "естественно, наши простенькие модели работают в своих пределах"... Интересно, что они Вам ответят?.. ;-(( >>причудливым способом, становясь прямо противоположным текущему. Практически >>НЕВОЗМОЖНО иметь ОДНО И ТО ЖЕ описание для каждого подпроцесса на все >>интересующее нас время решения задачи. И здесь не поможет никакая иерархия >>классов. Требуется для каждого "объекта" иметь БОЛЕЕ ЧЕМ ОДНО ОПИСАНИЕ >>и свободно переходить между ними в требуемые моменты исполнения модели. > > Скорее здесь нужна иерархия обьектов-моделей данного изделия и экспертная > система, определяющая какую из этих моделей задействовать в данных условиях. Модель и есть средство для создания КОЛЛЕКЦИЙ объектов-теорий, не обязательно иерархически связанных (но включая сюда и иерархии). Машина теорий (интер- претатор модели) и есть "экспертная система", определяющая не только "какую из теорий задействовать в данных условиях", но и способная сравнить (при наличии аппаратного мультипроцессорного параллелизма) практические последствия выбора той или иной теории (рассчитывая несколько вариантов по нескольким альтернативным теориям одновременно). ИЗ МОДЕЛИ экспертная система получается КОМПИЛЯЦИЕЙ (прямая задача), превратить ЭКСПЕРТНУЮ СИСТЕМУ в модель (обратная задача) часто просто НЕВОЗМОЖНО! Экспертная система есть вариант модели. Обратное -- неверно. >> 4.2. Каждый микропроцесс интересует нас как набор определенных параметров. >>Некоторые из них являются внешними для микропроцесса (параметры среды или па- >>раметры других, связанных ЛЮБЫМ способом с данным микропроцессов), некоторые - >>внутренние (параметры микропроцесса). Связи между ВСЕМИ параметрами микро- >>процесса (внешними и внутренними) задаются матрицами связей, описывающими >>правила перехода между значениями любого параметра при заданных значениях >>всех других связанных параметров. В простейшем (и наиболее общем случае) >>матрица связей имеет размерность алгебраического произведения всех значений >>всех собственных параметров микропроцесса и внешних связанных параметров. > > Ага, многомерное пространство, где каждая переменная - орт, и по начальной > точке и n-1 координат конечной получаем n-ую. И что здесь нового, зачем нам > матрица. Чем плоха система n уравнений? СОВЕРШЕННО нового в рассматриваемых методах действительно не очень много, поскольку придется вернуться к ряду идей, составлявших альтернативы современному программированию с начала 60-х -- конца 50-х (ДО массового использования ЯВУ). "Система уравнений" плоха тем, что это -- опять ЧАСТНЫЙ СЛУЧАЙ куда более общего описания связей в терминах логических значений, через логические матрицы связей. После школьной математики, конечно, бывает трудно представить, что логическая матрица есть БОЛЕЕ ОБЩАЯ структура, чем составленная НА ЕЕ ОСНОВЕ система уравнений, поскольку с последними знакомы все, а логические матрицы встречаются в спецкурсах и нечасто. Но когда Вы вспомните, что для решения систем уравнений все равно приходится прибегать к МАТРИЧНЫМ методам, где "уравнения", как таковые, просто исчезают в процессе выполнения БОЛЕЕ ОБЩИХ матричных операций, все станет на свои места. Тем более, что решать системы уравнений для определения N-го значения, при использовании моделей, к сожалению, приходится ОЧЕНЬ редко. По одной причине: крайне редко такие модели задают действительно "систему уравнений"! Получаемая "логическая матрица" есть скорее не система из N уравнений, а формальная грамматика, конечный автомат, R-диаграмма и т.п. Идея что-то "вычислять" по системе уравнений, полученной из грамматики языка Cи, может оказаться очень плодотворной, если знать две вещи: а) ЧТО вычислять, и б) ЗАЧЕМ. >> 5.0. Правила перехода между значениями параметров в матрице связей >>процесса ("функции/подпрограммы" в обычном программировании или "методы" в >>объектном) ОБЯЗАТЕЛЬНО должны иметь ДВА представления: логическое - >>оперирующее "словесными" обозначениями значений параметра типа {горячий, >>теплый, холодный} и числовое - оперирующее соответствующими числовыми значениями >>(для температуры это могут быть соответственно величины {3E+5C, 42.3C, -70C}). > > Ну зачем нам логика - она насквозь субьективна (горячо,холодно). > Она имеет смысл при введении субьекта в модель - зачем он нам? Беда состоит в том, что СУБЪЕКТИВНО ВСЕ ЗНАНИЕ! В математике, правда, открыли это недавно, но философы предупреждают нас об этом которую сотню лет. То, что Вы увидите, зависит от того, ОТКУДА Вы на это смотрите: от Вашей специфической точки зрения, опыта, образования, дальтонизма наконец. Даже физика "сломалась" на принципе неопределенности, когда выяснилось, что процесс измерения может РАДИКАЛЬНО менять картину изучаемого процесса. А значит, т.н. "абсолютную истину" можно предполагать только по правилам статистики, т.е. ПРОСТО НЕ ЗНАТЬ, что же точно будет в конкретно следующий момент времени с изучаемой системой, какой именно будет, например, ее структура из набора возможных вариантов. Разные люди видят мир, представляют его, раскладывают по полочкам и интерпретируют по-разному. И это -- основа т.н. "прогресса", который обеспечивают только ОБЪЕМНЫЕ представления о мире со всех возможных сторон, исключая догматическое невежество по принципу "этого не может быть, потому что не может быть никогда". Поэтому задача настоящего исследователя (аналитика, проектировщика) -- уметь СОБИРАТЬ РАЗНЫЕ ТОЧКИ ЗРЕНИЯ, ГОНЯТЬСЯ ЗА ОТЛИЧНЫМИ ОТ ОБЩЕПРИНЯТЫХ МНЕНИЯМИ, КОЛЛЕКЦИОНИРОВАТЬ ПОЛНОТУ ПРЕДСТАВЛЕНИЙ, а не убогий понравившийся ЛИЧНО МНЕ прецедент. Разница между догматикой и наукой состоит в этом. В этом же состоит и разница между знаниями и заблуждениями о своих знаниях. >> 5.1. МНОГОМЕРНОСТЬ значений таким образом введенных "переменных" >>(параметров процессов) позволяет выполнять ВСЮ постановку задачи в терминах >>СЕМАНТИКИ этой задачи, создавая тезаурус (словарь) предметной области, >>и оставляя детализацию "вычислительного" аспекта постановки либо на "потом", >>либо на работу профессионального математика, либо выполняя эту работу >>немедленно, если человек, создающий модель, владеет предметно-ориентированной > >>Каждый процесс интересен нам в конкретном случае проявлением ряда своих пара- >>метров. Каждый параметр характеризуется дискретным перечислимым набором зна- >>чений (например, {мир, война}, {горячий, теплый, холодный}, {киты, тюлени, >>олени} и т.п.). Каждому значению можно сопоставить числовое множество, иногда > > Представляю себе подобную постановку задачи: "Определить (качественно) температуру > большинства оленей в условиях военных действий". После чего профессиональный > математик начинает вычислять вероятность поражения оленя в условиях > плотности огня современных военных действий. Причем для тюленей картина > будет качественно иной :) > > Извини - не удержался - такая подставка. Охотно извиняю! Потому что это была не "подставка", а ЛОВУШКА. :-))) И Вы в нее попались! Поскольку "температура оленей во время боевых действий" или "связь небесных тел с судьбами людей" может быть, а может и не быть. Это ВОПРОС ИССЛЕДОВАНИЯ, на который априори отвечать НЕДОПУСТИМО. И если Вы даете БЕЗДУМНЫЕ ответы ВСЕРЬЕЗ, то, возможно, в своей жизни Вы пропустите реальный шанс сделать серьезное нешуточное открытие, заметив то, что другие ПРОСТО НЕ ВИДЯТ. Конечно, для Господа Бога, поручение которого на Земле Вы тем самым не выполнили, это будет не страшно: он снабдит соответствующим заданием другого младенца и отправит его с повторным поручением в нашу юдоль познания. Но лично "прозевавшему" это может быть ужасно обидно, только вот обнаружит он свой промах тогда, когда исправить что-то будет невозможно... Но это так, теософия... ;-)) Чтобы не попасться на крючок, нужно было представлять достаточно ясно то, что мы тут с Вами обсуждали. Искренне надеюсь, что не тая обид за мои ехидные замечания (Вы сами в начале просили извинить резкости, я решил, что вправе отвечать не в унылой академической манере "дано-- требуется доказать", а свободно), Вы задумаетесь немного над СУТЬЮ моих ответов. Надеюсь, что ответил на Ваши вопросы. > -- > Stas Selitsky Всего наилучшего, A.S. From chci!deity!deity.chci.chuvashia.su!L-relcom Tue Mar 04 10:11:41 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Tue, 4 Mar 1997 10:11:41 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA02427; Tue, 4 Mar 1997 05:09:46 +0300 Received: by deity.chci.chuvashia.su id VAA16282; (8.6.12/vak/1dot9) Mon, 3 Mar 1997 21:18:08 +0300 To: subscribers@deity.chci.chuvashia.su From: "Alexey A. Sedov" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Машiна теорий - когда же? Date: Mon, 03 Mar 97 20:29:14 +0300 Organization: Private site Distribution: su Message-ID: References: <3319B1DF.26E8AA31@compchem.kiev.ua> Reply-To: Alexey@sedov-a.msk.ru NNTP-Posting-Host: news.gamma.ru X-Return-Path: sedov!sedov-a.msk.ru!Alexey@gamma.srcc.msu.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 136 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 7301 Status: RO Andrey V Khavryutchenko Date: Sun, 02 Mar 97 18:59:11 +0200 wrote to me: > Hi, уважаемый Alexey A. Sedov. > > Осмелюсь сделать вам небольшое замечание и задать вопрос. > > Замечание: > Если бы Вы были бы менее категоричны в своих утверждениях > и меньше бы использовали БОЛЬШИХ БУКВ в своих ответах > они бы воспринимались намного легче. > > Вопрос: > Я уже достаточно прочитал Ваших расуждений о том, что языки > высокого уровня плохи, ОО никуда не годится, математика > малоприменима для реальных проблемм, etc. Но до сих пор > я не увидел связного описания Вашего способа решения > _реальных_ проблемм. Если Вам не трудо, возьмите какую нибудь > простую проблемму и продемонстрируйте Ваш способ ее решения: > от анализа предметной области до кода. Желательно было бы также > увидеть как проходит процесс исправления ошибок и неточностей > в исходной постановке проблеммы в Вашем варианте. > > Я уверен, что вся аудитория relcom.comp.software-eng будет > Вам очень благодарна. Hi, уважаемый Andrey V Khavryutchenko! Мне кажется, что я никогда не брал перед аудиторией relcom.comp.software-eng обязательств что-то ей демонстрировать, тем более, сложную программную систему объемом в 4 мегабайта .exe. Поэтому я приму к сведению потенциальную благодарность аудитории, но на пути этой благодарности есть некоторые препоны. 1. Описание используемой мною нотации DETAIL представляет собой полторы сотни страниц печатного текста формата A4. К сожалению, я не в силах "сжать" конкретный технический текст до пределов пропускной способности сети, даже если бы захотел его кому-то передавать. 2. Работа пользователя в моей системе представляет собой взаимодействие с серией редакторов под W31/W95 и описать ее "кратко" также нельзя из-за обилия рисунков без которых все это будет непонятно. Потребуйте от разработчиков Microsoft Excel описания работы с системой не имея средств показать используемые таблицы. Примеры очень похожих на мои таблиц напечатаны в книге Хамби. Остается ее открыть... 3. Состояние моей работы таково, что сегодня я могу пользоваться ею только сам -- это не "товарный продукт", а набор разнопестрых программ, связанных текстовыми транспортными файлами. Причем периодически часть программ переписывается и модифицируются их текстовые файлы, чтобы попробовать что-то новенькое. Описание системы представлений, лежащих "сверху" всего этого, достаточно громоздко и сложно. Все что можно было написать "простыми" словами, я уже сделал, совершенно полно и честно раскрыв "технологический изюм". Вы не удовлетворены. Очень сожалею. Я совершенно честно писал, что это моя "игрушка", пока что вовсе не предназначенная для публичных демонстраций или лекций. Подобные игрушки есть у многих профессионалов, но они о них ничего обычно не рассказывают. А зря, иногда это бывает довольно занятно и уж куда более поучительно, чем реклама Delhpi/C++Builder/VB/VC++/LogicWorks/IDEF*/etc. Я просто хотел подать пример "инжиниринга" самопальных технологий в надежде прочитать в ответ о чужих подобных работах. Я думаю, что "общественности" relcom.comp.software-eng это будет также весьма интересно и полезно, поскольку большая часть этой общественности выросла во времена, когда что-то сделанное не в USA, заведомо воспринимается как второсортная диковинка. Мне посчастливилось застать совсем другую ситуацию... 4. Честно сказать, мне глубоко наплевать и на шквал аплодисментов, и на свист в мой адрес. Поэтому кого-то "убеждать" и кому-то что-то "доказывать" я не собираюсь. Простите, но мне это неинтересно. Если Вам не нравятся "просто идеи" или Вы затрудняетесь представить их реализацию -- увы, бессилен Вам помочь, -- я писал для профессионалов, которые в состоянии это сделать. Тем более, что представить себе Forth у которого слова структур передачи управления заменены на ТР (хотя бы в смысле книги Хамби) -- это значит получить весьма ясную и точную аналогию моих методов, дальнейшая детализация которых уже доступна любому. Это описание есть прямой алгоритм построения системы для работы с логическими моделями. Чего же еще? Описания языка Forth? Пересказа книги Хамби? 5. Приведите мне примеры моих фактических ошибок в оценке роли ЯВУ, состояния прикладных теорий или современной математики. У меня возникло впечатление, что Вы раздражены моей мрачной картиной. С нетерпением жду чего-то радостного и жизнеутверждающего по теме. Обязуюсь не комментировать сию живительную информацию своими ужасными и грубыми выпадами. НУ ОПРОВЕРГНИТЕ МЕНЯ, НАКОНЕЦ!!! Я также готов представить Вам ссылки на известные мне печатные работы, которые, возможно, удовлетворят Вас уже тем, что там НЕТ обилия неприятных Вам БОЛЬШИХ БУКВ. Правда написано там будет примерно то же самое. И здесь утешить уже ничем не смогу... 6. Весь флейм про машину теорий зародился из желания сказать, что: а) проблемы современного программирования не случайны; б) они не "лечатся" введением нового ЯВУ или CASE; в) одной из альтернатив является использование не ЯВУ, а методов моделирования предметных областей логическими моделями; г) на этом пути много проблем, но интересующиеся могут сами что-то попробовать, для чего часть технологии была раскрыта довольно подробно и даны ссылки; д) мне было бы интересно услышать отзывы об использовании подобных методов у нас и за рубежом, о возможном наличии других альтернатив ЯВУ, не тех, о которых говорил я сам. 7. Поскольку "общественность" в Вашем лице явно желает прекратить разговоры на эту тему, я скромно умолкаю -- благо достаточно других забот, кроме изречения прописных истин неприятным Вам "категорическим" тоном. К сожалению, от изменения моего тона, РАЗДРАЖЕННОГО и ОЗЛОБЛЕННОГО беготней по порочному кругу общеиспользуемых программных технологий, ни у кого из программ не исчезнет ни одной ошибки. Если бы проблема была только в моем тоне, я лил бы елей ведрами... 8. Я сказал вполне достаточно. Имеющий уши да услышит. Имеющий мозги -- задумается. Выдумывать модельные примеры и писать еще десятки килобайт пояснений к ним у меня нет ни сил, ни времени, ни желания. Выдать сюда одну из существующих моделей -- это породить новую волну вопросов, а также показать то, что мне сейчас вовсе не хочется показывать по очевидным экономическим и правовым причинам. Чтобы что-то попробовать самому, достаточно прочитать книжку в сто страниц, взять бумагу, ластик, карандаш и составить свою собственную первую модель. Это может кому-то понравиться настолько, что он решит засунуть ее в компьютер. Если дело дойдет до этого, я буду считать, что говорил свои речи не зря. > SY > -- > Andrey V Khavryutchenko > akhavr@compchem.kiev.ua > Interests: Computational Chemistry, OOA&OOP, The Net > > Don't take life so seriously. It's not permanent. A.S. From chci!deity!deity.chci.chuvashia.su!L-relcom Wed Mar 05 11:19:58 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Wed, 5 Mar 1997 11:19:58 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA13422; Tue, 4 Mar 1997 23:14:34 +0300 Received: by deity.chci.chuvashia.su id PAA28556; (8.6.12/vak/1dot9) Tue, 4 Mar 1997 15:23:19 +0300 To: subscribers@deity.chci.chuvashia.su From: Andrey V Khavryutchenko Newsgroups: relcom.comp.software-eng Subject: [News] Re: Машина теорий - когда же? Date: Tue, 04 Mar 97 11:12:48 +0200 Organization: Computational Chemistry Group Message-ID: <331BE790.56159BAC@compchem.kiev.ua> References: <3319B1DF.26E8AA31@compchem.kiev.ua> NNTP-Posting-Host: netmaster.compchem.kiev.ua Mime-Version: 1.0 X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i486) Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 164 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 8439 Status: RO Alexey A. Sedov wrote: > > Hi, уважаемый Andrey V Khavryutchenko! > > Мне кажется, что я никогда не брал перед аудиторией > relcom.comp.software-eng обязательств что-то ей демонстрировать, > тем более, сложную программную систему объемом в 4 мегабайта .exe. > Поэтому я приму к сведению потенциальную благодарность аудитории, > но на пути этой благодарности есть некоторые препоны. > > 1. Описание используемой мною нотации DETAIL представляет собой > полторы сотни страниц печатного текста формата A4. К сожалению, я не в > силах "сжать" конкретный технический текст до пределов пропускной > способности сети, даже если бы захотел его кому-то передавать. > > 2. Работа пользователя в моей системе представляет собой взаимодействие > с серией редакторов под W31/W95 и описать ее "кратко" также нельзя > из-за обилия рисунков без которых все это будет непонятно. Потребуйте > от разработчиков Microsoft Excel описания работы с системой не > имея средств показать используемые таблицы. Примеры очень похожих > на мои таблиц напечатаны в книге Хамби. Остается ее открыть... Попробую. Идея работы электронной таблицы очень проста: в каждой клетке таблицы может находиться либо текст. либо число, либо формула. Формула может использовать как параметры содержимое любой клетки. Описание неполно в силу своей краткости, но основную идею IMHO отражает достаточно хорошо. > 3. Состояние моей работы таково, что сегодня я могу пользоваться ею > только сам -- это не "товарный продукт", а набор разнопестрых > программ, связанных текстовыми транспортными файлами. Причем > периодически часть программ переписывается и модифицируются их > текстовые файлы, чтобы попробовать что-то новенькое. Описание Очень знакомо :) > системы представлений, лежащих "сверху" всего этого, достаточно > громоздко и сложно. Все что можно было написать "простыми" словами, > я уже сделал, совершенно полно и честно раскрыв "технологический > изюм". Вы не удовлетворены. Очень сожалею. Я совершенно честно > писал, что это моя "игрушка", пока что вовсе не предназначенная > для публичных демонстраций или лекций. Подобные игрушки есть у многих > профессионалов, но они о них ничего обычно не рассказывают. А зря, > иногда это бывает довольно занятно и уж куда более поучительно, чем > реклама Delhpi/C++Builder/VB/VC++/LogicWorks/IDEF*/etc. Я просто > хотел подать пример "инжиниринга" самопальных технологий в надежде > прочитать в ответ о чужих подобных работах. Я думаю, что > "общественности" relcom.comp.software-eng это будет также весьма > интересно и полезно, поскольку большая часть этой общественности > выросла во времена, когда что-то сделанное не в USA, заведомо > воспринимается как второсортная диковинка. Мне посчастливилось > застать совсем другую ситуацию... [skip] > 5. Приведите мне примеры моих фактических ошибок в оценке роли > ЯВУ, состояния прикладных теорий или современной математики. > У меня возникло впечатление, что Вы раздражены моей мрачной картиной. > С нетерпением жду чего-то радостного и жизнеутверждающего по теме. > Обязуюсь не комментировать сию живительную информацию своими > ужасными и грубыми выпадами. НУ ОПРОВЕРГНИТЕ МЕНЯ, НАКОНЕЦ!!! > Я также готов представить Вам ссылки на известные мне печатные работы, > которые, возможно, удовлетворят Вас уже тем, что там НЕТ > обилия неприятных Вам БОЛЬШИХ БУКВ. Правда написано там будет > примерно то же самое. И здесь утешить уже ничем не смогу... Да, я слегка раздражен Вашей мрачной картиной. Я согласен, что ни один язык, ни одна прикладная теория, никакая часть математики или она целиком не может абсолютно точно описать любое происходящее явление. There is no silver bullet. Мы используем их как инструменты для познания мира путем понижения сложности. Все ошибки возникают от неправильного _применения_ инструментов. ЯВУ совсем не виноваты что ои не могут выразить всего многообразия окружающего мира -- они создавались совсем не для этого. Их цель -- всего-навсего выразить _алгоритм_ языком, достаточно близким к естественному. И в этом они преуспели. Следующий этап в приближении языков реализации к предметной области -- это объектно-ориентированые языки. Их тоже можно употреблять, а можно _зло_употреблять ( to use and to misuse ). Они уде достигли своей зрелости и сейчас работы ведутся над тем, чтобы облегчить преобразование формально записаной модели предметной области в код (IDEF*, Booch, OMT, UML, etc.) > 6. Весь флейм про машину теорий зародился из желания сказать, что: > а) проблемы современного программирования не случайны; Согласен > б) они не "лечатся" введением нового ЯВУ или CASE; CASE - слишком размытое понятие. Я считаю что эта аббревиатура сильно замусолена маркетологами пытающимися сбыть свой товар, а не решить проблемму. Я считаю что набор программ помогающих отслеживать взаимозависимости на всем пути от исходных требований до работающего кода и был бы тем средством, что мы бы все хотели увидеть под этим названием. Но -- увы... > в) одной из альтернатив является использование не ЯВУ, а методов > моделирования предметных областей логическими моделями; Не вижу никаких проблемм в использовании моделей. Тем более моделей, которые выражаются средствами ЯВУ. Или с помощью любого языка моделирования, который близок к предметной области и достаточно просто преобразуется в код. > г) на этом пути много проблем, но интересующиеся могут сами > что-то попробовать, для чего часть технологии была раскрыта > довольно подробно и даны ссылки; Я желаю! Судя по тем описаниям, что Вы дали Ваш метод позволяет ( я слегка утрирую ) посадить за терминал специалиста в предметной области, дать ему поработать с Вашей программой и в результате получить формализованное в коде описание предметной области. Если это так -- это потрясающе. Естественно, что я хочу понять _как_ это происходит. Но для того чтобы понять, нужно знать две вещи: базовые понятия и правила по которым их можно соединять друг с другом (иными словами онтологию). Увы -- я до сих пор не смог выделить из Ваших объяснений ни то, ни другое. > д) мне было бы интересно услышать отзывы об использовании подобных > методов у нас и за рубежом, о возможном наличии других > альтернатив ЯВУ, не тех, о которых говорил я сам. > > 7. Поскольку "общественность" в Вашем лице явно желает прекратить > разговоры на эту тему, я скромно умолкаю -- благо достаточно > других забот, кроме изречения прописных истин неприятным Вам > "категорическим" тоном. К сожалению, от изменения моего тона, > РАЗДРАЖЕННОГО и ОЗЛОБЛЕННОГО беготней по порочному кругу > общеиспользуемых программных технологий, ни у кого из программ > не исчезнет ни одной ошибки. Если бы проблема была только в моем > тоне, я лил бы елей ведрами... Я ни в коем случае не жедаю прекращения разговора на эту тему! Просто я убежден, что идею любого решения сколь угодно сложной проблеммы можно изложить в виде нескольких предложений. К сожалению я пока не увидел этого. Может плохо смотрел? Буду очень благодарен, если мне повторят этот кусок. > 8. Я сказал вполне достаточно. Имеющий уши да услышит. Имеющий мозги -- > задумается. Выдумывать модельные примеры и писать еще десятки > килобайт пояснений к ним у меня нет ни сил, ни времени, ни > желания. Выдать сюда одну из существующих моделей -- это породить > новую волну вопросов, а также показать то, что мне сейчас вовсе > не хочется показывать по очевидным экономическим и правовым причинам. > Чтобы что-то попробовать самому, достаточно прочитать книжку в сто > страниц, взять бумагу, ластик, карандаш и составить свою собственную > первую модель. Это может кому-то понравиться настолько, что он решит > засунуть ее в компьютер. > > Если дело дойдет до этого, я буду считать, что говорил > свои речи не зря. SY -- Andrey V Khavryutchenko akhavr@compchem.kiev.ua Interests: Computational Chemistry, OOA&OOP, The Net Don't take life so seriously. It's not permanent. From chci!deity!deity.chci.chuvashia.su!gamma.srcc.msu.su!sedov!sedov-a.msk.ru!Alexey Mon Mar 24 11:47:14 1997 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA06320 Mon, 24 Mar 1997 11:47:14 GMT Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA15720; Sat, 22 Mar 1997 07:34:13 +0300 Received: from gw-srcc.gamma.ru by deity.chci.chuvashia.su with ESMTP id XAA26568; (8.6.12/vak/1dot9) Fri, 21 Mar 1997 23:32:53 +0300 Received: from srcc.UUCP (uucp@localhost) by gw-srcc.gamma.ru (8.8.4/8.8.4) with UUCP id XAA08771 for alek@chavb.chuvashia.su; Fri, 21 Mar 1997 23:18:23 +0300 (MSK) Received: by gamma.srcc.msu.su; Fri, 21 Mar 1997 23:17:24 +0300 Received: by sedov-a.msk.ru (UUPC/@ v5.09gamma, 14Mar93); Fri, 21 Mar 1997 23:17:33 +0300 To: alek@chavb.chuvashia.su References: Message-Id: Organization: Private site From: "Alexey A. Sedov" Date: Fri, 21 Mar 97 23:17:32 +0300 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Машина теорий Lines: 360 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 21957 Status: RO > Добрый день, "Alexey A. Sedov" ! Здравствуйте, Алексей! > Просто спор о недостатках ЯВУ вполне ясно заставил думать, простите, > что Вы предлагаете заменить своими методами программирование как таковое. Вы весьма точно уловили СУТЬ моих предложений. Пожалуй, Вы единственный, кто в прошедшей дискуссии сделал столь ясный и очевидный вывод. Да, я считаю, что современное программирование безнадежно не отвечает никаким современным потребностям в области автоматизации обработки данных. И с этой т.з. вопрос о его замене чем-то более стОящим просто "перезрел". Я пишу программы более 20-ти лет. В принципе, могу реализовать ЛЮБУЮ программную систему (или проруководить ее реализацией силами группы в 3-5 программистов). За прошедшие годы я наблюдал смену нескольких технологий программирования. То, что я видел, не оставляет сомнений: мы имеем дело с обманом, точнее, с самообманом творцов этих технологий. Нет НИКАКИХ шансов на то, что в рамках парадигмы ЯВУ мы получим вообще когда-либо что-то отличное от "торговли пустыми надеждами" просто потому, что идеология ЯВУ не содержит никаких "идей", кроме парадигмы потока исполняемых команд. Это парадигма для машины, а не для человека. Путь "подстройки" человеческих возможностей под убогий "машинный интеллект" имеет очевидные физиологические и психологические ограничения и потенциал этого подхода был почти полностью исчерпан с появлением языка ФОРТРАН. Все последующее движение в этом направлении реально было бегом по кругу. Об этом еще в 60-70-х говорили и Кнут, и Мур, и другие корифеи. Поэтому единственным способом разорвать порочный круг идеологем ЯВУ является ОТКАЗ от ЯВУ как от средства работы ЧЕЛОВЕКА с машиной. Роль ЯВУ должна быть "сужена" до их истинных границ -- служить промежуточной формой между записью мысли человека и системой команд машины. Основным средством работы человека с машиной должны стать системы, где ЯВУ практически не будет виден конечному пользователю. ЯВУ неизбежно и в скором времени будут вытеснены в свои "природные" границы разнообразными системами записи, хранения, расширения, интерпретации и передачи ЧЕЛОВЕ- ЧЕСКОГО ОПЫТА. С развитием технологии распространения данных на CD-ROM, с появлением глобальных сетей стало ясно: надвигается революция в технологии хранения и передачи знаний между поколениями, сравнить которую в европейской истории можно только с распространением типографских методов издания книг в Средние века (что и послужило источником последовавшей затем промышленной революции, невозможной без "Возрождения", суть которого своди- лась к массовому распространению и взрывному накоплению разнообразных знаний, в основном, конечно, прикладных). ЯВУ для этих целей совершено не подходят, а значит будут заменены принципиально иными системами, например, вроде той, которую я пытался описать в своих заметках. > Что на сегодня вряд ли возможно. Поскольку мы по-прежнему боремся с ресурсами, > и чем быстрее растут аппаратные ресурсы, тем быстрее растут аппетиты > пользователей, то есть людей, которые в конечном счете платят деньги > за программирование и тем его финансируют. Если Вы возьмете систему типа Visual Basic 4.2, добавите к ней пять-шесть shareware CD-ROM с готовыми компонентами OCХ/VBX, то Вам и в страшном сне не захочется "бороться с аппаратными ресурсами" путем самостоятельного программирования чего бы то ни было. Наоборот, с появлением массовых систем визульно-компонентного программирования практически исчезла потребность в "собственно программировании" календарей, текстовых редакторов или СУБД для 95% профессиональных программистов. От них теперь требуется совсем иное: умение ПРОЕКТИРОВАТЬ, КОМПОНОВАТЬ систему из готовых "кирпичей" типа элементов известного конструктора Microsoft Office. В этом смысле реализовались все мечты сторонников "конвейерных" технологий, но оказалось, что их победа -- пиррова. Получив огромное количество "стандартных кирпичей" для сборки программ, они вдруг обнаружили, что разработку еще сильнее стали тормозить ОГРАНИЧЕНИЯ ЧЕЛОВЕЧЕСКИХ СПОСОБНОСТЕЙ по пониманию свойств и качеств ТАКИХ программных компонентов, постижению правил их использования и связывания, т.е. наконец стало очевидным всем то, что немногие понимали уже давно: решения основных проблем программирования лежат не в плоскости поисков 1001 способа закодировать много-много всего на любом из ЯВУ или даже на ассемблере, а в плоскости поисков способа организации данных, алгоритмов, процессов и компонентов таким образом, чтобы можно было все это вместить в ясной, простой и недвусмысленной форме в любую среднюю человеческую голову. Вот тут даже радикалы-адепты ЯВУ, вроде Чарльза Симонии, стали искать способы сделать это. И конечно же обнаружили их, но в направлении, прямо противоположном ЯВУ... Вместо Visual Basic (а лучше -- отталкиваясь от быстро сделанного прототипа программы на VB) Вы можете использовать MSVC++ 4.2, получая очень быстро работающую и практически не имеющую ограничений программную систему. И единственные проблемы, с которыми Вы будете там сталкиваться, состоят в том, что С++ крайне скверно подходит для описания связей между компонентами -- как и любой другой ЯВУ с парадигмой потока команд. Вам придется потратить ГОДЫ на выявление "стандартных связей" между элементами Вашей собственной системы, а вовсе не на реализацию обработки прерываний или взаимодействия с БД. > Или по-другому - Вы проектируете укрупненно, рассматривая разные внешние > процессы (мультимедиа, базы данных) как элементарные кирпичики. Но идеальные > инструменты-кирпичики еще не созданы, а тем, которые претендуют на это, > всегда ресурсов недостаточно ;-) (мультимедиа по определению требует > ресурсов отнюдь не XT). Не понимаю, о чем Вы говорите? :-( "Идеальных инструментов-кирпичиков" просто НАВАЛОМ даже на пиратских CD-ROM с Митинского рынка! Проблема в том, чтобы элементарно УСПЕТЬ ПОЗНАКОМИТЬСЯ с одной партией, когда уже привезли другую. "Кирпичики" OLE сыплются на голову потоками со всех WEB-серверов, и "мультимедиа" составляют совсем не главную часть этого потока. И насчет недостатка ресурсов. У меня уже третий год стоит 486DX2-66 & 16 Мб ОП! Все "визуальное" добро вполне прилично работает даже здесь, а на 586 это просто "летает"! Даже VB, не говоря о MSVC++ или Delphi! Либо Вы постоянно говорите о каком-то ОЧЕНЬ узком классе задач (вроде шахмат), проблемы с которым состоят не в hardware, а в ОТСУТСТВИИ ЭФФЕКТИВНЫХ АЛГОРИТМОВ РЕШЕНИЯ, либо размерность Ваших задач очень велика, и Вы пытаетесь решать на одной машине то, что требует матрицы процессоров. Я не встречался всерьез с ограничениями аппаратуры как минимум лет пять. Но ОЧЕНЬ часто наталкивался на две вещи: 1. Разговорами о быстродействии прикрывается АЛГОРИТМИЧЕСКОЕ УБОЖЕСТВО реализации (что связано с падением уровня образования). 2. Чудовищно медленно и ненадежно работают компонентные системы, построенные без глубокого понимания идей, лежащих в основе компонентов (что связано с объективной сложностью постижения и увязки компонентов при существующих формах их реализации на ЯВУ и распространения "as is"). Тогда как на практике вполне приличные системы строятся даже на VB! Если, конечно, знать, как это делать ;-)). Например, почитывая на досуге статейки и книжки на CD-ROMах Microsoft Development Network... >> Так о том и речь, что нужно таких МОДЕЛЕЙ делать больше, разных и лучших! >> Чтобы был выбор. Но таковые модели, будучи ПОГРЕБЕННЫМИ НАВЕК в кодах >> языка C/C++, Delphi или VB, не представляют собой НИКАКОЙ САМОСТОЯТЕЛЬНОЙ >> ценности НИ ДЛЯ КОГО, кроме разработчиков данной системы. Они не являются > > Согласен. Но без этого у Вас не будет процессов-кирпичиков, которые можно > в ТР использовать. И вообще, Вы нигде не упомянули о том, как РЕАЛИЗУЕТСЯ > прекрасная, логически непротиворечивая и т.п. модель : Как из логической модели СКОМПИЛИРОВАТЬ (т.е. АВТОМАТИЧЕСКИ ПОЛУЧИТЬ) код на любом существующем ЯВУ или ассемблере как раз и написано в книжке Хамби. Собственно, она почти целиком этому посвящена. Поэтому, если Вы получаете модель, то перевод ее в компьютерную программу делает КОМПИЛЯТОР! И потом. Я НИГДЕ не говорил, что надо ВОВСЕ и ВСЕГДА отказаться от ЯВУ или ассемблеров. Речь шла о том, чтобы ПЕРЕСТАТЬ ЗАПИСЫВАТЬ НА НИХ ЗНАНИЯ! Но лично я не собираюсь отказываться от уже существующей стандартной библиотеки C или Windows API только потому, что "эта гадость" написана не на любимых ТР! Более того, именно в сочетании с ТР удается реально ПОНЯТЬ и ЭФФЕКТИВНО ИСПОЛЬЗОВАТЬ такие огромные наборы пестрых возможностей, как Windows'95 API! >> удивительному выводу для меня темны и загадочны. Если Вас не устраивает >> шесть порядков прироста производительности hardware за 30 лет, то, >> боюсь, дело не в недостатках существующего hardware, а в свойствах >> лично Вашей ТОЧКИ ЗРЕНИЯ. > Дык, не так давно и алфавитно-цифровой дисплей был в новинку, а теперь всем > мультимедиа подавай. Прогресс техники => прогресс аппетитов в квадрате ;-( Дык, нету никакого "прогресса аппетитов в квадрате" в огромном количестве областей. Реально не нужно ни малтимедиа, ни GUI в экономических конторах! А это и есть основные заказчики программ. Нужно им совсем иное: другое КАЧЕСТВО обработки данных, надежность, дешивизна и простота при ОЧЕНЬ содержательной работе программ. Такие системы, как ЛокОФФИС, не имеют до сих пор графического интерфейса, и он не особо им нужен. Их "изюм" совсем в другом: в интегральной технологии работы с данными, в уникальных моделях экономических процессов, в возможности для владельца предприятия несколькими нажатиями кнопок выяснить, кто, где и что у него ворует... Все эти АБСТРАКТНЫЕ рассуждения про "аппетиты" ровно ничем не обоснованы и не подтверждаются практикой. Системы типа ЛокОФФИС хорошо работают на 386-х! Им не нужен никакой "пентиум". ТОЧНО ТА ЖЕ картина наблюдается и на развитом западном рынке, где одна из лучших банковских систем -- алфавитно-цифровой SYMBOLS! Разговоры про "повсеместное использование малтимедиа" (IMHO) всего-лишь модное пижонство программистов, которых быстро "поставят на место" заказчики и плательщики денег. Они АБСОЛЮТНО ПРАВЫ, требуя за свои деньги не ТУПОГО использования сверхмощных и дорогих машин на БЕЗДУМНЫХ и ПРОСТО ПРИМИТИВНЫХ "моделях" экономической деятельности, заменяющих живую мысль разработчика ломовой скоростью процессора, а УМА, ЗНАНИЙ, ОПЫТА и ВЫДУМКИ от программистов, реализующих систему так, чтобы она хорошо работала ВЕЗДЕ! >> Если для получения нового отчета приходится изменять постановку задачи, > [...] >> прототипов. Скорее, очень мало удачных МОДЕЛЕЙ экономической деятельности, >> опираясь на которые только и можно писать программы, работа с которыми >> действительно сведется к генерации новых справок и рисованию форм. > > Так, но не совсем - потому как эти требования - принципиально внешние, > а фантазия у Центробанка, налоговой и пр. поистине удивительна и неисчерпаема. > Чаще всего они требуют задним числом данные, которые просто взять неоткуда. > Как это в принципе можно учесть при проектировании? Если данных ПРОСТО нет, их можно только придумать "задним числом". Если данные СКРЫТЫ, неявно содержатся в существующей базе, нужно просто написать процедуру их вычисления -- разовую или многократную, избегая по-возможности радикальных переделок всей системы. Личный пример. В 1995 я написал систему торговли деньгами (дилинга) для АПР-Банка. За два года ЦБ, например, пять раз поменял форматы файлов платежей и правила работы с реквизитами. Ну и что? Как только я понял, что у ЦБ это в обычае, модуль генерации платежей был специально реализован как генератор "виртуального выходного файла". В реальный этот файл превращает маленькая утилита объемом в две страницы тупого текста (перестановки и форматирование полей данных). Теперь шараханья ЦБ обычно вызывают необходимость переписать только эту утилиту. И уж никак не "перепроектирование системы". Последним я как раз сейчас занимаюсь, но совсем по другому поводу: мои банкиры наконец "дозрели" до внутреннего понимания сути собственных банковских процессов и через два года работы системы, после хаотического "напихивания" туда груды возможностей, появилась наконец возможность КОРРЕКТНО ПОСТАВИТЬ исходную задачу. В АПР-Дилинг периодически добавлялась разнообразная аналитика, чтобы удовлетворить и налоговые ограны, и аудит, и ЦБ. Никто из них ни разу не ушел обиженным. И из-за таких справок в систему не было внесено НИ ОДНОГО существенного изменения. Просто нужно знать, что и зачем делаешь. Нужно немного профессионализма... Только и всего... Ж-)) >> Тут у Вас не случайное недопонимание. Тут Вы отрицаете наличие ПРИНЦИПОВ >> ЗАПРЕТА: законов природы, ЗАПРЕЩАЮЩИХ надеяться на то, например, что >> компьютерный перебор когда-нибудь станет эффективнее человеческого мышле- >> ния (НЕПЕРЕБОРНОГО, ИНТЕГРАЛЬНОГО, ИНСАЙТНОГО в принципе). Компьютеры >> еще могут УБИТЬ ПЕРЕБОРОМ шахматы за счет роста производительности. Но >> ДУМАТЬ они не смогут НИКОГДА. > > Я бы такие заявления делать не рискнул. Если мы когда-нибудь сможем > смоделировать функционирование нейрона (молекулы, атома), то и функционирование > мозга в целом МОЖНО смоделировать и на наших Фон-Неймановских компьютерах > (делать этого, конечно, не стоит - ресурсов не хватит, однако ;-) Вот я и говорю: Вы принципиально не признаете разницы в ДЕСЯТКИ ПОРЯДКОВ уровня сложности между молекулой (атомом) и мозгом. Чтобы моделировать КАК-НИБУДЬ, ДАЖЕ ПРИНЦИПИАЛЬНО И ОЧЕНЬ УПРОЩЕННО работу мозга, нужно как минимум ПОНИМАТЬ, как он работает. Сегодня этого НЕ ПОНИМАЕТ НИКТО! Что Вы собираетесь "моделировать" на фон-неймановских машинах? Это незнание? И каких "ресурсов" для этого сегодня "не хватает"? Может быть, ЧЕЛОВЕЧЕСКОГО УМА (а не скорости процессоров)? Уважаемый Алексей! "Моделировать" можно ТОЛЬКО то, что знаешь и понимаешь. "Моделирование" того, чего не понимаешь, называется БЛУЖДАНИЕМ! И не имеет отношения к реальному знанию. А есть просто метод для ленивых умом обмануть самого себя, "поручив" компьютеру "компенсировать" собственную бесталанность. Еще никто ни разу ничего этим методом не открыл. Ни с помощью компьютеров, ни без них. Подобные забавы -- любимое занятие в ИИ. А весь результат ИИ -- понимание его собственной бесперспективности. И насчет принципов запрета. Верю, что они ЭМОЦИОНАЛЬНО трудны для восприятия. Но есть релятивистский предел скорости света -- 300 000 км/с. Есть физиологическое ограничение внимания человека -- 12-14 чанков. Есть диаметр Земли. Есть средний радиус орбиты Луны. Есть много других ФУНДАМЕНТАЛЬНЫХ ПАРАМЕТРОВ БЫТИЯ, серьезные изменения которых либо невоз- можны, либо приведут к гибели существующего мира и повлению какого-то совсем иного, НО СО СВОИМИ СОБСТВЕННЫМИ ОГРАНИЧЕНИЯМИ! От того, что Вы не желаете признавать наличия стен в комнате, где живете, стены совсем не исчезнут. Просто пострадает лоб при попытках через них ходить. Мне не хочется углубляться в эту тему, но замечу, что ОСОЗНАНИЕ и ПРИЗНАНИЕ ограничений есть БОЛЕЕ ФУНДАМЕНТАЛЬНОЕ свойство реального знания, чем порождаемый этим осознанием и признанием поиск способов "преодолеть" указанные ограничения тем или иным образом: например, выяснением факта существования дверей или разбором соломенной крыши дома... > И если мне ограничения аппаратной части диктуют выбор инструмента > ПРОГРАММИРОВАНИЯ, то самая замечательная постановка на замечательной машине > теорий даст мне не более, чем тот же руками заполняемый ... > Вы что-нибудь здесь предлагаете? > Вот, оказывается, основной интересующий меня вопрос. Предлагаю. Заниматься не выбором hardware, а потом лимитированного аппаратурой software, или аналогичными обратными манипуляциями, а серьезным анализом СОДЕРЖАНИЯ решаемой задачи. В результате происходит обычно одна из двух вещей: 1. Выявляется, что задача на самом деле непонятна решающему и постановщику. В исходной постановке и требованиях есть логические противоречия. В таком случае заниматься отношениями hardware/software есть глупость, а умность состоит в ДОСТИЖЕНИИ должной полноты понимания и логической непротиворечи- вости постановки. В подавляющем большинстве проектов причиной неэффективнос- ти является элементарное непонимание того, ЧТО требуется делать, и связанная с этим НЕВОЗМОЖНОСТЬ сделать ХОТЬ ЧТО-ТО действительно "хорошо". Поэтому ВСЕ, что делает программа, она делает "плохо". 2. Если все же удается сформировать логически связную теорию в рамках модели, то ТРАНСЛИРОВАТЬ алгоритмы модели из формы ТР в коды целевой машины (хоть на ассемблер) есть техническая процедура, АВТОМАТИЗМ, ГАРАНТИРУЮЩИЙ ПРЕДЕЛЬНУЮ ЭФФЕКТИВНОСТЬ (см.Хамби). Если в результате решение ВСЕ РАВНО "неэффективно", то опять же глупо винить в этом hardware/software, а требуется строить альтернативную теорию с БОЛЕЕ ЭФФЕКТИВНЫМИ АЛГОРИТМАМИ, базирующимися, естественно, на более глубоком понимании СУТИ решаемых проблем. Итогом такой деятельности является убеждение, что достигнутое состояние понимания проблемы есть предельно возможное сегодня, а получаемые на его основе алгоритмы -- максимально эффективные. Вот на этом этапе и возникает проблема hardware, причем hardware выбирается не наобум, а под эффективность полученной реализации! Нужен PC XT -- можно работать и на 286. Требуется Cray-2 -- не следует обманывать никого (включая себя), что завтра случится чудо. Чуда, вероятно, не будет, даже если завтра появится Cray-4. Чудо будет, если завтра появится НОВАЯ ТЕОРИЯ изучаемого явления, ведущая к простым и эффективным алгоритмам. Кстати, заказчики очень разумно относятся к ОБОСНОВАННЫМ таким образом оценкам качества требуемого hardware и, обычно, либо покупают требуемое, либо просто отказываются, но не лично от Вас (Вас благодарят за предотвращение излишних трат!), а от заведомо неприемлимой постановки. Обычно "сужением" и "облегчением" постановки удается добиться даже в такой ситуации весьма эффективных, хотя и "частичных" решений, но вполне устраивающих заказчика, понимающего, что сегодня это -- предел возможного. > >> Еще по тексту (до меня не дошла часть 1) > > > > Могу выслать ее Вам на адрес. > > Если не трудно! Высылаю параллельно со своим ответом. > > > 3. Состояние моей работы таково, что сегодня я могу пользоваться ею > > только сам -- это не "товарный продукт", а набор разнопестрых > > Что мешает довести до товарного продукта? Если честно, высказанные > здесь Вами ИДЕИ, ИМХО, наиболее интересны за все время существования > конференции. Может быть, стоит поднапрячься, привлечь тех же "кодировщиков" > для придания товарного вида? Может быть, стоит и запатентовать что-то > побыстрее. А есть ли что у буржуев на эту тему? Дело не только в том, чтобы все это закодировать. В коде мне помощники не особенно нужны, поскольку сейчас я и сам довольно легко пишу программы и в 50 000 строк объектного кода, и в 100 000, и в 150 000... А это больше объема, требуемого для реализации машины теорий. Дело в нехватке времени для обдумывания, "связывания" множества идей в непротиворечивый единый организм. Здесь также многое уже сделано, но, естественно, есть и проблемы. Например, хотелось бы иметь более эффективные методы поддержки редукции/декомпозиции, чем может дать тупое "разрезание" полного пространства состояний задачи на варианты с ручной "выбраковкой" "мертвых комбинаций". Алгоритмически эта задача проработана довольно плохо. Еще, конечно, есть пробелы в понимании методов организации смены поколений понятий тезауруса. Только в общих идеях состоит пока математический анализ получаемых моделей на предмет выявления, например, структурного подобия или изоморфизма моделей. Что есть, по сути, выявление ГЕНЕТИЧЕСКОГО КОДА ОБЩИХ ЗАКОНОВ ПРИРОДЫ, проявляющихся, возможно, в самых содержательно отдаленных друг от друга предметных областях (тут вспоминается работа А.А.Богданова начала 20-х по общей тектологии)... > Я вот в первый раз с Вашей помощью задумался об этом, и мне тема кажется > достаточно большой и перспективной. Тем более, что у Вас за плечами много лет > опыта. Если я могу быть чем-то полезен... ;-) Если у меня получится мой ближайший проект, делаемый ради денег, то следующим шагом я сделаю первую "товарную" версию машины теорий. А затем хочу сделать что-то вроде закрытой корпорации, которая будет производить для ВНЕШНЕГО потребления, как товар, НЕ такие машины теорий, а РЕЗУЛЬТАТЫ их использования: модели, знания, экспертные системы и т.п. Внутри фирмы будут разрабатываться и использоваться технологии, не "выпускаемые" наружу, ИСКЛЮЧИТЕЛЬНО для внутреннего потребления. Это должно обеспечить первичное накопление денег и на специальный Компьютерный университет, и на специальный городок для способных программистов со всей страны (вроде Редмонда, где расположен Microsoft), и на многое другое. Лично я сам не слишком жадный человек и деньги для меня всего-лишь способ сделать что-то стоящее... Если у меня начнет это получаться, мне придется привлекать к этому много людей, разделяющих подобные идеи. Если Вас это ТОГДА заинтересует, то отчего бы и нет... > С уважением, Алексей Донской Всего наилучшего! A.S. P.S. Извините за задержку ответа. Я действительно сейчас ОЧЕНЬ занят. From chci!deity!deity.chci.chuvashia.su!L-relcom Wed May 20 09:47:36 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Wed, 20 May 1998 09:47:36 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA20776; Wed, 20 May 1998 02:38:24 +0400 Received: by deity.chci.chuvashia.su id BAA11991; (8.6.12/vak/1dot9) Wed, 20 May 1998 01:37:53 +0400 To: subscribers@deity.chci.chuvashia.su From: "Michael V. Tokarev" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Tue, 19 May 98 22:21:57 +0400 Distribution: su Organization: Private Domain Message-ID: Reply-To: michael@tokareff.pgu.karelia.su References: X-Return-Path: michael@tokareff.pgu.karelia.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 101 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 5345 Status: RO Добрый день! > > Могу сказать только одно -- лет 5 назад мы писали встроенные программки > > на Форт-ориентированном языке. > > и припомнив Ваши прошлогодние слова, что "Форт не так эффективен, как > хотелось бы", мне захотелось повторить прошлогодний вопрос, на который так > и не получил ответа: если Вас сильно не затруднит, поделитесь опытом и > набросайте в нескольких пунктах достоинства и недостатки Форта; напишите, > почему Вы от него все же отказались? Алексей, если мне не изменяет память, я ответил на все твои вопросы. Если нужно -- черкни -- я поищу в архивах мои перлы. Вкратце могу повторить для обчества. 1. Про "Форт не так эффективен как хотелось бы". Это несколько выдернуто из контекста. А общий смысл был следующий: Форт помогает писать очень компактные и устойчивые программы. И ему трудно найти замену в embedded software (встроенных программах). С++ -- даже рядом не валялся. (Расскажу байку про одного моего студня -- дело было очень давно и С++ был писком моды. Мы имели некоторую дискуссию с ним, в которой я утверждал, что ассемблер очень хороший язык особенно для железных применений (к тому же в не зависимости от моды и т.п.), на что он возражал, что на С++ сделать все тоже самое намного легче. Но ведь он же компилит громадный исходник -- защищался я. На что он РЕЗОННО возразил, что если разобраться, то при компиляции С++ можно отключить все ЛИШНИЕ библиотеки и процедуры, а если приспичит, то и прямо писать на ассемблере. Простите, а на кой же черт он тогда сдался, если я сидя в нем могу писать на Ассемблере? На кой черт он нужен со всеми библиотеками, если их надо отключать? В 1987 году я первый раз сел Ассемблерить на Правце. Тогда не было никаких ДОК, никаких ИНетов (в России). Для того, чтобы хоть в чем-то разбираться пришлось реассемблировать BIOS. Так вот -- спецы знают (теперь уже) что программа рисования графической точки в BIOSе может занимать до 1000 байт и больше. (потому что она должна быть УНИВЕРСАЛЬНА). И любой школьник сегодня может написать подобное же (правда, менее унисерсальное) программой в 10 байт. Так вот -- это и есть коренное отличие универсального С++ и ему подобного от Ассемблера и Форта. О, как я долго подводил вас к мысли о Форте. Все слышали о сегодняшней Java. Форт -- это тоже самое, только более компактное, красивое и логичное. Это простой интерпретатор команд. На ассемблере интерпретатор реализуется десятком строк общей длиной байт 20-50 -- просто инкрементация адресного регистра. А теперь об эффективности. Вспомните Альтшуллера (ТРИЗ) : наиболее _эффективен_ именно _простейший_ механизм (может я чуть переврал слова, но мысль такая). Один из немногих ФОРТ-недостатков -- это его недоработанность (как и всех почти Российских компиляторов-трансляторов) до маркетингового уровня в связи с "избыточным" финансированием. А вообще есть страшно хорошая книжка Баранова Сергея Николаевича (автора НЕ одной реализации Форта) и Ноздрунова Н.Р. Язык Форт и его реализация., Л.-Машиностроение, 1988 г. 2. Еще недостатки. Если к недостаткам относить обратную * польскую запись, то грошь цена таким программистам. * Может быть несколько более медленная скорость выполнения программы по сравнению с подобной на ассемблере, так как при интерпретации происходит постоянная передача управления из проц. в процедуру (каждая операция присутствует в исходнике только один раз -- то есть не делается макроподстановок, что и замедляет в известной степени выполнение программы). Однако стоит затащить ядро в оперативку (оно ведь маленькое) и скорость возрастет на порядки -- ядро в ОЗУ, исполняемый код там же. * Не видел я в последнее время реализаций Форта на НТ и Вин95, но это же смешной недостаток. Как только ты его там реализуешь, ты убьешь его основные достоинства : 3. Эффективность, контроль (динамический и статический) типов, а следовательно устойчивость, встраиваемость, переносимость (ядро-то малюсенькое), расширяемость (тут он всех переплюнул, наверное), синтаксис языка (его можно придумать любой -- хоть смесь иврита и китайского, если захочется -- на конечном исходнике это никак не скажется). В последнем потребуется немного пояснений, probably. Если я создаю новую процедуру на любом языке, я сразу получаю весомую прибавку в размере исходника, во времени вызова этой процедуры и т.п. На Форте же -- новая процедура реализуется просто другим смещением (инкрементом) при интерпретации, и самое КРАСИВОЕ (именно это слово), что алгоритм интерпретации при этом тот же что и при линейном исполнении. Но самое главное во всем этом, что я ведь не Фортист, а почти посторонний человек (почти, потому что мне удалось подсмотреть алгоритм интерпретации и я ЗАТАЩИЛСЯ -- другое слово трудно придумать) и я писал на нем года 4 всего и было это 10 лет назад. 4. Почему мы от него отказались. Баранов от Форта, насколько мне известно, не отказался, как ни тяжело ему было. В нашей компании под руководством доцента Котлярова Всеволода Павловича задумки эти остались -- просто рынок нас сделал немножко нищими (и это хорошо, наверное, но не для чистой науки). Пришлось кормиться на стороне. Ведутся ли сегодня там разработки какие-никакие -- не знаю. Что еще надо -- спрашивайте. Не обещаю быстрого ответа, правда. Michael V. Tokarev, PhD. From chci!deity!deity.chci.chuvashia.su!L-relcom Wed May 20 09:47:37 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Wed, 20 May 1998 09:47:37 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA20784; Wed, 20 May 1998 02:38:25 +0400 Received: by deity.chci.chuvashia.su id BAA12001; (8.6.12/vak/1dot9) Wed, 20 May 1998 01:37:54 +0400 To: subscribers@deity.chci.chuvashia.su From: "Michael V. Tokarev" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Tue, 19 May 98 22:28:54 +0400 Distribution: su Organization: Private Domain Message-ID: Reply-To: michael@tokareff.pgu.karelia.su References: <6jorv8$bo0$1@nnrp1.dejanews.com> X-Return-Path: michael@tokareff.pgu.karelia.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 47 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 1733 Status: RO Hi! > In article , > michael@tokareff.pgu.karelia.su wrote: > > > > Hi! > > > > Я не стал приводить всей ругани на С++. > > > > Могу сказать только одно -- лет 5 назад мы писали встроенные программки > > на Форт-ориентированном языке. > > Ядро 50 кило. > > И самая большая программка, которая у меня получилась занимала менее > > 100 кило, а занималась она управлением взлета/посадки > > в аэропорту со всеми связями со всем оборудованием. > > Оговорюсь, что это был прототип сисстемы, но если бы я его рискнул > > нарисовать на С++ (или даже на С) он бы вылез далеко за мегобайт. > > Программулька-то была посложнее MS OFFICE. > > Вопрос 1. Это было бы быстре сделано на С++? Конечно и безусловно. Ведь там пол-мира писали библиотеки. А если их стереть? И существенным здесь является слово "сделано". Потому что отладить этого монстра на С++ я бы не взялся ни за какую зряплату. Там же сплошное реальное время и взаимодействие железяк с программой и друг другом. > Вопрос 2. Это было так же просто сопровождать, как программы на С++? Однозначно ДА! > Вопрос 3. Что это за язык и какого его теперешнее состояние? Смотри статью рядом. > > А попробуйте встроить монстра типа офиса в микросхему!!!??? > > Даже при сегодняшних технологиях это заняло бы дециметр кубический. > > Вот Жаба вроде-бы тудыть влезает. Что кто может по этому поводу сказать? В соседнем письме я и по ее поводу высказался -- но чуть-чуть повторюсь. Жаба это универсальный монстр. Поэтому любить ее можно (как и все большое -- слова из кинофильма "Вам и не снилось"). А в embedded soft -- никогда. Michael V. Tokarev, PhD. From chci!deity!deity.chci.chuvashia.su!news-service Thu May 21 10:26:21 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Thu, 21 May 1998 10:26:21 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA02709; Wed, 20 May 1998 22:38:20 +0400 Received: by deity.chci.chuvashia.su id VAA04307; (8.6.12/vak/1dot9) Wed, 20 May 1998 21:36:18 +0400 To: subscribers@deity.chci.chuvashia.su From: druchin@bn3000.dd.vaz.tlt.ru (Serge I.Droutchin) Newsgroups: relcom.comp.software-eng Subject: [News] Re: Re: My Language Right or Wrong ;) Date: Wed, 20 May 98 13:52:49 -0400 Organization: General Department of Development, AutoVAZ Distribution: su Message-ID: References: Reply-To: druchin@bn3000.dd.vaz.tlt.ru NNTP-Posting-Host: aa3000.dd.vaz.tlt.ru Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 122 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 5079 Status: RO >From: "Michael V. Tokarev" >> и не получил ответа: если Вас сильно не затруднит, поделитесь опытом и >> набросайте в нескольких пунктах достоинства и недостатки Форта; напишите, >> почему Вы от него все же отказались? > >Алексей, если мне не изменяет память, я ответил на все твои вопросы. Подтверждаю, год-полтора назад это все было ;-) Наверняка и в моих архивах есть ;) [помню, было...] >А теперь об эффективности. Вспомните Альтшуллера (ТРИЗ) : >наиболее _эффективен_ именно _простейший_ механизм (может я чуть переврал >слова, но мысль такая). И наиболее _надежен_ >А вообще есть страшно хорошая книжка Баранова Сергея Николаевича >(автора НЕ одной реализации Форта) и Ноздрунова Н.Р. >Язык Форт и его реализация., Л.-Машиностроение, 1988 г. Точнее сказать, нашпигованная идеями, как хорошая колбаса -- шпиком ;) большинство из которых прошли суровую проверку парактикой, временем, и имеют научно-теоретическое обоснование. Баранова знают и видные зарубежные фортисты. >2. Еще недостатки. Если к недостаткам относить обратную >* польскую запись, то грошь цена таким программистам. >* Может быть несколько более медленная скорость выполнения программы по сравнению с ассемблером [помню, было...] Дело еще и в том, что какой-нибудь драйвер -- невелик по размеру, и достаточно ясно что и как он должен делать. Здесь именно с ассемблером конкурировать трудно. Но стоит программе слегка увеличить размер, как сложности начинают возрастать в удивительно быстрой пропорции. В форте управлять сложностью легче (_потенциальная_ возможность!) и в какой-то момент программа становится компактнее ассемблерной и быстрее выполняющейся 8-0 Не говоря об относительной простоте модернизации и локализации вносимых изменений (эффект затухания). >* Не видел я в последнее время реализаций Форта на НТ и Вин95, >но это же смешной недостаток. Как только ты его там реализуешь, >ты убьешь его основные достоинства : Win32Forth Тома Зиммера (Циммера), SP-F Андрея Черезова. Это не коммерческие. Есть и мощные коммерческие пакеты, оснащенные кросс-компиляторами, что дает любопытную тенденцию: люди писали софт для разных железяк сначала под дос, потом под 3.ХХ, теперь под 95/NT и даже Linux, при этом они работали в привычной предметной области, независимо от изменений в инструментальной платформе. Есть еще одно изумительное ню, упускаемое очень многими даже приверженцами форта: принцип замены сложения умножением. Форт дает возможность мультиплицировать понятия, так же, как это делает обычное человеческое сознание. : База центр передней оси центр задней оси расстояние ; и уже я могу говорить просто о Базе, как о термине, я могу эту базу подставлять в расчетную модель с чертежа, это как бы неделимое понятие. Так по кусочкам можно собрать модель автомобиля, с любой необходимой степенью проработанности нужного участка. Интересно еще и то, что приведенное мной "определение слова" на форте может быть совершенно реально и выглядеть именно так, т.е. это не прототип, а "кусок кода" На форте можно очень легко получать уровень абстракции очень высокий, по сути, описав предметную область, вы получаете возможность моделирования -- как бы автоматически. Подобрав параметры модели, можно определить узкие места в эффективности, если это требуется, и расшить их на ассемблере, зачастую являющемся частью форт-системы. Еще один аспект -- описав-определив предметную область, вы даете в руки специалисту прикладнику язык управления моделированием или ЯУ заданиями (например испытаниями). Далее он может самостоятельно ставить и решать задачи предметной области. Конструкции управления могут быть реализованы такими, какие только могут прийти в вашу голову ;) т.е. никаких принципиальных ограничений! И наконец, у вас есть выбор -- оставить интерпретацию и получить машиннонезависый или ОС-независимый исполнямый код, или целевая компиляция в машинные команды родного процессора. Подходы к проектированию тоже диктует, в общем-то не язык, а та методология, которой вы намерены придерживаться... хотя у форта есть "своя методология", но это достаточно специфично и нимало не похоже на то, к чему здесь привыкли ;) Я сейчас не готов сформулировать отчетливо, в чем же эта методология состоит, это еще бродит внутри ;) часть ответов можно найти в бестселлере Броуди "Думаем на форте" (есть оригинал "Thinking Forth", есть русский перевод в виде компьютерного текста) [помню, было...] >4. Почему мы от него отказались. >Баранов от Форта, насколько мне известно, не отказался, >как ни тяжело ему было. В нашей компании под руководством >доцента Котлярова Всеволода Павловича задумки эти остались -- [...] >Ведутся ли сегодня там разработки какие-никакие -- не знаю. Насколько я знаю, Гассаненко Михаил в прошлом году успешно защитился, и вроде даже публикуется время от времени ;) в Форт Дименшнз, самого С.Н. не достать -- стало быть работают ;) и это хорошо... Вот пока и все, с уважением, Дручин Сергей. From chci!deity!deity.chci.chuvashia.su!news-service Thu May 21 17:11:06 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Thu, 21 May 1998 17:11:06 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA16520; Thu, 21 May 1998 16:43:15 +0400 Received: by deity.chci.chuvashia.su id PAA14784; (8.6.12/vak/1dot9) Thu, 21 May 1998 15:41:19 +0400 To: subscribers@deity.chci.chuvashia.su From: "Alexey Donskoy" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Re: My Language Right or Wrong ;) Date: Thu, 21 May 98 15:01:39 +0400 Organization: XSN Ltd. Message-ID: <6k1294$e6r@deity.chci.chuvashia.su> References: NNTP-Posting-Host: ipchavb.chuvashia.su X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 80 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 3784 Status: RO Serge I.Droutchin (druchin@bn3000.dd.vaz.tlt.ru) wrote: > >А теперь об эффективности. Вспомните Альтшуллера (ТРИЗ) : > >наиболее _эффективен_ именно _простейший_ механизм (может я чуть переврал > >слова, но мысль такая). > > И наиболее _надежен_ ИМХО, ключевые слова для прогресса CASE! > В форте управлять сложностью легче (_потенциальная_ возможность!) Расскажите подробнее об управлении _немаленьким_ проектом на Форте! Как бороться с размерами словарей, как найти, что уже сделано, в какой степени и каким образом, чтобы не приходилось почти дублировать слова и потом путаться в синонимах. Есть ли какие методики, пригодные для _промышленного_ производства софта на Форте? > короче ассемблерной и быстрее выполняющейся 8-0 > Не говоря об относительной простоте модернизации и локализации > вносимых изменений (эффект затухания). Ok! > Win32Forth Тома Зиммера (Циммера), SP-F Андрея Черезова. Видел в инете (может быть, не то и не там?) - пакеты годовой давности, ограниченной функциональности, с лицензией, запрещающей коммерческое использование... > Это не коммерческие. Есть и мощные коммерческие пакеты, > оснащенные кросс-компиляторами, что дает любопытную тенденцию: Где, почем, что могут, перспективы? > Форт дает возможность мультиплицировать понятия, так же, как > это делает обычное человеческое сознание. Ok! > Подходы к проектированию тоже диктует, в общем-то не язык, > а та методология, которой вы намерены придерживаться... > хотя у форта есть "своя методология", но это достаточно > специфично и нимало не похоже на то, к чему здесь привыкли ;) Вот сравнение SM vs UML мы все еще ждем от Рудовича, а не мог бы кто-нибудь провести сравнение методик, использованных в проектах на Форте, и SM? > часть ответов можно найти в бестселлере Броуди "Думаем на форте" > (есть оригинал "Thinking Forth", есть русский перевод в > виде компьютерного текста) Весьма любопытная книга, но "недостало пороху" (ИМХО!) при очень интересном начале Броуди на всем протяжении книги сбивается на то, что в SE именуется "кодированием" и теоретической ценности с точки зрения проектирования не представляет. Полкниги ушло на несущественные особенности реализации Форта, на архаичные блоки и пр... Попробуем сформулировать требования к (скажем так) среде проектирования, которуб мы хотели бы иметь (к идеальному CASE-средству ;-): - поддержка всего цикла разработки вплоть до генерации кода (+переносимость, платформонезависимость); - простой и надежный механизм редукции сложности в фундаменте (Форт + модифицированные таблицы решений Седова?) - иерархическая (?) модель проекта (SM? Форт?) - поддержка различных методик проектирования (визуальное представление и работа с "табличной" метамоделью в виде графов, диаграмм, формул, SQL, ЯВУ... то есть проекция метамодели в те же диаграммы и пр. - хотим - работаем с диаграммами, хотим - с деревом классов, хотим - выстроим те же классы в иерархию по другому критерию...); - гарантия полноты разрабатываемых моделей: а) транзакционность всех изменений; б) автоматическая проверка полноты; б) доступность и удобство работы с "таблицами перекрестных ссылок" и пр. информацией о структуре и взаимных зависимостях; - поддержка версионности и вариантности (условная компиляция, параллельное ведение нескольких вариантов, отличающихся по функциональности); - средства RAD для интерфейсов; - развитые средства связи с внешним окружением: а) возможность использования DLL; б) компоненты Delphi; в) Active-X и все такое прочее... ... ...) API к базам данных, Вебу, сетям и другим пргограммам... С уважением, Алексей Донской -- E-mail: alek@chavb.chuvashia.su ! http://www.chuvashia.su/timer From chci!deity!deity.chci.chuvashia.su!L-relcom Thu May 21 17:11:09 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Thu, 21 May 1998 17:11:08 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA17171; Thu, 21 May 1998 17:43:16 +0400 Received: by deity.chci.chuvashia.su id QAA15406; (8.6.12/vak/1dot9) Thu, 21 May 1998 16:41:39 +0400 To: subscribers@deity.chci.chuvashia.su From: "Alexey Donskoy" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Thu, 21 May 98 15:37:04 +0400 Organization: XSN Ltd. Message-ID: <6k14bj$ein@deity.chci.chuvashia.su> References: NNTP-Posting-Host: ipchavb.chuvashia.su X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 152 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 8015 Status: RO Добрый день! (Пардон заранее, если это сообщение появится повторно - у наших с ньюсами проблемы. Посылаю с другого адреса, для переписки просьба использовать alek@chavb.chuvashia.su). Michael V. Tokarev отписал в конференцию: > Алексей, если мне не изменяет память, я ответил на все твои вопросы. > Если нужно -- черкни -- я поищу в архивах мои перлы. Если не трудно - похоже, мыло до меня не доехало :-((( Ньюсы тоже %-[ > Вкратце могу повторить для обчества. > 1. Про "Форт не так эффективен как хотелось бы". > Это несколько выдернуто из контекста. > А общий смысл был следующий: Форт помогает писать очень компактные > и устойчивые программы. И ему трудно найти замену в embedded software Верно. И в чипах графических плат он же используется. --------------------------------------------------------------------- : Однако хотелось бы рассмотреть возможность его применения сегодня: : в "коммерческом софте общего назначения". И с точки зрения SE. : --------------------------------------------------------------------- > Мы имели некоторую дискуссию с ним, в которой я утверждал, что ассемблер > очень хороший язык особенно для железных применений Каюсь, на том же погорел - недооценил Форт лет 10 назад... > Все слышали о сегодняшней Java. > Форт -- это тоже самое, только более компактное, красивое и логичное. Разве Java не к Си ближе? > Это простой интерпретатор команд. Сильно зависит от реализации. В упомянутых Вами книгах рассматриваются разные виды шитого кода - адресный, подпрограммный. Однако, можно посмотреть и шире (такого подхода еще не встречал): Что есть Форт? - АРХИВАТОР АЛГОРИТМА (c) мой. Выкинув из рассмотрения всякие примитивные dup/drop, отвращающие от него новичков, видим иерархию, похожую на LZ-словарь. Если будем, по совету его классиков, мыслить маленькими словами, включающими в себя от 3 до 8 прочих слов, получим максимальную степень сжатия. Но можно и развернуть весь код полностью в линейный. Можно также сгенерировать из него любой другой код, например опять же Сишный. Но это, ИМХО, не обязательно. У Форта есть еще одно интересное свойство - использовав где-то некоторое слово из словаря, меня не волнует, процедура это или переменная. Главное, чтобы соблюдался интерфейс передачи параметров. > Один из немногих ФОРТ-недостатков -- это его недоработанность > (как и всех почти Российских компиляторов-трансляторов) до маркетингового уровня Пардон, Форт не в России изобретен! > в связи с "избыточным" финансированием. К сожалению, доступные реализации Форта являют собой рай для хаккера и маниакально одержимого кодера. Там нет ничего. Нет ни ODBC, ни GUI, ни CORBA ;-) Что и отвратило меня от него в самом начале. Сколько видел лежащего в Инете, все какое-то сырое и велосипедистое... Тут коллеги даже мнение высказывали, что так и будет, поскольку военные его монополизировали из-за эффективности. А нам - M$ ;-( > 2. Еще недостатки. > * Может быть несколько более медленная скорость выполнения программы См. выше. Никто не мешает "развернуть" код до нужного баланса размера/ эффективности, построив компилятор, разворачивающий вызываемые слова как макроподстановки. Мой коллега, например, как промежуточное решение, просто ввел некий порог - глубину "макроподстановки". > * Не видел я в последнее время реализаций Форта на НТ и Вин95, > но это же смешной недостаток. Как только ты его там реализуешь, > ты убьешь его основные достоинства : Почему? Подробнее! > 3. Эффективность, контроль (динамический и статический) типов, где там контроль типов? нет его там, поэтому он потенциально ошибкоопасен и назвал я его выше раем для хаккера (это ИМХО, буду рад опровержению!). > а следовательно устойчивость, встраиваемость, переносимость переносимость? Исходя из требований "коммерческого софта общего назначения", надо иметь поддержку GUI, API к стандартным сетевым средствам и базам данных, а вот всего этого и нет... > 4. Почему мы от него отказались. > Баранов от Форта, насколько мне известно, не отказался, Коммерческие результаты каковы? (Тут Сергей Дручин уже упоминал о состоянии дел, но очень кратко. Где есть коммерческие версии Форта, почем и что могут?) > Пришлось кормиться на стороне. Вот про то и речь. Надо нам софт под MS - берем какой-нидь RAD типа Delphi. Надо бухгалтерию - Access для маленькой и MS SQL для большой (или те же Дельфы). Быстрее и дешевле получается. Т.е., мы остаемся рабами рынка и заложниками технологического уровня общества... И ставим крест на ранее достигнутом (ассемблер, Форт, математика ;-) > Что еще надо -- спрашивайте. Как Вы ориентировались в упомянутом проекте - там ведь словарь должен был разрастись до неоглядных размеров? Как в каждом конкретном случае Вы вспоминали - есть ли уже такое слово, и насколько такое, и не путались при этом в синонимах? Как проектировался этот проект? Вообще очень было бы разумно использовать сам механизм его словаря для упорядочивания структуры проекта. Построить CASE-средство на его основе... Помните прошлогодние выступления Alexey A. Sedov о "Машине теорий"? в relcom.comp.software-eng? К сожалению, моих мозгов, крутящихся вокруг этой темы в свободное от двух работ время, не хватает ;-) Зато я окончательно убедился, что: - кризис в программировании (в т.ч. в моих собственных проектах) имеет место, проекты, правда, вытягиваются, но слишком большой кровью, и это не есть хорошо; - (было время, познакомившись с Паскалем, мне стало психологически трудно работать на Фортране - исключительно из-за такой мелочи, как необязательность объявления переменных, что провоцирует ошибки) - даже если рассмотреть только сам процесс кодирования, то в сколько-нибудь нетривиальном случае необходима гарантия полноты всех совершаемых с ним действий (какие-то специфические средства контроля топологии кода + транзакции редактирования); - наименее трудоемким способом разработки является (желательно) полный механизированный (поддерживаемый неким CASE-средством) анализ, который на очередном этапе редукции сложности превращается в код; - механизм такого анализа должен быть максимально прост (что отлично перекликается и с упомянутой МТ ТРИЗ, которая, кстати, так и просится быть примененной в SE); - в основе машинной реализации всего (в т.ч. графа, дерева и пр. топологических конструкций лежит таблица (ссылок), поэтому идея Седова о некоей универсальной таблице решений мне представляется очень простой и плодотворной; - в то же время таблица, как основа реализации, может иметь одно или несколько визуальных представлений, более удобных для восприятия человека, например, те же use-case диаграммы; - Форт дает гениально удобный механизм для описания многосвязного кода, и соединение этого механизма с вышеперечисленным может дать CASE-средство принципиально нового поколения. Однако я никак не могу въехать в это до конца и не представляю, как можно запихать в такую таблицную форму ВСЕ знания о модели. Мне все казалось, что модель надо описывать "наскоками" с разных сторон - одно лучше диаграммой состояний, другое - алгоритмом, третье - деревом и т.д. Седов по этому поводу говорит, что это есть только частичная аналогия реальности и это его не устраивает. Действительно, а) есть проблемы с взаимоувязкой разных сторон, б) при таком подходе нет гарантии полноты анализа. К сожалению, Седов молчит и на письма не отвечает... Боюсь, не заела ли его обыкновенная текучка... Или буржуи на корню купили... Возможно, у кого-то есть свежая информация по этому поводу? Вот еще пытаюсь осилить Шлеер-Меллора (по Инету ;-), похоже, его можно рассматривать как подходящую методику высокого уровня, а те же таблицы решений - как основу (низкого уровня) для некоего тула, использующего в т.ч. того же ШМ. Как же оно все, черт побери, между собой пересекается? -- С уважением, Алексей Донской -- E-mail: alek@chavb.chuvashia.su http://www.chuvashia.su/timer From chci!deity!deity.chci.chuvashia.su!news-service Fri May 22 10:12:01 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Fri, 22 May 1998 10:12:00 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA26859; Fri, 22 May 1998 07:58:15 +0400 Received: by deity.chci.chuvashia.su id GAA06744; (8.6.12/vak/1dot9) Fri, 22 May 1998 06:53:25 +0400 To: subscribers@deity.chci.chuvashia.su From: "Michael V. Tokarev" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Thu, 21 May 98 23:02:02 +0400 Distribution: su Organization: Private Domain Message-ID: Reply-To: michael@tokareff.pgu.karelia.su References: <6ju5ro$ntt$1@nnrp1.dejanews.com> X-Return-Path: michael@tokareff.pgu.karelia.su Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 64 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 2896 Status: RO > > 1. Про "Форт не так эффективен как хотелось бы". > ... > > Так вот -- это и есть коренное отличие универсального С++ и ему подобного > > от Ассемблера и Форта. > ... > > Все слышали о сегодняшней Java. > > Форт -- это тоже самое, только более компактное, красивое и логичное. > > Это простой интерпретатор команд. > > Минуточку. А как же ОО. Ведь это для чего-то нужно ;-) А причем тут ОО? Это просто модная технология -- не более. Серъезные системы на ней не пишут (не кидать камнями). Она нужна также как и традиционные технологии, но для своего круга задач. > > Один из немногих ФОРТ-недостатков -- это его недоработанность > > (как и всех почти Российских компиляторов-трансляторов) до маркетингового > > уровня в связи с "избыточным" финансированием. > > Форт - возможность каждому программисту создать свой язык наиболее для > него пригодный. Но это противоречит промышленному производству софта. > Ты знаешь как решить это противоречие? Элементарно. На производстве существуют стандарты (например ISO). Но никто никого не заставляет, чтобы процесс разработки был стандартизован. Я могу детальку обточить в детских ладошках и она получится большего класса точности, чем тоже самое изготовленное на станке. Главное, чтобы конечный класс точности совпал (или размер, например). Чем я обрабатывал -- никого не касается. А производительность труда -- дело каждой фирмы в отдельности -- в одной русский пишет на своем языке, в другой немец (на английском). > > 4. Почему мы от него отказались. > > Баранов от Форта, насколько мне известно, не отказался, > > как ни тяжело ему было. В нашей компании под руководством > > доцента Котлярова Всеволода Павловича задумки эти остались -- > > просто рынок нас сделал немножко нищими (и это хорошо, наверное, > > но не для чистой науки). > > Пришлось кормиться на стороне. > > А можно ли немножко про задумки и перспективы Форта. Что бы было, если...? Угу! На чем остановилась работа, во-первых. Это виртуальные машины. Ну понятно -- свое адресное пространство, свои и общие ресурсы и т.п. Во-вторых, куча проектов военных (тут все ясно без слов). Я вот сейчас вспомнил, что КомФорт был написан первоначально на ДЕСе (ПиСьков тогда еще не было в России). И когда они появились ядро было перенесено на них, по-моему, всего за месяц. Потом пошли крутые доработки новых возможностей, которые были невозможностями не ДЕСе. Это у нас было. К сожалению, я не помню чем занимался Баранов С.Н., кроме самих компиляторов- интерпретаторов. > PS.: Если кто сталкивался со зверем по имени ОБЕРОН, большая просьба > поделиться впечатлениями. Я не сталкивался сам, но на кафедре, где я сейчас читаю свой курс занимались с ним очень плотно и студни и сотрудники. У них у всех есть Емеля, но они все сильно занятые. Michael V. Tokarev, PhD. From chci!deity!deity.chci.chuvashia.su!news-service Fri May 22 10:12:00 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Fri, 22 May 1998 10:12:00 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA26856; Fri, 22 May 1998 07:58:14 +0400 Received: by deity.chci.chuvashia.su id GAA06739; (8.6.12/vak/1dot9) Fri, 22 May 1998 06:53:24 +0400 To: subscribers@deity.chci.chuvashia.su From: "Michael V. Tokarev" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Thu, 21 May 98 23:27:42 +0400 Distribution: su Organization: Private Domain Message-ID: Reply-To: michael@tokareff.pgu.karelia.su References: X-Return-Path: michael@tokareff.pgu.karelia.su Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 131 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 5821 Status: RO > [помню, было...] > >А теперь об эффективности. Вспомните Альтшуллера (ТРИЗ) : > >наиболее _эффективен_ именно _простейший_ механизм (может я чуть переврал > >слова, но мысль такая). > > И наиболее _надежен_ Немаловажное (точнее, строго говря, существенное) дополнение. > >А вообще есть страшно хорошая книжка Баранова Сергея Николаевича > >(автора НЕ одной реализации Форта) и Ноздрунова Н.Р. > >Язык Форт и его реализация., Л.-Машиностроение, 1988 г. > > Точнее сказать, нашпигованная идеями, как хорошая колбаса -- шпиком ;) > большинство из которых прошли суровую проверку парактикой, временем, > и имеют научно-теоретическое обоснование. Баранова знают и видные > зарубежные фортисты. Он ездил в Англию (кажется) писать кому-то компилятор еще в жутко застойные времена. > >2. Еще недостатки. Если к недостаткам относить обратную > >* польскую запись, то грошь цена таким программистам. > >* Может быть несколько более медленная скорость выполнения программы > по сравнению с ассемблером > > [помню, было...] > Дело еще и в том, что какой-нибудь драйвер -- невелик по размеру, > и достаточно ясно что и как он должен делать. Здесь именно > с ассемблером конкурировать трудно. Но стоит программе слегка > увеличить размер, как сложности начинают возрастать в удивительно > быстрой пропорции. В форте управлять сложностью легче (_потенциальная_ > возможность!) и в какой-то момент программа становится компактнее > ассемблерной и быстрее выполняющейся 8-0 > Не говоря об относительной простоте модернизации и локализации > вносимых изменений (эффект затухания). По поводу "быстрей выполняющейся" ты несколько неправ, а вообще откуда ты взялся такой умный :-) Я тут борюсь с кучей брюзжащего народу уже год, а ты почитываешь и посмеиваешься? Ты же все знаешь -- чего молчал? Ну это юмор, а если серъезно: Так вот компактнее -- это мягко сказано даже по сравнению с Ассемблерной (не то что С++ или С--) -- в разы. Быстрей выполняющейся -- неправда (быстрей проектируемой -- это другое дело). Основное время в любом исполнении исходного кода уходит на переходы. В Форте -- это практически каждый шаг. Другой разговор, что он реализован настолько эффективно, что десяток его переходов равен одному переходу в других прогр.технологиях. А простота модернизации и локализация... -- вообще недосягаемы для других языков. И вся сложность при этом -- это построение хорошего компилятора, позволяющего осуществлять сборку модулей со всеми контролями типов и т.п. как можно быстрей, потому что их много. Зато потом наряду с кодами можно хранить доку (на модуль), характеристики, и т.п. в виде таких же объектов как и модули (как сейчас НДС сделан в Твари). Потом это все собирается хоть вместе, хоть по-отдельности (это была задумка Котлярова В.П., претворенная в жизнь его соратниками). > >* Не видел я в последнее время реализаций Форта на НТ и Вин95, > >но это же смешной недостаток. Как только ты его там реализуешь, > >ты убьешь его основные достоинства : > > Win32Forth Тома Зиммера (Циммера), SP-F Андрея Черезова. > Это не коммерческие. Есть и мощные коммерческие пакеты, > оснащенные кросс-компиляторами, что дает любопытную тенденцию: А вот я ничего такого не видел :-( Подождите минутку -- на СДюке запел David F.R. песенку "Words". -- это одно из немногих удовольствий достающихся на долю программера в России. Повторим ее. О-о-о-о -- класс!!!!!! Так, о чем это я? > Есть еще одно изумительное ню, упускаемое очень многими даже > приверженцами форта: принцип замены сложения умножением. Никто этого не опускает -- просто это само-собой разумеющееся (какой ты начитанный товарисч). > На форте можно очень легко получать уровень абстракции очень > высокий, по сути, описав предметную область, вы получаете > возможность моделирования -- как бы автоматически. > > Подобрав параметры модели, можно определить узкие места > в эффективности, если это требуется, и расшить их на > ассемблере, зачастую являющемся частью форт-системы. А если это все помножить на формальные модели-спецификации, которые помогут это сделать, то получится DREAM. > Еще один аспект -- описав-определив предметную область, > вы даете в руки специалисту прикладнику язык управления > моделированием или ЯУ заданиями (например испытаниями). > > Далее он может самостоятельно ставить и решать задачи > предметной области. > > Конструкции управления могут быть реализованы такими, какие > только могут прийти в вашу голову ;) т.е. никаких принципиальных > ограничений! Ну это во многих языках теперь есть -- правда в реализации -- это такие монстры, что лучше с ними не связываться. > И наконец, у вас есть выбор -- оставить интерпретацию и получить > машиннонезависый или ОС-независимый исполнямый код, или > целевая компиляция в машинные команды родного процессора. Аналогично вышеизлежащему замечанию. (возьмите Фокс с его интерпретатором -- его EXEшник просто бесподобен). > >4. Почему мы от него отказались. > >Баранов от Форта, насколько мне известно, не отказался, > >как ни тяжело ему было. В нашей компании под руководством > >доцента Котлярова Всеволода Павловича задумки эти остались -- > [...] > >Ведутся ли сегодня там разработки какие-никакие -- не знаю. > > Насколько я знаю, Гассаненко Михаил в прошлом году успешно защитился, > и вроде даже публикуется время от времени ;) в Форт Дименшнз, > самого С.Н. не достать -- стало быть работают ;) и это хорошо... Они теперь круты!!! И с Мотороллой им повезло, хотя это все опять же заслуга почти исключительно С.Н. > Вот пока и все, с уважением, Дручин Сергей. Чтож ты до сей поры молчал! Michael V. Tokarev, PhD. From chci!deity!deity.chci.chuvashia.su!news-service Fri May 22 10:11:59 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Fri, 22 May 1998 10:11:59 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA26848; Fri, 22 May 1998 07:58:12 +0400 Received: by deity.chci.chuvashia.su id GAA06729; (8.6.12/vak/1dot9) Fri, 22 May 1998 06:53:23 +0400 To: subscribers@deity.chci.chuvashia.su From: "Michael V. Tokarev" Newsgroups: relcom.comp.software-eng Subject: [News] Форт, Комфорт (было: Re: My Language Right or Wrong ;) Date: Wed, 20 May 98 23:44:24 +0400 Distribution: su Organization: Private Domain Message-ID: Reply-To: michael@tokareff.pgu.karelia.su References: <6ju59s$n45$1@nnrp1.dejanews.com> X-Return-Path: michael@tokareff.pgu.karelia.su Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 34 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 1538 Status: RO > > > Вопрос 1. Это было бы быстре сделано на С++? > > > > Конечно и безусловно. Ведь там пол-мира писали библиотеки. > > А если их стереть? > > И существенным здесь является слово "сделано". Потому что отладить этого > > монстра на С++ я бы не взялся ни за какую зряплату. > > Там же сплошное реальное время и взаимодействие железяк с программой > > и друг другом. > > Вопрос 1.1. Для какого языка/OS сделано достаточно, чтобы на нем можно было > разрабатывать встроенные системы быстро и эффективно? Мне не совсем нравится заниматься рекламой, но прощает меня то, что я сам уж как 4 года там не работаю, да к тому же язык сыроват (деньги нужны, как всегда). Язык тот называется КОМФОРТ и произошел от Форт подхода. Я уже тут как-то писал с годик назад, что это за язык и где его найти. Сегодня нет времени, если нужно напиши -- изложу поподробнее или поищу в архивах. > > > Вот Жаба вроде-бы тудыть влезает. Что кто может по этому поводу сказать? > > > > В соседнем письме я и по ее поводу высказался -- но чуть-чуть повторюсь. > > Жаба это универсальный монстр. Поэтому любить ее можно (как и все большое > > -- слова из кинофильма "Вам и не снилось"). > > А в embedded soft -- никогда. > > Так есть же embebed Java. В принципе она для этого и создавалась. > Размер исполняемых файлов маленький. Почему же "никогда"? Я что-то о ней слышал, но сильно мельком. А реальные ракеты на ней еще не летали. Вот полетают, тогда посмотрим. Michael V. Tokarev, PhD. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon May 25 10:00:41 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Mon, 25 May 1998 10:00:41 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA06830; Sat, 23 May 1998 00:02:53 +0400 Received: by deity.chci.chuvashia.su id WAA13955; (8.6.12/vak/1dot9) Fri, 22 May 1998 22:59:10 +0400 To: subscribers@deity.chci.chuvashia.su From: druchin@bn3000.dd.vaz.tlt.ru (Serge I.Droutchin) Newsgroups: relcom.comp.software-eng Subject: [News] Re: Re: My Language Right or Wrong ;) Date: Fri, 22 May 98 12:50:11 -0400 Organization: General Department of Development, AutoVAZ Distribution: su Message-ID: References: Reply-To: druchin@bn3000.dd.vaz.tlt.ru NNTP-Posting-Host: aa3000.dd.vaz.tlt.ru Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 83 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 3670 Status: RO >From: "Michael V. Tokarev" >> Минуточку. А как же ОО. Ведь это для чего-то нужно ;-) >А причем тут ОО? Это просто модная технология -- не более. Структурный программинг тоже далеко не всегда позволяет сделать то, что нужно, но его задача была в том, чтобы можно было _легче_ разобраться в том, что делает программа, т.е. он был направлен на _снижение_ сложности путем абстракций передачи управления в программе. Кстати, во многом его победа в свое время была обеспечена не столько реальными нуждами, сколько удачным языком структурного программирования -- Паскалем, Никлауса Вирта. Следующий шаг при увеличении сложности программ -- концепция объектов, см. Гатэг, Лисков -- и уровни фукциональной абстракции (к тому времени стандарт де-факто, Unix уже шагал широко и Си проникал в сознание масс: обычных людей -- тяжело, студней, где стояли льготные комплексы с Юниксом -- легче ;) уровни абстракций данных, перенос действий над объектами внутрь этих самых объектов и появление абстракции спецификаций -- прообразов сегодняшних сообщений (IMHO, могу ошибаться) Это дало возможность быстрых адаптаций и использования собственных наработок, если ты первый успевал объявить их стандартом, и у тебя было решающее право голоса на рынке софта ;) Кстати, быстрая адаптация позволила еще быстрее устранять баги, которые к тому времени стали настоящим бичом программирования систем. Уровень абстракций возрос, но средств для успешной работы с ними так и не появилось, посчитали, что программер все это должен держать в черепушке ;) Да, забыл упомянуть о Смоллтоке, где все это и было обкатано. Потом появился С++ и это было большой ошибкой поддерживать мнение, что это лишь расширение Си, тогда как это совершенно другой язык, предусматривающий другую методологию проектирования. Мало того, на нем вообще нельзя просто так сесть и начать писать. Ну об этом у Голуба гораздо лучше написано, тем более, он специалист ;) Вот откуда растут ноги всех этих методологий. Кстати, любая метода лучше, чем отсутствие оной (один полюс), но только до тех пор, пока она не вытесняет здравомыслия (другой полюс) и уровень сложности, с которым может работать человек, обычно ограничен числом абстракций в пределах числа пальцев на его руках (если все целы ;) Соврешенно простой вывод в том, что мы нуждаемся в таких средствах, которые позволят _снижать_ уровень сложности любого объекта, до такого, с которым наш контингент может уже работать точно и безошибочно. Только такие средства могут вывести программирование из того тупика в который оно благополучно забралось, в свое время не позаботившись о завтрашнем дне :( Кстати, о завтрашнем дне: обратите внимание, Си привнесли в жизнь студни, которые могли с ним знакомится и играться (а попробуй в Юниксе без Си ;) Структурный программинг тоже прошел через Паскаль -- язык обучения студентов основам систематического программирования (как все раньше было просто ;) Даже Бороланд состряпал себе капитал и имя на студнях, продавая им "Турбо-паскаль" -- систему програмирования на ПиСи на одной дискетке всего за $49.50 >Я вот сейчас вспомнил, что КомФорт был написан первоначально на ДЕСе >(ПиСьков тогда еще не было в России). И не только в России ;) >И когда они появились ядро было перенесено на них, по-моему, всего за месяц. >Потом пошли крутые доработки новых возможностей, которые были невозможностями >не ДЕСе. Я закроспостирую (мама, какое слово 8-) сейчас письмо из relcom.comp.lang.forth <-> fido7.su.forth <-> SU.FORTH Оно от группы продолжающих работать с ДССП. С уважением, Дручин Сергей. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon May 25 10:00:47 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Mon, 25 May 1998 10:00:47 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA06878; Sat, 23 May 1998 00:03:00 +0400 Received: by deity.chci.chuvashia.su id WAA14026; (8.6.12/vak/1dot9) Fri, 22 May 1998 22:59:21 +0400 To: subscribers@deity.chci.chuvashia.su From: druchin@bn3000.dd.vaz.tlt.ru (Serge I.Droutchin) Newsgroups: relcom.comp.software-eng Subject: [News] Re: Re: My Language Right or Wrong ;) Date: Fri, 22 May 98 14:55:18 -0400 Organization: General Department of Development, AutoVAZ Distribution: su Message-ID: References: Reply-To: druchin@bn3000.dd.vaz.tlt.ru NNTP-Posting-Host: aa3000.dd.vaz.tlt.ru Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 147 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 6713 Status: RO >From: "Michael V. Tokarev" >Он ездил в Англию (кажется) писать кому-то компилятор еще в жутко застойные >времена. Наверное в MPE -- MicroProcessor Enginering, они как раз и производят мощные, профессиональные кросс-средства на базе PC, плюс сами эти средства генерит специальный компилятор высокого уровня, ну и дальше ручками... Он, кстати, тоже доступен, в продаже. У них есть веб-сайт. Я про них уже рассказывал, 13 человек в фирме, жена главы ведет денежные дела, сам Стивен завсегдатай comp.lang.forth. >> Дело еще и в том, что какой-нибудь драйвер -- невелик по размеру, >> и достаточно ясно что и как он должен делать. Здесь именно >> с ассемблером конкурировать трудно. Но стоит программе слегка >> увеличить размер, как сложности начинают возрастать в удивительно >> быстрой пропорции. В форте управлять сложностью легче (_потенциальная_ >> возможность!) и в какой-то момент программа становится компактнее >> ассемблерной и быстрее выполняющейся 8-0 >> Не говоря об относительной простоте модернизации и локализации >> вносимых изменений (эффект затухания). > >По поводу "быстрей выполняющейся" ты несколько неправ, а вообще откуда ты >взялся такой умный :-) Я тут борюсь с кучей брюзжащего народу уже >год, а ты почитываешь и посмеиваешься? >Ты же все знаешь -- чего молчал? Ну... (потупя голову и ковыряя носком ботинка пол ;) Я вообще-то не только здесь, я еще последние два года как могу, популяризирую форт на бездонных просторах ex-U и не безуспешно. Конечно, добрые люди помогают ;) Бытрее оно будет, при определенной величине сложности задачи, я же говорю, при линейной структуре с ассеблером не потягаешься, но вот когда пошли подпрограмки и процедурки, макросы и структуры данных, то ручками оптимизировать это не получается, точнее, пальцев на руках не хватает (см. другую статью ;) >Так вот компактнее -- это мягко сказано даже по сравнению с Ассемблерной >(не то что С++ или С--) -- в разы. Мужики (за бугром) долго и успешно шили в пзу сишную прогу, в автомат-игрушку какую-то. Потом, в результате бесконечных усовершенствований и добавлений, как ни бились, не удавалось или вместится в заданный объем, или получить приемлемое время реакции. Сменили язык на форт (разработчик по-моему остался но может и нет) и с первой попытки сложности были сняты. (Публиковалось в comp.lang.forth участником эпопеи) >Быстрей выполняющейся -- неправда (быстрей проектируемой -- это другое >дело). Основное время в любом исполнении исходного кода уходит на переходы. >В Форте -- это практически каждый шаг. Другой разговор, что он реализован >настолько эффективно, что десяток его переходов равен одному переходу >в других прогр.технологиях. При написании на ассемблере, естесственно оптимизируется все в уме, поэтому запросто может быть неоптимальное распределение на процедуры, неоптимальные ветвления, и т.п. (опять же, при достаточном уровне сложности) а уж джампов там, как собак нерезанных, включая иреты, коллы, и т.п. удовольствия. Задачами оптимизации машкода занимается за бугром Ф.Коулман (или Кулмэн) (нет под рукой английского написания) и он использует для этой оптимизации форт ;) В форте переходы реализованы не только эффективно, но еще и однообразно, как в армии, а мы знаем, что это за сила ;) хотя, как я понимаю, можно контролировать и это... >А простота модернизации и локализация... -- вообще недосягаемы для других >языков. Что не освобождает программиста от четкого и умелого анализа и критического мышления и интуитивного сопротивления сложности. >> Win32Forth Тома Зиммера (Циммера), SP-F Андрея Черезова. >> Это не коммерческие. Есть и мощные коммерческие пакеты, >> оснащенные кросс-компиляторами, что дает любопытную тенденцию: >А вот я ничего такого не видел :-( Хочу еще добавить. Характерный подход для буржуев: берут Win32Forth и решают на нем свои задачи, при непонятках и багах контактируют с автором или c.l.f Характерный подход для наших: хотя реализовать классную идею. Берут что найдут. Вертят в руках. О, как интересно. Потом другое, третье -- не то. Что ж, надо писать свое. И пишут, и доводят годами, а тем временем изначальная идея протухла уже в первом полугодии от начала поисков. Справедливости ради стоит сказать, что соблазн написать свой форт появляется практически у каждого, кто только начинает в нем работать, не пытаясь понять его идеи, а таща за собой "кладезь" своих. Ну так и надо их реализовывать, для этого компилятор не обязательно писать свой. >> Есть еще одно изумительное ню, упускаемое очень многими даже >> приверженцами форта: принцип замены сложения умножением. >Никто этого не опускает -- просто это само-собой разумеющееся Увы, практика моего общения с приверженцами языка говорит чаще об обратном. Разговор все время трется (отсюда thread) о деталях самих компиляторов, не переносясь на область задач. А ведь задача может быть поставлена и так: объяснить быстро запоминающей ;) и обучающейся машине что нужно делать в терминах предметной области т.е. вполне понятной прикладнику. И далее говорить на этом языке для постановок, поисков решений, манипулирования данными, но уже целиком в _предметной области_ Это не будет "новым" языком программирования, это будет "согласование понятий" между машиной и человеком, при которых гнется Software, а не насаждаются обезьяньи навыки у оператора ;) К великому сожалению пока не заполнена именно область средств позволяющих машине помогать нам понижать уровень сложности при постановках, проектировании, моделировании. Но точно знаю, что в этом направлении есть очень серьезные наработки. И даже у нас :-) >> Подобрав параметры модели, можно определить узкие места >> в эффективности, если это требуется, и расшить их на >> ассемблере, зачастую являющемся частью форт-системы. > >А если это все помножить на формальные модели-спецификации, >которые помогут это сделать, то получится DREAM. Как пример вышесказанного >Они теперь круты!!! И с Мотороллой им повезло, хотя это все опять же заслуга >почти исключительно С.Н. Едва ли "повезло", просто вовремя подумали о будущем и правлиьно приложили силы. >Чтож ты до сей поры молчал! Агхм, осмелюсь ляпнуть еще вот что: Вам с Витом нужно открывать консалтинговую фирму, или что-то еще, дающее возможность жить и быть замеченными, далее перебираться в заметный, опять же, университет, далее выпустить 3-4 поколения студней с вашими реализованными идеями, а потом это, как новые веянья вернется и к нам, сюда ;) Такая вот кривая кажется мне самой прямой в нынешних условиях. С уажением, Дручин Сергей. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon May 25 10:00:47 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Mon, 25 May 1998 10:00:47 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA06874; Sat, 23 May 1998 00:03:00 +0400 Received: by deity.chci.chuvashia.su id WAA14021; (8.6.12/vak/1dot9) Fri, 22 May 1998 22:59:20 +0400 To: subscribers@deity.chci.chuvashia.su From: druchin@bn3000.dd.vaz.tlt.ru (Serge I.Droutchin) Newsgroups: relcom.comp.software-eng Subject: [News] Re: Форт, Комфорт (было: Re: My Language Right or Wrong ;) Date: Fri, 22 May 98 13:00:14 -0400 Organization: General Department of Development, AutoVAZ Distribution: su Message-ID: References: Reply-To: druchin@bn3000.dd.vaz.tlt.ru NNTP-Posting-Host: aa3000.dd.vaz.tlt.ru Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 32 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 1617 Status: RO >From: "Michael V. Tokarev" >> > > Вот Жаба вроде-бы тудыть влезает. Что кто может по этому поводу сказать? >> > В соседнем письме я и по ее поводу высказался -- но чуть-чуть повторюсь. >> > Жаба это универсальный монстр. Поэтому любить ее можно (как и все большое >> > -- слова из кинофильма "Вам и не снилось"). >> > А в embedded soft -- никогда. >> Так есть же embebed Java. В принципе она для этого и создавалась. >> Размер исполняемых файлов маленький. Почему же "никогда"? >Я что-то о ней слышал, но сильно мельком. >А реальные ракеты на ней еще не летали. Вот полетают, тогда посмотрим. Жабы в встроенных системах не будет, разьве что как клиентская часть домофонов, которым нужно будет исполнять апплеты из Инета, под аккомпанимент квартета... (пардон, расшалился) Блин, неужели не ясно, Java -- не достижение и не передовая технология, и не решение проблем. Java -- эта карта в игре большого софт-бизнеса, и чем больше шуму вокруг нее, тем быстрее эту наживку заглотят. Тем более, она уже довольно прочно к интернету прицепилась. Да в ней есть позаимствованные и обкатанные идеи, у нее первоклассная упаковка, отменный сервис -- посмотрите их обучалки... Денежная машина совершила четверть оборота, и теперь хотим мы того, или нет, еще несколько оборотов воспоследуют. А если уж и МС взялась этот барабан раскручивать, значит тут пахнет деньгами. Притом, что у нее действительно наверное есть привлекательные стороны, кроме одежки, но эта Жаба едва ли превратится в Василису Прекрасную... С уважением, Дручин Сергей. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon May 25 10:01:19 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Mon, 25 May 1998 10:01:19 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA23550; Sun, 24 May 1998 05:14:19 +0400 Received: by deity.chci.chuvashia.su id EAA29060; (8.6.12/vak/1dot9) Sun, 24 May 1998 04:08:10 +0400 To: subscribers@deity.chci.chuvashia.su From: "Michael V. Tokarev" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Sat, 23 May 98 11:33:35 +0400 Distribution: su Organization: Private Domain Message-ID: Reply-To: michael@tokareff.pgu.karelia.su References: <6k1294$e6r@deity.chci.chuvashia.su> X-Return-Path: michael@tokareff.pgu.karelia.su Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 70 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 3613 Status: RO > Alexey Donskoy > > В форте управлять сложностью легче (_потенциальная_ возможность!) > Расскажите подробнее об управлении _немаленьким_ проектом на Форте! > Как бороться с размерами словарей, как найти, что уже сделано, в какой > степени > и каким образом, чтобы не приходилось почти дублировать слова и потом > путаться в синонимах. Есть ли какие методики, пригодные для _промышленного_ > производства софта на Форте? Я могу немного рассказать о КомФорте. Там специально боролись с такой проблемой. Ведь мелкомодульное сборочное программирование предполагает неимоверное число таких модулей. И здесь есть 2 проблемы: 1. Как разбираться в тысячах программках. 2. Как компилировать. Было найдено достаточно простое решение -- 1. Точность описания интерфейса. Хранение модуля с ДОКой на него в одной библиотеке. (я уже писал? что такое возможно да еще и с метриками и т.п.) 2. Объединение модулей собственно в библиотеки. Как это делается во всех языках, с той только разницей, что здесь библиотека любая видна как на ладони. Список модулей, ДОКов и т.п. просто просмотреть в любой момент проектирования. Остается одна проблема (как и в любой древовидной структуре типа директориев поддиректориев -- правильное название библиотек, и подбиблиотек. Но библиотека с точки зрения проектировщика объект аналогичный модулю, ДОКу и т.п., т.е. с библиотекой рядышком в родительской библиотеке хранится и документация на нее. Конечно мы все не привыкли вести ДОКу на каждый модуль, но, в конце концов, все вынуждены хотя бы по реализации проекта эту ДОКу выдавать. Получается, что или ДОКа пишется тогда очень долго (надо ведь вспомнить, что творил и зачем -- это реже) или (чаще всего) ДОКа становится неполной или просто ошибочной. > Попробуем сформулировать требования к (скажем так) среде проектирования, > которуб мы хотели бы иметь (к идеальному CASE-средству ;-): > - поддержка всего цикла разработки вплоть до генерации кода > (+переносимость, > платформонезависимость); > - простой и надежный механизм редукции сложности в фундаменте (Форт + > модифицированные таблицы решений Седова?) > - иерархическая (?) модель проекта (SM? Форт?) > - поддержка различных методик проектирования (визуальное представление и > работа с "табличной" метамоделью в виде графов, диаграмм, формул, SQL, > ЯВУ... > то есть проекция метамодели в те же диаграммы и пр. - хотим - работаем с > диаграммами, хотим - с деревом классов, хотим - выстроим те же классы > в иерархию по другому критерию...); > - гарантия полноты разрабатываемых моделей: > а) транзакционность всех изменений; > б) автоматическая проверка полноты; > б) доступность и удобство работы с "таблицами перекрестных ссылок" и пр. > информацией о структуре и взаимных зависимостях; > - поддержка версионности и вариантности (условная компиляция, параллельное > ведение нескольких вариантов, отличающихся по функциональности); > - средства RAD для интерфейсов; > - развитые средства связи с внешним окружением: > а) возможность использования DLL; > б) компоненты Delphi; > в) Active-X и все такое прочее... > ... > ...) API к базам данных, Вебу, сетям и другим пргограммам... Может где и проскочило, но я не заметил еще одного, чем страдают ВСЕ CASE -- отсутствие качественных оценок на проекты, модули и тем более сравнение этих оценок у альтернативных вариантов или у разных проектов И, конечно же -- РЕПОЗИТОРИЙ. Правда он есть во всех CASE. Michael V. Tokarev, PhD. From chci!deity!deity.chci.chuvashia.su!news-service Mon May 25 10:01:24 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Mon, 25 May 1998 10:01:24 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA27280; Sun, 24 May 1998 14:14:14 +0400 Received: by deity.chci.chuvashia.su id NAA02285; (8.6.12/vak/1dot9) Sun, 24 May 1998 13:09:32 +0400 To: subscribers@deity.chci.chuvashia.su From: "Michael V. Tokarev" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Sun, 24 May 98 10:03:22 +0400 Distribution: su Organization: Private Domain Message-ID: Reply-To: michael@tokareff.pgu.karelia.su References: X-Return-Path: michael@tokareff.pgu.karelia.su Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 88 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 4329 Status: RO > >From: "Michael V. Tokarev" > > Ну... (потупя голову и ковыряя носком ботинка пол ;) > Я вообще-то не только здесь, я еще последние два года > как могу, популяризирую форт на бездонных просторах > ex-U и не безуспешно. Конечно, добрые люди помогают ;) И надеюсь деньгами в первую очередь.(с). > А ведь задача может быть поставлена и так: объяснить быстро > запоминающей ;) и обучающейся машине что нужно делать в терминах > предметной области т.е. вполне понятной прикладнику. Ну-у батенька -- в машинный интеллект я не верю, во всяком случае в ближайшее будущее. Даже с новыми объемами памяти -- ее слишком мало (но это уже другая история). > И далее говорить на этом языке для постановок, поисков решений, > манипулирования данными, но уже целиком в _предметной области_ > Это не будет "новым" языком программирования, это будет > "согласование понятий" между машиной и человеком, при которых > гнется Software, а не насаждаются обезьяньи навыки у оператора ;) Да, именно это я и хотел сказать. То, что программеров не хватает и все больше не будет хватать -- не секрет. А значит нужны языки (типа драного АКСЕСА даже), которые позволят чайникам ваять простейшие бухгалтерские программы. У меня на службе даже есть ценный опыт -- на Аксесе рисуют уже 2 человека конечно без Visual (образование у них штурман и строитель). Если за ними хорошо следить (это получалось до последнего времени) и не закинуть потом (а вот это уже не получается), то в общем проблему можно решить. А Форт как раз на такое способен. Опять же та же проблема -- не видел я его реализаций в нормальном виде, так чтобы можно было сесть и начать писать проекты, да еще в сети многопользовательские. > К великому сожалению пока не заполнена именно область средств > позволяющих машине помогать нам понижать уровень сложности > при постановках, проектировании, моделировании. > Но точно знаю, что в этом направлении есть очень серьезные > наработки. И даже у нас :-) Сейчас куча народу закричит ДАВАЙ!!! ДАВАЙ!!! > >Они теперь круты!!! И с Мотороллой им повезло, хотя это все опять же заслуга > >почти исключительно С.Н. > > Едва ли "повезло", просто вовремя подумали о будущем и правлиьно приложили > силы. Нет именно повезло. Потому что до этого мы голодали года 3. Теперь об этом чувстве забыли (появилось другое чувство -- недосыпания, неуспевания и т.п.). > Агхм, осмелюсь ляпнуть еще вот что: > Вам с Витом нужно открывать консалтинговую фирму, или что-то еще, > дающее возможность жить и быть замеченными, далее перебираться > в заметный, опять же, университет, далее выпустить 3-4 поколения студней > с вашими реализованными идеями, а потом это, как новые веянья > вернется и к нам, сюда ;) Я уже начал реализовывать твою идею. 1. Открыл (не без ведома Георгия-модератора) консалтинговую фирму в relcom.comp.software-eng. (с). Причем бесплатно как и Вит. (тут то нас и заметили Дручин (прости если ошибся), Донской и еще парочка человек). 2. В заметном Универе я подрабатываю (не за деньги, а за интерес) -- там студни помогают сильно в ИНете копаться, разгребать мусор безинформационных статей проклятых, загнивающих буржуев и т.п. 2 поколения студней уже прониклись идеями -- один даже диплом готов писать по данной тематике. Из них, правда, только человек 10 вспомнят потом о моих уроках жизни. Но если хотя бы 2 из них кому-то еще скажут об этом -- вот вам и цепная реакция. 3. К нам сюда -- это в Россию? Дело в том, чтоя уже писал о совершенно реальных американосовских предложениях, которые были отклонены. Поэтому данный тип к.т.н. обретается до сей поры в России и возвращаться сюда не собирается.(смайлик не рисую -- сам видишь). > Такая вот кривая кажется мне самой прямой в нынешних условиях. Где-то год назад у нас с Георгием как раз и возник спор по этому поводу. Он говорил, что ничего нельзя сделать для перелома сознания и программеров и менегеров. А я писал, что есть путь -- это вбивание своих мыслей в молодые и незаполненные (читай -- пустые) головы студней, пока их не заполнили С++ом и Джавой. К сожалению здесь трудно конкурировать с теми долларовыми вливаниями, которые идут на пропаганду этого барахла. Michael V Tokarev, PhD. From chci!deity!deity.chci.chuvashia.su!L-relcom Tue May 26 10:18:56 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Tue, 26 May 1998 10:18:56 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA17440; Mon, 25 May 1998 22:19:15 +0400 Received: by deity.chci.chuvashia.su id VAA17302; (8.6.12/vak/1dot9) Mon, 25 May 1998 21:18:17 +0400 To: subscribers@deity.chci.chuvashia.su From: "Alexey Donskoy" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Mon, 25 May 98 20:44:03 +0400 Organization: AVTOVAZBANK Cheboksary Branch Message-ID: <6kc7vm$gqd@deity.chci.chuvashia.su> References: <6k14bj$ein@deity.chci.chuvashia.su> <6k3isd$1j6$1@nnrp1.dejanews.com> NNTP-Posting-Host: ipchavb.chuvashia.su X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 153 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 7148 Status: RO Добрый день! vrudowit@onestone.de (vrudowit@onestone.de) wrote: > > Попробуем сформулировать требования к (скажем так) среде проектирования, > > которуб мы хотели бы иметь (к идеальному CASE-средству ;-): > ^^ > Кто вы? Мы, Николай Вторый ;-) угораздило меня выразиться за все программистское сообщество... Я вспомнил, что Вы не так давно намеревались творить свой тул для рисования диаграмм (готовый лучше, но по пять рублей)... Почему бы нам ;-) сообща не составить что-то вроде ТЗ на желаемое CASE-средство? (Это не то чтобы шапкозакидательство, но вот тулы для Шлеер-Меллора мне явно не по карману, а жить и работать надо ;-) > Давайте тогда говорить о методиках, или наборе техник. Очень сомневаюсь, что > CASE будет проводить опрос пользователя :-) см.выше. Такой опрос и предлагаю провести (как независимое исследование). > > - простой и надежный механизм редукции сложности в фундаменте (Форт + > > модифицированные таблицы решений Седова?) > Что такое таблицы решений Седова? см. архив r.c.s-e весна 1997 2 moderator: где-нибудь лежит сей архив? Там много ценных мыслей! > > диаграммами, хотим - с деревом классов, хотим - выстроим те же классы > > в иерархию по другому критерию...); > > Очень дорога будет реализация подобной универсальности. Не обязательно. Что может быть проще таблицы? А все из нее растет (хотя пока не совсем понятно, как ;-( Конечно, мужики не мало и не зря думали, методики разрабытывая. Но Вы же сами здесь их критиковали ;-) (Кстати, где обещанные Вами материалы?) > > - гарантия полноты разрабатываемых моделей: > > а) транзакционность всех изменений; > Критерии транзакционности? ? Я имел в виду, что система должна предъявлять для проверки все взаимные зависимости изменяемого элемента модели (кода) и не закрывать транзакцию до тех пор, пока разработчик все эти места не проверит и флажки не выставит. Делают ли это те же тулы для ШМ? И как решаются вопросы взаимного влияния транзакций? > > б) автоматическая проверка полноты; > Невозможна. Возможно только нахождение неполноты и ошибок. Разве неполнота=false не есть полнота? > > б) доступность и удобство работы с "таблицами перекрестных ссылок" и пр. > > информацией о структуре и взаимных зависимостях; > Опять же каковы критерии доступности и удобства? Эргономические! Четкое структурирование, 7+-2 фрейма, простота навигации и пр. > > - поддержка версионности и вариантности (условная компиляция, параллельное > > ведение нескольких вариантов, отличающихся по функциональности); > Я против :-) Почему? Например, почти в любом продукте нужно предусматривать версии Light и Professional. Как Вы предлагаете это реализовывать - разными проектами? > > - средства RAD для интерфейсов; > Зачем? Я опять же против. (Ох. Ждите, ждите. Это тоже будет :-) ) Ждем (заранее не соглашаясь на 50% - а вдруг?)! > А нахрена завязываться с винтел? Против однозначно. Да сделано тут много готового, у всех есть и грех не использовать (ИМХО)... > > ...) API к базам данных, Вебу, сетям и другим пргограммам... > > Это зависит только от количества народа, работающего в данном окружении. Если > исходить из таких требований, то получается Вижуал Васик. Это уж точно без > меня. Кстати, а какого рода задачи Вы в Германии решаете? далее по соседней статье: > > --------------------------------------------------------------------- > > : Однако хотелось бы рассмотреть возможность его применения сегодня: > > : в "коммерческом софте общего назначения". И с точки зрения SE. : > > --------------------------------------------------------------------- > > Предлагаю не рассматривать. Давайте тогда включим искусственный интеллект и > нейронные сети. И что получится? Предлагаю не выбрасывать полезные вещи. Они очень даже тут кстати. Очень кстати тут и ТРИЗ, и теория познания, и топология... Каждый из нас, предлагая что-то, исходит из неких своих потребностей. (Ваши я пока не понял, поскольку в других статьях Вы очень заинтересовались и Фортом, и КомФортом). Мои - в понимании, что работать так, как я сейчас, дальше нельзя. Но BridgePoint (или кто там еще для ШМ?), как бы они мне не понравились, недоступны (суммы всех моих заказчиков << , и хорошего менеджера под рукой тоже нет ;-) Так я хочу узнать, стоит ли делать ставку на Форт? Есть ли пригодные ГОТОВЫЕ инструменты? Насколько эффективнее/быстрее/дешевле разработка крупных проектов на Форте? > > Что есть Форт? - АРХИВАТОР АЛГОРИТМА (c) мой. > > Выкинув из рассмотрения всякие примитивные dup/drop, отвращающие от него > > новичков, видим иерархию, похожую на LZ-словарь. > > Есть ли серьезные разработки темы? См. литературу, указанную MT. Серьезные аналитические разработки также хотел бы увидеть. > > > Пришлось кормиться на стороне. > > Вот про то и речь. Надо нам софт под MS - берем какой-нидь RAD типа > > Delphi. > > По некоторым отзывам исправление ошибок съедает весь R. > > > Быстрее и дешевле получается. > > Маленький вопросец. > Вы это измеряли или Вам так кажется? Если я предлагаю заказчику сделать то и то за время T и $X, но в UNIX, да еще Sun ему покупать Ж-), а рядом стоит толпа "голодных студентов" и предлагает то же, но на PC, в Дельфи, за Т/2 и $X/2, что выберет заказчик? Дальше будут его проблемы, но деньги уже не мои... Можно долго ругаться, что "сами вы заказчика развращаете", но ведь есть объективные законы рынка... А измерить можно на маленьком тесте, а кто же будет платить за параллельную разработку крупного проекта разными способами? > > на очередном этапе редукции сложности превращается в код; > Шлейер-Меллор. > Но вот эти CASE стоят хороших денег. Правда, стоят не зря. см.выше > > - в основе машинной реализации всего (в т.ч. графа, дерева и пр. > > топологических конструкций лежит таблица (ссылок), поэтому идея Седова о > > некоей универсальной таблице решений мне представляется очень простой и > > плодотворной; > > Это только идея, или есть конкретные наработки? Сам Седов писал, что занимается этим уже 15 лет, и производительность его труда при использовании его тула возросла на порядок... > По этому поводу большой и толстый вопрос. > Кто может дать метамодель Форта? Можно совсем сырую. ранее_определенный_идентификатор: {идентификатор, найденный в словаре} определение: идентификатор начало ранее_определенный_идентификатор конец ^---------------------------------/ словарь: начало идентификатор адрес_кода_определения конец ^-------------------------------------/ Работа, разумеется, через стек. Если очередной встреченный идентификатор есть число (текст, имя переменной и т.п.) - оно выкладывается в стек. Если идентификатор найден в словаре, исполняется код его определения. В общих чертах - все!!! остальное - частности и детали реализации (в т.ч. следующие принятым стандартам, но они не обязательны!) Как инструмент понижения сложности - это здорово. > Regards! > Vit -- С уважением, Алексей Донской alek@chavb.chuvashia.su From chci!deity!deity.chci.chuvashia.su!L-relcom Tue May 26 19:26:09 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Tue, 26 May 1998 19:26:09 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA29830; Tue, 26 May 1998 17:24:13 +0400 Received: by deity.chci.chuvashia.su id QAA26811; (8.6.12/vak/1dot9) Tue, 26 May 1998 16:23:50 +0400 To: subscribers@deity.chci.chuvashia.su From: "Serge I.Droutchin" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Tue, 26 May 98 12:58:41 -0400 Organization: unknown Distribution: su Message-ID: Reply-To: druchin@bn3000.dd.vaz.tlt.ru NNTP-Posting-Host: aa3000.dd.vaz.tlt.ru Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 121 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 5581 Status: RO Добрый день! Промахнувшись по клавише, отослал по личной Виту, а вообще-то отвечалось в конференцию. Если уж не ко времени, прошу прощения, а в субботу и воскресенье я связи лишен :(( 19-May-98 13:25 Serge I.Droutchin wrote: >From: vrudowit@onestone.de > druchin@bn3000.dd.vaz.tlt.ru wrote: >> Дык у мокрософта для тестирования пользователи есть, и причем, >> с них за удовольствие "потестировать" еще денежки берут. >> Вон, 98 еще не официален, а поди у половины уж стоит. >В Мелкомягком на каждого разработчика по тестеру. Не хватает, однако, раз насквозь сырые продукты выходят как релизы, и это именно _политика_ фирмы, ведущая свое начало с самых первых версий дос, наскоро передранных с cp/m. Притом, "пользователям _нравится_ находить ошибки в наших продуктах, т.к. это снимает излишний психологический барьер при работе с новым продуктом, позволяет пользователю почувствовать себя увереннее..." >> А вообще, про то, какая кака C++ очень хорошо у Алена Голуба написано, >> некоторые даже вроде как читали, а мне, темному, эта книга >> просто глаза открыла, и теперь я в С++ не ногой. Слишком >> много свободы на алтарь методологии, слишком много сил >> на поддержание плохо понимаемых абстракций, и все это только >> для того, чтобы облегчить сопровождение продукта. >По-моему Голуб говорит только о том, что идиотизм безграничен. В принципе >свобода должна правильно использоваться. В любом случае она может >быть опасна. Основные проблемы идут IHMO от того, что ОО учат по >С++, а не так, как надо. В принципе я знаю людей, которые писали >оптимизированные программы и на С++. Например в библиотеке практически не >были использованы виртуальные функции, что повысило скорость выполниения. Я не на ОО "наехал", я сказал, что понял, в каких ситуациях оправдано применение именно С++, сколько и чем нужно заплатить за это, чего я буду иметь в итоге -- и лично мне все это _не надо_ Это приближение к _разумному_ выбору языка реализации, а не потому что "мы хотим видеть этот проект реализованым на С++"... >> Платить надо не за ту или иную _реализацию_ (хоть и под ключ) >> а за реально _работающую_ систему, приносящую денежку, >> в той или иной форме, ибо как давно было сказано, >> лучшая программа -- та, которая работает. >> (Понятно, что не вообще в абстрактном прогоне, а там где и для >> чего она писалась) Уточню. Я смещал термин "готовый продукт" с того, что продается в коробке, на тот, что работает у пользователя. Тем более, если это продукт единичного заказа и исполнения. Реальный смысл есть именно и только в _работающей_ программе, во время ее работы. Сама по себе коробка, буклеты, статьи в околокомпьютерной прессе, многотомные руководства для полных идиотов и идиотов начинающих, а также для нормальных, желающих непременно стать идиотами, не имеют в принципе никакого смысла в отрыве собственно от железяки. Так же как бесполезна сама эта железяка без ОС и прикладного ПО. >Ага. M$ Офис работает. Вроде бы. Можно над ним стебаться сколько угодно, но для конечного пользователя который не различает, где начинается и кончается системный блок и какая из машин в сети является сервером, это вполне работоспособный и достаточно добротно сделанный продукт, который _все_ пользовательские задачи по обработке информации решает. Очень здоровый подход для большинства, не связанного непосредственно с комп-индустрией. Когда мы смотрим новости, сильно мы призадумываемся о том, как работает отклоняющая система, или какие именно модуляции претерпевает ИК-луч при смене надоевшего канала? Мало того, нам это надо? Т.е. программа работает и делает то, что нужно пользователю. Да, не идеально. Но она полностью заполнила свою нишу и не надо быть семи пядей во лбу, чтобы уверенно сказать, что в ближайшее время ей конкурентов нет и не будет, что это де-факто стандарт делового мира, по крайней мере при общении между конторами форматы *.doc *.xls нормально понимаются. Мне не нравится Микрософт, их методы работы, оболочки для запуска программ, и т.д. но давайте будем не зависимыми от собственных пристрастий, когда речь идет о достаточно очевидных вещах, можно с осторожностью сказать, фактах. >> Японцы в свое время вышли в лидеры и заставили весь мир >> обратить внимание на качество, еще и в значительной мере >> потому, что повели широкофронтальную борьбу со _сложностью_ >> на всех стадиях ее возникновения. >И где сейчас японские программы? Во-первых, быть лидером тяжело и обременительно, во-вторых качество всех солидных производителей (а не только суперэлитных) в результате заметно подтянулось, в третьих, вы не учитываете психологию островитян ;) в полчетвертых, они чтят _свой_ язык, культуру и традиции, и не стремятся навязать обществам американский путь развития. Ы? В Вашу пользу говорит провал их компутеров 5-го поколения с супер-пупер интеллектом, потому что это было ошибкой. И в противополжность моей мысли, здесь они таки попробовали борьбу "за" сложность. ну и на сладкое: First of all ;) я хотел бы чтобы читающие обратили внимание на смысл или идеи, если они там были, а не на их эмоциональную окраску, добавленную для яркости и выразительности. Наверное получилось ярковато... С уважением, Дручин Сергей. : тупик begin 0 1 and until ; PS Foreword: Я с достаточным почтением отношусь к профессиональным качествам и знаниям завсегдатаев, но эти качества и знания никоим образом не предопределяют умения видеть новое или явление в целом. Это раздельные навыки. Поэтому просьба не обижаться. From chci!deity!deity.chci.chuvashia.su!news-service Tue May 26 19:26:18 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Tue, 26 May 1998 19:26:18 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA02319; Tue, 26 May 1998 20:29:19 +0400 Received: by deity.chci.chuvashia.su id TAA28766; (8.6.12/vak/1dot9) Tue, 26 May 1998 19:24:33 +0400 To: subscribers@deity.chci.chuvashia.su From: druchin@bn3000.dd.vaz.tlt.ru (Serge I.Droutchin) Newsgroups: relcom.comp.software-eng Subject: [News] Таблицы решений. Date: Tue, 26 May 98 16:57:34 -0400 Organization: General Department of Development, AutoVAZ Distribution: world Message-ID: References: <6kc7vm$gqd@deity.chci.chuvashia.su> Reply-To: druchin@bn3000.dd.vaz.tlt.ru NNTP-Posting-Host: aa3000.dd.vaz.tlt.ru Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 102 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 4317 Status: RO >From: "Alexey Donskoy" > Добрый день! Добрый! ;) >> > - простой и надежный механизм редукции сложности в фундаменте (Форт + >> > модифицированные таблицы решений Седова?) >> Что такое таблицы решений Седова? Гм. Зреете что ли? ;) Не верю. ;) Не таблицы решений Седова, а: Pollack S.L., Decision Tables: Theory and Practice, J.Wiley & Sons Inc., __1971__ [общетеоретическая работа] Э.Хамби. Программирование таблиц решений., Мир, М. __1976__ [содержит ссылку на предыдущую книгу] плюс Communication of the ACM за 1972-92 годы [наверное и позже] В C-o-t-ACM было много статей о том, как с помощью ТР моделировать, проектировать, компилировать, выражать рекурсию и циклы, структуры данных и пр. [т.е. не так уж и необходимые, но очень привычные и понятные абстракции, методы и методики] > см. архив r.c.s-e весна 1997 >2 moderator: где-нибудь лежит сей архив? Там много ценных мыслей! У меня есть присланная Алексеем выжимка из бурных тогда (более годичной давности) дебатов в конференции. Сам я тогда сидел без связи. Уже три месяца или больше не могу найти русское издание Хамби :((( (Я живу в Тольятти, с книгами того времени здесь тяжеловато) >> Это только идея, или есть конкретные наработки? > Сам Седов писал, что занимается этим уже 15 лет, и производительность его >труда при использовании его тула возросла на порядок... Я хочу "обрадовать" тех, кто заинтересуется. Форт -- средство, таблицы -- метод. Есть еще авторское ноу-хау об _автомате_ редукции сложности. (да, плюс 15 лет разнообразных экспериментов с языками и методами в практической работе) Это требует и знания специальных областей современной математики, которой, например, в бывшем союзе не учат в вузах, тем паче программистов. Если где-то есть счастливые исключения, то только рад буду. >> По этому поводу большой и толстый вопрос. >> Кто может дать метамодель Форта? Можно совсем сырую. > ранее_определенный_идентификатор: {идентификатор, найденный в словаре} > определение: > идентификатор начало ранее_определенный_идентификатор конец > ^---------------------------------/ > словарь: > начало идентификатор адрес_кода_определения конец > ^-------------------------------------/ словарь традиционно является цепочечным списком, что дает возможность линейного просмотра при поиске. Существует понятия контекстных словарей, которые соединяются в цепочку с нужным приоритетом и слова управления этими словарями: создания, включения, отключения, управления порядком поиска. > Работа, разумеется, через стек. Если очередной встреченный идентификатор >есть число (текст, имя переменной и т.п.) - оно выкладывается в стек. Если >идентификатор найден в словаре, исполняется код его определения. > В общих чертах - все!!! остальное - частности и детали реализации (в т.ч. >следующие принятым стандартам, но они не обязательны!) Еще характерный элемент Форта -- трехстадийность состояния ;) Стадия определения, стадия компиляции, стадия выполнения. Это необходимо учитывать для слов, которые называют "порождающими", для остальных это не так критично. Все в целом вписывается в обрисованную мета-модель. Вообще, были попытки стандартизировать Виртуальную Форт-Машину, но вроде это не увенчалось успехом: блин, каждый начинающий мечтает написать свой компилятор ;))) а многие его и пишут. > Как инструмент понижения сложности - это здорово. Форт не инструмент понижения сложности, это топор, одинаково подходящий для рубки голов, бритья ушей НР и строительства баньки или чуда архитектуры. Механическая редукция сложности -- ТР, при этом все зависит от концуптуальных моделей и субъекта и его мировоззрения. Автомат понижения сложности -- это как раз комплекс. Кстати, у Броуди в книге Думаем на Форте, есть наметки "табличного" программирования, я там впервые осознал эту идею, а уж потом познакомился с идеями А.Седова. С уважением, Дручин Сергей. PS Я в понедельник просидел без связи, а статьи на сервере новостей, где я подписан, хранятся три дня. Если у кого-то были конкретные вопросы, а я не ответил, прошу продублировать мылом. PPS Если кто-то нароет статей из C_ACM о DT -- поделитесь, пожалуйста, бо он-лайн мне еще не скоро светит :-((( (Примечание - смотрел я - есть там статьи, но ftp услуги платные - $10 за статью. А.Донской) From chci!deity!deity.chci.chuvashia.su!news-service Wed May 27 14:23:38 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Wed, 27 May 1998 14:23:38 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA14868; Wed, 27 May 1998 15:29:19 +0400 Received: by deity.chci.chuvashia.su id OAA08462; (8.6.12/vak/1dot9) Wed, 27 May 1998 14:28:57 +0400 To: subscribers@deity.chci.chuvashia.su From: "Serge I.Droutchin" Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Wed, 27 May 98 09:40:50 -0400 Organization: unknown Distribution: su Message-ID: Reply-To: druchin@bn3000.dd.vaz.tlt.ru NNTP-Posting-Host: aa3000.dd.vaz.tlt.ru Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 69 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 2746 Status: RO Писано 24-Май-98 10:03 Michael V. Tokarev: > > >From: "Michael V. Tokarev" > > Ну... (потупя голову и ковыряя носком ботинка пол ;) > > Я вообще-то не только здесь, я еще последние два года > > как могу, популяризирую форт на бездонных просторах > > ex-U и не безуспешно. Конечно, добрые люди помогают ;) > И надеюсь деньгами в первую очередь.(с). Если книжку напишу о и про Форт, как советуют ;) Нет, самое смешное, что пока на своей работе результаты хуже, чем в других местах, но тут дело во мне и в моих личностных проблемах. Пока я именно сею в незасоренные или от природы здравомыслящие головы полезные форт-семена ;) > > А ведь задача может быть поставлена и так: объяснить быстро > > запоминающей ;) и обучающейся машине что нужно делать в терминах > > предметной области т.е. вполне понятной прикладнику. > > Ну-у батенька -- в машинный интеллект я не верю, во всяком случае в ближайшее > будущее. Даже с новыми объемами памяти -- ее слишком мало (но это уже > другая история). Ну и я не верю. Но ведь имелось ввиду другое: быстрота запоминания -- быстрота компиляции одного форт-определения, обучение -- выработка нужной последовательности слов или построение нового слова, которые машина наконец-то выполняет так, как надо. > > К великому сожалению пока не заполнена именно область средств > > позволяющих машине помогать нам понижать уровень сложности > > при постановках, проектировании, моделировании. > > Но точно знаю, что в этом направлении есть очень серьезные > > наработки. И даже у нас :-) > Сейчас куча народу закричит ДАВАЙ!!! > ДАВАЙ!!! Да вон Донской уже проговорился ;)) а я с работы отписал уже. > Нет именно повезло. Потому что до этого мы голодали года 3. > Теперь об этом чувстве забыли (появилось другое чувство -- недосыпания, > неуспевания и т.п.). Голодание -- чрезвычайно полезная вещь, как-то интересно точки зрения смещаются. Очень много ненужного становится очам видным ;) У меня тоже неплохой опыт в этой области. Теперь страдаю от отсутствия устойчивых навыков стенографии и скорочтения (по Кузнецову-Хромову). Еще очень рекомендую у-шу. (Не боевые, мирные направления) > Где-то год назад у нас с Георгием как раз и возник спор по этому поводу. > Он говорил, что ничего нельзя сделать для перелома сознания Он прав. > и программеров и менегеров. А я писал, что есть путь -- это вбивание > своих мыслей в молодые и незаполненные (читай -- пустые) головы студней, > пока их не заполнили С++ом и Джавой. Вы правы. Некто третий: Но, Дручин, они не могут быть одновременно правы?! Оборачиваясь и с улыбкой: И ты, Третий, прав тоже. С уважением, Дручин Сергей. From chci!deity!deity.chci.chuvashia.su!news-service Wed May 27 14:23:38 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Wed, 27 May 1998 14:23:38 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA14871; Wed, 27 May 1998 15:29:20 +0400 Received: by deity.chci.chuvashia.su id OAA08468; (8.6.12/vak/1dot9) Wed, 27 May 1998 14:28:58 +0400 To: subscribers@deity.chci.chuvashia.su From: "Serge I.Droutchin" Newsgroups: relcom.comp.software-eng Subject: [News] Re: Fort. Мысли по поводу. Date: Wed, 27 May 98 09:40:50 -0400 Organization: unknown Distribution: su Message-ID: Reply-To: druchin@bn3000.dd.vaz.tlt.ru NNTP-Posting-Host: aa3000.dd.vaz.tlt.ru Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 94 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 4342 Status: RO Писано 24-Май-98 20:53 Vit Rudovich: > Вот чего у меня пока получилось. Просьба закидывать камнями и тухлыми > помидорами. А можно я кактусом? ;-)) > 1.Форт - язык функциональный. Мы это недавно обсудили с одним парнем, Можно, я тозе подумаю в этом месте? > - Форт обладает и недостатками функциональных языков. Плюс к этому, он > является низкоуровневым. Можно позиционируя С, как императивный > метаассемблер, назвать Форт процедурным метаассмблером. Эх, а вот я еще помню, как Си классифицировали как низкоуровневый язык, потому что: в нем была использована адресная арифметика; в нем использовались битовые операции; у него отсутствовал ввод/вывод; многие вещи зависели от реализации; ... наверное чего-нибудь забыл. Низок уровень не форта а стартового подмножества примитивов форта. Форт расширяем и наращиваем, а вот если я всю жизнь пишу драйвера или работаю со встроенным оборудованием, то мне и не надо очень высокого уровня абстракций. Наследование-порождение, контекстно-зависимое и векторно-табличное исполнение тоже кажутся неотъемлемыми чертами низкоуровнего языка? Способность подерживать _любую_ методологию проектирования -- тоже относит его к разряду низкоуровневых? Способность соответствовать моделям человеческого способа познания? И все это в системе программирования для 95-го, занимающей в развернутом виде ~1М, из которых почти половина -- примеры и исходник транслятора, который может работать как интерактивная произвольно наращиваемая среда и как компилятор независимых *.exe файлов формата 95/NT, откомпиленые программы которого преспокойно работают на сервере NT, который успешно имитирует жуткую перегрузку всего-то выводя на печать файл в 40М? Многие и наши и буржуи совершенно спокойно реализуют ОО на форте, и наверное потом работают в этом ключе ;) не догадываясь, что это все весьма низкого уровня... Легкость реализации системы дающей возможность писать сложную программу, как совокупность сопрограмм. Староватые примеры реальных систем, реализованных на форте, скорее всего стэндэлон: ---------------------- из книги Л. Броуди Starting Forth --------------- Экспертные системы. Для компании General Electric Corporate Research and Development на Форте была создана экспертная система диагностики дизель-электровозов. Форт также использовался компанией Applied Intelligence Systems and IRI. Inc. для промышленного прогнозирования. Центр исследований проблем сна Станфордского университета применяет созданную на Форте экспертную систему в целях идентификации моделей сна. Фирма Bell Canada выбрала Форт для реализации программ аварийной диагностики телефонной связи и сети баз данных, где единственный процессор 68000 обслуживает 32 терминала и базу данных объемом 200 МБ. Медицина. Единственный в Главном госпитале компьютер PDP-11 дает возможность одновременно обслуживать большую базу данных, где хранится информация о пациентах, управлять 32 терминалами и оптическим считывателем, делать анализ крови и измерять пульс больного в реальном времени, осуществлять статистический анализ информации из базы данных для установления соответствия между физическими симптомами заболевания, правильностью диагноза и результатами лечения. Сбор и анализ данных. Форт применяется во многих крупных обсерваториях планеты. Например, компьютер PDP-11/34 с Форт-системой полностью управляет обсерваторией, в том числе телескопом, куполом, несколькими электронно-лучевыми трубками, строчнопечатающим устройством, дисководами с гибкими дисками, и в то же время обеспечивает сбор данных по инфракрасному излучению из космоса, анализ этих данных и выдачу результатов на графический монитор. ----------------------------------- конец цитаты ----------------------- По остальным вещам мне не очень хочется что либо говорить, я не совсем понимаю, зачем тянуть ОО в форт, например ;) Еще раз обращу внимание на то, что форт лишь средство в ваших руках, очень мощное, очень гибкое, но не снимающее с вас ответственности и не дающее, как золотая рыбка, правильного и успешного пути. Это вообще _неязыковая область_ иначе давно бы уж воцарился язык универсальный... Вит, попробуйте еще писать на нем. Что-нибудь для забавы. Сначала Вы будете разочарованы и раздосадованы, потом... ;) С уважением, Дручин Сергей. From chci!deity!deity.chci.chuvashia.su!L-relcom Wed May 27 11:54:17 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Wed, 27 May 1998 11:54:17 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA11286; Wed, 27 May 1998 09:29:18 +0400 Received: by deity.chci.chuvashia.su id IAA05623; (8.6.12/vak/1dot9) Wed, 27 May 1998 08:27:40 +0400 To: subscribers@deity.chci.chuvashia.su From: vrudowit@onestone.de Newsgroups: relcom.comp.software-eng Subject: [News] CASE for us. Re: My Language Right or Wrong ;) Date: Tue, 26 May 98 08:16:10 GMT Organization: Deja News - The Leader in Internet Discussion Message-ID: <6kdto9$uhr$1@nnrp1.dejanews.com> References: <6k14bj$ein@deity.chci.chuvashia.su> <6k3isd$1j6$1@nnrp1.dejanews.com> <6kc7vm$gqd@deity.chci.chuvashia.su> NNTP-Posting-Host: 194.77.23.25 X-Article-Creation-Date: Tue May 26 08:16:10 1998 GMT X-Http-User-Agent: Mozilla/4.04 [en] (WinNT; I) X-Http-Proxy: 1.0 gate.onestone.de:8080 (Squid/1.1.5), 1.0 proxy.teuto.de:8080 (Squid/1.1.21) for client 192.168.100.76, unknown Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 166 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 6281 Status: RO In article <6kc7vm$gqd@deity.chci.chuvashia.su>, "Alexey Donskoy" wrote: > > > которуб мы хотели бы иметь (к идеальному CASE-средству ;-): > > ^^ > > Кто вы? > Мы, Николай Вторый ;-) угораздило меня выразиться за все программистское > сообщество... Я вспомнил, что Вы не так давно намеревались творить свой тул > для рисования диаграмм (готовый лучше, но по пять рублей)... > Почему бы нам ;-) сообща не составить что-то вроде ТЗ на желаемое > CASE-средство? 1. CASE не может быть универсальным. Иначе это будет столь неэффективно, что применять его будет невозможно. 2. CASE должно расчитываться на определенную группу пользователей (квалификация, обучение и пр.) 3. CASE должно быть оптимальным по соотношению выгода_применения/общие_затраты. > (Это не то чтобы шапкозакидательство, но вот тулы для Шлеер-Меллора мне > явно не по карману, а жить и работать надо ;-) BridgePoint и другие мощные CASE созданы для разработки больших проектов в больших многоуровневых коллективах. По-этому и стоят немало. Применение CASE оправдано далеко не всегда. > > Что такое таблицы решений Седова? > см. архив r.c.s-e весна 1997 > 2 moderator: где-нибудь лежит сей архив? Там много ценных мыслей! Выдало под 700 статей. Если я бы отвечал такими ссылками, то, думаю, Вы тоже бы ничего не нашли. Кстати посмотрел по архивам. 1. Хорошие идеи высказываются с завидной приодичностью (как новые.) 2. Темы обсуждения возвращаются снова и снова. Предложение: Обязать товарища доктора поручить кому-нибудь из своих студентов составить реферат(ы) на тему "Развитие идеи применения SE в реальных проектах по материалам конференции relcom.comp.software-eng" Ну и еще просьба: давайте менять текст Subj каждый раз, когда обсуждение перекидывается на новую тему. Иначе в архиве не разобраться. > Не обязательно. Что может быть проще таблицы? А все из нее растет (хотя > пока не совсем понятно, как ;-( Вот это "как" и будет самым дорогим местом. > Конечно, мужики не мало и не зря думали, методики разрабытывая. Но Вы же > сами здесь их критиковали ;-) (Кстати, где обещанные Вами материалы?) Будут. У меня пока что лежат черновики кучи начатых текстов :-) > > > - гарантия полноты разрабатываемых моделей: > > > а) транзакционность всех изменений; > > Критерии транзакционности? > ? Я имел в виду, что система должна предъявлять для проверки все взаимные > зависимости изменяемого элемента модели (кода) и не закрывать транзакцию до > тех пор, пока разработчик все эти места не проверит и флажки не выставит. > Делают ли это те же тулы для ШМ? И как решаются вопросы взаимного влияния > транзакций? Там другой принцип. Грубо говоря разрабатывается верхний уровень и тестируется. Потом более низкий уровень и т.д. Существует еще проверка полноты модели. Транзакционность мне не нравится. > > > б) автоматическая проверка полноты; > > Невозможна. Возможно только нахождение неполноты и ошибок. > Разве неполнота=false не есть полнота? Нет. Выдается тулом : количество _найденых_ ошибок == 0 > > Опять же каковы критерии доступности и удобства? > Эргономические! Четкое структурирование, 7+-2 фрейма, простота навигации и > пр. Семерка проходит. Остальное вилами по воде писано. > > > - поддержка версионности и вариантности (условная компиляция, > параллельное > > > ведение нескольких вариантов, отличающихся по функциональности); > > Я против :-) > Почему? Например, почти в любом продукте нужно предусматривать версии > Light > и Professional. Как Вы предлагаете это реализовывать - разными проектами? Professional == Light + ProfModul > > А нахрена завязываться с винтел? Против однозначно. > Да сделано тут много готового, у всех есть и грех не использовать > (ИМХО)... 1. Сделано много хренового. 2. Реализация "под" требует лишних ресурсов. 3. Можно проще и эффективнее. > Кстати, а какого рода задачи Вы в Германии решаете? Я деньги зарабатываю. > > далее по соседней статье: ... > Предлагаю не выбрасывать полезные вещи. Они очень даже тут кстати. Очень > кстати тут и ТРИЗ, и теория познания, и топология... > Каждый из нас, предлагая что-то, исходит из неких своих потребностей. Вы забываете о возможностях. :-) > (Ваши я пока не понял, поскольку в других статьях Вы очень заинтересовались > и Фортом, и КомФортом). Мои - в понимании, что работать так, как я сейчас, > дальше нельзя. Но BridgePoint (или кто там еще для ШМ?), как бы они мне не > понравились, недоступны (суммы всех моих заказчиков << , и хорошего > менеджера > под рукой тоже нет ;-) Так я хочу узнать, стоит ли делать ставку на Форт? > Есть ли пригодные ГОТОВЫЕ инструменты? Насколько эффективнее/быстрее/дешевле > разработка крупных проектов на Форте? Комфорт мне нужен также как и Оберон для изучения того, как реализованы идеи, нужные мне, в этих продуктах. Хотя я уже ругался по тому поводу, что приходится разбрасываться. Давал себе слово сосредоточится на теории управления, а не получается :-( > > > Delphi. ... > Если я предлагаю заказчику сделать то и то за время T и $X, но в UNIX, да > еще Sun ему покупать Ж-), а рядом стоит толпа "голодных студентов" и > предлагает > то же, но на PC, в Дельфи, за Т/2 и $X/2, что выберет заказчик? Смотря что ему нужно. Работающая надежная программа, или красивая игрушка. > А измерить можно на маленьком тесте, а кто же будет платить за > параллельную разработку крупного проекта разными способами? Вот реальные крупные проекты как раз и начинаются с нескольких пилот-проектов. Чтобы было ясно как дешевле, быстрее и лучше. > > По этому поводу большой и толстый вопрос. > > Кто может дать метамодель Форта? Можно совсем сырую. ... > В общих чертах - все!!! остальное - частности и детали реализации (в т.ч. > следующие принятым стандартам, но они не обязательны!) > Как инструмент понижения сложности - это здорово. Это не то, что я просил :-( Ну да ладно. > -- > С уважением, Алексей Донской > alek@chavb.chuvashia.su Regards! Vit From chci!deity!deity.chci.chuvashia.su!L-relcom Fri May 29 10:51:20 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Fri, 29 May 1998 10:51:20 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA02482; Thu, 28 May 1998 21:38:20 +0400 Received: by deity.chci.chuvashia.su id UAA25999; (8.6.12/vak/1dot9) Thu, 28 May 1998 20:37:39 +0400 To: subscribers@deity.chci.chuvashia.su From: "Alexey N. Donskoy" Newsgroups: relcom.comp.software-eng Subject: [News] Re: CASE for us. Re: My Language Right or Wrong ;) Date: Thu, 28 May 98 19:39:41 +0400 Organization: AVTOVAZBANK Distribution: su Message-ID: References: <6kdto9$uhr$1@nnrp1.dejanews.com> Reply-To: "Alexey N. Donskoy" NNTP-Posting-Host: deity.chci.chuvashia.su Mime-Version: 1.0 X-Return-Path: deity.chci.chuvashia.su!chci!chavb!chavb.chuvashia.su!alek Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 85 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 3607 Status: RO Hi ! vrudowit@onestone.de (vrudowit@onestone.de) wrote: > 1. CASE не может быть универсальным. Иначе это будет столь неэффективно, что > применять его будет невозможно. ОС на Вашем компьютере = универсальна. Однако, неэффективна, если это Win95. Однако, редактировать графики или таблицы из Ворда + прочие удобства = good. Однако, глючит и даже тексты корежит. Однако, где разумная конкуренция MS Office? Однако, для управления промышленным оборудованием я возьму другую ОС ;-) Т.е., я хотел показать многоплановость и неоднозначность любого утверждения. Систему, которая удовлетворяет 70-90% моих потребностей, я назову универсальной (и не буду неправ). > 2. CASE должно расчитываться на определенную группу пользователей > (квалификация, обучение и пр.) а) даже в Ворде можно работать через меню "Правка" или нажимать Shift+Ins (и даже писать макросы всякие, чего 90% _квалифицированных_ секретарей не умеют) - т.е., хорошая система должна предоставлять несколько путей (уровней) работы (не навязывая при этом самый идиотский); б) видели ли Вы фортепиано подростковое, фортепиано докторское и пр.? Тем не менее - это универсальный инструмент ;-) - т.е., методика должна быть простой, но не мешающей творчеству (хорошее противоречие!) > 3. CASE должно быть оптимальным по соотношению > выгода_применения/общие_затраты. > BridgePoint и другие мощные CASE созданы для разработки больших проектов в > больших многоуровневых коллективах. По-этому и стоят немало. Применение CASE > оправдано далеко не всегда. Так в r.c.s-e и не дал никто ответа, когда оправдано, когда нет ;-( Мне лично нужен хоть какой-нибудь тул, достало уже "кустарное производство". И рисовать диаграммки на бумажке, как тут мне советовали, хотя и полезно (практикой проверено!), но жутко неудобно. Пусть этот CASE будет вроде Turbo Pascal - просто и дешево. А вот если навороты пойдут типа поддержки коллективной разработки - тут и цену можно увеличить ;-) > Там другой принцип. Грубо говоря разрабатывается верхний уровень и > тестируется. Потом более низкий уровень и т.д. Существует еще проверка полноты > модели. Транзакционность мне не нравится. Жизненный цикл, изменение требований => перепроектирование... Начали транзакцию, изменили верхний уровень, спустились до самого низу, проверили полноту, закончили транзакцию... Да и не всегда это удобно. Вот живопись, например, по прототипам и итерациям работает... А результаты получше, чем в SE ;-) > > > Опять же каковы критерии доступности и удобства? > > Эргономические! Четкое структурирование, 7+-2 фрейма, простота навигации и > > пр. > Семерка проходит. Остальное вилами по воде писано. четкое структурирование => 7, но не наоборот, или будет бардак > Professional == Light + ProfModul пожалуйста, подробнее! > > Если я предлагаю заказчику сделать то и то за время T и $X, но в UNIX, да > > еще Sun ему покупать Ж-), а рядом стоит толпа "голодных студентов" и > > предлагает > > то же, но на PC, в Дельфи, за Т/2 и $X/2, что выберет заказчик? > Смотря что ему нужно. Работающая надежная программа, или красивая игрушка. Разница выявится не сразу (а может, и вовсе не выявится из-за неразвитости или личных предпочтений заказчика). Что касается subj, то, ИМХО, чтобы лучше оценить возможности, надо осознать свои потребности, что я и предлагал. Если потребностей больше ни у кого нет, можно закрыть тему (до следующего витка спирали ;-) -- С уважением, Алексей Донской -- E-mail: alek@chavb.chuvashia.su http://www.chuvashia.su/timer From chci!deity!deity.chci.chuvashia.su!news-service Fri May 29 13:48:19 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Fri, 29 May 1998 13:48:19 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA16111; Fri, 29 May 1998 14:43:25 +0400 Received: by deity.chci.chuvashia.su id NAA06007; (8.6.12/vak/1dot9) Fri, 29 May 1998 13:42:20 +0400 To: subscribers@deity.chci.chuvashia.su From: druchin@bn3000.dd.vaz.tlt.ru (Serge I.Droutchin) Newsgroups: relcom.comp.software-eng Subject: [News] Re: Re: Fort. Мысли по поводу. Date: Fri, 29 May 98 10:25:30 -0400 Organization: General Department of Development, AutoVAZ Distribution: world Message-ID: References: Reply-To: druchin@bn3000.dd.vaz.tlt.ru NNTP-Posting-Host: aa3000.dd.vaz.tlt.ru Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 23 MIME-Version: 1.0 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 1027 Status: RO >From: Andrey V Khavryutchenko >О! Вит, тебе нужно пообщаться с г-ном Alex Usoff, тусующемся в >fido7.su.oop. Он на асме сваял некую жутко паралельную объектную систему и >с ее помощью штампует системы уровня управлением предприятием (по его >словам). Правда я успел с ним горшки побить, т.к. он жутко не любит >определять термины, которыми пользуется :-\ Ассемблер -- болезнь кустарей и самоучек. А упертые в него товарищи встречаются мне со времен IBM 360/370 ;) Ну а с обычным человеческим языком у них бывают нелады, техжаргон в смеси с нижегородским им ближе. Вообще, ассемблер, строго говоря, не является языком программирования, это данность процессора (мнемомашкод) и конкретные дополнительные возможности транслятора с этого ассемблера. Конечно, его применение бывает оправдано, бывает необходимо, бывает единственно возможно. Но приведенный пример -- ближе к полюсу, а для пром-сти производства софта лучше подальше от полюсов. С уважением, Дручин Сергей. From chci!deity!deity.chci.chuvashia.su!L-relcom Mon Jun 01 09:45:01 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Mon, 1 Jun 1998 09:45:01 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA21519; Fri, 29 May 1998 21:48:26 +0400 Received: by deity.chci.chuvashia.su id UAA00335; (8.6.12/vak/1dot9) Fri, 29 May 1998 20:40:57 +0400 To: subscribers@deity.chci.chuvashia.su From: Ruslan Shevchenko Newsgroups: relcom.comp.software-eng Subject: [News] Re: CASE for us. Re: My Language Right or Wrong ;) Date: Fri, 29 May 98 15:16:17 +0300 Organization: GlavAPU Message-ID: <356EA70B.F67D2830@Shevchenko.Kiev.UA> References: <6kdto9$uhr$1@nnrp1.dejanews.com> <6klrob$80t$1@nnrp1.dejanews.com> Reply-To: rssh@grad.kiev.ua NNTP-Posting-Host: grad-utc-28k8.ukrtel.net Mime-Version: 1.0 X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) Sender: L-relcom@deity.chci.chuvashia.su Precedence: junk Lines: 21 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 498 Status: RO > > > ? Мне лично нужен хоть какой-нибудь тул, достало уже "кустарное производство". > ? И рисовать диаграммки на бумажке, как тут мне советовали, хотя и полезно > ? (практикой проверено!), но жутко неудобно. > Я использую Graphviz ot att: http://www.research.att.com/sw/tools/graphviz/ как рисовалку. Довольно приятно. -- @= //RSSH mailto:Ruslan@Shevchenko.Kiev.UA CORBA in Ukraine ? ex-USSR: http://www.corbadev.kiev.ua From chci!deity!deity.chci.chuvashia.su!news-service Mon Jun 08 09:06:01 1998 Received: by chavb.chuvashia.su (UUPC/@ v6.14f, 10May95) with UUCP; id AA04450 Mon, 8 Jun 1998 09:06:01 +0100 Received: by chci.chuvashia.su (uumail/ache) with UUCP id AA29872; Sat, 6 Jun 1998 07:02:48 +0400 Received: by deity.chci.chuvashia.su id GAA14098; (8.6.12/vak/1dot9) Sat, 6 Jun 1998 06:00:29 +0400 To: subscribers@deity.chci.chuvashia.su From: seriakov@aha.ru (George Seriakov) Newsgroups: relcom.comp.software-eng Subject: [News] Re: My Language Right or Wrong ;) Date: Fri, 05 Jun 98 03:21:04 GMT Organization: $1000 plus $1 per byte fee for proofing commercial mail sent to me. Distribution: world Message-ID: <357be583.2999013@news.aha.ru> References: <6k1294$e6r@deity.chci.chuvashia.su> <6k3gtb$vj5$1@nnrp1.dejanews.com> NNTP-Posting-Host: p197.n77.dip.aha.ru Mime-Version: 1.0 X-Newsreader: Forte Agent 1.5/32.451 Sender: news-service@deity.chci.chuvashia.su Precedence: junk Lines: 84 Content-Type: text/plain; charset=x-cp866 Content-Transfer-Encoding: 8bit Content-Length: 2578 Status: RO Привет! On Fri, 22 May 1998 09:35:39 GMT, in relcom.comp.software-eng vrudowit@onestone.de wrote: >> Попробуем сформулировать требования к (скажем так) среде проектирования, >> которуб мы хотели бы иметь (к идеальному CASE-средству ;-): > ^^ >Кто вы? Прибавь еще меня и Козлинского. Прежде всего кейз должен поддерживать некоторую методику анализа и дизайна (A&D), для того, чтобы можно было строить систему (принимать решения) на различных уровнях абстракции. >> - поддержка всего цикла разработки вплоть до генерации кода >> (+переносимость, платформонезависимость); >Давайте тогда говорить о методиках, или наборе техник. Очень сомневаюсь, что >CASE будет проводить опрос пользователя :-) Козлинский, помнится, проводил. >> - простой и надежный механизм редукции сложности в фундаменте (Форт + >> модифицированные таблицы решений Седова?) Не знаю как за форт и ТРС, все методики A&D для этого и построены. >> - иерархическая (?) модель проекта (SM? Форт?) A&D >> - поддержка различных методик проектирования (визуальное представление и >> работа с "табличной" метамоделью в виде графов, диаграмм, формул, SQL, >> ЯВУ... >> то есть проекция метамодели в те же диаграммы и пр. - хотим - работаем с >> диаграммами, хотим - с деревом классов, хотим - выстроим те же классы >> в иерархию по другому критерию...); Главное, чтобы модели эти допускали сквозную стыковку. >Очень дорога будет реализация подобной универсальности. Это да. >> - гарантия полноты разрабатываемых моделей: >> а) транзакционность всех изменений; >Критерии транзакционности? Контроль версий на уровне репозитория имеется в виду, скорее всего. >> б) автоматическая проверка полноты; >Невозможна. Возможно только нахождение неполноты и ошибок. Неалгоритмизуемо. Возможен прогон определнных проверок по модели (типа все ли стрелки поименованы). >> - поддержка версионности и вариантности (условная компиляция, параллельное >> ведение нескольких вариантов, отличающихся по функциональности); >Я против :-) А если я попрошу? :-)) >> - средства RAD для интерфейсов; >Зачем? Я опять же против. (Ох. Ждите, ждите. Это тоже будет :-) ) Ничего страшного. Интеграция с оконным глюкалом. >> - развитые средства связи с внешним окружением: >> а) возможность использования DLL; >> б) компоненты Delphi; >> в) Active-X и все такое прочее... Библитека моделей и компонентов. >Vit --- George Seriakov (http://www.aha.ru/~seriakov/George_Seriakov.jpg)