Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
antares0
1. slot-value не прошит раз и навсегда и для всего. Его поведение определяет metaclass класса. Для обычного объекта это standart-class (Или как то так). Обычный класс хранит значения полей в внутренней структуре и соответсвено slot-vlaue просто дает доступ к полям этой структуры. Но никто не мешает создать другой метакласс для персистентных объектов например. Standart-object это всего лишь один из возможных выборов.
2. Что значит эмулировать? Можно взять готовое или написать самому так как хочется другого не дано.
Lisp уже виртуальная машина а mop уже готовая платформа для объектных систем. И то и другое можно изменять под свои нужды.
Про статистику я уже не понял, что мешает её считать?
3. Гугол выдает инфу по ревалентности и поэтому найти php-связзаное гораздо легче. В случае Лиспа нужно быть в теме и точно знать предмет и место поиска.
Я дико извиняюсь но хотя бы pcl http://pcl.lisper.ru был пролистан?
Суть ведь не в том что б доказать, что ЛИСП ЭТО САМЫЙ МОЩНЫЙ ЯЗЫК. Просто для рассматриваемых случаев и пары глав pcl про CLOS в принципе хватит.


1. Даже из того описания что вы дали я все равно не понимаю, как это решит проблему с множественными полями, ведь слот привязан к одному классу (и соответственно метаклассу, который как я понял просто определяет реалищацию slot'а)
2. Эмулировать это, повторяюсь, значит что такой возможности нету в спецификации языка. То есть если захотеть можно эмулировать (читай написать) и СУБД на Lisp'е, но такая "эмуляция" будет иметь такое же отношение к Lisp'у, как Oracle к C++ (или на чем там он написан)

Про статистику, вы себе хорошо представляете алгоритмическую сложность такого процесса (оптимизации реализации хранения)? Там нужно ловить все вызовы, все записи, в отдельных потоках реорганизовывать\собирать мусор у таких множественных полей. Этого никто кроме виртуальной машины сделать не в состоянии, и средствами самого Lisp'а это делать, все равно что симплекс-метод на SQL'е писать.

Еще раз CLOS да решает проблему с множественной диспетчеризацией и не привязывает метод к одному объекту как это сделано в ООП. Чем он реально превосходит большинство существующих языков. Но и дальше он не ушел, во всяком случае если не рассматривать то докуда его теоретически можно расширить в следствие его гибкости
15 дек 09, 18:04    [8071203]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
antares0
Member

Откуда:
Сообщений: 247

1. Даже из того описания что вы дали я все равно не понимаю, как это решит проблему с множественными полями, ведь слот привязан к одному классу (и соответственно метаклассу, который как я понял просто определяет реалищацию slot'а)
2. Эмулировать это, повторяюсь, значит что такой возможности нету в спецификации языка. То есть если захотеть можно эмулировать (читай написать) и СУБД на Lisp'е, но такая "эмуляция" будет иметь такое же отношение к Lisp'у, как Oracle к C++ (или на чем там он написан)

Про статистику, вы себе хорошо представляете алгоритмическую сложность такого процесса (оптимизации реализации хранения)? Там нужно ловить все вызовы, все записи, в отдельных потоках реорганизовывать\собирать мусор у таких множественных полей. Этого никто кроме виртуальной машины сделать не в состоянии, и средствами самого Lisp'а это делать, все равно что симплекс-метод на SQL'е писать.

Еще раз CLOS да решает проблему с множественной диспетчеризацией и не привязывает метод к одному объекту как это сделано в ООП. Чем он реально превосходит большинство существующих языков. Но и дальше он не ушел, во всяком случае если не рассматривать то докуда его теоретически можно расширить в следствие его гибкости

1. Вернусь к предыдущему утверждению и повторю что принадлежность слота классу опредляется метаклассом класса, точнее релизацией нужных методов для этого метакласса. Можно например, что бы один и тот же слот случайным образом появлялся у разных объектов.
2. Возможность реализации такого поведения заложено в спецификации языка. Нет конечно можно называть реализация пары методов эмуляцией, но для меня это странно.
Oracle реализует другю виртуальную машину поверх того на чем он написан. В случае CL реализация необходимого поведения объектов происходит внутри самой лисп-машины и на самом Common Lisp-е. Разница по-моему очевидна. Даже объектная система не меняется скорее настраивается.
3. Как уже говорил Лисп уже Вирт. машина поэтому ничего не мешает собирать статистику и делать любые другие вещи. В смысле реализации Лисп в отличае от sql компилируемый язык общего назначения ничем не хуже явы или плюсов. Или у вас для реализации нечто более экзотичное?

Но тема скатывается в дискуссию о лиспе. Это не было моей первоначальной целью.
Про что и куда можно расширить с удовольсвием послушаю, если вас не затруднит.
15 дек 09, 18:46    [8071420]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
нитро, вы не правы. Я в SQL я пришел из FoxPro много лет назад. Так вот, даже неопытному новичку тогда было видно, что SQL дает большие преимущества и гибкость в решении задач манипулирования данными, множествами данных. Мозг человека так устроен, что мыслит образами/картинками и основные операции - синтез (соединение), анализ (разделение/фильтрация) и поиск совпадений (корелляция/сравнение). SQL эти абстракции работы мозга отлично реализует. Поэтому при изучении его не надо выворачивать мозг наизнанку. SQL совершил такой прорыв и заслужено получил признание, ибо это действительно удобный инструмент для манипулирования данными.

ФП шаг вперед в развитии языков программирования, но по революционности идей он до SQL не дотягивает. Всякие рекурсии - не свойствены работе мозга, рекурсивные выражения тяжело разбирать и анализировать. Кстати рекурсивные расширения SQL тоже тяжело воспринимать.

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

P.S. Я не зря упомянул форт, нравился он мне очень. И до сих пор жив на всяких embedded системах. Позволяет писать в каком хочешь стиле.
15 дек 09, 20:25    [8071725]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Ggg_old
нитро, вы не правы. Я в SQL я пришел из FoxPro много лет назад. Так вот, даже неопытному новичку тогда было видно, что SQL дает большие преимущества и гибкость в решении задач манипулирования данными, множествами данных. Мозг человека так устроен, что мыслит образами/картинками и основные операции - синтез (соединение), анализ (разделение/фильтрация) и поиск совпадений (корелляция/сравнение). SQL эти абстракции работы мозга отлично реализует. Поэтому при изучении его не надо выворачивать мозг наизнанку. SQL совершил такой прорыв и заслужено получил признание, ибо это действительно удобный инструмент для манипулирования данными.

ФП шаг вперед в развитии языков программирования, но по революционности идей он до SQL не дотягивает. Всякие рекурсии - не свойствены работе мозга, рекурсивные выражения тяжело разбирать и анализировать. Кстати рекурсивные расширения SQL тоже тяжело воспринимать.

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

P.S. Я не зря упомянул форт, нравился он мне очень. И до сих пор жив на всяких embedded системах. Позволяет писать в каком хочешь стиле.


Первое, я ничуть не преуменьшаю ценность SQL как единственного декларативного на данный момент языка. Он также по сути является одним из очень немногих чистых функциональных языков программирования, в отличие от того же Lisp'а. То есть императивности в нем нету вообще, как класса.

Мозг человека как раз мыслит объектами и свойствами, а не таблицами и строками, поэтому объяснить человеку что такое JOIN, а особенно тип JOIN, который по сути является одним из видов условий (кстати еще одна грубая ошибка при создании SQL) далеко не так просто. Вызов функции в этом смысле более интуитивно понятен.

То что за декларативными подходами будущее это мы как раз понимаем, собсно над этим и работаем.
16 дек 09, 10:25    [8073066]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Nitro_Junkie

Мозг человека как раз мыслит объектами и свойствами, а не таблицами и строками, поэтому объяснить человеку что такое JOIN, а особенно тип JOIN, который по сути является одним из видов условий (кстати еще одна грубая ошибка при создании SQL) далеко не так просто. Вызов функции в этом смысле более интуитивно понятен.
Вы в карты в "тысячу" например когда-нибудь играли? Когда данных немного то можно и образами мыслить, а когда их столько что уже в мозг не влезает, то ручки сами табличку начинают рисовать
16 дек 09, 10:33    [8073127]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
antares0

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

antares0, мы о разных вещах говорим... Еще раз значение слот может определятся сразу несколькими объектами\классами\метаклассами. То есть в описанном случае про контракт музыканта со студией как slot как должен реализовываться какому классу\метаклассу (вы в них по моему немного путаетесь) принадлежать?

antares0

2. Возможность реализации такого поведения заложено в спецификации языка. Нет конечно можно называть реализация пары методов эмуляцией, но для меня это странно.
Oracle реализует другю виртуальную машину поверх того на чем он написан. В случае CL реализация необходимого поведения объектов происходит внутри самой лисп-машины и на самом Common Lisp-е. Разница по-моему очевидна. Даже объектная система не меняется скорее настраивается.

На C++ я тоже могу вручную реализовать сборку мусора, означает ли что C++ поддерживает сборку мусора?

antares0

3. Как уже говорил Лисп уже Вирт. машина поэтому ничего не мешает собирать статистику и делать любые другие вещи. В смысле реализации Лисп в отличае от sql компилируемый язык общего назначения ничем не хуже явы или плюсов. Или у вас для реализации нечто более экзотичное?

Лисп к нашему проекту никакого отношения не имеет, а всего лишь демонстрация что наследование можно заложить в язык без привязки функции одному объекту (как в ООП)
16 дек 09, 10:41    [8073192]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
SergSuper
Nitro_Junkie

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


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

Сама табличка, как представление списка, безусловно человеку понятна, но вот операции над ними проще понять руководствуясь более высокой логикой, нежели логикой матриц.
16 дек 09, 10:45    [8073229]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
если рассмотреть множество всех возможных параметров функции и ее результатов, то получается таблица.

таблица - это функция натурального аргумента - номера строки, определенная на мн-ве кортежей.
сами кортежи тоже могут содержать таблично заданные функции. Т.о SQL - это язык для работы с табличными функциями.
16 дек 09, 11:06    [8073435]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Любого из параметров... Если не должна то зачем она вообще нужна? и как вообще по вашему в функциональном\структурном программировании изменяются объекты?

Любого на выбор ? Не пойдет. А объекты изменяют свои св-св методами.
Когда методы конструируют результат это и есть изменение объекта.
Т.е. было одно значение, применили метод, получили другое значение этого-же св-ва этого-же объекта.
Nitro_Junkie

То что множественное наследование есть во многих ЯП я в курсе, речь шла про C...

Я имел ввиду не наследование, а возможность конструировать новые типы данных.
16 дек 09, 11:11    [8073480]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
antares0
А можно раскрыть что такое "множественные поля"?

Автор так называет функции нескольких переменных :)
16 дек 09, 11:13    [8073500]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie

Знаете если бы SQL не был бы общепризнанным и вам дали бы его в первый раз... Я думаю ваша реакция была такой же...

В первый раз я смотрел не SQL, а его прототип альфа. Реакция была положительной.
16 дек 09, 11:15    [8073528]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Nitro_Junkie
если рассмотреть множество всех возможных параметров функции и ее результатов, то получается таблица.

таблица - это функция натурального аргумента - номера строки, определенная на мн-ве кортежей.
сами кортежи тоже могут содержать таблично заданные функции. Т.о SQL - это язык для работы с табличными функциями.


Во второй НФ, таблицу уже можно рассматривать как отображение множества ключей (объектов) на множество значений (свойств). И де-факто SQL всегда используется во второй НФ (что собсно и подтверждает что в задачах нужны именно объекты и свойства, а не таблицы и строки). Или вы про 2-ю НФ не согласны?
16 дек 09, 11:23    [8073620]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Любого на выбор ? Не пойдет. А объекты изменяют свои св-св методами.
Когда методы конструируют результат это и есть изменение объекта.
Т.е. было одно значение, применили метод, получили другое значение этого-же св-ва этого-же объекта.

Честно говоря мало что понял...
Допустим для примера есть класс Query и у него есть метод execute(Session), который выполняет результат SQL запроса, как допустим List<Map<String,Object>>, он не изменяет ни Query ни Session, то есть он не метод?
И вообще не совсем понимаю откуда вы берете такие определения\требование, что функции не могут менять свойства параметров в ФП или методы обязаны изменять объекты в ООП, может дадите ссылку какую нибудь. Первый раз такое слышу...

_мод
Я имел ввиду не наследование, а возможность конструировать новые типы данных.

А какое отношение конструирование новых типов данных имеет к наследованию? В C типы данных можно наследовать друг от друга?
16 дек 09, 11:32    [8073743]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
antares0
А можно раскрыть что такое "множественные поля"?

Автор так называет функции нескольких переменных :)


Функции они по определению нескольких переменных... Скорее поля нескольких переменных...
16 дек 09, 11:33    [8073757]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Объект и образ есть по-сути одно и тоже. Операцию join очень легко представить визуально, достаточно два кватратика нарисовать со стрелочками. Решение задачи на SQL почти есть задачка образно-визуальная, на геометрический преобразования, и по сложности сравнима с пазлами для детей раннего возраста, когда надо кубики и кружочки вставлять в соответствующие им отверстия. Такого рода задачи - самые естественные для мозга.
16 дек 09, 11:59    [8074120]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
В первый раз я смотрел не SQL, а его прототип альфа. Реакция была положительной.


Вообще по моим наблюдениям программистов условно пожно поделить на:

1) "пролетарии", которым пофигу, что делать лишь бы им деньги платили, они бы SQL даже не начали изучать, пока начальство не сказало что им за это заплатят... Таких людей процентов 50...
2) "гуру", имеют определенный опыт использования технологий, очень себя ценят за него. Для них все остальное это просто "другое", может и полезное но не сравнится с теми технологиями, в которых они разбираются. Соответственно ищут любую зацепку вроде что на SQL нельзя решить дифференциальное уравнение, после чего разводят руками и ставят на ней крест. Начинают интересоваться только когда технология станет общепризнанной, то есть будет использоваться минимум в процентах 10 существующих систем. Таких "гуру" процентов больше чем следует из названия (просто потому что к ним относятся не те кто таковыми являются, а те кто таковыми себя считают) где-то процентов 25
3) "энтузиасты", делятся в свою очередь:
a) "любители" - с небольшим опытом или идеалисты по жизни - много суеты толку мало, ни глобального видения, ни аналитического мышления, никогда не могут оценить экономическую составляющую своей деятельности, ни какой пользы, кроме большой трудоспособности. Яркий пример тусуется в соседнем треде. Их больше чем кажется процентов 15 наверное
б) "реалисты" - самая интересная категория, реально стремятся развиваться куда-то, анализировать существующие проблемы и т.п. , но их мало не больше 10 процентов

Конечно на самом деле бывают смеси из этих категорий, но не в пропорции 50\50, а скорее с примесями...

Но я рад _мод что вы относитесь больше к последней категории, чем ко всем остальным... ;-)
16 дек 09, 12:10    [8074243]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Ggg_old
Объект и образ есть по-сути одно и тоже. Операцию join очень легко представить визуально, достаточно два кватратика нарисовать со стрелочками. Решение задачи на SQL почти есть задачка образно-визуальная, на геометрический преобразования, и по сложности сравнима с пазлами для детей раннего возраста, когда надо кубики и кружочки вставлять в соответствующие им отверстия. Такого рода задачи - самые естественные для мозга.


Это во второй НФ и связываемая таблица с одним ключем... Да и дети вряд ли кубики с кружочками могут клонировать что по сути делает Join. А попробуйте представить этот процесс когда связь идет не по ключу а по нескольким колонкам где могут повторяться значения, вы себе мозг сломаете...
16 дек 09, 12:16    [8074336]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
нитро, не знаю, у меня мозг не ломается на операциях соединения. Мне реально тяжело представлять операции оконные, рекурсивные типа WINDOW, WITH RECURSIVE. Я вот что подумал, что может дело в способе мышления. Если почитать книги по психологии и работе мозга то там выделяются несколько психотипов мышления. Если сильно огрубить, то основными явлются образное (рулит правое полушарие) и логическое (рулит левое). Лично я мыслю картинками. А вот математики как правило имеют ярко выраженное логическое мышление. В общем это тоже надо учитывать при разработке инструментов для прграммистов.
Кстати, что именно вы хотите предложить или хотя-бы над какой проблемой работаете? Ведь даже тот-же лисп не создавался как язык программирования общего назначения, а был предназначен для решения вполне практических задач в области ИИ определнными методами развитыми в 50-е, 60-е годы. Отсюда и название язык обработки списков.
16 дек 09, 12:28    [8074435]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Ggg_old
нитро, не знаю, у меня мозг не ломается на операциях соединения. Мне реально тяжело представлять операции оконные, рекурсивные типа WINDOW, WITH RECURSIVE. Я вот что подумал, что может дело в способе мышления. Если почитать книги по психологии и работе мозга то там выделяются несколько психотипов мышления. Если сильно огрубить, то основными явлются образное (рулит правое полушарие) и логическое (рулит левое). Лично я мыслю картинками. А вот математики как правило имеют ярко выраженное логическое мышление. В общем это тоже надо учитывать при разработке инструментов для прграммистов.
Кстати, что именно вы хотите предложить или хотя-бы над какой проблемой работаете? Ведь даже тот-же лисп не создавался как язык программирования общего назначения, а был предназначен для решения вполне практических задач в области ИИ определнными методами развитыми в 50-е, 60-е годы. Отсюда и название язык обработки списков.


Чисто математически саму операцию то легко выполнить, а вот представить логический результат (то есть что с функциональной точки зрения мы получим в конце) тяжеловато. Вот вы часто выполняете связывание когда у вас одна из таблиц связывается не по полному ключу? не говоря уже о том часто ли у вас встречаются таблицы с повторяющимися записями?

Я уже писал выше, создание полностью декларативной парадигмы разработки бизнес-приложений (информационных систем) .Обобщение и развитие SQL если хотите, вплоть до пользовательского интерфейса, хотя конечно все не совсем так просто.
16 дек 09, 12:38    [8074524]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
antares0
Member

Откуда:
Сообщений: 247
Nitro_Junkie
[quot antares0]
1. Вернусь к предыдущему утверждению и повторю что принадлежность слота классу опредляется метаклассом класса, точнее релизацией нужных методов для этого метакласса. Можно например, что бы один и тот же слот случайным образом появлялся у разных объектов.
[quot]
antares0, мы о разных вещах говорим... Еще раз значение слот может определятся сразу несколькими_____
объектами\классами\метаклассами. То есть в описанном случае про контракт музыканта со студией как____
slot как должен реализовываться какому классу\метаклассу (вы в них по моему немного путаетесь)_______
принадлежать?

`Значение слота определяемое несколькими объектами\классами\метаклассами` - про метаклассы в описаном примере речи не шло.
slot-vаlue согласно CLHS вызывает slot-value-using-class определенную в Metaobject Protocol.
Primary Method slot-value-using-class (class standard-class) object (slot standard-effective-slot-definition)
Primary Method slot-value-using-class (class funcallable-standard-class) object (slot standard-effective-slot-definition)
Аргументы по порядку: метакласс,класс.слот.
В живую это вот так (я подравнял для наглядности)
(SLOT-VALUE-USING-CLASS (CLSQL-SYS::STANDARD-DB-CLASS  T                 T))
(SLOT-VALUE-USING-CLASS (SB-PCL::STD-CLASS             STANDARD-OBJECT   STANDARD-EFFECTIVE-SLOT-DEFINITION))
(SLOT-VALUE-USING-CLASS (STRUCTURE-CLASS               STRUCTURE-OBJECT  SB-PCL::STRUCTURE-EFFECTIVE-SLOT-DEFINITION))

Замечу что STANDARD-OBJECT здесь type specifier в виде символа, но можно и что-нибудь поинтереснее, например
(cons Студия Музыкант)
или что-нибудь параметрическое под спец. требования.
Справедливости ради скажу, что сигнатура slot-value несколько портит эту радужную картину.
Это все про опредление значения слота несколькими параметрами.
Общий слот для нескольких объектов, рассматривать уже лень.

На C++ я тоже могу вручную реализовать сборку мусора, означает ли что C++ поддерживает сборку мусора?

Это похоже на спор о полупустом стакане, но все же.
По моему разумению, С++ поддерживает сборку мусора но предоставляет програмсту на выбор: собирать мусор руками, или автоматизировать процесс по собсвенному вкусу.

Если кажется что я что-то путаю ,то можно попробовать указать на ляпы и смысла в словах станет больше.
16 дек 09, 13:46    [8075156]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
ну, умножение двух таблиц, когда образуются все возможные комбинации всего со всем я представить могу. Вернее представляю это себе как квадратик, где "все со всеми". Такое на практике случается не часто, сходу сложно вспомнить, когда такое пришлось делать в последний раз.
Декларативный подход - дело благое, может что и получится путное. удачи, но не забывайте про такие мелочи как 2+2 vs 2 2 +
16 дек 09, 13:56    [8075233]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
в задачах нужны именно объекты и свойства, а не таблицы и строки). Или вы про 2-ю НФ не согласны?

Согласен, но таблицы нужны для применения к ним рел. алгебры. У объектов никакой алгебры нет, поэтому никаких серьезных задач на них решать нельзя.
16 дек 09, 14:16    [8075405]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
И вообще не совсем понимаю откуда вы берете такие определения\требование, что функции не могут менять свойства параметров в ФП или методы обязаны изменять объекты в ООП, может дадите ссылку какую нибудь. Первый раз такое слышу...

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

А какое отношение конструирование новых типов данных имеет к наследованию?

Это одно и тоже.
16 дек 09, 14:24    [8075473]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
antares0, касательно lisp, C++

Следуя такой логики ассемблер поддерживает наследование, сборку мусора, множественную диспетчеризацию и т.п. И вообще самый лучший язык. Все то что не входит в описание языка, а только может быть реализовано при помощи его, не является частью языка...
16 дек 09, 15:12    [8075992]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Ggg_old
ну, умножение двух таблиц, когда образуются все возможные комбинации всего со всем я представить могу. Вернее представляю это себе как квадратик, где "все со всеми". Такое на практике случается не часто, сходу сложно вспомнить, когда такое пришлось делать в последний раз.
Декларативный подход - дело благое, может что и получится путное. удачи, но не забывайте про такие мелочи как 2+2 vs 2 2 +


Мы пока не язык делаем... Там настройка в виде кода, потом XML, потом визуальная, и только потом когда-нибудь может в язык оформим.
16 дек 09, 15:15    [8076027]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить