Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  03:22[Войти] | [Зарегистрироваться]
Обсуждение темы:
Русская ОС

Здравствуйте!

Хотелось бы знать, как народ отнесся бы к появлению проекта по созданию Руccкой ОС. Причём не только русской, но и всего русскоговорящего населения? Присоеденились бы вы к такому проекту?

Прошу не относить к флейму. Речь идёт о уже существующем проекте.

С уважением,

VICH

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 5452 сообщения



Отслеживать это обсуждение
<<<... | 2692—2683 | 2682—2673 | 2672—2663 | ...>>>
Всего сообщений в теме: 5452; страниц: 546; текущая страница: 278


№ 2682   09-09-2007 15:02 Ответить на это сообщение Ответить на это сообщение с цитированием

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

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


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

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


№ 2681   09-09-2007 12:12 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2680« (Сергей Прохоренко)
___________________________

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

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

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


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

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

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

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


№ 2679   09-09-2007 11:02 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2677« (Сергей Прохоренко)
___________________________

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

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


№ 2678   09-09-2007 10:58 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2676« (Сергей Прохоренко)
___________________________

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


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

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

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

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


№ 2677   09-09-2007 10:52 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2673« (Илья Ермаков)
___________________________

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


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

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


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


№ 2676   09-09-2007 10:38 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2672« (Илья Ермаков)
___________________________

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

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


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

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


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

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

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


№ 2674   09-09-2007 08:25 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2671« (Сергей Прохоренко)
___________________________
Сергей, я теперь лучше понимаю ваши идеи и ваши мотивы... И мне они теперь гораздо больше нравятся.

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

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

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

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


№ 2673   09-09-2007 07:49 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2666« (Сергей Прохоренко)
___________________________

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


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

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


<<<... | 2692—2683 | 2682—2673 | 2672—2663 | ...>>>
Всего сообщений в теме: 5452; страниц: 546; текущая страница: 278




Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования