Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andrei N.Sobchuck
Guest
Гм. Сайт КЕШЕ-фобов какой-то :)

По теме. Сейчас полноценных ООСУБД не существует, потому как во всех нарушается одно из основных свойств ООП - инкапсуляция. Даже в упомянутой GemStone/S (вот на что нужно смотреть, как на образец, а не Cache`) для выполнения оптимизированных запросов нужно знать структуру объекта (для неоптимизированых - не нужно).

Что касается ОО вообще.
Что такое ОО по определению создателя концепции уже написал Метелица.
И только к 1992 году туда добавали наследование. По простой причине - в статически типизированном языке невозможно реализовать полиморфизм без наследования.
Тем кто думает, что без наследования ОО - не ОО, предлагаю ответить, без какого именно наследования - одиночного, множественного, наследования интерфейсов, mixins, traits, делегирования?

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

"Если внимательно почитать топик от 13:59, то получается что и сам Alan Kay отказался от своих начальных принципов и включил наследование с свой список требований". Кроме первичных признаков ОО системы, Алан Кей приводил наследование просто как одно из свойств Smalltalk-а, введённое для облегчения декомпозиции кода.

"Если Паскаль или С++ не удовлетворяют каким-то там требованиям - то скорее надо пересмотреть эти требования"
"ООП - это не просто свод абстрактных библейских заветов. ИМХО, это технология упрощения жизни программиста." Именно. По крайней мере, так задумывалось :) Кстати, первая цитата противоречит второй.

"А другим, работающим с языками имеющими нормальную коммерческую версию, глубоко плевать на то, что думает Alan Kay об ООП. Ну придумал человек термин - ну и невелика заслуга". Что касается первой части фразы: http://v2.anekdot.ru/an/an0308/o030821.html#2 Что касается второй части - опять же, придумано не просто так. У каждого требования было обоснование.

"термин в старом своем занчении практически вышел из употребления". http://www.c2.com/cgi/wiki?ObjectOrientation и вперёд по-ссылкам.

"А если на C сэмулировать C++..." - изначально С++ был реализован как макропроцессор к С. Желающим считать, что С++ это ООП язык - сам автор (Страуструп) называет его гибридным. В каком-то недавнем интервью он это подчеркнул - не ОО, а гибридный.

"в Лиспе все представлено списками и функции являются тоже списками, всё что можно - это списки". Так описать Лисп - это всё равно, что назвать лимузин "длинным автомобилем". Вроде и правильно, но суть не отражает.

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

"Метод класса вызвать нельзя, но зато можно послать сообщение с параметрами, которое будет обработано соответсвующим методом." Не понял я, что ты хотел сказать.

"интерфейсов нет - т.к. сообщения с обработчиками связываются по именам, то и смысла в них нет". Интерфейсы есть (SmallInterfaces), но по указанной тобой причине они никому не нужны.

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

"...блоки. Это нечто-то среднее между операторными скобками и процедурой". Не нужно зацикливаться на VB, C++, Delphi. Тогда в лексику попадут такие термины как [лексические] замыкания, продолжения, генераторы, внутренние итераторы, ко-процедуры. Кроме обогащения лексики, также будет обогащено и мышление.

"И на С++ я могу тоже сделать ВСЕ, что можно на Smalltalk, да еще и несколькими способами". А я на ассемблере могу. И что теперь? На асме всем лабать? Хотелось бы, кстати, видеть реализацию делегирования на С++. Хочу удостовериться, что там всё так просто.

"На С++ можно писать удивительно надежные программы (вопреки непонятно откуда взявшемуся мнению)" Мнение взято тут http://oss.software.ibm.com/icu/docs/papers/cpp_report/the_assignment_operator_revisited.html

"Специалистов именно по C++ ОЧЕНЬ МАЛО". А что ж так? Может потому, что при таком колличестве разных ньюансов стать по нему спецом очень не просто?

"В "чистом" С++ я могу всякими const, private или protected прикрыться, а в Win32 API - нет! Никакой безопасности!!! Дырявый баян." Ужас. Теперь когда комп с виндой увижу буду сразу прятаться, а то ведь любой объект завалить можно. Кстати, ты выход за границы массива чем - const, private или protected прикрываешь?
1 ноя 03, 20:34    [402820]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
bushmen
Member

Откуда: г. Москва
Сообщений: 828
>Andrei N.Sobchuck

Один набор цитат. Что-нибудь более убедительное есть и желаьельно свое?!
3 ноя 03, 09:26    [403350]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 Andrei N.Sobchuck

Отвечу так же аргументированно:

Ты не прав

Вобщем-то можно было бы и не продолжать, но не удержусь...

Тем кто думает, что без наследования ОО - не ОО, предлагаю ответить, без какого именно наследования - одиночного, множественного, наследования интерфейсов, mixins, traits, делегирования?

Животное-многоклеточное-позвоночное-млекопитающее-человек-программист - это какие наследование? Наверное одиночное. Значит без одиночного. Я к тому что оно появилось гораздо раньше программирования и не использовать его глупо.

Делегирование обладает большими(!) возможностями, чем наследование (См. Self).
А я напишу: Делегирование обладает меньшими(!) возможностями, чем наследование. Ну и кто из нас прав? Аргументируйте хоть как-то. Я кстати даже не знаю что такое делегирование(не считаю что это мой недостаток - мне это пока не надо было). Может не будем кидаться терминами?

в качестве мелочи - напиши мне на С++, например, вычисление факториала, а я тебе покажу на этом примере преимущества
Да это на любом языке будет одна строчка, даже на SQL. Не буду утруждать себя тем, что всем и так понятно. Если есть желание что-то показать - почему бы сразу не сделать.

это ООП язык - сам автор (Страуструп) называет его гибридным.
Мне лично глубоко плевать на его мнение, подозреваю что и ему на моё.

Не нужно зацикливаться на VB, C++, Delphi. Тогда в лексику попадут такие термины как [лексические] замыкания, продолжения, генераторы, внутренние итераторы, ко-процедуры. Кроме обогащения лексики, также будет обогащено и мышление.

"Специалистов именно по C++ ОЧЕНЬ МАЛО". А что ж так? Может потому, что при таком колличестве разных ньюансов стать по нему спецом очень не просто?

Дык я не понял: где количество нюансов слишком большое?

Кстати, ты выход за границы массива чем - const, private или protected прикрываешь?
Ну к примеру в Delphi можно сделать property и очень хорошо прикрыть.


Ну и напоследок замечу что термин "длинный автомобиль" очень точно определяет лимузин.
3 ноя 03, 12:02    [403658]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andrei N.Sobchuck
Guest
"Ты не прав"
Вполне возможно.

"Я кстати даже не знаю что такое делегирование(не считаю что это мой недостаток - мне это пока не надо было)."
Делегирование - вызов метода в другом объекте, но при этом 'self' продолжает указывать на объект который делегирует вызов. Похоже на наследование, но вызов можно делегировать любому объекту. При помощи делегирования можно эмулировать наследование, но при помощи наследования нельзя эмулировать делегирование. Из возможностей - позволяет на лету менять объект, которому делегируется выполнение. Это аналог динамического изменения базового класса.
Кстати, я тоже не считаю незнание недостатком. Но я дал ссылку, и поскольку ты нашел время ознакомиться с информацией по Smalltalk-у, то мог бы заглянуть и по ней.

"в качестве мелочи - напиши мне на С++, например, вычисление факториала, а я тебе покажу на этом примере преимущества
Да это на любом языке будет одна строчка, даже на SQL. Не буду утруждать себя тем, что всем и так понятно."
Сам же говоришь - одна строчка. Ты словами больше написал. Я ж говорю - код на с++ дай, а я тебе, на однострочном примере обосную преимущества.

"(Страуструп)...
Мне лично глубоко плевать на его мнение, подозреваю что и ему на моё. "
Нигилизм? А на чьё мнение не плевать?

"Ну и напоследок замечу что термин "длинный автомобиль" очень точно определяет лимузин."
Так же можно описать и КАМАЗ. Я ж не доколупаться хочу. Просто за каждым термином скрываются определённые возможности. В ОО изначально заложено больше, чем "полиморфизм,наследование,инкапуляция" (тем более в том виде, как это в С++,Object Pascal)
3 ноя 03, 12:54    [403775]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 Andrei N.Sobchuck
Что касается факториала - мне не нравиться такое общение загадками, если есть чего сказать - пожалуйста, а дразнить не надо, писать принципиально не буду. Разве что компромисный вариант на SQL: select exp(sum(log(N))) from t1000 where N<=@N

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

В ОО изначально заложено больше, чем "полиморфизм, наследование, инкапуляция"
Одно слово пропушено, правильно (на мой взгляд) так: В ОО изначально было заложено больше, чем "полиморфизм, наследование, инкапуляция". Остальные возможности остались атовизмами. Мне например кажется что делегирование и возможность посылки объекту любого сообщения - это источник трудновыявляемых ошибок.
3 ноя 03, 14:54    [404060]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andrei N.Sobchuck
Guest
"select exp(sum(log(N))) from t1000 where N<=@N"
Что есть t1000?

"Мне например кажется что делегирование и возможность посылки объекту любого сообщения - это источник трудновыявляемых ошибок."
Будет время - попробуй.
3 ноя 03, 15:25    [404139]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Garya
Member

Откуда: Москва
Сообщений: 33209
Блог
> Что есть t1000?

Извини, SergSuper, что отвечаю за тебя. Мне кажется этот ответ очевидным.
t1000 - это таблица, с одним-единственным полем, хранящая последовательность из чисел 1....1000.

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

В принципе, верно. Но давайте не будем опускаться до флейма. Иногда (очень-очень редко) бывает нужен такой супер-пупер динамизм. И вот в таких редчайших случаях лучше иметь делегирование и универсальные сообщения, нежели не иметь ничего. Возможность интерпретации в C переменной одного типа как переменной другого типа - тоже источник трудновыявляемых ошибок. По этому поводу уже скрещивали шпаги невообразимые полчища сишников и паскалистов (последние из которых сии волности не принимали). И что же? В большинство современных компиляторов введена возможность интерпретации переменной одного типа как переменной другого типа (например, Char как Integer), но только при указании ЯВНОГО ЖЕЛАНИЯ ПРОГРАММИСТА (выраженного через поправки к стандартному синтаксису) такой интерпретации.
ИМХО, и в вашем споре имеется золотая середина. Ребята, давайте жить дружно.
3 ноя 03, 16:13    [404264]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
bushmen
Member

Откуда: г. Москва
Сообщений: 828
И давайте не будем "наезжать" друг на друга. Здесь все-таки не поле битвы.
3 ноя 03, 16:45    [404344]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andrei N.Sobchuck
Guest
"Возможность интерпретации в C переменной одного типа как переменной другого типа - тоже источник трудновыявляемых ошибок."
Факт.

"По этому поводу уже скрещивали шпаги невообразимые полчища сишников и паскалистов (последние из которых сии волности не принимали). И что же? В большинство современных компиляторов введена возможность интерпретации переменной одного типа как переменной другого типа (например, Char как Integer), но только при указании ЯВНОГО ЖЕЛАНИЯ ПРОГРАММИСТА (выраженного через поправки к стандартному синтаксису) такой интерпретации."
Это может быть полезным в системном программировании, но не в прикладном.

"Иногда (очень-очень редко) бывает нужен такой супер-пупер динамизм. И вот в таких редчайших случаях лучше иметь делегирование и универсальные сообщения, нежели не иметь ничего."
До конца года (а может даже в ноябре) выйдет следующая версия Cincom VisualWorks Smalltalk (это прямой наследник оригинального ST-80). http://www.cincom.com/smalltalk . Есть полнофункциональная бесплатная для неккомерческого использования версия. В дистрибутив также входит некоммерческая версия ООСУБД - GemStone/S. Там есть доки и по ST и по GemStone/S. Есть туториал с краткой демонстрацией некоторых возможностей. Скачать можно как исошник со всем сразу, так и по частям. Под винду и всякие юниксы/линух. Рекоммендую посмотреть, что может это самое "чуть больше, чем ничего". Хотя бы для аргумментированной критики :)

За сим прощаюсь, всем больших успехов в работе и приятного отдыха по вечерам и на выходных. Андрей Собчук
4 ноя 03, 10:05    [405059]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Ну вот, еще один ушел так и не обосновав преимуществ на однострочном примере.
4 ноя 03, 13:00    [405390]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
По этому поводу уже скрещивали шпаги невообразимые полчища сишников и паскалистов (последние из которых сии волности не принимали). И что же? В большинство современных компиляторов введена возможность интерпретации переменной одного типа как переменной другого типа (например, Char как Integer), но только при указании ЯВНОГО ЖЕЛАНИЯ ПРОГРАММИСТА (выраженного через поправки к стандартному синтаксису) такой интерпретации.

Нету такого в С++. Вы никогда не "интерпритируете" - вы всегда приводите, если это возможно, один тип к другому - и все это делается с помощью соотвесвующих конструкторов - которых может и не быть
4 ноя 03, 16:18    [405881]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andrei N.Sobchuck
Guest
"Ну вот, еще один ушел так и не обосновав преимуществ на однострочном примере."
Аах. Ну раз есть предложение... Но я пока не увидел однострочного примера. (Я думаю ты согласишся, что то что ты предложил не совсем подходит, ибо количество натуральных чисел... э-э... несколько побольше 1000).
Кстати, что у тебя выдаёт для N=1000?
У меня PostgreSQL для SELECT exp(5912.1281892061); выдаёт 'ERROR: exp() result is out of range'. (5912.1281892061 - сумма ln от 1 до 1000). Я так понимаю, дело в формате хранения чисел с плавающей точкой
4 ноя 03, 16:45    [405968]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andrei N.Sobchuck
Guest
"Нету такого в С++"
А через указатели?
4 ноя 03, 16:50    [405987]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Это legacy - такого в С++ делать не надо
4 ноя 03, 16:54    [405992]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Garya
Member

Откуда: Москва
Сообщений: 33209
Блог
> Нету такого в С++. Вы никогда не "интерпритируете" - вы всегда приводите, если это возможно, один тип к другому - и все это делается с помощью соотвесвующих конструкторов - которых может и не быть

Конструктор может быть только у объектного типа. То же касается и приведения типов. В C++ (в отличие, например, от C#) далеко не все типы являются объектными. Например, тип "целое" или "символ" - это НЕ объектный тип, и конструктора они не имеют вообще и иметь не могут. Далее, приведение типа, которое, например в Дельфях работает через "as" может производиться только между родственными классами. Насколько мне известно, в C++ тоже.
Речь шла о том, что в C можно обявить переменную как struct нескольких целых чисел, положить в нее несколько целочисленных значений, а потом передать ссылку на эту переменную и рассматривать уже эту ссылку как ссылку на число с плавающей точкой(или на битовый массив). Подобные вещи могли происходить и непреднамеренно. Посему, где-то слегка опечатавшись, можно было получить вещественное, содержащее значение, бог весть откуда взявшееся. Поди-ка найди такую ошибку. Я просто пояснил, что имел в виду.
4 ноя 03, 18:33    [406240]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2Garya:

Я это знаю - да все базовые типы не являются классами - но внешне это (за этим следит компилятор) ничего не меняет и сделать то что ты говоришь на C++ нельзя. А тем кто будет пытаться надо руки отламывать
5 ноя 03, 10:09    [406757]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 Andrei N.Sobchuck
Прочитай еще раз что ты мне ответил о моём вычислении факториала и ты поймёшь почему я не хотел его писать - я ожидал (и ты мои ожидания не разочаровал) что будет не обсуждение решения, а придирки типа что мол не для любого числа считается, мне придётся исправлять, оправдываться, вобщем чувствовать себя студентом на экзамене у профессора. Но поскольку я уже давно не студент, то я настаиваю что решение моё правильно, оно полностью подходит поскольку:
  • решение однострочное
  • задача чисто теоритическая, решение расчитано на теоритический сервер, если у кого-то сервер выдаёт переполнение - это проблемы не мои, а сервера
  • о размерах чисел и о их точности мы не договаривались, а раз не договаривались то и никаких претензий быть не может: до 20 считает - получите, распишитесь

    Хотя скорее всего я тут только зря воздух сотрясаю, преимущества ST остануться неведомыми как военная тайна Мальчиша-Кибальчиша
  • 5 ноя 03, 11:11    [406921]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Andrei N.Sobchuck
    Guest
    "Прочитай еще раз что ты мне ответил о моём вычислении факториала и ты поймёшь почему я не хотел его писать - я ожидал (и ты мои ожидания не разочаровал) что будет не обсуждение решения, а придирки типа что мол не для любого числа считается, мне придётся исправлять, оправдываться, вобщем чувствовать себя"
    При написании программ приходится учитывать ограничения накладываемые платформой. Ты упорно считаешь, что это нормально если программы считает только до 20 (для большинства программ ограничения побольше, но сути это не меняет). Я считаю, что в 21 веке не нужно об этом задумыватся. И использую платформу, которая, помимо прочих возможностей, скрывает от меня всю эту белиберду с форматами чисел, выбирая для каждого конкретного случая оптимальный вариант. Если я пишу 1, то получаю SmallInteger, пишу 1000000000000000, получаю BigInteger, никогда не волнуюсь, что умножив два числа получу переполнение (о котором и не узнаю!).

    "я настаиваю что решение моё правильно, оно полностью подходит поскольку:
    # решение однострочное
    # задача чисто теоритическая, решение расчитано на теоритический сервер,"
    Для тебя сервер теоретический, для меня практический.

    "если у кого-то сервер выдаёт переполнение - это проблемы не мои, а сервера
    # о размерах чисел и о их точности мы не договаривались, а раз не договаривались то и никаких претензий быть не может: до 20 считает - получите, распишитесь"
    Интересный подход. У тебя все программы считают только до 20?

    "Хотя скорее всего я тут только зря воздух сотрясаю, преимущества ST остануться неведомыми как военная тайна Мальчиша-Кибальчиша"
    Я уже предложил, но повторюсь. Возьми либо текущую версию VisualWorks-а либо через месяц свежую версию. Посмотри примеры в туториале для начинающим. Просмотри хотя бы доки по другому диалекту Smalltalk-а - GemStone/S.

    ЗЫ как пнуть тутошнего веб-мастера, что-бы в форме для набора поста заработали кнопочки форматирования шрифта в мозилле (firebird)?
    5 ноя 03, 12:33    [407158]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    2 Andrei N.Sobchuck
    Ну как и ожидалось, ничего от себя написано не будет. Это понятно, критиковать проще чем предлагать что-то своё.

    Если я пишу 1, то получаю SmallInteger, пишу 1000000000000000, получаю BigInteger, никогда не волнуюсь, что умножив два числа получу переполнение (о котором и не узнаю!).

    У меня PostgreSQL для SELECT exp(5912.1281892061); выдаёт 'ERROR: exp() result is out of range'.

    Для тебя сервер теоретический, для меня практический.


    Что ж такой непрактичный то сервер тогда выбрал, а? Кстати а факториал от 1000000000000000 слабо посчитать? Ну или хотя бы от миллиона? Надеюсь до миллиона программы у тебя считают.

    Интересный подход. У тебя все программы считают только до 20?

    Теперь и к 20 придрался... Нет, они у меня вообще не считают, всё сервер считает, это тот, который у тебя переполнение выдаёт.

    Возьми либо текущую версию VisualWorks-а либо через месяц свежую версию. Посмотри примеры в туториале для начинающим. Просмотри хотя бы доки по другому диалекту Smalltalk-а - GemStone/S.
    Соотнеси трудозатраты - тебе написать самому или вставить сюда копи-пастингом пример(я так понимаю у тебя всё уже стоит) или мне это откуда-то брать, разбираться, ставить и т.д. Либо месяц ждать.

    Вобщем продолжать видимо нет смысла, любое мое слово может быть (и будет) использовано против меня. Ну зачем еще было просить написать вычисление факториала?
    5 ноя 03, 15:35    [407582]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Andrei N.Sobchuck
    Guest
    Тяжело с тобой, Серж.

    "Ну как и ожидалось, ничего от себя написано не будет. Это понятно, критиковать проще чем предлагать что-то своё."
    Если это относится к строке вычисления факториала, то вот решение "в лоб":
    (2 to: N) inject: 1 into: [:factorial :i | factorial * i].
    Пояснение: 'inject:into:' - итератор, который при каждой итерации передаёт в переменную factorial (накапливает там) результат предыдущей итерации.

    "Кстати а факториал от 1000000000000000 слабо посчитать? Ну или хотя бы от миллиона? Надеюсь до миллиона программы у тебя считают." У моего компа не хватит памяти разместить эти числа.
    Я вычислил факториал ста тысяч. Это заняло 152сек на 1,7Ггц атлоне с 512 Мб оперативки. Результат - число из 456'574 десятичных знаков. В памяти число занимает 189589 байт. Думаю, что факториал от миллиона займёт в памяти не меньше 3х мег. И это только на результат. Резюме: посчитать то можно, но ресурсов таких у меня нет. Если тебе будет интересно - поставлю на ночь и посмотрю до какого числа досчитает.

    "Теперь и к 20 придрался..."
    Не придрался. Просто это ограничение не из-за нехватки ресурсов возникло.

    "Соотнеси трудозатраты - тебе написать самому или вставить сюда копи-пастингом пример"
    Я предлагал тебе (да кому угодно) просто детальнее ознакомится с предметом. На единичном примере ведь всего не показать. Но даже на этом примере с факториалом видно, что я прогу накидал и всё - меня не заботит ни формат (int, long или еще что нибудь) чисел, ни то, что там может случится переполнение. Я предлагал написать на С++ и сравнить ибо ты считаешь его образцом ОО (SQL, кстати, очень даже не ОО). И эти мелкие преимущества проявляются во-всём.
    А программа на Gemstone/S, в общем случае, выглядит как обычная ST программа. Только состояние объектов еще и само по себе сохраняется.
    5 ноя 03, 19:44    [407991]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Garya
    Member

    Откуда: Москва
    Сообщений: 33209
    Блог
    Подводя некоторые промежуточные итоги на уровне моего ИМХО :)...

    1. ST может работать с числами произволной размерности и точности. Это что-то вроде достоинства. Есть только один нюанс. Насколько мне известно, существуют библиотеки для работы с подобными числами, которые можно использовать практически из любых современных инструментариев (включая C++, который я почему-то недолюливаю, даже сам не знаю почему). Вот только пользуются ими очень мало и редко. Вопрос - почему? Это же так классно! Ответ - потому что:
    а) для подавляющего большинства реальных практических задач вычислять расстояние до альфа центавра в микронах никому не нужно. Иже с ним факториал 1000000 с точностью до единицы. Потому как ЧИТАТЬ глазами результат даже никто не станет. А для реальных практических задач хватает стандартных машинных слов и типов данных.
    б) работает такая вычислительная арифметика (в смысле, для резиновых чисел) медленнее, нежели с машинными словами, байтами и т.п., потому как неоптимально использует процессор, когда (то есть, почти всегда) вычисление идет над числами, умещающимися в традиционные разрядные сетки.
    Нет, конечно же, плюс. Но так себе, ма-ахонький плюсик.

    2. Синтаксис этого самого инжекта меня убил наповал. Это следует понимать как плюс языка? Может быть, у меня заскорузлое и приземленное мышление, но таких заумностей я не понимаю. Мне сразу припоминается COS со своим умопомрачительным синтаксисом, направленным, судя по всему, на разделение людей на "постигнувших и достойных" и "всех прочих". Еще припоминается Forth, который в отношении синтаксиса еще более лаконичен и еще менее доступен традиционному (ну, акромя суперпуперменов) человеческому сознанию. Может быть, поэтому он не прижился, а прижился совершенно простой до отупения Бейсик, который пережил уже многих своих правнуков? Но даже в том же Бейсике по крайней мере в наши времена переменные принято сначала объявлять, а уж потом использовать. Вообще-то, в древних изначальных вариантах Бейсика их не объявляли, но потом дядя Билли со товарищи прислушались к несущейся со всех сторон матершине ошибающихся и опечатывающихся программеров и решили все-таки добавить декларацию переменных. В приведенной строчке ничего похожего на объявление я не разглядел. Хотя разглядел три штуки чегой-то похожего на переменные - N, Factorial и i. Можно предположить, что N - кроме того, что играет роль конечного значения счетчика цикла (каковым, как я понял, является i), одновременно еще является и параметром. Тогда 2 - тоже параметр?. Если необходимо устроить цикл в цикле (и не один), как разобраться, какая из "i" к какому циклу относится?
    Можно сей цикл написать на фокале, к примеру с однобуквенными операторами (как это любили делать фокалисты и мампсники). Будет, в общем-то, еще короче. Но почему-то фокал тоже не прижился. Почему-то большинство программистов мира (ну за исключением всяких уникумов) предпочитают длинные но понятные фразы вроде Date_Of_Birdth кратко-лаконичной DOB. Те же, кто из текста самой программы не могут догадаться, что $HOROLOG - это обозначение (языковое!) текущей даты, те, разумеется просто не доросли до понимания высшего и прекраснейшего. Те, которые НЕ арабы, должны понять, что читать справа-налево, когда все читают слева-направо, это высший кайф элитного самоосознания. (Замечание:Разумеется, из арабов в элиту намечаются только те, что читают слева-направо, главное, чтобы не как все).

    3. И, наконец, третье, и главное достоинство ST... Так, о чем бишь я?... Ах да! Ну вот. Он просто крутой.
    5 ноя 03, 21:03    [408073]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Andrei N.Sobchuck
    Guest
    "ST может работать с числами произволной размерности и точности. Это что-то вроде достоинства."
    Н-да. Я писал одно, а ты прочитал другое. Будем считать, что у меня туго со способностью объяснять. Попробую еще раз. Одно из преимуществ - не просто прозрачное приведение типов, а работа так, что в не зависимости от исходных значений твой результат всегда будет правильный, и ты не получишь отрицательное число при сложении двух положительных. При том молча! (Насколько я помню у американцев ракета завалилась когда-то из-за переполнения)

    "работает такая вычислительная арифметика (в смысле, для резиновых чисел) медленнее, нежели с машинными словами, байтами"
    Ты теоретик? С чем, по-твоему, работает виртуальная машина ST? Естественно со словами, с байтами и пр. Число умещается в SmallInteger - работает со SmallInteger, не умещается - переключается на другой, более подходящий тип. Но от программиста всё это скрыто. Замедление есть, но оно не настолько большое, чтобы скушать те преимущества, которые даются.

    "Насколько мне известно, существуют библиотеки для работы с подобными числами"
    одна из них гнутая gmp. Это так, к слову.

    "Синтаксис этого самого инжекта меня убил наповал."
    "Мне кажется этот ответ очевидным." (C) Garya.
    Попробую пояснить.
    1 to: N - результат, коллекция натуральных чисел от 1 до N.
    inject:into: - Имя сообщения. После каждого двоеточия ставятся аргументы метода. Даный метод принимает два аргумента - начальное значение аккумулятора и блок. Блок - суть анонимный метод. Параметры блока задаются в виде двоеточия плюс имя переменной. Определение параметров отделяется от тела блока вертикальной чертой. Из блока возвращается результат вычисления последнего выражения (в примере оно только одно).
    Суть метода - для каждого числа из потока вызывается блок, в первую переменную которого (factorial) передаётся на первой итерации начальное значение, а на каждой последующей результат работы блока. Во-вторую переменную блока (i, имя специально для понятности выбрал) передаётся очередное значение из коллекции. То есть, туда последовательно передаются натуральные числа от одного до N. Если переписать это в несколько строчек, то получится:

    "в кавычках комментарии"
    | factorial | "определяем временную переменную ( не параметр)"
    factorial := 1.
    (2 to: 1000) "коллекция чисел от одного до 10000"
    do: [:i | factorial := factorial * i] "значение числа в текущей итерации"
    "метод do: перебирает по очереди все числа и на каждой итерации в блок передаёт текущее число"

    "Если необходимо устроить цикл в цикле (и не один), как разобраться, какая из "i" к какому циклу относится?"
    Называть эти переменные по-другому:
    1 to: 100 do: [:i |
    1 to: 100 do: [:j
    "Тут что-то делаем с i и j"]]

    Если тебе больше нравятся фигурные скобки вместо прямоугольных, и чудные мена методов вместо человеческих, то посмотри на Ruby - там ST с синтаксисом Perl-а.

    "И, наконец, третье, и главное достоинство ST... Так, о чем бишь я?... Ах да! Ну вот. Он просто крутой."
    "Настоящие программисты не используют паскаль". Кто бы мог подумать, что этот рассказик будет актуален и в 21 веке :-\
    6 ноя 03, 11:05    [408546]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Garya
    Member

    Откуда: Москва
    Сообщений: 33209
    Блог
    > Одно из преимуществ - не просто прозрачное приведение типов, а работа так, что в не зависимости от исходных значений твой результат всегда будет правильный, и ты не получишь отрицательное число при сложении двух положительных. При том молча!

    Вопрос можно? Если ты попросишь ST разделить число Пи на квадратный корень из двух, то в каком-нибудь тысячелетии он получит результат? Или будет пытаться молча найти самую последнюю значащую цифру после точки?
    6 ноя 03, 12:38    [408744]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Garya
    Member

    Откуда: Москва
    Сообщений: 33209
    Блог
    Ну, или пример попроще. Результат деления 1/3 будет вычисляться молча и до бесконечности, или когда-нибудь все-таки прервется?
    6 ноя 03, 12:43    [408754]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Andrei N.Sobchuck
    Guest
    В результате деления 1 на 3 мы получим натуральную дробь (тип такой) - одну третью.
    То бишь 1 / 3 * 3 выдаст единицу.
    6 ноя 03, 12:51    [408771]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 83   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить