Доброго времени суток!

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

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

Что касается хранимых процедур и т.п., то Вы, наверное не в курсе, что в Access'е есть и очень удобный построитель макросов, и редактор кода на Вижуалбейсике, а набранный в построителе макрос можно автоматически преобразовать в модуль на Вижуалбейсике.
Да, Вы правы, с этим я не сталкивался. Но вот что гласит справка по Access 2002 ("Выбор между использованием макросов и программ Visual Basic"):
Макрос является удобным средством выполнения простых задач, таких как открытие и закрытие форм или запуск отчетов...
Программы Visual Basic используют вместо макросов в следующих случаях:
- Упрощение управления базой данных. Поскольку макросы являются объектами, существующими отдельно от использующих их форм и отчетов, поддержание базы данных, в которой реакция на события в формах и отчетах определяется многими макросами, становится достаточно затруднительным...
Таким образом, как я понимаю, макросы имеют вспомогательное значение, и для серьезной разработки все равно нужно писать модуль на VB.

P.S.
Что-то мы в offtopic свалились.

С уважением,

О тонкостях внедрения.
В технаре все ходят с квадратными глазами. Ибо пришло два приказа сверху:
1. По возможности внедрять Linux
2. В обязательном порядке использовать в обучении ПО "Гранд Смета" :)))))))))) Каковая под win32

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

Кроме сомнительного по качеству Access какие ещё примеры подобных систем?
На примерах понятнее.

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

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

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

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

Есть другая аналогия, вскрывающая ту же проблему. Языки с Си-синтаксисом -- это приоритет синтеза (скорости набора над анализом). Модула и Оберон исходят из другого критерия (важнее анализ, возможность держать все под контролем).  Хочу обратить внимание на существенную разницу в подходах: Си-синтаксис заточен на удобство синтеза исходного текста (экономит время написания); виртовский синтаксис -- на удобство анализа исходного текста (экономит время на понимание программы -- с целью проверки и модификации). Писать компактно (синтез) просто так не получится, приходится жертвовать пониманием (анализ). Одни готовы идти на эти жертвы (нужно написать быстро и сейчас), другие -– нет. Другие предпочитают иметь меньше проблем при анализе. Оно и понятно, что пишет человек один раз, а вот читать приходится -– много. Так где лучше экономить время?

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

К чему подталкивает желание экономить время при наборе текста? К неаккуратности. Причем неаккуратности даже не внешней, а смысловой. Меня не удивляет то, что работа с отладчиками и системами тестирования -- это норма для современных языков. Мир Модулы-2 мне открыл совсем иной подход. Я стал не кодировать (как при работе на Фортране, Си или даже том же классическом Паскале -- с этих языков я начинал), а КОНСТРУИРОВАЛ. При этом меня не интересовало желание побыстрее скомпилировать что-нибудь и запустить. Зачем? Я методично конструировал здание (модуль, совокупность модулей). Шаг за шагом. И спокойно анализировал исходный текст. Не один день. На этом не экономил. При таком подходе для меня крайне важен синтаксис, позволяющий постоянно работать в режиме анализа. Я вообще не пользовался никаким отладчиком (хотя в той же TopSpeed Modula-2 или в Logitech Modula-2 отладчики по своему уровню превосходили ведущие отладчики для других языков). Мне не нужен был и посмертный отладчик. Это качественно иной подход к программированию. И он дает результат такого качества, которого очень трудно добиться в мире языков с Си-синтаксисом.

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

Доброго времени суток!

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

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

Для меня лично отсутствие представления в виде текста/гипертекста ведет к утрате целостного понимания системы и потере контроля над ней. Видимо, у нас с Вами разные типы мышления :)

С уважением,

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

Что касается хранимых процедур и т.п., то Вы, наверное не в курсе, что в Access'е есть и очень удобный построитель макросов, и редактор кода на Вижуалбейсике, а набранный в построителе макрос можно автоматически преобразовать в модуль на Вижуалбейсике.

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


Кстати, при вводе мышкой снижается вероятность ошибок (включая смысловые, т.к. используются подсказки), а это - уменьшение времени на отладку.
Возможно, но потом не вспомнить, поставил ли галочку в диалоге 3-го уровня вложенности или нет.
Для меня лично отсутствие представления в виде текста/гипертекста ведет к утрате целостного понимания системы и потере контроля над ней. Видимо, у нас с Вами разные типы мышления :)

Кстати, да. Первейшая и основная "отладка" - это анализ системы. Любое облегчение синтеза должно вводиться только в том случае, когда оно не затрудняет анализ (пример нарушения этого правила С-синтаксис).

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

Ответ на »сообщение 2681« (Илья Ермаков)
___________________________
Насколько мне известно, в ЛЮБОМ языке программирования производительнось, выраженная в строках кода за период, примерно одинаковая.
Это неверная информация. Если ставиться требование "готового и 100%-надёжного кода", то очень даже разная. Для С/С++ приводятся цифры порядка 15 тыс. строк в год на Западе и 18 тыс. строк в наших фирмах (в чём причина отличия - не знаю).

Доброго времени суток!

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

Access'ом большей частью пользуются не профессиональные программисты, а аналитики, офисные работники, которым SQL без надобности, и изучать нет никакого резона.
Согласен, поэтому давайте не будем распространять стиль Access'а повсюду только потому, что он хорошо подходит для Ваших задач.
Даже если брать только СУБД, то в клиент-серверных системах метаданные БД всегда представимы в виде SQL-скрипта, и логику хранимых процедур и триггеров в общем случае с помощью конструкторов и мастеров выразить невозможно.
Я всего один раз имел дело с Access, и мне он очень не понравился, как раз из-за ориентации на мышь.
Кстати, при вводе мышкой снижается вероятность ошибок (включая смысловые, т.к. используются подсказки), а это - уменьшение времени на отладку.
Возможно, но потом не вспомнить, поставил ли галочку в диалоге 3-го уровня вложенности или нет.

Для меня лично отсутствие представления в виде текста/гипертекста ведет к утрате целостного понимания системы и потере контроля над ней. Видимо, у нас с Вами разные типы мышления :)

С уважением,

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


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

Ну вот, один пишет, что конструктором запросов в Access мало кто пользуется - вручную код запроса проще ввести, другой пишет прямо противоположное... Эх, эксперты, кому из вас верить... :о))


Мне. Access'ом большей частью пользуются не профессиональные программисты, а аналитики, офисные работники, которым SQL без надобности, и изучать нет никакого резона.

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

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

Ответ на »сообщение 2678« (Илья Ермаков)
___________________________
Например, захотел пополнить список импорта - ткнул в IMPORT, и из выпавшего списка выбрал добавляемый модуль (или где-то нашел его браузером). Если же где-то приспичит сделать рукописный ввод, то его пришлось бы разбирать парсером, проверять, интегрировать в документ - целая история.
Сергей, Вы хоть представляете, насколько падает производительность, если я буду список импорта пополнять через списки мышкой? Вот это, действительно, целая история. Вы знаете, но нормальная производительность на КП - это около 6 тыс. строк кода с человека в месяц. Вы думаете, что это реально "натюкать" мышкой? Другое дело, что общие схемы проекта, автогенерацию каркаса отдельных частей кода - т.е. то, что сейчас делается на бумажке и ручками, можно было бы вести через соотв. инструменты. Но относительно этого момента я сказал выше - пока ещё толком не ясно, какими именно должны быть такие инструменты. Только вырисовывается.

Возьмите самую что ни на есть графическую задачу - вёрстку брошюры. Плавали, знаем - набрать с типографским качеством в тегах LaTeX гораздо быстрее, чем тюхаться с Офисом, в котором всё поминутно съезжает (и не говорите, что это "от неумения работать", для крупных документов в Офисах "разъезжание" неизбежно, даже если Вы всё вылижете, то оно может поползёт при первой же правке единственного абзаца). Потому что тегом я могу указать ТОЧНО, чего я хочу, а мышью - только приблизительно...

Ну, не надо в пример приводить заведомо халтурный офис. Есть же специализированные программы верстки. И мышью Вы можете всё указать точно, был бы толковый графический интерфейс (скажем так, "цифровой", а не "аналоговый"). А то, что Офис сделан хуже LaTeX'а, так это не имеет никакого отношения к способу ввода.

Мышкой можно "натюкать" гораздо больше, чем клавишами, и вот почему: прежде, чем "тюкать" солидное время тратится на определение того, что же именно надо "тюкать". И здесь графический интерфейс с его подсказками, средствами поиска, гиперссылками, КОРОТКИМИ (в хорошем интерфейсе) списками выбора и т.п. очень увеличивает производительность. Т.е. для измерения производительности нужно брать всё время разработки, а не только время собственно ввода. Кстати, при вводе мышкой снижается вероятность ошибок (включая смысловые, т.к. используются подсказки), а это - уменьшение времени на отладку.

Насколько мне известно, в ЛЮБОМ языке программирования производительнось, выраженная в строках кода за период, примерно одинаковая. Но 6 тыс. строк ассемблера - это гораздо меньший объем в смысле функциональности разрабатываемого приложения, чем 6 тыс. строк на том же Обероне. То есть, с повышением уровня абстракции эффективность каждой строчки кода растет. После перехода с клавиатурного набора операторов на "мышиный" ввод целых конструкций эффективность еще больше вырастет. А если еще учесть подсказки, удобные средства поиска и т.п. автоматизацию, то на прежние 6 тыс. строк Вы будете смотреть уже по-другому.

А вот с примером я промахнулся. Список импорта вообще не должен никах вводиться - ни с клавиатуры, ни выбором из списка. Он должен формироваться АВТОМАТИЧЕСКИ при использовании идентификаторов из других модулей - с уведомлением программиста.

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