Ответ на »сообщение 3109« (Илья Ермаков)
___________________________

Ответ на »сообщение 3108« (Стэн)
___________________________

Ответ на »сообщение 3103« (Илья Ермаков)
___________________________
>>> "использование шаблонов увеличивает требования кода к соответствию компилятора стандарту". Не слабо, да: какая наглая программа, чего-то хочет от компилятора :-)
А встречный вопрос можно? Код, написанный на ББ со всеми его особенностями можно скомпилировать на КП или на классическом Обероне и наоборот?
А любой код, который компилируется на Оберон-1 будет компилироваться на Оберон-2 и наоборот?
Пример неверен - это разные языки.



Ну, то есть, Вы сами признаёте, что у каждой системы программирования обычно имеется свой собственный (хотя, может быть, очень похожий) язык, не совместимый с языками других систем программирования! Чего же после этого стОят Ваши требования к графическим системам программирования: "программа как формальная схема технической системы не должна сама по себе иметь ни малейшей привязки к конкретной системе программирования"? Или, что позволено Юпитеру, то не позволено быку? С какой стати к графическим системам программирования предъявляются более строгие требования совместимости, чем к текстовым? И так ли уж нужна эта совместимость, если на практике без нее прекрасно обходятся? Сколько разных, но совместимых графических систем программирования Вы хотите иметь, и зачем Вам несколько таких систем? Наконец, найдутся ли софтверные компании и разработчики, столь обеспокоенные вопросом совместимости с продуктами конкурентов?

Ответ на »сообщение 3110« (Илья Ермаков)
___________________________
Более того, сравнение с фотошопом неверно также и потому что речь идет о файлах данных, а не о GUI инструмента.
То есть корректное сравнение с фотошопом было бы, если бы речь шла о графическом файле jpeg который должен одинаково открываться как в фотошоп так и в paintshop, хотя при этом палитры инструментов могут быть разными.
Стандарт должен поддерживаться.
Стандартом языка программирования является его текстовое представление. Других пока нет.
Это значит, как не показывай программу на экране - результат все равно должен быть текстом.

Ответ на »сообщение 3106« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 3103« (Илья Ермаков)
___________________________

Не согласен. Это все равно как требовать, чтобы в Фотошопе и Пэйнте были одинаковые палитры инструментов. Ваше требование КАК ПРАВИЛО не выполняется даже для программ на текстовых ЯВУ.
Сергей, а мы здесь, вроде бы, говорим не про графические редакторы, а про нотацию программирования.
И нотация программирования никакого отношения к конкретной среде иметь не должна.
Это идеал, который мы должны держать в уме. На практике некоторые мелочи приходится "доводить напильником". Но и то не всегда. Пример - Ada, любая реализация которой одинаково откопилирует любую программу, соответствующую стандарту. А если не откомпилирует, то её никто не сертифицирует.

Ответ на »сообщение 3108« (Стэн)
___________________________

Ответ на »сообщение 3103« (Илья Ермаков)
___________________________
>>> "использование шаблонов увеличивает требования кода к соответствию компилятора стандарту". Не слабо, да: какая наглая программа, чего-то хочет от компилятора :-)
А встречный вопрос можно? Код, написанный на ББ со всеми его особенностями можно скомпилировать на КП или на классическом Обероне и наоборот?
А любой код, который компилируется на Оберон-1 будет компилироваться на Оберон-2 и наоборот?
Пример неверен - это разные языки.
Стандарт КП был определён именно ОберонМайкросистемз, и воплощён в ББ. Но никаким образом этот стандарт на сам ББ не опирается.
Gardens Points кое-что меняет, уходя от стандарта - это издержки дотНета, который требует, чтобы всё было к нему за уши притянуто :-)

А про С++ пример как нельзя более актуален - ни одного компилятора, соответствующего стандарту и правильного, нет. Работал с шаблонами - C++ Builder тянет их ближе к стандарту, но жутко глючен, в Visual C++ 6.0 с глюками не сталкивался, но зато были ограничения на шаблоны, код при переносе просто переставал компилироваться ("слишком много параметров у шаблона"). Ну и т.п.
Высосанные из пальца фантазии Бьярна порой слишком трудно реализовать.

Ответ на »сообщение 3103« (Илья Ермаков)
___________________________
>>> "использование шаблонов увеличивает требования кода к соответствию компилятора стандарту". Не слабо, да: какая наглая программа, чего-то хочет от компилятора :-)
А встречный вопрос можно? Код, написанный на ББ со всеми его особенностями можно скомпилировать на КП или на классическом Обероне и наоборот?
А любой код, который компилируется на Оберон-1 будет компилироваться на Оберон-2 и наоборот?

Ответ на »сообщение 3097« (Сергей Прохоренко)
___________________________
Хоть горшком назовите. В моем представлении это графика, а не текст. Но если Вы ратуете за ТАКОЙ текст, то я тоже только "за".
Давайте различать текст с элементами графического оформления (при отбрасывании которых текст не меняет смысл) и графическое представление, где часть текста ЗАМЕНЕНА графическими обозначениями.

Ответ на »сообщение 3103« (Илья Ермаков)
___________________________

Ответ на »сообщение 3095« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 3080« (Руслан Богатырев)
___________________________
Следующий шаг вперед - представление программы в форме комбинации графики и текста, обеспечиваемой средствами системы программирования.
Сергей, программа как формальная схема технической системы не должна сама по себе иметь ни малейшей привязки к конкретной системе программирования.


Не согласен. Это все равно как требовать, чтобы в Фотошопе и Пэйнте были одинаковые палитры инструментов. Ваше требование КАК ПРАВИЛО не выполняется даже для программ на текстовых ЯВУ.

Хорошая цитата из статьи по CASE-системам - http://www.osp.ru/cio/2002/01/172005/

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

Вот теперь подумайте и над такой задачей: как одновременно дать наглядность, и таки "лишить разработчика".
А не лишите - получите проблемы, известные по обычным ЯВУ.

Кстати, в Драконе эта задача решена на 100% - язык не оставляет места никакому "волюнтаризму" в представлении, у каждого элемента есть строго определённые правила положение и связывания в схеме.
Поэтому Паронджаров гордо называет Дракон формальным языком - и он прав. Потому что ему удаётся описать формально, как строятся схемы, в отрыве от реализации, сформулировав всего десяток правил.

Ответ на »сообщение 3098« (Руслан Богатырев)
___________________________


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

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

Не спорю. Голый текст (в первом приближении - гибрид XML и ЯВУ для сохранения комбинации графики и текста в памяти компьютера) останется, как остался ассемблер. Только 99% программистов не будут их использовать в своей ежедневной работе, а системы программирования будут ориентированы вовсе не на голый текст, а на комбинацию графики и текста.

Ответ на »сообщение 3095« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 3080« (Руслан Богатырев)
___________________________
Следующий шаг вперед - представление программы в форме комбинации графики и текста, обеспечиваемой средствами системы программирования.
Сергей, программа как формальная схема технической системы не должна сама по себе иметь ни малейшей привязки к конкретной системе программирования.
А то получится нечто типа фразы из спора С++-сников:
"использование шаблонов увеличивает требования кода к соответствию компилятора стандарту". Не слабо, да: какая наглая программа, чего-то хочет от компилятора :-)

Это значит, что прежде чем позиционировать графические языки как языки программирования, Вам придётся выработать систему их формального описания в отрыве от реализации. Существующие формализмы - БНФ, различные формальные семантики - ориентированы преимущественно на текст. Для графики ничего подобного пока нет.
А теперь вспомните - развитие обычных ЯВУ пошло в гору с того момента, как возникла теория трансляции.
Поэтому, если угодно продвигать графические языки - так создайте для них "графическую теорию трансляции". Тогда дело, может, и пойдёт. Только сначала прикиньте сложность проблемы. Проведите SWOT-анализ, так сказать :-)