Здравствуйте, Max.Subpixel, Вы писали:

AVC>>А в vi все просто: yy999p

MS>Ну это знаете у меня и ФАР умеет...

А у меня не умеет...
Или, по крайней мере, я не знаю, как это сделать в FAR.
Разве что нажать Ctrl-C, а затем до конца жизни не отпускать Ctrl-V.
Я уж не говорю о том, чтобы 1000 раз повторить последнюю команду редактирования или выполнить какой-нибудь макрос.

MS>И не надо помнить эти бестолковые сочетания...

Да их и не надо много помнить. Достаточно знать с десяток основных команд. Уже будет польза.
Кроме того, Vim доступен и в "гуевом варианте", с менюшками, можно почти ничего и не помнить.
А собственно о чем спор-то?
Просто когда мне нужно быстро выполнить большой объем редактирования, я использую Vim, потому что это заметно быстрее.
Поэтому я в таких случаях не собираюсь отказываться от использования vi.

Вся эта тема, конечно, оффтоп, но резюме, IMHO, такое: не все старое и "негуевое" плохо.

MS>Ну на самом деле фичка от Майкрософта при надлежащей поддержке оного становится стандартом на виндах в добровольно-принудительном характере...

Не всегда. Микрософт монополист только в самих виндах и Офисе. Он даже в браузерах уже не монополист.

А если фичка сначала появится у Мозиллы, и только потом появится ее аналог у Микрософта?

MS>И что? Ну докажете вы From и что дальше?

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

MS>Стандартизация конечно нужна от M$. Базовые классы и библиотеки на все случаи жизни. Будет это на .NET я думаю. Чего и нет. Просто не сразу. Не завтра. Все это нельзя так сразу делать. Тут организационных вопросов тьма

Кастом-атрибуты есть уже 12 лет. Воз и ныне там. Значит — не прижились.

.NET тут вообще не при чем, он пока что нуль в мире коробочного софта.

Здравствуйте, shuklin, Вы писали:

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

Да до фигищи.

Данные могут из себя представлять некую амебную массу, которую просто невозможно типизировать. Только интерпретировать и то, в каждом состоянии по свойму.

Данные могут быть слаботипизированны, тогда накладные расходы на типизацию в ООDB могут превысить все мыслимые пределы. Представь себе какие расходы будут на

<commandir>
   <mycommandir1/>
   <commandir>
      <mycommandir2/>
      <hendehoh/>
      <commandir/>
   </commandir>
</commandir>

Здесь 3 commandir и все разного типа. Здесь всего 6 разных типов, которые на которые надо иметь типизацию и уметь хранить 6 разными способами. Для реляционки такое не проблема, потому как она ее можно подвернуть так, чтобы она меньше задумывалась о типе, а больше задумывалась именно о данных.

Кто сказал что в будущем останется ООП. ООП обладает рядом недостатков, собственно поэтому его и влепили в рамки КОП. И вообще на ООП не кончается все программирование.

Когда-то Microsoft весьма живо рекламировала Ole Storage. Обещала всемерную поддержку. И где это все сейчас? Даже Office на нее не перевели полностью. А проблема банальна, структура файла была сделана уникально эффективной под каждое приложение.

Здравствуйте, AVC, Вы писали:

AVC>А у меня не умеет...

Plugins...

AVC>Или, по крайней мере, я не знаю, как это сделать в FAR.

Plugins...

AVC>Разве что нажать Ctrl-C, а затем до конца жизни не отпускать Ctrl-V.

Plugins...

AVC>Я уж не говорю о том, чтобы 1000 раз повторить последнюю команду редактирования или выполнить какой-нибудь макрос.

Plugins...

AVC>Да их и не надо много помнить. Достаточно знать с десяток основных команд. Уже будет польза.
AVC>Кроме того, Vim доступен и в "гуевом варианте", с менюшками, можно почти ничего и не помнить.

А я не про VIM

AVC>А собственно о чем спор-то?

Не знаю.

AVC>Просто когда мне нужно быстро выполнить большой объем редактирования, я использую Vim, потому что это заметно быстрее.

Верю. А я фар использую...

AVC>Поэтому я в таких случаях не собираюсь отказываться от использования vi.

Ну. Ок.

AVC>Вся эта тема, конечно, оффтоп, но резюме, IMHO, такое: не все старое и "негуевое" плохо.

Согласен! Фар тоже негуевый.

P.S. Но vi это конечно жуткое угребище по юзабилити....

Здравствуйте, Maxim S. Shatskih, Вы писали:

MS>>Ну на самом деле фичка от Майкрософта при надлежащей поддержке оного становится стандартом на виндах в добровольно-принудительном характере...
MSS>Не всегда. Микрософт монополист только в самих виндах и Офисе.

Ну да. Прямо звучит как в "узком семейном кругу" он монополист

MSS>Он даже в браузерах уже не монополист.

Ну. Скажем есть альтернативы уже неплохие, все же шестерка подзатянулась. Посмотрим что там будет с IE7 финальным...

MSS>А если фичка сначала появится у Мозиллы, и только потом появится ее аналог у Микрософта?

Значит кто-то в Майкрософте согласился, что она полезная посмотрев на опыт Мозиллы.
Это ничего не значит. Если кто-то первый придумал колесо, не значит что Мерседес спер идею, верно?

MS>>И что? Ну докажете вы From и что дальше?

MSS>В таких условиях спамить никто не захочет. Потому как спамера сразу вычислит его провайдер, и отключит. Весь спам основан на безнаказанности этого дела ввиду анонимности.

Да никакой там анонимности часто нет. Просто есть сети, которые закрыть трудно и наказать нельзя... Вот и все...

Здравствуйте, Maxim S. Shatskih, Вы писали:

MS>>Стандартизация конечно нужна от M$. Базовые классы и библиотеки на все случаи жизни. Будет это на .NET я думаю. Чего и нет. Просто не сразу. Не завтра. Все это нельзя так сразу делать. Тут организационных вопросов тьма

MSS>Кастом-атрибуты есть уже 12 лет. Воз и ныне там. Значит — не прижились.

Да их как-то особо и не проталкивали. Ну есть и есть. Кто-то использует, кто-то нет... Это как бы не показатель...

MSS>.NET тут вообще не при чем, он пока что нуль в мире коробочного софта.

Он даже не один нуль, а уже много нулей с другими цифрами впереди. Что конечно считать коробкой....

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>........

Ну короче резюме. В суть предложения вы не въехали толком.

Кто вам мешает, чтобы за всеми документами был базовый класс файл с теми же самыми методами, свойствами и т.п., что и сейчас? Кто вам сказал забудем про файлы вообще? Вы как-то не очень понимаете, что просто сейчас есть только 1 класс — файл. Ну есть еще какие-то доступные разные методы через что-то. Но мало, вяло и несерьезно. А надо чтобы было хорошо, много и прямо. И .NET для этого лучший кандидат. И такая идея у M$ и есть. Вот и все дела.

Здравствуйте, GlebZ, Вы писали:

GZ>Данные могут из себя представлять некую амебную массу, которую просто невозможно типизировать. Только интерпретировать и то, в каждом состоянии по свойму.

А про наследование классов вы ведь наверняка знаете...

GZ>Данные могут быть слаботипизированны, тогда накладные расходы на типизацию в ООDB могут превысить все мыслимые пределы. Представь себе какие расходы будут на
GZ>

GZ><commandir>
GZ>   <mycommandir1/>
GZ>   <commandir>
GZ>      <mycommandir2/>
GZ>      <hendehoh/>
GZ>      <commandir/>
GZ>   </commandir>
GZ></commandir>
GZ>

GZ>Здесь 3 commandir и все разного типа. Здесь всего 6 разных типов, которые на которые надо иметь типизацию и уметь хранить 6 разными способами. Для реляционки такое не проблема, потому как она ее можно подвернуть так, чтобы она меньше задумывалась о типе, а больше задумывалась именно о данных.

Да не надо вообще задумываться о данных... Я что-то не вник.

GZ>Кто сказал что в будущем останется ООП. ООП обладает рядом недостатков, собственно поэтому его и влепили в рамки КОП. И вообще на ООП не кончается все программирование.

Конечно, и не начинается. И что? Типа объекты долой? Нет такого понятия? Мы против объектов... Не знаем таких...

GZ>Когда-то Microsoft весьма живо рекламировала Ole Storage. Обещала всемерную поддержку. И где это все сейчас? Даже Office на нее не перевели полностью. А проблема банальна, структура файла была сделана уникально эффективной под каждое приложение.

Опыт сын ошибок трудных...

Здравствуйте, shuklin, Вы писали:

Всё СЛИШКО сложно, это будет весьма глючная и негибкая система, скорее нужно делать наооборот -- всё это файлы (смотри Plan9) а c пользовательской инфой нужно работать потипу Beagle или Google Desktop.

Здравствуйте, CrazyPit, Вы писали:

CP>Всё СЛИШКО сложно, это будет весьма глючная и негибкая система,
Сошласен.
CP>скорее нужно делать наооборот -- всё это файлы (смотри Plan9) а c пользовательской инфой нужно работать потипу Beagle или Google Desktop.
Это другая крайность. ИМХО Singularity очень близко к золотой середине.

Здравствуйте, Max.Subpixel, Вы писали:

MS>Plugins...
MS>Plugins...
MS>Plugins...
MS>Plugins...

Да, плагины — сила.
Но пока что это выглядит как "волшебная палочка".
Что-то вроде:

Волшебная палочка...
Волшебная палочка...
Волшебная палочка...


Хотелось бы знать, как именно задаются в этих плагинах
— число повторений операций,
— макросы,
— регулярные выражения для поиска и замены.
Если все через менюшку, то это — заметная потеря времени (конечно, при большом числе операций).
А синтаксис регулярных выражений не напрягает?
Или для него тоже нашли "гуевый" и "юзабильный" аналог? (Я такого не знаю, но рад бы узнать.)

MS>P.S. Но vi это конечно жуткое угребище по юзабилити....

Вот здесь, видимо, мы и расходимся во мнениях.
Важны функциональность и простота. Это, IMHO, и есть "юзабилити".
Ни в коем случае не утверждаю, что есть только один "правильный" способ достижения функциональности.
Например, мне нравятся и UNIX, и Оберон, хотя они и основаны на несколько разных принципах (впрочем, в Inferno была сделана попытка синтеза).
И в случае UNIX, и в случае Оберона функциональность (и => юзабильность) достигается за счет простоты конструктивных принципов, что позволяет постоянно наращивать возможности системы в нужном направлении.
Тот же vi может использовать при редактировании все возможности системы.
Ему даже не нужны отдельные "плагины", потому что в UNIX (как и в Обероне) все "плагин".
А Вы — "юзабилити, юзабилити..."

Здравствуйте, AVC, Вы писали:

AVC>Вот самый простой пример.
AVC>Товарищу надо вставить 1000 одинаковых строк в навороченном "гуевом" редакторе.
AVC>И что?
AVC>А в vi все просто: yy999p

А что, часто требуется такое сделать? (какое-нибудь индийское программирование )

Я обычно копирую строчку 10 раз, потом выделяю блок из 10 строчек, копирую его еще 10 раз, потом повторяю операцию еще раз — не намного дольше, чем вспомнить yy999p

Здравствуйте, Ranger_XL, Вы писали:

R_X>А что, часто требуется такое сделать? (какое-нибудь индийское программирование )

Просто это реальный случай, имевший место пару недель назад.

R_X>Я обычно копирую строчку 10 раз, потом выделяю блок из 10 строчек, копирую его еще 10 раз, потом повторяю операцию еще раз — не намного дольше, чем вспомнить yy999p

Вы же программист.
У меня "алгоритм" O(1).
А у Вас O(ln n).
И Вам не стыдно? (шутка, конечно )

Здравствуйте, AVC, Вы писали:

AVC>Вы же программист.
AVC>У меня "алгоритм" O(1).
AVC>А у Вас O(ln n).
AVC>И Вам не стыдно? (шутка, конечно )

Важна не скорость одной операции, а скорость выполнения задачи в целом

Здравствуйте, Ranger_XL, Вы писали:

R_X>Важна не скорость одной операции, а скорость выполнения задачи в целом

OK.
Поговорим чуть подробнее.
(Мне сначала казалось, что внезапно всплывшая тема о vi явный оффтоп, а сейчас мне видится что-то общее с темой топика.
Общее, возможно, в том, как воспринимается непривычное. )

Поговорим об эффективности в целом.
Что делает программист ежедневно?
Редактирует, компилирует, тестирует, отлаживает, сохраняет версии. (Можно этот список дополнить.)
В остальное время общается и думает. Тем больше, чем меньше потратил времени на указанные "технические" шаги.
Возьмем, к примеру, (1) редактирование.
Редактирование в vi эффективнее.
Меньше нажатий клавиш, мышь и меню (зачастую — растратчики времени) практически не используются.
Но это далеко не все.
Любые операции редактирования с регулярными выражениями, любые макросы и т.д.
И это не все.
Я могу использовать любую внешнюю программу-фильтр для редактирования как любого блока текста, так и файла целиком.
Написать программу-фильтр, согласитесь, гораздо проще, чем любой иной плагин.
И т.д. и т.п.
А теперь немного о (2-4) компиляции, тестировании и отладке.
Подойдем с точки зрения языка.
Сколько мелких и порой трудноуловимых багов проникает в программы на Си/C++?
(Не хочу "плевать в колодец", сам пишу в основном на Си/C++.)
Сколько иногда тратится времени на их поиски?
В то же время, для программиста на Обероне такие проблемы практически незнакомы.
Почему?
Потому что Вирт сумел "замкнуть" систему типов, в ней больше нет слабых мест, какие есть в Си/C++.
(Решающий шаг — избавление от вариантных записей, теперь для используется только расширение типа.)
Со времен Паскаля (как минимум) Вирт совершенствовал систему типов в своих языках и, IMHO, добился своей цели.
(Также в нем нет типичной "сишной" путаницы между оператором и выражением.)
В том же Обероне есть все главное, что сейчас считается "прогрессивным" в императивных языках.
Оберон — type-safe, расширяем, изначально поддерживает компонентное программирование и сборку мусора (и это в 80-е годы).
Кроме того, очень прост, эффективен. неприхотлив (работает по голому железу — на нем пишут ОС; а также на JVM, на .NET).
Я знаю людей, чья личная производительность многократно выросла при переходе на Оберон.
Так, стоп! Слишком много про Оберон (как и про vi)!
В данном случае главное — не сам Оберон, а принцип: использовать type-safe языки.
И т.д. и т.п.
Вот вопрос:
Все ли ресурсы мы используем для повышения своей производительности труда?
Я думаю, что и к теме топика надо подходить с этой точки зрения.
Эта "будущая ОС" повысит нашу производительность или нет?
Технические вопросы здесь вторичны. Сначала нало выяснить, а хороша ли основная идея?

Здравствуйте, Max.Subpixel, Вы писали:

GZ>>Данные могут из себя представлять некую амебную массу, которую просто невозможно типизировать. Только интерпретировать и то, в каждом состоянии по свойму.
А при чем тут наследование. Возьмем к примеру DVD фильм. Если мы хотим его посмотреть, то это всего лишь stream который надо проинтерпретировать. В случае редактирования, на нужно больше информации о том, что и как в ней лежит.
Или возьмем к примеру bmp. Что такое пиксель? В зависимости от заголовка мы можем понять что пиксель это может быть один бит для черно-белых изображений, может быть набором битов разбитых по слоям, или может быть вообще 4 байтным словом.

MS>А про наследование классов вы ведь наверняка знаете...
Знаю. Только для данных это палка о двух концах. С одной стороны оно нам дает многомерность. С другой стороны, ну например такой запрос(насколько я помню, вы Net знаете):
select * from object where object.GetHashCode()=5
В данном случае у нас минимум 3 выстрела в ногу. Найдите их(справшиваю потому, что может быть некоторые выстрелы не заметил сам).

MS>Да не надо вообще задумываться о данных... Я что-то не вник.
Надо. Когда я только начинал, объем в 1 Гигабайт для меня казался чем то огромным, в котором можно сохранить все. Но с развитием техники, увеличилось количество обрабатываемой информацией, и сейчас 1 Гиг является обычным делом. Не думаю что что-то изменится и объем обрабатываемой информации не будет увеличиваться.
Одно из достоинств реляционной модели то, что ее можно легко трансформировать. То есть, разложить информацию таким образом, чтобы эти миллионы строк обрабатывались со сложностью не превышающей O(logN). Для реляционки модель хранения и предоставления данных независимы. И эта трансформация пока недоступна для OODB.

GZ>>Кто сказал что в будущем останется ООП. ООП обладает рядом недостатков, собственно поэтому его и влепили в рамки КОП. И вообще на ООП не кончается все программирование.
MS>Конечно, и не начинается. И что? Типа объекты долой? Нет такого понятия? Мы против объектов... Не знаем таких...
Объекты обладают множеством недостатков, но я не знаю лучше. Поищите по форуму Философии. Объектная модель не столь однозначна. Это обсасывалось множество раз.

Здравствуйте, Ranger_XL, Вы писали:

R_X>А что, часто требуется такое сделать? (какое-нибудь индийское программирование )

R_X>Я обычно копирую строчку 10 раз, потом выделяю блок из 10 строчек, копирую его еще 10 раз, потом повторяю операцию еще раз — не намного дольше, чем вспомнить yy999p

Здравствуйте, AVC, Вы писали:


AVC>В Обероне проблем с уничтожением ненужных объектов ( =сборкой мусора ) тоже нет.
AVC>А вот с выгрузкой модулей — есть.

У меня эта проблема решена лишь частично. Выгрузить assembly саму по себе невозможно. Тут даже не моя причина а .NET так работает. Реализация классов у меня хранится во внешнешних assebly. Со всеми вытикающими. А вот выгрузить экземпляр — никаких проблем. Даже если он используется его все равно можно насильно вытиснить. Впрочем в большинстве случаев это не нужно. Всегда в RAM найдется кто нибудь, кто уже не выполняется. Вот его и вытесняю. Очень важной особенностью моей СУБД является возможность закружать граф связанных объектов по частям. Тоесть если А ссылается на Б, Б ссылается на С, а С ссылается на А — загружать их можно в любом порядке и в любой комплектности не зависимо друг от друга. Далее незагруженные объекты загружаются ondemand и вытисняются по мере исчерпания RAM.

S>>Я в своей ОБД сделал по другому. У меня любой экземпляр может иметь переменное число аттрибутов изначально. Тоесть добавить/удалить field в классе это не задача версионирования а просто штатная операция ОБД. При этом разные экземпляры одного и того же класса могут иметь различный набор аттрибутов.

AVC>А методов?

Методы реализованны во внешних DLL. После старта приложения заменить их нельзя. Чтоб заменить DLL на новую версию надо остановить приложение. При остановке данные в объектах не теряются — объекты даже не заметят что их останавливали.

Здравствуйте, Max.Subpixel, Вы писали:

MS>Здравствуйте, shuklin, Вы писали:

S>>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

MS>Мне кажется, что подводный камень это то, что работать в некоторых вопросах станет труднее.

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

MS>Мне кажется, что нельзя отказываться от понятия хранилище. Т.е. нельзя бесповоротно стирать грань между персистивными и транзиентными объектами.

А это и не обязательно. В моей ОБД все контролируемо.

MS>Почему? Потому что эта грань несет кроме сложностей еще и пользу. Как то — контроль производительности (все-же простите меня но доступ в ОЗУ всегда будет существенно быстрее чем в более медленное, но более емкое хранилище),
Здесь возможен компромис. В текущей версии моей ОБД доступ в хранилище производится только при первом обращении к объекту.
Хранилище написано не очень оптимально и обеспечивает около 1000 инстанциирований в секунду. Затем следующие обращения по ИД идут в RAM. Индекс в RAM обеспечивает 50000 — 80000 разадресаций в секунду (для AMD 1.7).


MS>Ну а в вашей реализации подводные камни это:
MS>1. Сложность задачи — не справиться гораздо проще, чем кажется по дороге
Эт есть. Однако справился. Уже не первую версию опубликовал. И еще на подходе.

MS>2. Технические возможности — вы все таки не можете писать свою ОС и тягаться в производительности со своп файлом трудно
Да. Свою ОС я и не пишу. Я пишу свою ООСУБД.

MS>3. Как результат производительность
По сравнению с РБД+ОРМ имхо можно выиграть весьма.

MS>4. Сложные схемы работы для программиста — они не захотят разбираться или многим это будет неудобно
Не для всех задач. Для интереса портировал небольшую программу с MS-SQL на свое изделие. Исходный код работы с персистент объектами в моей БД оказался проще. Нет никаких SqlCommand постоянный ExecuteQuery и пересылки данных из датасетов в объекты и обратно. Вот уш по этому пункту ОБД точно в переди, даже если отстает по скорострельности.