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

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


Поэтому и полномасштабная поддержка ООП на первом месте - без нее со сложностью не справиться.

Есть мнение, что ООП создаёт проблем больше, чем решает...

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

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

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

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

Насчет первой части сообщения. Теория на 90% правильная. 10% - это обязатаельный просмотр низкоуровневого представления. Это целиком зависит от того, качественно ли реализовано высокоуровневое представление. Например, в Access это совершенно не нужно - это отличный продукт в отличие от микрософтовских инструментов работы с графическими объектами. Да, в исключительно редких случаях SQL-код нужен и в Access'е, но не для контроля правильности (я это знаю, потому что работаю с Access'ом более 10 лет), а потому, что в конструкторе предусмотрены не все необходимые функциональные возможности.
Аналогично: Вы же не контролируете каждый раз в ассемблере правильность работы компилятора Оберона? Вы же ему доверяете?

Но как это касается пост-Оберона? Если структура документа с кодом будет автоматически сопоставляться с результатом разбора парсером компилятора, то и вычислительная полнота, и правильность обоих уровней абстракции будут одинаковы.

По второй части сообщения: СОВЕРШЕННО НЕ ФАКТ. Вы же сами пишите, что если вычислительная полнота обоих уровней абстракции одинакова (а что мешает это сделать, если оба уровня уже изначально - при вводе кода - интегрированы друг с другом?), то нет никакой необходимости обращаться к низкоуровневому представлению. Кстати, в моем понимании оба уровня представления должны отображаться в документе с кодом ОДНОВРЕМЕННО - как структурированный текст, сопровождаемый иконками-кнопочками, раскрывающимися списками, флажками, линиями связей и прочими контролами. А вот доступ, кроме специально выделенного поля ввода текстового кода (для программистов старой закалки), должен быть через графический интерфейс. Например, захотел пополнить список импорта - ткнул в IMPORT, и из выпавшего списка выбрал добавляемый модуль (или где-то нашел его браузером). Если же где-то приспичит сделать рукописный ввод, то его пришлось бы разбирать парсером, проверять, интегрировать в документ - целая история.

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

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

Ответ на »сообщение 2666« (Сергей Прохоренко)
___________________________
Есть способ, принятый в хранилищах данных. Каждый "абзац" помечается датой и временем создания и датой и временем удаления/замены (промежуточные изменения не допускаются). Тогда для любого момента времени в прошлом можно сконфигурировать весь проект (не один документ). Хотя, конечно, механизм версий проще. Кстати, версии хорошо бы различать не толко по времени, но и по статусу (действующая стабильная версия, отлаженная версия, версия в разработке и т.п.).
Мне в этом смысле нравится SVN. Любую политику версий формирует сам разработчик, как угодно копируя файлы проекта с любого момента. А система версий только гарантирует, что эти копии "лёгкие", т.е. копируются только ссылки и дельты.

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

Ответ на »сообщение 2672« (Илья Ермаков)
___________________________
Но с Вашей мыслью, что "инструменты поддержки" нужны лишь на каком-то начальном этапе, я совершенно не согласен. Если программист при первой возможности переходит к "прямой работе" путём долбежки по клавишам, это означает только то, что "инструменты поддержки" сделаны плохо. Это всё равно как вырваться из языка высокого уровня на "простор прямой работы" в ассемблере.

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

А вот с инструментарием 4GL всё ох как неоднозначно. Тот же Access не эквивалентен по выч. полноте SQL - это очевидно. Для типовых запросов может быть удобно. Для сложных случаев я бы не стал полагаться на графику. Нет, допустимо использовать графический инструментарий конструирования схем данных - но с обязательной явной трансляцией в SQL и анализом и этого уровня. Так же, как профессиональные веб-дизайнеры не "закрываются" от html-уровня, хотя WYSWYG-интрументарий, конечно пользуют. (А Microsoftовский инструментарий, в частности, отличается отвратной генерацией кода, который потом плох для ручной обработки). Точно так же, как в вёрстке ещё ни одна графическая система не превзошла по качеству текстовый LaTeX, который является недосягаемым эталоном... Даже, казалось бы, в визуальных задачах, добиться полной эквивалентности графических оболочек по сравнению с текстовым ядром не удаётся. И в любой CAD-системе точно так же есть текстовое ядро (как AutoLISP в AutoCAD).

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

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

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


3. Необходим механизм просмотра истории изменений с возможным откатом к предыдущим версиям (как в Ворде или Википедии).

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

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

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

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

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

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

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

Ответ на »сообщение 2671« (Сергей Прохоренко)
___________________________
Это просто неверно, не соответствует действительности. Такие приложения, как Excel и Access не являются специализированными.
У нас просто очень разное понимание понятия специализированные.
Калькулятор тоже не является специализированным устройством - на нем можно выполнить любой расчет. Теоретически. А на практике никому в голову не придет подсчитывать на нем баланс банковского дня (хотя когда-то делали). Делали и в электронных таблицах. И на простых СУБД.
Вместо удобного инструментария, где всё под рукой - захламленное рабочее место.
Слишком многое должно быть под рукой. Не ложки режем :)
Что касается химического завода, то стрелочный индикатор уровня опасности будет понятен любому неспециалисту.
По этому индикатору будет ясно только пора бежать подальше или еще можно подождать. Для неспециалиста достаточно. А для управления процессом нужно знать множество параметров и, главное, понимать в чем их суть.

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

Я имел дело с полноценными ERP/АСУП, реализованными на связке Excel-Access в крупных компаниях.
Для того, чтобы еще раз подчеркнуть разницу взглядов на программирование вообще и терминологию в частности скажу крамольную вещь: я не считаю современные ERP системы сложными программами. Большими - да, сложными - нет. Вся сложность там возникает на уровне неграмотной постановки задачи.

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

Но следует сказать, что ничего в этой сфере "из головы" выдумать нельзя. Нужен большой опыт использования конкретного языка/среды, чтобы понять, ЧТО и КАК именно следует дополнить. "Зоопарк" написанных "с кондачка" дополнений к Блэкбоксу (типа подсветки синтаксиса) уже есть и не в одном экземпляре - и он не используется потом даже самими их разработчиками (с объяснением "систему обновлял - доставлять было неохота"). И дописывать ещё таким же образом - это просто плодить ту самую "свалку на рабочем месте электронщика", которую Вы в предыдущем сообщении не одобрили...
С другой стороны, навигатор кода и интерактивность в DEFINITIONs, которые я ввёл не с "кондачка", а когда встала острая потребность (работал с Kernel, который имеет весьма нетипичный для нормальных модулей размер - более 2 тыс. строк) - используются всеми в нашей команде, и я сам никогда не поленюсь их доставить - они входят Service Pack 4.

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

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

Поэтому, что касается графического инструментария - вырастет со временем. Именно таким эволюционным путём. Т.е. подход "сначала позолотим - а потом начнётся массовое использование" не заработает. Наоборот, по мере расширения использования идёт обрастание реально ценными вещами.

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

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


3. Необходим механизм просмотра истории изменений с возможным откатом к предыдущим версиям (как в Ворде или Википедии).

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