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

> Гы, открыл Америку! Открой для себя IntelliJ IDEA, она все это уже давно делает. И делает хорошо.

IDEA - кастыль, как и остальные рефакторилки.

> Это начало конца программированию как профессии?

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

Какое нонче самое сложное дело при написании софта? Правильно --- собрать, проанализировать и структурировать требования. Почему? Да потому, что программисты "лезут" уже почти что во все профессии.

SOP --- это возможность автоматизировать свои действия для всех. Сбор требований больше не нужен (не утрирую, но лишь гиперболизирую:)) --- программу пишет тот, кому она нужна. Уж с самим собой он сам как-нибудь договорится:)

thedailywtf.com не читали? там было описание одной такой системы. ядро этой системы работало с диаграммами процессов описаных в visio. Сложность задачи величина в рамках задачи величина постоянная. В не зависимости от способа представления.

Так дело то все в том, что программировать вообще не сложно. Освоить програмирование могут даже люди прослужившие в армии 20 лет. Сложность в задаче, в понимании задачи и в построении непротиворечивой модели решения задачи.

А вот таких гениальных изобретателей надо в газовые камеры.

1. Одно из важнейших правил аксессабилити: "Информация никогда не должна быть представлена только цветом". Даже светофор помимо цветовых обозначений во всем мире имеет одинаковое расположение индикаторов.

2. Информация представленная однородно сложнее понимается, но обучиться одному виду представления информации проще. Расширить визуальную составляющую можно и после написания системы (чем и занимаются современные среды и инструменты для рефакторинга).

3. Единое представление информации - это интерфейс позволяющий связывать программы между собой. При отсутствии такого интерфейса - его придется придумать.

А шо вы думаете таки про это: http://rsdn.ru/Forum/Message.aspx?mid=2532092&only=1

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

Смотрим на beryl и видим что то же самое сделано меньшей кровью и за гораздо меньшие деньги.

Далее смотрим на opensource fs с postgresql внизу и видим что это было сделано за год с небольшим _очень_небольшой_коммандой_.

Делаем вывод - что потолок не в програмировании, а в бестолковом управлении в microsoft. Возможно еще и в сверхвысокой сложности разработки под windows, что может быть результатом низкого качества кода и слишком большого числа абстракций и большого количества изобретенных велосипедов.

ёXOR,

ты нифига фишку не прорубаешь. :)

Речь шла не о том, чтобы использовать цвета и картинки. А о создании единой, и не обязательно текстовой, универсальной формы представления кода программы. Ну, допустим, в виде графа. Этот граф ты можешь визуализировать как тебе угодно - хоть кружочки со стрелочками, хоть привычный текст с бегином и эндом, хоть тот же текст, но с фигурными скобками, хоть китайские иероглифы, хоть шумерская клинопись. И никакие, блин, дальтоники не будут обижены, потому что никто их не заставляет использовать цветовые обозначения, и никаким тру программёрам не придётся обламываться, они по прежнему будут править plain text в своём виме или емаксе.

Иными словами, исходником программы предлагается считать не текст, а AST, или типа того. AST первичен, текст вторичен. Только и всего. Непосредственно с этим ASTом будут работать и IDE, и VCS, и компиляторы, и все остальные инструменты. (Правда, сабжевый автор, как я понял, предлагает пойти ещё дальше, и использовать не синтаксическое, а семантическое дерево, и вот это уже имхо утопия. Ну и фиг с ней.)

Или, если хочешь, воспринимай эту всю тему как язык программирования с индивидуально настраиваемым синтаксисом. Примерно так же, как настраивается подсветка в современных редакторах.

Или как стили виджетов в графических тулкитах.

Я доступно излагаю? :)

Я конечно дико извиняюсь, но ИМХО программирование в его нынешнем виде это жуткое убожество. И вообще, не смотря на, казалось бы, большие достижения в области программирования, с точки зрения мировой революции оно, программирование, находится сейчас в (относительно, конечно) убогом и зачаточном состоянии. Неужели кто-то думает, что через 15-20 лет прикладные программисты будут также лабать программы на этих корявых так называемых "объектно-ориентированных" (вы хоть сами понимаете смысл этого словосочетания) С++, Питонах, Дельфях и протчее ? А через 50 лет ? Не знаю будет ли это семантическое программирование, но то, что оно будет другим, это к бабке не ходи !!!....

Поиски святого Грааля программирования идут с самого начала программирования как дисциплины и как профессии. Но исходя из того, что современный компьютер был и остается потомком программируемого калькулятора, который, в свою очередь, является потомком машины Бэбиджа, то как бы народ не изголялся этот самый Грааль "машина! Сделай мне ЭТО!" означает всего навсего зачатие и рождение собственного ребенка и его обучение. Именно поэтому классные программисты - "психи", поскольку тупо сублимируют, а не занимаются "делом" ;-). Понятно, что это кайф, когда "оно работает так, как Я сказал!", но даже собаку (достаточно умное животное) не научишь делать того, чему можно научить человека! Все вышесказанное лишний раз (см. труды Минского, CYC и др. AI-проекты) показывает: нехер решать организационную проблему (не все созданы программистами) техническими средствами. Оптимизировать компиляторы под процессоры и повводить более мощные парадигмы программирования - пожалуйста, можно и нужно! Но вот превращать человека со всей его человечностью, страхами, желаниями, творческими порывыми и изращениями в придаток машины - не надо. Программисты (т.е те, кто имеют душевную склонность и способности к этому делу) пусть программируют, а те у кого такой склонности нет - пусть занимаются тем, к чему есть. Домохозяйки домохозяйничают, блондинки - удовлетворяют, гуманитарии - пишут стихи и рисуют/лепят...

Я конечно дико извиняюсь, но ИМХО программирование в его нынешнем виде это жуткое убожество. [...]

Э-э-э... А мсье сам много написал?

Трансляция в байт-код? Java и .NET? Проблема в адекватности семантики различных предметных областей. Ты представляешь разницу на уровне ПОНЯТИЙ между китайским профессором-историком с их четырехтысячелетней культурой и, например, современного подростка, воспитанного на ТВ-рекламе и Доме-2? Или систему образов паталогоанатома и дизайнера ландшафта? Конструктора боевого вертолета и конструктора Burj Al Arab? Ты (этот чувак) говоришь, по-сути, о едином языке, едином способе выражения ЗНАНИЙ! Этого просто не будет. Слишком много различий в предметной области. Слишком мало экспертов в этих областях, чтоб составить полные непротиворечивые словари для такого единого формата. Похожий проект под Eclipse Foundation, Stellarium вроде, успешно загнулся, а ведь он предлагал гораздо меньшее - просто различное представление на java-кода: хочешь - объектно-ориентрованное, хочешь - процедурное.

Вот я и говорю газовые камеры. О том как представить задачу думают и думают. Лучше чем то, что придумали математики за 160 000 лет пока нету ничего. ЯП - это продолжение идей математических языков. А с вашими визуализаторами получается вот что: http://worsethanfailure.com/Articles/The_Customer-Friendly_System.aspx

А по поводу фишки. Единая и универсальная форма представления уже есть - текст. Отображать его можешь как хочешь. Увы от _СЛОЖНОСТИ_ЗАДАЧИ_ это никак не спасает. И не может спасти.

> Ты (этот чувак) говоришь, по-сути, о едином языке, едином способе выражения ЗНАНИЙ!

Не совсем так. Я предлагаю гораздо более приземлённую вещь - единый способ выражения ИСХОДНОГО КОДА ПРОГРАММ. И то он, очевидно, будет свой собственный для каждого отдельного языка. Единое представления сишного кода и кода на Хаскеле - это будет та ещё хохма. :) Но представьте, например, что в Питоне появятся опциональные фигурные скобки вместо отступов, или в Руби появятся опциональные отступы вместо фигурных скобок, причём форму представления кода можно будет выбирать по вкусу и менять на лету.

> Трансляция в байт-код? Java и .NET? Проблема в адекватности семантики различных предметных областей.

Типа того, но не совсем. Я предлагаю вместо текстовых исходников использовать сразу некий AST, и с этим ASTом работать непосредственно. Ну или преобразовывать его в текст и обратно. И в тарболы класть исходники в виде этого ASTа. В каком формате его хранить - это дело десятое. И естественно, для каждого языка и AST будет свой, тут я иллюзий не строю. Предлагается абстрагироваться лишь от (текстового) синтаксиса, а не от семантики.

> А по поводу фишки. Единая и универсальная форма представления уже есть - текст. Отображать его можешь как хочешь. Увы от _СЛОЖНОСТИ_ЗАДАЧИ_ это никак не спасает. И не может спасти.

Есть ещё одна -- граф.

Можно отображать структурой (а-ля XML-редактор)

Можно отображать текстом (прямолинейный вариант = Lisp, непрямолинейный -- через любую граммтаику)

Можно отображать в БД...

Разве что второй набор UNIX-утилит придется писать, чтобы они были ориентированы на узлы, а не на строки.

> Лучше чем то, что придумали математики за 160 000 лет пока нету ничего. ЯП - это продолжение идей математических языков.

Во! Прямо в точку. ЯП - это продолжение идей математических языков, втиснутое в узкие рамки ASCII-текста. Ну представь, открывает студент Фихтенгольца, а там прямо ASCII-текстом ему написано: \frac{df}{dx} = \lim_{x \rightarrow x_0} \frac{f(x) - f(x_0)}{x - x_0} и т. д. :D Но люди, однако, пользуются кучей разных символов и значков и не пытаются всю математическую запись утрамбовать в двумерный текст, ибо осознают, что математическое выражения - это скорее дерево, чем текст. Как и код программы для ЭВМ. Любой компилятор по исходному тексту строит некоторое дерево, потом это дерево преобразует в другое дерево, и т. д. Любая рефакторилка делает примерно то же самое. Любой паршивый класс-браузер из любой IDE обратно вынужден заниматься этим же: из текстового представления получать древовидную структуру. Обрати внимание: по тексту построить дерево гораздо сложнее, чем из дерева получить текст. Так что предлагается хранить и распространять не текстовые исходники, а готовые деревья. Чем эта идея плоха?

Cложность задачи тут не причём, я только предполагаю, что это сможет сделать работу программиста более удобной. Ты ведь наверняка используешь разные умные IDE, чтобы они часть грязной работы взяли на себя, а не пишешь код голыми руками в уиндоуз нотапеде? :P

> Есть ещё одна -- граф.

Хех, наконец-то хоть кто-то фишку прорубил. :)

а граф разве в результате не будет хранится как поток байт? двумерный поток байт? и что мешает этот поток представить ввиде текста?

> thedailywtf.com не читали? там было описание одной такой системы. ядро этой системы работало с диаграммами процессов описаных в visio.

Нет. Но интересено пишут :)

> Сложность задачи величина в рамках задачи величина постоянная. В не зависимости от способа представления.

От способа представления зависит не сложность задачи, а сложность ее восприятия. Сложность этой страницы не увеличится, если ее просматривать без браузера. Хотите - откройте в Firefox DOM Inspector, там будет дерево.

> а граф разве в результате не будет хранится как поток байт?

В UNIX всё поток байт. Включая изображения и базы данных :-)

> двумерный поток байт?

А это что такое?

> и что мешает этот поток представить ввиде текста?

Граф в виде текста -- это Lisp. Или XML (тоже типа текст). Вот работать с текстовым представлением не всегда удобнее. Тебе ж не придет в голову .svg текстовым редактором создавать? Хотя там тоже текст :-)

Автор, как я понимаю, предлагает создать по сути "идеальный декомпилятор".
Извините, но это утопия.
Например:
Я пишу программу в виде С-кода, сохранаю в это "блаблабла нисовершатьполовыхдействий уникальное" поделие.
Затем её (в виде этой "единой формы представления") скачивает быдлокодер, который кроме явы и шарпа ничего не знает.
Открывает.
А теперь внимание, вопрос. Что он увидит, если супер-мега-гига-IDE для этой бяки даже и представит ему всё в виде явовского кода?
В лучшем случае - один класс с 100-4000 членов.
Ещё "лучше" будет если я попытаюсь представить в виде ANSI C исходник, первоначально писанный на объектно-ориентированном языке (хоть на той же яве). И так далее.

> а граф разве в результате не будет хранится как поток байт?
> двумерный поток байт? и что мешает этот поток представить ввиде
> текста?

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

> Автор, как я понимаю, предлагает создать по сути "идеальный декомпилятор".

Как я понял, автор предлагает создать _среду_, в которой декомпиляция максимально облегчена, также как и понимание программ программистом.

>> Есть ещё одна -- граф.

> Хех, наконец-то хоть кто-то фишку прорубил. :)

а чем тебя пролог не устроил?

Не только прологовские программы представимы в виде графов.

>Не только прологовские программы представимы в виде графов.

а зачем прологовские программы представлять в виде графа?

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

>А теперь внимание, вопрос. Что он увидит, если супер-мега-гига-IDE для этой бяки даже и представит ему всё в виде явовского кода?
>В лучшем случае - один класс с 100-4000 членов.

не обязательно. Можно делать отображение файл -> класс. Тогда увидит
 что-то типа твоей исходной программы. Вот только компилироваться 
она не будет из-за несоответствия библиотек.

>Ещё "лучше" будет если я попытаюсь представить в виде ANSI C исходник, первоначально писанный на объектно-ориентированном языке
 (хоть на той же яве). И так далее.

Без проблем

C++:
class A
{
  int memeber;
  void f(int x);
}
...
---------
C:
struct A
{
   int member;
};
void A_f(struct A *this, int v)

не осилил все читать, но мне кажется сам создатель слабо уверен в возможности довести это до юзабельного состояния. всё это похоже затеяно для того чтобы можно было добавить еще парочку "крутых" слов в список чем занималась его контора.

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

> Паяльщики, как профессия, вымрут. станутся профессионалы, которые конструируют чипы, их производят и собирают готовый продукт. Примерно так будет. Вопрос - как скоро?

Да уже - набивщики перфокарт вымерли лет 30 назад.

Собственно, неудача Пролога как идеи в том, что его невозможно отлаживать. Тут тоже с отладкой мягко говоря не понятно.

> Не совсем так. Я предлагаю гораздо более приземлённую вещь - единый способ выражения ИСХОДНОГО КОДА ПРОГРАММ. И то он, очевидно, будет свой собственный для каждого отдельного языка. Единое представления сишного кода и кода на Хаскеле - это будет та ещё хохма. :)

Вот к этой хохме Вы и ведёте. Т.е. по тексту я так и не понял, видится ли разница в ЯП (в частности, между функциональными языками и процедурными) (т.е. разница в _парадигмах_ ЯП). Или это всё сводится к мегагениальному способу расставлять скобочки "как я хочу"?

вот, написалось:

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


IMXO,человек должен описывать что нужно сделать,
а компилятор должен представлять собой экспертную систему,
которая подбирала-бы способ решения задачи (списки/деревья/массивы/рекурсия/циклы/нити/etc и прочие частности) или, в случае отсутствия в её БЗ подходящего случая, предлагала-бы программисту написать решение на ее внутреннем языке низкого уровня (этаком "обобщённом С"), после чего это решение через центральный сервер должно становиться доступным для всех(этакий CPAN)

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

Да скупит его разработку Sun или Microsoft за $5M и будет он щастлив до конца дней своих. Я бы тоже был на его месте, ради этого и в общаге пожить можно

Есть разные языки. Есть буквы и есть иероглифы. Ты предлагаешь заменить буквы иероглифами. Ну что ж. Учить алфавит будет сложнее. :)

Не так давно была похожая тема, "Языки программирования и иероглифы" - http://www.linux.org.ru/jump-message.jsp?msgid=1649072

Люди, а он бороду себе отращивает... так что толк будет :)

> Иными словами, исходником программы предлагается считать не текст, а AST, или типа того. AST первичен, текст вторичен. Только и всего.

И сильно AST отличается по сути от s-expr?

Не хочется обижать этого Кулибина, но по-моему его понимание языков сводится к паскалеподобным разновидностям, т.е. процедурник. Думаю, он сильно удивится, увидев НАСКОЛЬКО различается мышление (и код) в функциональных или логических языках. На ближайшие 100 лет исходный код совершенно спокойно просуществует в виде текста. Разве что рамочек всяких добавят :)

Я не понимаю этих изобретателей квадратных колёс: есть парадигма, есть языки - чего не пишется? Плохая парадигма - исправь! Но зачем же как мессия ходить и обсирать существующие и успешные решения? Его идея похожа на универсальный аппарат, которым можно доить, пить коктейли, заправлять машины и ещё надувать шарики! Шиза, да и только...

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


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

Что-то сразу вспоминается фидошный бАян про управление голосом,
админа, секретутку, "опен виндоу" и "шатдаун нахрен дура"....:))))

>Это байан. программисты они как тараканы - уже лет 30 продают средства чтоб программировать без программистов а программистов изжыть так и не удается.

Более того - после появления какого-то нововведения - их все больше и больше :р

Ещё один моск зохаван нежизнеспособной идеей построения универсального графического языка. Следом за jetbrains Кизуб потопал отважно в болото. И между ними, идущими не туда, есть нечто общее - все не смогли освоить Лисп, все жаловались на скобочки. Симптоматично-с.

> На ближайшие 100 лет исходный код совершенно спокойно просуществует в виде текста. Разве что рамочек всяких добавят :)

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

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

>Инструменты художника прошли длинный путь от кисти и красок до фотошопа, корела и тд но что-то Мону Лизу так до сих пор в фотошопе и не сотворили.

хуже, в паинте сделали:
http://rutube.ru/tracks/32407.html?v=d7ce2f47a481ed93a61ddb6bebaad129

> Потому как живой моск еле справляется и с одномерными конструкциями, а уж двумерные (в стиле того же UML) моск зохавывают в момент.

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

> рельно выжать на 100% можно только на Асме..смиритесь

к сожалению, компилятор оптимизирует гораздо лучше чем ты осилишь... если ты не эксперт по конкретному процессору. http://gns-ua.livejournal.com/26268.html

Мозг мыслит не символами, не иконками, не иероглифами, не значочками со стрелочками. Мозг мыслит образами. А наиболее адекватная визуальная форма для образа - это слово. Текст.

Кстати, программа с goto как раз совсем уже и не одномерная.

> Мозг мыслит образами. А наиболее адекватная визуальная форма для образа - это слово.

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

А как насчет этого http://www.xakep.ru/post/38388/default.asp