Семантически Ориентированное Программирование

У японцев не так :).

> Некоторые мысли лучше "овеществляются" в виде картинок. Самый очевидные примеры - чертеж или картина.

А ещё есть мнение (психолога Тони Бьюзена), что для человеческого мозга наиболее естественная структура -- интеллект-карты (http://en.wikipedia.org/wiki/Mind_map).

Что опять приводит нас к языкам программирования основанных на графам: Lisp, scheme, XML, ... :-))

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

:) Понятно, с чертежами ты не в теме. Тогда другой, более банальный пример. Видел схему метро ? А теперь представь что было бы если вместо простой и понятной всем картинки там был plain text. Считаешь было бы нагляднее ?

> Что опять приводит нас к языкам программирования основанных на графам: Lisp, scheme, XML, ... :-))

а что означает "основанных на графах" ?

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

Противоестественные ?!! Хм-м... Товарищи, гомосапиенс в его нынешнем виде существует уже десятки, а то и сотни тысяч лет. Устройство мозгов у него имеет такой возраст. А теперь вспомним когда человечество научилось писать и читать ?

Огромное количество людей до сих пор не умеет этого делать. Чертеж это рисунок. Наскальные рисунки помните ?

Другое дело разные люди по разному воспринимают и запоминают информацию. Одни легче запоминают информацию в виде образов и очень плохо запоминают в виде набора слов. Дригие, наоборот, могут запомнить набор слов иногда совершенно не понимая его смысла. Толькор сейчас придумал им определение - абстрактники. Ну, помните, есть такие - зубрилки. Запомнят набор слов и вперед, на экзамен. Лично я визуал - понимание любого процесса для меня - представление его визуально. Поэтому математика для меня темный лес т.к. представить математическую формулу для меня сложно. Хотя не то что сложно, просто преподают математику у нас не визуальными представлениями, а словесными...

> А теперь вспомним когда человечество научилось писать и читать ?

А, да, кстати, если мне тот же текст прочитают, то на слух я ещё лучше его смогу воспринять.

Да, конечно было бы нагляднее.

Я, собственно, так её для себя и переписал, в виде текста. Иначе слишком долго искать, как из точки A в точку B проехать.

> Лично мне гораздо понятнее прочитать чистым текстом (желательно без формулок) о том, как работает двигатель внутреннего сгорания, чем пытаться разобраться с его чертежом.

Если нужен принцип, то да. Только чертеж (= схема) при этом тоже не помешает, чтобы не приходилось в уме представлять где же там что, или хочешь сказать, что схемы на http://ru.wikipedia.org/wiki/Бензиновый_Двигатель совсем лишние и непонятны?

А в случае сложных чертежей с большим количеством значащих деталей, текстовое описание чертежа намного сложнее самого чертежа (полное текстовое описание двигателя реального автомобиля с описанием формы деталей я не уверен, что смогу представить). Полное текстовое описание реактивного двигателя видел: чертеж (достаточнго простой) -- полстраницы + описание на 30 страниц (и то без чертежа с трудом воспринималось).

Ещё можешь глянуть http://ru.wikipedia.org/wiki/Гироскоп -- раздел "Свойства роторного гироскопа" и попытаться понять текст, не глядя на схему справа (конкретно положение осей гироскопа). :-)

>> Что опять приводит нас к языкам программирования основанных на графам: Lisp, scheme, XML, ... :-))

>а что означает "основанных на графах" ?

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

> Я, собственно, так её для себя и переписал, в виде текста. Иначе слишком долго искать, как из точки A в точку B проехать.

Я хочу это видеть! Можешь выложить?

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

ааафигеть... они опять изобрели блок-схемы :D

Я уже давно в Москве не бывал, так что схемку уже и потерял. Но могу восстановить, принцип там очень простой.

> Я, собственно, так её для себя и переписал, в виде текста. Иначе слишком долго искать, как из точки A в точку B проехать.

:) Круто! Может "напишешь" как ты ее представляешь в виде текста ?

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

Или я чего-то непойму или я отстал от жизни, но программа на лиспе это последовательность строчек текста ?

http://www.metro.ru/map/2005/

А я-то думаю "Что мне это все напоминает?" :)

> Или я чего-то непойму или я отстал от жизни, но программа на лиспе это последовательность строчек текста ?

Не совсем. В С оператор = строка текста, которая разбирается согласно некой грамматике. строки разделяются символами ";"

В Лисп программе оператор = список, элементами которого являются другие списки, то есть дерево. Аналогично, данные. Поэтому, в общем случае в C-подобных языках eval принимает на вход строку (и поэтому так страшен eval в python), в Lisp-подобных языках eval принимает на вход дерево.

Есть еще semantic web тоже хорошая штука :)

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

Кроме того, освоение синтаксиса некоторого языка - это простая и второстепенная задача, основной работой программистов было и остаётся конструирование алгоритмов. Затея с унификацией синтаксиса напоминает хармсовский Солнцетермос.

Только мне не нравяться революцинеры? Да, людям легче усваивать образы, одако они их усваивали-усваивали и придумали математику (формализовали образы - усложнили себе жизнь) - построили цивилизацию, а тут им предлагают опять жизнь "упростить". Господа революционеры - вы прежде чем кричать про наше новое всё вникните в то что уже есть. Особенно повеселило про графы. Может ещё гиперграфы - можно, с виду всё красиво, особенно K5,K6 а вот даже ту же гомеоморфность - пойди определи. Тут даже планарность махоньких графов, вершин в 1000 определить не могут, а вы господа планируете на миллион (БОЛЬШИЕ ПРОЕКТЫ :-) ). В общем учиться, а потом на базе опыта, смоделировать процесс - потщательней, и нам рассказать как крута.

PS:не повышайте энтропию - ещё успеете

> Не совсем. В С оператор = строка текста, которая разбирается согласно некой грамматике. строки разделяются символами ";"

Да, но разбирается оно в промежуточное представление - AST, которое и есть по сути граф. Это наглядно продемонстрировано в camlp4 и Nemerle. Получается, что си-шная грамматика лишь несколько извращенный текстовый способ записи графа AST.

> В Лисп программе оператор = список, элементами которого являются другие списки, то есть дерево. Аналогично, данные. Поэтому, в общем случае в C-подобных языках eval принимает на вход строку

Не обязательно. Могут принимать на вход AST.

>> ... В С оператор = строка текста ...

> Да, но разбирается оно в промежуточное представление - AST, которое и есть по сути граф. ... Получается, что си-шная грамматика лишь несколько извращенный текстовый способ записи графа AST.

Я именно это и утверждаю. Точнее утверждаю, что для человека проще выражать свое представление алгоритма в тех языках, где этот самый граф доступен для просмотра/редактирования.

>> C-подобных языках eval принимает на вход строку

> Не обязательно. Могут принимать на вход AST.

Как мне в Perl или Python в eval запихнуть AST? Особенно в Python, т.к. обилие внутри eval \n\t\t выглядит очень некрасиво :-(

> Кроме того, освоение синтаксиса некоторого языка - это простая и второстепенная задача, основной работой программистов было и остаётся конструирование алгоритмов.

Синтаксис определяет мышление. Проектируя только на ассемблере/Си/Паскале/Бейсике тяжело мыслить категориями ООП, использовать сложные структуры (списки, деревья, хэши, ...).

Для каждого синтаксис есть родные структуры данных и программ.

Pascal приучает к мысли, что всё есть процедура (или блок кода).

C заставляет мыслить в терминах указателей и чисел. Структурная единица программы = функция.

Perl вынуждает мыслить в категориях -- строка, regexp, хэш

Python и Java вынуждают мыслить в категориях классов и объектов

Ocaml добавляет в мышление pattern matching.

Haskell -- ленивые вычисления и монады.

Forth -- идею изменяемго синтаксиса

Lisp -- удобство работы со списками и деревьями

Common Lisp позволяет практически все вышеперечисленное http://www.paulgraham.com/avg.html

> Я именно это и утверждаю. Точнее утверждаю, что для человека проще выражать свое представление алгоритма в тех языках, где этот самый граф доступен для просмотра/редактирования.

Всмысле "для просмотра и редактирования" ? Когда ты пишешь программу на Cи ты редактируешь и просматриваешь граф AST, записанный в текстовом виде.

> Как мне в Perl или Python в eval запихнуть AST? Особенно в Python, т.к. обилие внутри eval \n\t\t выглядит очень некрасиво :-(

Я не программист на питоне, но думаю ответ здесь http://docs.python.org/lib/node885.html

> Как мне в Perl или Python в eval запихнуть AST? Особенно в Python,
т.к. обилие внутри eval \n\t\t выглядит очень некрасиво :-(

Вообще-то, можно, хотя и несколько через ж-пу:

>>> import compiler
>>> from compiler.ast import Expression, Add, Const
>>> ast = Expression(Add((Const(40), Const(2))))
>>> compiler.misc.set_filename('<INPUT>', ast)
>>> code = compiler.pycodegen.ExpressionCodeGenerator(ast).getCode()
>>> answer = eval(code)
>>> print answer
42

> Когда ты пишешь программу на Cи ты редактируешь и просматриваешь граф AST, записанный в текстовом виде.

Я не могу добавить правила. Например для ООП, для хэшей, для строк без концевого нулевого символа и т.д.

Согласен. Каждый язык заявляет определённый способ реализации определённых концепций и парадигм и предоставляет для этого соответствующий синтаксис. Это, кстати, ещё один довод против унификации синтаксиса. Однако настоящая работа с языком начинается, когда синтаксис и разные фичи изучены, и теперь нужно применить всё это для решения конкретной задачи.

Унификация тут вообще зло :). В той же математике для каждой области есть свой язык. Если попробовать тервер, мат логику и матан выразить одним унифицированым языком - получится что-то вроде естественного языка :). С вытекающей отсюда сложностью работы с ним.

PS: Прекратите забивать гвозди микроскопами. Для этого есть молотки. И кувалдами мебельные гвоздики тоже забивать не нужно.

> Я не могу добавить правила. Например для ООП, для хэшей, для строк без концевого нулевого символа и т.д.

Просто в Си нету такого механизма (хотя ничто не мешает его туда приделать в виде развитого препроцессора). Зато такой механизм есть в Ocaml и Nemerle.

> Зато такой механизм есть в Ocaml и Nemerle.

В Nemerle действительно симпатичный механизм макросов. А насчет Ocaml я где-то недопонял. разве там есть расширение синтаксиса?

Угу, camlp4

Взято с http://www.paulgraham.com/avg.html
Хех! Не в бровь а в глаз! Жаль Виталика вокруг нету :)
---8<------------
But there is a contradiction in the conventional wisdom: Lisp will make you a better programmer, and yet you won't use it.
Why not? Programming languages are just tools, after all. If Lisp really does yield better programs, you should use it. And if it doesn't, then who needs it?
---8<------------