1
хотел использовать слово парадигма - но не знаю как - вопрошание
в трепе не помогло.

2
sFx и Cooper - подсказали начало

sFx>2Cooper: это из серии:
sFx>Бог всесилен и всемогуч.
sFx>Может ли он создать такой камень, который не сможет поднять.


Cooper>Я сомневаюсь, что изучение древней религии может принести
Cooper>хоть какое-то прикладное применение. Врядли я с могу применить это
---------------------------------------
начало про кризис в программировании должно быть приблизительно такое:
программирование изучает формальные системы, каковыми собственно и
являются языки программирования.
формальные системы также изучает матлогика.
любая непротиворечивая формальные системы строится из набора
нескольких утверждений(не выводимых друг из друга - в некотором смысле
ортогональных) и правил вывода (почти всегда используется логика Аристотеля).
(Монографию Куратовского по общей топологии на 600 страницах - замечательный
пример такого формального изложения - читать ни кто не будет)

наверно первые два примера такого построения формальной системы -
геометрии Евклида и Лобачевского.
Изменил Лобачевский 4 постулат Евклида по поводу пересекающихся прямых -
и на тебе - другую формальную систему получил.

Да уж. При рассмотрении якобы парадокса про Него сразу видно противоречие.
Противоречие между между аксиомой про всемогущего Него и правилом
вывода исколюченного третьего от Аристотеля. Правило сие Аристотель высосал
из своего (хоть и очень уважаемого) пальца.
Правило с очевидностью
всегда до сих пор работало на конечных множествах.
в данном якобы парадоксе его пытаются применять вместе с аксиомой, описывающую
бесконечную сущность. Кто сказал что то, что хорошо работает на конечных
множествах, должно хорошо работать на бесконечных?
/*
По этому поводу есть замечательный рассказ Йона Тихого в его Звездных
дневниках как он в битком забитую бесконечную гостинницу левой задней ногой
подселил еще бесконечное колво постояльцев не увеличивая число жителей в
каждом отдельном номере. С конечными заполненными гостинницами такой
фокус проделать нельзя. То есть свойства конечных и бесконечных множеств
сушественно разные.
*/

Вывод - раз из формальной системы нельзя выкинуть аксиому о Нем - бесконечном,

из этой формальной системы надо выкинуть правило исключенного третьего.
и может добавить туда другое правило для работы с бесконечностями -
континуум - гипотезу, аксиому выбора, аксиому Мартина и т.д.
На русском языке вывод звучит так - не фиг о Нем такое спрашивать вообще.

--------------
Следующий пример построения формальных систем - правило математической
индукции Пеано, которая была им добавлена для построения такой формальной
системы как натуральные числа с операциями сложения и умножения.
Отсутствие математической индукции (читай структура - цикл) в исчислениях
высказываний первого порядка - это единственное, что отличает исчисление
высказывания первого порядка (читай SQL) от системы, содержащей арифметику
(читай Бейсик).
-------------
Далее, существует монография Пратта Языки программирования -
в которой делается вывод - что все языки программирования -
машина тьюринга, ассемблер, фортран и пл/1 (от себя - си++, паскаль, ада,
джава, бейсик, горячо ненавидимый фокспро) не отличаются друг от друга.
то что можно написать на одном - можно написать на
другом (с точностью до производительности).


Поскольку почти во всех известных (мне) языках программирования нету аксиомы о
бесконечности, все языки можно разделить на три группы:
- sql - не содержит циклов;
- все кроме sql и rsl (http://www.iist.unu.edu/raise)- содержат циклы и не содержат бесконечности;

- rsl (RAISE Specification Language) - в явной форме содержит первую актуальную
счетную бесконечность (из ординалов Канта) которая называется алеф ноль и
операции для работы с ней. почему то в rsl алеф ноль обозначается словом
chaos.

to be continued...

--
а чем же они отличаюся?
языки отличаются друг от друга только удобствами с точки зрения
программиста, использующих язык.
Удобный язык позволяет писать программу (описывать предметную
область) более быстро.
Некоторые считают (ссылки утеряны - например - очень фундаментальные
отчеты
фирмы TRW "характеристики качества программного обеспечения" были изданы в
84-86? году)
что так так очень существенная часть усилий уходит на поиск и исправление
ошибок - первая цель - уменьшение количества ошибок, совершаемых программистом
и обнаружение этих ошибок на более ранних этапах.
(
Давно надоевшее обсуждение что лучше интерпретарор (фокспро, бейсик ) или
компилятор (си паскаль модула еффель).
компилятор ищет больше ошибок и заставляет больше работать программиста
(причем добавляя "механическую работу", например, описание переменных -
убирает "интеллектуальную работу" - поиск ошибок).
)
В отчетах различных исследователей проблем программирования отмечен
факт - отношение колва ошибок программиста к написанному им
колву строчек есть константа. смотри по этому поводу работу
Прехельта (http://www.osp.ru/os/2000/12/045.htm)

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


А среднему программисту с типовымы мозгами надо использовать язык, который
позволяет описывать прикладную область (писать софту) за минимальное кол-во
строк.
Такому анализу языков языков программирования и посвящена
собственно вышеуказанная статья Прехельта.
лично я с ней согласен.
далее моя лично оценка этой характеристики (кол - во строчек) для разных
языков. числа взяты с ПОТОЛКА. они показывают мое лично мнение об этом
соотношении. и используются не более чем иллюстрация.

to be continued ...

/*\r
блин, как сюда красиво вставлять код??\r
мы эти кнопки давили, давили, давили, давили\r
*/\r
\r
\r
ordinary programmer (I mean me, I don't mean a man like Chess World Champion)\r
can keep in his mind only 7-8 entities simultaneous.\r
So language should not to force a programmer to think about\r
not essential entities (name of register of computer, for example).\r
As a result it should allow to write as few strings\r
as possible (to make as few errors as possible).\r
\r
year____language_______number of strings to keep the same solution\r
\r
\r
\r
_______Turing Machine__10000\r
_______Assembler______1000\r
1950?__Fortran_________100 and procedure-oriented expansion of SQL:\r
___________________________PL/SQL of Oracle, Watcom SQL,\r
___________________________Transact-SQL of Sybase and so on.\r
1970?__C______________10 and PL/1, Algol66, Pascal, so on.\r
1988?__C++____________5 and Ada, Java, Effel, Vault, C#, so on. \r
1990?__RSL____________1\r
___pure SQL___________ 0.5 or impossible\r
\r
\r
надо обратить внимание на количесто других языков, созданных в\r
соответствующее время.\r
к 1990 году было создано более 10000 языков.\r
То есть усилия, потраченные на путь от фортрана к С (10 кратное улучшение),\r
не идут ни в какое сравнение с усилиями, затраченные на путь от C к Jave.\r
А полученные результаты гораздо слабее.\r
Похоже на то, что достигнут предел.\r
Этот предел из себя предстваляет голая математика (которую представляют\r
языки формальных спецификаций - например RSL).\r
За меньшее число строчек не возможно однозначно описать алгоритм решения.\r
-----\r
\r
Строчки многим не нравятся - заменим строчки на что то другое\r
вот определение алгоритма любезно вспомненное Cat2-ом\r
\r
Последовательность элементарных действий, ведущая к поставленной цели\r
за конечное время и с конечным числом шагов. \r
\r
от себя переиначу \r
Записанная Последовательность элементарных действий понятных некоторому\r
исполнителю, ведущая оного к\r
поставленной цели за конечное время и с конечным числом шагов.\r
(наличие исполнителя с его субьективной оценкой - важно имхо)\r
--\r
далее теорема рожденная в годы бесславно проигранной борьбы за светлое программисткое будущее под флагом структурного программирования:\r
\r
каждая программа может быть записана в виде\r
последовательного записанных элементарных действий,\r
структуры ветвления (if then else ) и\r
структуры цикл (while do )\r
\r
выкинем строчки из размышлений - \r
макроподстановка строчка на оператор == элементарное действе или структура ветвления или структура цикл.\r
\r
----------------\r
борьба с увеличением сложности алгоритма посреством изменения языка,\r
на котором записываются операторы похожа пришла к завершающему этапу.\r
на этом направлении больше сделать ни чего не удастся.\r
\r
борьба с\r
увеличением сложностью алгоритма посредством выделения похожих \r
последовательностей операторов и оформления их как\r
подрограммы/модули\r
(сверху один вход - снизу - один оператор return : написано для однозначности)\r
не надолго откладывает проблему невозможности охватить средним умом\r
алгоритм и множество полученных подпрограмм. \r
/*\r
можно представить алгоритм пошагового\r
выделения общих последовательностей операторов\r
из первоначальной последовательности для выделения подпрограммы и\r
уменьшения длины оной. только лень \r
\r
*/\r
\r
\r
пусть алгоритм решения прикладной задачи (оно же описание прикладной области в\r
формальной системе), без подрограмм имеет сто тысяч миллионов строчек, блин,\r
операторов.\r
если разбить на подпрограммки, например, по двадцать строчек\r
получим, к примеру, пять тысяч миллионов подпрограмм и двадцать операторов\r
алгоритма решения задачи. \r
картина достаточно безрадостная.\r
\r
очень большой хаос из операторов заменен на просто большой хаос подпрограмм.\r
единственная польза - хаос подпрограмм оторван от порядка в котором они\r
записаны в новом алгоритме решения и, поэтому, это множестве подпрограмм\r
можно разбивать на менее крупные подмножества.\r
система разбивается на подсистемы.\r
или модули классифицируются каким то образом.\r
\r
и, судя по всему, это должно стать основным методом борьбы с\r
нарастающей сложностью алгоритма при усложнении задачи.\r
\r
\r
ОСНОВНЫМ МЕТОДОМ НАВЕДЕНИЯ ПОРЯДКА ПРИ ОПИСАНИИ ХАОСА \r
ПРИКЛАДНОЙ ОБЛАСТИ\r
\r
\r
\r
рекурсивное разбиение (не процесс, а готовое разбиение )\r
системы == множества всех операторов\r
(создание порядка на множестве всех операторв )\r
на подсистемы (а подсистемы на подподсистемы)\r
наверно называется архитектурой системы.\r
\r
см. /topic/18798\r
\r
to be continued ...

ссылка на ваулт
http://research.microsoft.com/Vault/
/*
не по теме
когда спрос на сертификаты си-шарп упадет,
микрософт обьявит новую революции и переход на
функциональное программирование, якобы изобретенное микрософтом
(не упоминая про другие языки, десятилетиями до микрософта, позволяющие
функциональное программирование) и начнет продажу новых сертификатов.
*/



типовая иерархия хорошей архитектуры интерактивной системы, использующей
рсубд имеет след. уровни абстракции
1 - приложение
2 - состояние приложения
3 - документ (обьект прикладной области)
4 - рекодвинвов
5 - множество записей (запрос)
6 - запись
7 - поле
8 - байт/файл - уже не рассматривается за ненадобностью, добавлено для
демнострации основной идеи.

функции -методы обьекта, соответствующего уровню
1 - инициализация/деинициализация
2 - переход к другой вершине автомата состояний (читай смена окна)
3 - коммит/роллбак/ редактирование документа/обьекта оператором
4 - скролинг по плосткости и реагирование на мышь и фокус ввода
5 - == 6
6 - select/insert/update/delete
7 - значение присвоить в переменную/извлечь из переменной
8 - write/read/seek



так как возможности компиляторов, по-видимому, исчерпаны
и программист не может уменьшить количество совершаемых ошибок
то , наверно, остается единственный путь -
уменьшение числа строчек-операторов, которые пишет
программист (при прочих равных условиях) для решения задачи.

ПАРАДИГМА

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

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


из доступных мне работ по исследованию числа строчек в программах
есть вышеупомянутая статья Прехельта.
http://www.osp.ru/os/2000/12/045.htm

у меня есть подсчитанные строчки в двух личных проектах.
Сравнивались rsl, c++ и sql.

Следствие 1\r
\tsql - не будет заменен ничем на протяжении следующих \r
100 лет\r
\r
Следствие 2\r
\tпро ООБД имеет смысл говорить на уровне Документа(Обьекта)\r
иерархии приложения\r
\r
Следствие 3 \r
\tна более нижних уровнях, относящихся к рсубд, имеет смысл\r
говорить не более чем о отображении обьектов в реляционную бд\r
(вслед за Scott W.Ambler-ом).\r
а разговоры про реляционную БД как хранилище обьектов есть\r
обман трудового народа. Как не существует, к примеру, обьектов\r
протокола SMTP на более нижних уровнях иерархии сети - \r
на транспортном или на сетевом, так и не существует ни каких \r
обьектов на уровне реляционной БД (в предложенной иерарихии - на\r
уровне Множества строчек ). Существует образ обьекта в виде\r
множества из множеств строчек. Но некоторая информация об обьекте\r
безвозвратно утеряна. Она существует только на уровне Документа(Обьекта) \r
/*\r
/topic/12523\r
*/\r
\r
\r
\r
Следствие 4\r
\tООБД должны проектироваться с максимальным использованием\r
возможностей рсубд. К примеру те ограничения целостности, которые\r
соответствуют уровням рсубд обязаны быть записаны на языке \r
рсубд. Их ни в коем случае нельзя выносить на более высокий уровень\r
Документа (Обьекта). /* такие предложения делались в треде рсубд-\r
как хранилище обьектов */\r
Это ведет к увеличению кода и, кроме этого, к нарушения\r
12-го правила Кодда (напомненного by Cat2):\r
не должно быть языка способного нарушить целостность данных.\r
(а в ообд - основным средством работы - языком будет язык работы с обьектами уровня Документ, поскольку останется язык рсубд - и ограничения целостности, проверяемые обьектным языкам лежат выше его (рсубд) уровня, он (язык рсубд) и станет нарушителем 12 правила Кодда)\r
\r
Следствие 5\r
\tСтиль программирования, насажденный микрософтом под виндовс\r
(у которого корни живут в винвовс 3.11 и изложены в фундаментальной монографииПедзольда), загадочным образом не совмещается с предложенной иерархией. Такие примеры как микроскопический, по сравнению с виндовс,\r
Photon из QNX или экспериментальная швейцарская система (\r
название и ссылка утеряна) наводят на мысль, что кривой виндовс.\r
и лепить его в "хорошую" ( архитектуру - все равно, что лепить горбатого к стене.\r
\r
Комментарий\r
Большое кол-во разнообразных оболочек есть косвенным свидетельством\r
непрекащающихся попыток улучить кривизну исходной среды - виндовса. \r
\r
--------\r
все

приложение 1
ссылки по формальным спецификациям
http://www.cs.iastate.edu/~leavens/larchc++.html
http://s3.informatik.uni-essen.de/publications/
http://www.cs.concordia.ca/htbin/fac_page.cgi?Alagar

/*
при попытке найти ссыли на проверяльщик языка Z - fuzz
наткнулся на любопытную статейку - про тестирование виндюков
http://www.cs.wisc.edu/~bart/fuzz/fuzz-nt.html
*/

ссылка на fuzz - Spivey (Oxford) - автор мануила по fuzz
http://spivey.oriel.ox.ac.uk/~mike/fuzz/ - она у меня не работает
-------------------

>которой будет условный оператор) Совсем ошибок связанных с использование >условных операторов не будет в программе написанной на языке в котором нет >условных операторов (проверка на крайних точках).

там будут другие ошибки, связанные с использованием других операторов.


>В языке RSL есть условные оператор. И поэтому ошибки там будут. И

ошибки связанные с использованием if будут.
кстати в rsl-методе принято начинать писать спецификации с
аппликативного стиля (аппликативный - описательный / алгебраический -
императивный - обычный програмный с переменными)
там условный оператор применяется существенно реже.


>компилятор их пропустит.

согласен, но условный оператор - это 'вещественное' выражение в языке
программирования правил вывода логики Аристотеля.
и ошибки такого рода будут везде где применяется такое правило.
--------------------------------
какие языки не используют условные операторы?
sql, lisp???, prolog- тут я не очень помню


с новым годом

пытался найти ссылку на занятную работу
Klaus Renzel Error Handling for Business Information Systems от 16.01.2003
и нашел список литературы


http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htmAppendices/literature.htm

и

http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm