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

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

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

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

И как часто в таких средствах бывает

> concept of replacing textual source code with user-definable semantic nodes tree.

То есть осмысленный revision control, патчи, диффы, и возможность запостить кусов кода на форум идут лесом.

Закончится все как обычно - текстовый редактор в зубы и править этот чертов файл с semantic nodes tree.

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

Присоединяюсь к мнению gods-little-toy - это начало очередного баяна. Но может, что интересное и проскользнёт.

имхо, это все только облегчит труд самих программистов, а когда "спецалисты далекие от программирования" посмотрят на это дело, то они офигеют и вспомнят о программистах

А как же проблемы безопасности? Типа будут семантически ориентированные вирусы и т.п.?

Литовский проект! Супер =) Не только на диком западе новые идеи появляются :).

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

Еще один UML?

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

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

чем выще абстракция, тем медленнее работает результат.

И выжать 100% из процессора можно только на C + asm (не чистом С!)

Да фигня все это, дальше современного ООП двигать программирование к домохозяйке бессмысленно. А все эти семантические заморочки - если бы существовал нормальный анализатор семантики живого языка, то системы машинного перевода были бы уровнем повыше ПРОМТа, а так все упрется в очередные формализмы в языке исходного кода и ни чем не будут отличаться от того, что уже есть

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

в таком случае в *nix'ах уже практически всё написано -- смотреть консольные утилиты и связи между ними

>То есть осмысленный revision control, патчи, диффы

С какой это радости? "текстовый" revision control - это само по себе костыль.

>>И выжать 100% из процессора можно только на C + asm (не чистом С!)

но на чистом ASM

>Не только на диком западе новые идеи появляются :).

Это проект Максима Кизуба который сделал Kiev Compiler.

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

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

Функциональное программирование изобретают? Ну-ну.

P. S. Все равно С вечен (почти).

Немного пиара и очередная жаба готова.

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

"А не замахнутся-ли нам на Вильяма, нашего, Шекспира?" (c) "Берегись автомобиля" :)

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

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

>и в дальнейшем специалист (может быть далёкий от программирования) сможет писать программу в удобной ему форме

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

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

с таким подходом оно уже мертво лет эдак 20 - с появлением всяких васиков, паскалей и т.д.

http://www.transhumanism-russia.ru/content/view/331/116/

> Kiev Compiler.

Что-то не видно, чтобы Prolog-like features in Java широко использовались :D

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

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

Ну, кстати, нечто похожее давно бродит...

http://www.pcmag.ru/library/detail.php?ID=6331

Наивен тот кто думает что программист переводит с человеческого языка задачу в машинный.

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

Некоторые возразят что это задача аналитика, но кому нафиг нужны быдлокодеры? Их вот вполне можно автоматизировано заменить.

в немалом числе прикладных областей, специалист в ней и есть программист в качестве второй профессии

> быдлокодеры? Их вот вполне можно автоматизировано заменить.

Только после переводчиков :D

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

А речь не идет о домохозяйках. Речь идет о по-настоящему крупных проектах, в которых существенную роль играет архитектура проекта. Для управления арзитектурой используют сложные методики, например, широко известные UML диаграммы, которые по сути представляют собое то же СОП, только в отрыве от кода. Вы не работали с продуктами Rational?

> если бы существовал нормальный анализатор семантики живого языка

Напиши :)

> в таком случае в *nix'ах уже практически всё написано -- смотреть консольные утилиты и связи между ними

Ага. Только уровнем ниже :)

История - это постоянное изобретение велосипедов, isn't it? :) Кстати, широко разрекламированная SOA - это то же и туда же. Набор модулей и связей между ними.

Программирование без программистов - всеравно что секс без девчины... Впринципе возможно - но детей не будет

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

ДРАКОН много где описан в восторженных тонах. У певца советского военно-промышленного комплекса Максима Калашникова, например. Но, выглядит все так, что на самом деле он недалеко от обычной блок-схемы ушел.

О да, человек по имени Максим Кизуб, снимающий, судя по адрессу, комнатку, в двеорце культуры МВД (или как оно там сейчас называется) это конечно сразу и литовский и проект.

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

2anonymous_incognito: зачем этот бред был допущен в новости?

/me представил ядро на этом энтерпрайз бейсике...

>Как думаете почему у Кнута все алгоритмы на ассемблере?

Потому что он садист. Сами посмотрите на его ехидно улыбающуюся физиономию - накуролесил и радуется :)

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

А еще есть такая профессия, как инженер по знаниям.
Впрочем, профессия программиста вряд ли исчезнет.
Идеальной базы знаний не построить, так как в любой предметной области много субъективной информации.
Но облегчить процесс программирования, используя некоторые мат. модели, можно.

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

для тех, кто не ходит по ссылкам, расскажите плз, че там? Аффтар сего поделия ниасилил prolog? я прав?

> А еще есть такая профессия, как инженер по знаниям.

> Впрочем, профессия программиста вряд ли исчезнет.

> Идеальной базы знаний не построить, так как в любой предметной области много субъективной информации.

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

> И еще - при развитии и более широком использовании баз знаний, проблема авторского права будет очень серьезной, так как "рефакторинг" (использование) знаний упростится.

Ахтунг! Гуманитарии на ЛОР-е!

>>И выжать 100% из процессора можно только на C + asm (не чистом С!)

>но на чистом ASM

было бы правдой лет пятнадцать назад. В наше же время процы делают не для людей, а для компиляторов, поэтому 100% из проца может выжать только компилятор, написанный производителем проца ;)

Ээээ ... типа ... а где примеры Семантически-ориентированных Программ ? По ссылкам нашел только кучу лозунгов.

>С какой это радости? "текстовый" revision control - это само по себе костыль.

Заблуждение..

gods-little-toy +1 согласен..

>И выжать 100% из процессора можно только на C + asm (не чистом С!)
>но на чистом ASM

Какой нахрен C? или C+Asm(это только костыль будет..)
рельно выжать на 100% можно только на Асме..смиритесь

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

на каком именно асме?) и что вы собрались выжимать? переносимость? стабильность ?:-)

Мда... чем то напомнает этапы развития игровой компьютерной отрасли - сперва пытались - и все радовались, потом ждали нового и радовались, потом ждали нового продолжения от старого и радовались, а теперь с каждым днем их появляется эм... много! и что? Все прилавки полны игр - а ты тока смотришь на эти радости с круглыми глазами, но что бы купить попользоваться ими у тебя не возникает даже мысли, теряется все это. Так же я наблюдай и сейчас в области програмирования, был один язык - а сейчас елси перечислить все спобосы создания одного тока хеловорда здесь пера не хватит. Зачем столько? нет чтобы выбрать определенные ветки развития программостроеня и доводить их до ума каждую. А получаетс что каждый наровит написать свое, в итоге рядовому программисту в попользование сотни технологий программирования и найти ты что в сочетании с мозгами даст максимальный кпд недопустимо сложно... ИМХО

Почитал и не понимаю, почему такие простые и лежащие на поверхности идеи воспринимаются в штыки. Почему-то большинство отписавшихся здесь и на РСДН априори считает, что программа - это текст. Откуда вы взяли эту догму? Программы _как правило_ представляют в виде текста по той лишь причине, что с текстом достаточно просто и удобно работать. Однако, текст программы несёт в себе кучу избыточной информации. Те же отступы, например, как правило, никакой семантической нагрузки не несут. Одному нравится четыте пробела, а другому - один таб, отсюда вечная ругань, и даже GNU indent не спасает. Или фигурные скобки vs begin-end vs отступы, сколько гигабайтов уже нафлеймлено, хотя все эти формы записи более-менее эквивалентны. Отсюда и мысль: создать некоторую нормальную форму представления компьютерных программ, в виде графа или не важно, чего. Так, чтобы эта форма была инвариантна по отношению к разным преобразованиям синтаксиса и прочей мишуре. То есть, человек скачивает из репозитория код в этой "нормальной форме", преобразует её в своё любимое текстовое представление, вносит изменения, преобразует обратно. А уж какой синтаксис он использует, "begin-end", "начел-кончел" или вообще какие-нибудь S-выражения, и по сколько пробелов он там делает отступы, никого не волнует - на конечный результат это не влияет. Все отмазки типа "а чо ваще, у нас diff умеет работать только с текстовыми файлами" - детский сад и мракобесие.

Вообще, текстовая форма обладает кучей ограничений и недостатков. Хотя бы потому, что длинные строчки не умещаются на экране. Или в глазах начинает рябить от разных значков типа $%@#!, как будто программа напичкана криптованными матами. Всё это - тяжкое наследие текстовых терминалов, АЦПУ и перфокарт. Но ведь можно использовать какие-то цветовые обозначения, разные шрифты, изображения, всякие хитрые символы, да фиг знает, надо только приложить фантазию. Собственно, все приличные редакторы сейчас умеют подсветку кода, только она самостоятельного смыслового значения сейчас не имеет и используется только для облегчения чтения. Вполне разумным кажется развить эту идею и использовать все эти нетекстовые штуки для визуализации и редактирования кода в "нормальной" (нетекстовой) форме. Впрочем, это давно уже используют, да та же DrScheme, или Mathematica. Почему этот подход до сих пор не завоевал мир - для меня загадка.

Ещё мысль. Текстовое представление программ не обеспечивает их семантической целостности. Я имею в виду, если мы в одном месте перееименуем какую-нибудь переменную, а в другом забудем это сделать, будет лажа. Отсюда всякие костыли для автоматизированного рефакторинга. Разумным было бы завести какую-нибудь таблицу типа "id integer primary key, имя_переменной varchar(256)". И все упоминания каждой переменной заменять ссылками на соответствующую строку в этой таблице. Почему-то прогрессивное человечество давно уже осознало, что для хранения сложных данных удобнее использовать не текстовые файлы, реляционные базы данных, и никто не говорит "фтопку оракел, grep и awk его не поддерживают". Ну так, программы разве не сложные структуры данных?

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

Что-то ещё mauhuur вспомнился и его DSL Engine. :)

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

ИМХО - автор путает семантику с улучшениями в синтактике. Это "немного" разные понятия. Или Тарский наше всё ?

>А уж какой синтаксис он использует, "begin-end", "начел-кончел" или вообще какие-нибудь S-выражения, и по сколько пробелов он там делает отступы, никого не волнует - на конечный результат это не влияет. Все отмазки типа "а чо ваще, у нас diff умеет работать только с текстовыми файлами" - детский сад и мракобесие.

Щас сюда прийдут кошерные программисты и тебя затопчут

> Разумным было бы завести какую-нибудь таблицу типа "id integer primary key, имя_переменной varchar(256)".

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

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

См. пост lg от 10.06.2007 10:04:11

P.S. С месяц--другой назад тут один товарищ тоже, помнится,
махал флагом, что 

int a, b ;
...
a ^= b ^= a ^= b

быстрее, чем

template<typename _T>
inline void swap( _T &a, _T &b )
{
  _T tmp = a ;
  a = b ;
  b = tmp ;
}
...
int a, b ;
...
swap( a, b );

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