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

Ответ на »сообщение 2649« (Сергей Прохоренко)
Поскольку параллельно с программным кодом должна формироваться сложным образом организованная структура модуля, то здесь нельзя обойтись встраиванием парсера в RAD. Наоборот, исходить надо из того, что структура программного модуля первична, а ее наполнение - вторично.

Совершенно верно, "встраиванием парсера в RAD" такие задачи не решаются...
Мне нравится вариант с наличием стандартизированного для языка интерфейса доступа к структуре программы. Когда любой инструмент RAD не занимается разборкой плоского исходника, а начинает через этот интерфейс работать с деревом структуры программы. Для Ada такой стандарт есть - ASIS. Нужно нечто подобное и для Оберона (OSIS?). В этой области, кстати говоря, есть с кем консультироваться - для известнейшей реализации Ada - GNAT - поддержкой ASIS занимается с.н.с. НИИВЦ МГУ С.Рыбин.

"Окологипертекстовые идеи" - это по мне гораздо симпатичнее, чем идеи абстрактной графики. Основной упор не на форму представления (которая может сочетать и текст, и графику), а на интерактивность.
Но только обязательное "отсутствие пустого места" - опять как-то фанатично... Т.е. в обязательном порядке организовывать для программиста "заполнение полей анкеты"? :-) С тырканьем мышкой или табуляцией там, где можно непосредственно записать мысль "на бумагу"...

Я попробую даже точно сформулировать требование к разным "инструментам поддержки". Они должны уметь в любой момент становиться абсолютно незаметными и ненавязчивыми. Нужны - есть, только стали мешать - мгновенно ушли с горизнота и дали простор прямой работе... И тут наилучший путь как раз, как Вы правильно заметили, - в сторону интерактивных документов...
(Хм... Вы всё на Pedsovet.org порывались с идеями, а там многие до сих пор Блэкбоксу неголотекстовый формат исходников простить не могут... :-) ).

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

Ответ на »сообщение 2669« (Сергей Прохоренко)
___________________________
В плане интерфейса они (IDE) гораздо хуже бизнес-приложений.
Дело в том, что бизнес приложения гораздо более узко специализированны.


Это просто неверно, не соответствует действительности. Такие приложения, как Excel и Access не являются специализированными. Они предназначены для решения сколь угодно широкого (в функциональном смысле) спектра задач, правда имеются ограничения по размеру задач (до 1 Гб в Access, до 1 млн. строк в таблице в последней версии Excel, а до этого было всего 64 тыс. строк), да и скорость обработки данных невелика (особенно в Excel). Я имел дело с полноценными ERP/АСУП, реализованными на связке Excel-Access в крупных компаниях. В этих приложениях есть и построители макросов, и встроенный Вижуалбейсик, и ODBC (а Access - это настоящая СУБД), и солидный набор встроенных функций (более широкий - в Excel) и объектов, и средства разработки GUI.

Если же говорить о специализированных бизнес-приложениях классов Business Intelligence Business и Performance Management, то благодаря богатейшему встроенному инструментарию с их помощью можно решать задачи очень широкого спектра. Достаточно вспомнить такой модуль, как Data Integrator, который позволяет связывать данные из любых источников, фильтровать, проверять на корректность, трансформировать и закачивать в хранилище данных (Data Warehouse). А уж по возможностям построения GUI этим приложениям нет равных.


Они отличаются от среды программирования, как готовые гаджеты от рабочего места радиомонтажника.


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


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


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


1. Очень сложный навороченный интерфейс. Отсутствие наглядности и "интуитивной понятности".
Интуитивной понятности для неспециалиста? Как не отображай состояние химического завода, интуитивно понятным для несведущего в данной технологии оно не будет.


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


2. Зацикленность на ООП и построении форм.
Это две очень разных претензии: ООП используется для борьбы со сложностью и для решающих маленькие задачи не привлекательно, а построение форм, один из немногих почти всегда применимых шаблонов.


Я говорю о том, что IDE должна быть универсальной, а имеющиеся IDE, напротив, заточены под ООП и формы. Мне не важны причины такой однобокости. Важен результат.


3. Отвлекающая подсветка синтаксиса "вырви глаз".
Я не знаю ни одной среды программирования, в которой не было бы возможности настроить цвета под свой вкус.


Дело не в цвете, а в том, что она отвлекает. Расцвечивать разными цветами имеет смысл идентификаторы, а зачем расцвечивать стандартные конструкции языка? Для них лучше подходят пиктограммы и связывающие линии.


4. Недостаточная автоматизация по принципу "нажал на кномпку - и мешок на спине".
Слишком разнообразные задачи - потребуется куча кнопок.


Разъясняю смысл шутки: нажатие на кнопку приводит не к автоматическому выполнению операции, а к тому, что мешок оказывается на спине, и дальше надо тащить его на своем горбу - делать всё вручную.


7. Половинчатость в реализации именно графического интерфейса.
Какой графический интерфейс Вы имеет в виду. Сейчас другого практически не встречается.


В том то и проблема, что все IDE похожи друг на друга как близнецы. Какой интерфейс я имею в виду - см. мои сообщения в этом форуме (в т.ч. ссылки) и в форуме http://forum.oberoncore.ru/viewtopic.php?f=7&t=389&hilit=


8. Длинные списки с прокруткой вместо кнопок "быстрого доступа", позволяющих обойтись без клавиатурного ввода.
Кнопок "быстрого доступа" к чему? Если к одному из трех вариантов, то как правило есть и кнопки и менюшки и т.д. А если к одному из сотни вариантов (хотя бы к выбору шрифта), то кнопок не напасешся.


К шаблонам конструкций языка программирования (см. ответ выше). Их немного.


9. Непонятные иконки и надписи на вкладках, очень абстрактные пункты главого меню.
Иконки предназначены для опытных пользователей - сокращают время вызова. А пунктов главного меню должно быть немного. Как сгруппировать сотню возможных действий в несколько групп с короткими но очевидными названиями - вопрос очень сложный. Тот же Access имеет весьма нетривиальное меню, особенно для тех, кто с БД не знаком :)


Это не так. Я специально открыл Access и посмотрел. Он имеет совершенно стандартное для всех оффисных программ главное меню (файл, правка, вид, вставка, сервис, окно, справка). Все нестандартные иконки подписаны.


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


Я неточно выразился. Нужна не структуризация собственно кода - она есть. Нужна структуризация документа, в котором код содержится. Причем эта структура должна быть видима, и должна быть возможность с ней манипулировать напрямую, а не выделением, копированием и вставкой текста.


11. Не чувствуется поддержка в таких областях, как WinAPI и библиотеки функций.
Практически все среды программирования имеют объектные обертки для функций WinAPI. С библиотеками функций и их использованием тоже в большинстве систем проблем нет.


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


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


Совершенно ГОЛОСЛОВНОЕ утверждение, никак не следующее из существа описанных недостатков. Из того, что я не профессиональный программист, вовсе не следует, что я не могу разглядеть недостатки, которые мешают профессиональным программистам работать с бо'льшим удобством, быстрее и безошибочнее. Во-первых, мы ведь говорим об интерфейсе, а не о языках программирования. Во-вторых, я имею вполне достаточное представление и о языках программирования, и о процессе разработки в целом (последнее, в отличие от кодирования, как раз входит в область моей ПРОФЕССИОНАЛЬНОЙ деятельности на протяжении многих лет).

Я понимаю, что Вам IDE нравятся гораздо больше, чем программирование в текстовом редакторе. Мне тоже. Но это вовсе не значит, что нужно так безапелляционно отвергать любую критику в адрес IDE. Тем более, использовать такие неэтичные приемы, как огульная ссылка на непрофессионализм оппонента без связи с конкретным предметом обсуждения.

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


На днях спрашивал разработчиков одной CAD системы что принципиально нового появится в следующей версии. Он ехидно ответил: " ничего ПРИНЦИПИАЛЬНО нового не будет - сама система конструировать не научится, конструктор все равно будет нужен".


Ну и что? Ему просто нечего сказать. Тоже мне, авторитет.

Ответ на »сообщение 2669« (Сергей Прохоренко)
___________________________
Но раз программисты до сих пор обходятся текстовым редактором, то значит, что большей частью я прав.
Не многие программисты обходятся текстовым редактором, большинство прикладных программистов работает в современных средах удовлетворяющих практически всем пунктам Вашего манифеста.
В плане интерфейса они гораздо хуже бизнес-приложений.
Дело в том, что бизнес приложения гораздо более узко специализированны.
Они отличаются от среды программирования, как готовые гаджеты от рабочего места радиомонтажника.
Универсальная среда может предоставлять огромное число шаблонов - все равно это будет ничтожно мало по сравнению с разнообразием возникающих задач. Стандартизации поддаются разработка пользовательского интерфейса и некоторые часто встречающиеся части алгоритмов и структур данных.
Отсюда все те отличия, которые вызывают Ваше неудовольствие.
1. Очень сложный навороченный интерфейс. Отсутствие наглядности и "интуитивной понятности".
Интуитивной понятности для неспециалиста? Как не отображай состояние химического завода, интуитивно понятным для несведущего в данной технологии оно не будет.
2. Зацикленность на ООП и построении форм.
Это две очень разных претензии: ООП используется для борьбы со сложностью и для решающих маленькие задачи не привлекательно, а построение форм, один из немногих почти всегда применимых шаблонов.
3. Отвлекающая подсветка синтаксиса "вырви глаз".
Я не знаю ни одной среды программирования, в которой не было бы возможности настроить цвета под свой вкус.
4. Недостаточная автоматизация по принципу "нажал на кномпку - и мешок на спине".
Слишком разнообразные задачи - потребуется куча кнопок.
5. Отсутствие подхода "от решаемой задачи предметной области", т.е. разработки "сверху вниз".
Какой-такой предметной области? Разработка сверху вниз поддерживается.
6. Отсутствие всякого рода "мастеров" и "конструкторов".
"мастеров" и "конструкторов" прорва, натраиваемых компонентов еще больше. Но типов решаемых задач необозримо больше.
7. Половинчатость в реализации именно графического интерфейса.
Какой графический интерфейс Вы имеет в виду. Сейчас другого практически не встречается.
8. Длинные списки с прокруткой вместо кнопок "быстрого доступа", позволяющих обойтись без клавиатурного ввода.
Кнопок "быстрого доступа" к чему? Если к одному из трех вариантов, то как правило есть и кнопки и менюшки и т.д. А если к одному из сотни вариантов (хотя бы к выбору шрифта), то кнопок не напасешся.
9. Непонятные иконки и надписи на вкладках, очень абстрактные пункты главого меню.
Иконки предназначены для опытных пользователей - сокращают время вызова. А пунктов главного меню должно быть немного. Как сгруппировать сотню возможных действий в несколько групп с короткими но очевидными названиями - вопрос очень сложный. Тот же Access имеет весьма нетривиальное меню, особенно для тех, кто с БД не знаком :)
10. Недостаточная структурированность программного кода.
Модули, секции, объекты, методы, процедуры, интерфейсы, записи - какая еще структуризация нужна?
11. Не чувствуется поддержка в таких областях, как WinAPI и библиотеки функций.
Практически все среды программирования имеют объектные обертки для функций WinAPI. С библиотеками функций и их использованием тоже в большинстве систем проблем нет.

В общем все претензии сводятся к тому, что система программирования не позволяет писать программы непрофессионалу.
На днях спрашивал разработчиков одной CAD системы что принципиально нового появится в следующей версии. Он ехидно ответил: " ничего ПРИНЦИПИАЛЬНО нового не будет - сама система конструировать не научится, конструктор все равно будет нужен".

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

Ответ на »сообщение 2666« (Сергей Прохоренко)
___________________________
А по поводу полезных мыслей: они не Дельфями навеяны? :)

Нет. Я вообще никогда не видел Дельфи. Я вообще-то не программист, хотя опыт программирования был - PL/I в ВУЗе (первое место занял) и древний Бейсик на работе. Оберон только начал осваивать (в силу необходимости, но не по работе). Просто по роду занятий мне приходится быть пользователем очень разнообразного программного обеспечения, а также регулярно делать разработки на Access'е.

Мне вообще-то не очень понравились те IDE, которые я видел (хотя я не в восторге и от Блэкбокса). В плане интерфейса они гораздо хуже бизнес-приложений. Сама идея хорошая, но реализация неудачная. Я вижу следующие недостатки:
1. Очень сложный навороченный интерфейс. Отсутствие наглядности и "интуитивной понятности".
2. Зацикленность на ООП и построении форм.
3. Отвлекающая подсветка синтаксиса "вырви глаз".
4. Недостаточная автоматизация по принципу "нажал на кномпку - и мешок на спине".
5. Отсутствие подхода "от решаемой задачи предметной области", т.е. разработки "сверху вниз".
6. Отсутствие всякого рода "мастеров" и "конструкторов".
7. Половинчатость в реализации именно графического интерфейса.
8. Длинные списки с прокруткой вместо кнопок "быстрого доступа", позволяющих обойтись без клавиатурного ввода.
9. Непонятные иконки и надписи на вкладках, очень абстрактные пункты главого меню.
10. Недостаточная структурированность программного кода.
11. Не чувствуется поддержка в таких областях, как WinAPI и библиотеки функций.

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

Ответ на »сообщение 2666« (Сергей Прохоренко)
___________________________
А по поводу полезных мыслей: они не Дельфями навеяны? :)

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

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

Два примера того, как мог бы выглядеть действительно эффективный (в отличие от блок-схем) графический интерфейс программирования:

http://gurin.tomsknet.ru/visual2k.html

http://rsdn.ru/article/philosophy/LOP.xml

Просто - к све'дению

Еще пара ссылок:

http://www.eplsw.com/Introduction_IDE.asp

http://community.sharpdevelop.net/blogs/mattward/articles/FeatureTourCodeGeneration.aspx

Несколько, надеюсь, полезных мыслей по поводу графического интерфейса программирования:
1. Программный модуль на пост-Обероне (это не обязательно для других языков) должен быть полностью структурированным гипертекстовым документом, не содержащим ничего, что может быть охарактеризовано как "просто программный код". Поскольку параллельно с программным кодом должна формироваться сложным образом организованная структура модуля, то здесь нельзя обойтись встраиванием парсера в RAD. Наоборот, исходить надо из того, что структура программного модуля первична, а ее наполнение - вторично. Не должно быть "пустого места", куда может быть введен программный код, который потом еще должен как-то распознаваться и структурироваться.
2. Необходимы автоматически формируемые оглавление и указатель (идентификаторов) на боковой панели, а также панель перехода к модулям проекта.
3. Необходим механизм просмотра истории изменений с возможным откатом к предыдущим версиям (как в Ворде или Википедии).
4. Должна в первую очередь поддерживаться разработка программы методом "сверху вниз", то есть от структуры к реализации, для чего необходимы заголовки, заглушки и шаблоны, которые в дальнейшем будут конкретизированы (насторены или заменены программным кодом). Программный код, требующий конкретизации, должен выделяться жирным шрифтом.
5. Должна также поддерживаться разработка библиотек компонентов (т.е. метод разработки "снизу вверх") - как? - это еще требует уточнения.
6. Для перемещения между разными местами в модуле и между модулями необходимы кнопки "Назад" и "Вперед", закладки, ярлыки (для доступа из файлового менеджера) и внешние гиперссылки (для доступа из браузера).
7. Необходима боковая панель типа "Зависимости объектов" в MS Access. Посмотреть ее можно так: в MS Access 2003 (но не ранних версий) щелчком правой клавиши мыши по любой таблице вызвать локальное меню и выбрать в нем "Зависимости".
8. Необходима автозамена имен. Если изменяется имя модуля или процедуры, то это не должно сказываться на доступности описанных в них идентификаторов.
9. Должно быть несколько режимов отображения программного модуля на экране (на соответствующих вкладках):
- просмотр (по умолчанию)
- правка (может быть запрещена)
- для печати
- веб-страница
Кроме того, нужны вкладки:
- обсуждение (для па'рного или коллективного программирования)
- история
10. Целесообразно ввести дополнительный уровень абстракции для инкапсуляции всех объектов, относящихся к какой-либо подсистеме моделируемой системы (не в смысле, в котором это слово используется в Блэкбоксе). При этом неважно, содержатся ли инкапсулируемые объекты в одном модуле (новый уровень ниже уровня модуля - хотя такая возможность необязательна) или в нескольких модулях (новый уровень выше уровня модуля - как в Блэкбоксе, но только нужны еще и механизмы инкапсуляции).
11. Для всей моделируемой системы целесообразно также ввести уровень "проект" (это многие предлагают).

Ответ на »сообщение 2664« (Как слышно? Приём!)
___________________________

Ответ на »сообщение 2661« (Valery Solovey)
___________________________
>>> модели первичны (предпосылка чего-то нового), а графика вторична

90% информации человек получает по зрительному каналу.
Манипулировать графическими объектами эффективнее.
Примером успех Дельфи и прочих визуальных сред.
Сложные системы в инженерии без чертежа представить вообще невозможно.
Утверждать что первично, а что вторично - это слишком рискованно.
В рамках гештальт теории в философии показывается, что, наоборот, зрительные
представления составляют основу нового знания, служат для построения новых
моделей в различных предметных областях, являются генераторами новых идей.
Построение математической теории является уже финальной фазой исследования
когда подвижный бетон застывает, формирует остов и предоставляет конструкцию,
готовую к тиражированию, которую знающий математику человек может повторно
использовать в схожих ситуациях.

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

Ответ на »сообщение 2661« (Valery Solovey)
___________________________
>>> модели первичны (предпосылка чего-то нового), а графика вторична

90% информации человек получает по зрительному каналу.
Манипулировать графическими объектами эффективнее.
Примером успех Дельфи и прочих визуальных сред.
Сложные системы в инженерии без чертежа представить вообще невозможно.
Утверждать что первично, а что вторично - это слишком рискованно.
В рамках гештальт теории в философии показывается, что, наоборот, зрительные
представления составляют основу нового знания, служат для построения новых
моделей в различных предметных областях, являются генераторами новых идей.
Построение математической теории является уже финальной фазой исследования
когда подвижный бетон застывает, формирует остов и предоставляет конструкцию,
готовую к тиражированию, которую знающий математику человек может повторно
использовать в схожих ситуациях.
Как указывалось, есть люди с различным воспитанием, восприятием и обучением.
И тот факт, что сейчас, действительно, символьные методы более распространены
можно объяснить тем же, чем большую распространенность правшей - традицией.
Никто Вас лично силком не тянет в визуальные системы анализа и разработки.
Считаете верхом совершенства текстовой редактор плюс компилятор и достигли
совершенства в использовании этих средств - за Вас можно только порадоваться.
Паганини, ходит миф, мог и на одной струне играть. Может Вы тоже обессмертите своё имя.
Или, более приземлённо, вот ещё - некоторые на бутылках любят симфонии исполнять.

Ответ на »сообщение 2658« (Zuzza)
___________________________

>>> Кто-нибудь г-на Раскина читал? Сформулируйте что Вы хотите сделать.undefined

Ну вот и читали мы с тобой Раскина - и что изменилось? Если проект Роса так интересен - ну давай что-нибудь для него действительно сформулируем! Эдак... конструктивно! А не так...