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

Откуда: NGC 6137
Сообщений: 2771
Nitro_Junkie
Пилотажный,

ООП добавил очень важный аспект программирования как наследование, только при этом почему-то потребовал присваивать функцию одному объекту и обзывать это дело методом. Как следствие получил массу гемора в виде : неоднозначного определение класса для метода, невозможность множественного полиморфизма, проблемы с модульностью и т.п. ...


методы у класса объекта
а проблемы с полиморфизмом появлялись из-за множественного наследования, поэтому для простоты во многих языках отказались от множеств. наследования в пользу интерфейсов (интерфейсы не только поэтому конечно, но так или иначе интерфейсы подтянули другие затыки и неудобства)
Про этот контекст фраза?

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

Откуда:
Сообщений: 1090
Пилотажный,

Да методы у класса объекта... в этом их проблема...

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

abstract class Thing {
abstract void collide(Thing thing);

abstract void collideAsteroid(Asteroid asteroid);
abstract void collideSpaceShip(SpaceShip spaceShip);
};
class Asteroid extends Thing {
void collide(Thing thing) {
thing.collideAsteroid(this);
}
void collideAsteroid(Asteroid asteroid) {
System.out.println("Asteroid 2 hits asteroid 1");
}
void collideSpaceShip(SpaceShip spaceShip) {
System.out.println("Asteroid 2 hits spaceShip 1");
}
};
class SpaceShip extends Thing {
void collide(Thing thing) {
thing.collideSpaceShip(this);
}
void collideAsteroid(Asteroid asteroid) {
System.out.println("SpaceShip 2 hits asteroid 1");
}
void collideSpaceShip(SpaceShip spaceShip) {
System.out.println("SpaceShip 2 hits spaceShip 1");
}
};

в случае функций делаются реализации collide(Asteroid,Asteroid), collide(Asteroid,SpaceShip), collide(SpaceShip,Asteroid), collide(SpaceShip,SpaceShip), после чего все они через какую-нить конструкцию как defgeneric объединяют в один метод collide(Thing,Thing)... Чувствуете разницу. А теперь еще представьте что SpaceShip из другого модуля и функция collide относится к этому модулю, и попробуйте сделать это в ООП не нарушив модульности...

И кстати отказ в от множественного наследования, из-за неоднозначности выбора реализаци тоже редкий дебилизм... Даже в базовых классах уже чувствуется, когда есть интерфейс Map и абстрактный класс AbstractMap... А уж сколько раз я на эту проблему при построении архитектуры нарывался... :( Но как ни крути Java, C# заняли весь рынок, и уйти от них очень не просто...
15 дек 09, 10:55    [8067483]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
а что по вашему в структурном программировании (и ООП) вызов функции как не реляционная алгебра?

реляционная алгебра работает с множествами, а функции - с элементами множеств.
15 дек 09, 14:17    [8069125]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Да... и к вам тот же вопрос, часто вы сталкиваетесь с задачами рекурсии (кроме классификации) при разработке бизнес-приложений?

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

Все гораздо хуже: функция - это не метод (т.к. ничего не изменяет), и не свойство. В ООП вообще функциям нет законного места.
А наследование существует со времен С как коструирование новых типов данных.
15 дек 09, 14:22    [8069180]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
в случае функций делаются реализации collide(Asteroid,Asteroid), collide(Asteroid,SpaceShip), collide(SpaceShip,Asteroid), collide(SpaceShip,SpaceShip), после чего все они через какую-нить конструкцию как defgeneric объединяют в один метод collide(Thing,Thing)

Я бы сделал наоборот: функция collide(Thing,Thing) сама разбиралась-бы с типами своих параметров
15 дек 09, 14:27    [8069244]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
реляционная алгебра работает с множествами, а функции - с элементами множеств.


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

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

Часто - все функции на конструкторском графе


Забыл упомянуть в вопросе, что не касаясь задач производства (особенно узкоспециализированных)... :) Там много может быть рекурсий не вопрос, хотя объемы там в любом случае как я понимаю небольшие, так что как минимум по скорости использование CTE не так уж и критично...
15 дек 09, 14:40    [8069362]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

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

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


Функция не может записывать в поля объекта? Или метод обязательно что-то должен изменять в объекте? В спецификации ООП ничего не сказано, о mutability ни объектов ни функций ни методов.
Вы немножко путаете с "чистыми" (математическими) функциями, и соответствующими языками (кроме Haskell'а никого даже и не вспомню), но речь шла не про них...

Вот кстати не помню в C наследования, там типы данных можно наследовать? а то на чистом C писал ну очень давно...
15 дек 09, 14:44    [8069403]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Nitro_Junkie
в случае функций делаются реализации collide(Asteroid,Asteroid), collide(Asteroid,SpaceShip), collide(SpaceShip,Asteroid), collide(SpaceShip,SpaceShip), после чего все они через какую-нить конструкцию как defgeneric объединяют в один метод collide(Thing,Thing)

Я бы сделал наоборот: функция collide(Thing,Thing) сама разбиралась-бы с типами своих параметров


Это как? Через if и instanceof... Так по такой логике зачем вообще наследование и полиморфизм, если всегда можно все через if'ы решить? :)
15 дек 09, 14:46    [8069423]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Элемент множества это подмножество из одного элемента.

Нет. Также как один элемент это не список из одного элемента. Это разные типы данных.
15 дек 09, 14:52    [8069487]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Забыл упомянуть в вопросе, что не касаясь задач производства (особенно узкоспециализированных)

Любое сборочное. Объемы ~ 10^7 вершин
15 дек 09, 14:54    [8069502]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Функция не может записывать в поля объекта?

Не должна. И еще вопрос - какого объекта.
Nitro_Junkie
Или метод обязательно что-то должен изменять в объекте?

Обязательно, на то он и метод.
Nitro_Junkie
Вот кстати не помню в C наследования, там типы данных можно наследовать? а то на чистом C писал ну очень давно...

Во многих ЯП (напр эйфория) можно конструировать новые типы на основе уже существующих - вот вам и наследоване и даже множественное.
15 дек 09, 14:58    [8069530]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Это как? Через if и instanceof... Так по такой логике зачем вообще наследование и полиморфизм, если всегда можно все через if'ы решить? :)

Действительно, зачем ?
15 дек 09, 14:58    [8069537]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Nitro_Junkie
Элемент множества это подмножество из одного элемента.

Нет. Также как один элемент это не список из одного элемента. Это разные типы данных.


Не правильно выразился... Элемент множества можно рассматривать как подмножество из одного элемента. Таким образом переход от SQL к структурному программированию есть. И наоборот если рассмотреть множество всех возможных параметров функции и ее результатов, то получается таблица. Это конечно очень условное доказательство эквивалентности SQL и структурного программированию. Но идею я надеюсь вы поняли...
15 дек 09, 15:04    [8069573]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Не должна. И еще вопрос - какого объекта.

Любого из параметров... Если не должна то зачем она вообще нужна? и как вообще по вашему в функциональном\структурном программировании изменяются объекты?

_мод
Или метод обязательно что-то должен изменять в объекте?
Обязательно, на то он и метод.

Издеваетесь? С точки зрения надежности архитектуры, идеальный вариант, когда большинство классов immutable'ы, то есть методы конструируют результат, не изменяя ничего в объектах... Интересно почитать где написано, что метод обязан изменять объект.
Вообще интересно, а как тогда называются все то что относится к классу например String, который как известно immutable...

_мод
Во многих ЯП (напр эйфория) можно конструировать новые типы на основе уже существующих - вот вам и наследоване и даже множественное.

То что множественное наследование есть во многих ЯП я в курсе, речь шла про C...
15 дек 09, 15:17    [8069678]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Nitro_Junkie
Это как? Через if и instanceof... Так по такой логике зачем вообще наследование и полиморфизм, если всегда можно все через if'ы решить? :)

Действительно, зачем ?


Затем что понятие наследования существует в человеческой логики. То есть даже человек далекий от программирования понимает что роза это цветок, то есть у нее как и у всех цветов есть интерфейс дарения на 8 марта и т.п.. И программы написанные с использованием наследования более читабельны, как следствие расширяемы надежны и т.п.
15 дек 09, 15:20    [8069703]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
antares0
Member

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

Хотя справедливости ради, даже в Common Lisp'е не догадались сделать поля множественными и сделать их частным случаем функций, так что он тоже не особо был бы панацеей.

А можно раскрыть что такое "множественные поля"?
И имея некоторый опыт Сommon Lisp c трудом могу предствить поле объекта в виде не-функции (применительно к CL естественно).
Конечно это можно реализовать благо Lisp - язык гибкий, но вы ведь не об этом?
Извиняюсь за некоторое отклонени от темы.
15 дек 09, 15:39    [8069844]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

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

Хотя справедливости ради, даже в Common Lisp'е не догадались сделать поля множественными и сделать их частным случаем функций, так что он тоже не особо был бы панацеей.

А можно раскрыть что такое "множественные поля"?
И имея некоторый опыт Сommon Lisp c трудом могу предствить поле объекта в виде не-функции (применительно к CL естественно).
Конечно это можно реализовать благо Lisp - язык гибкий, но вы ведь не об этом?
Извиняюсь за некоторое отклонени от темы.


Множественные поля это первичные (хранимые) данные не от одного объекта (класса) а сразу от нескольких. То есть например для музыканта, студии записи может быть один контракт... формально в Java это реализуется, как

class Музыкант {
Map<Студия, Контракт> Контракты_музык_со_студ;
};

или

class Студия {
Map<Музыкант, Контракт> Контракты_музык_со_студ;
};

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

Контракт Контракты_музык_со_студ(Студия, Музыкант) initial;

Соответственно обращаться как к функции (что кстати удобно если поле из первичного надо вычисляемым сделать), а записывать через оператор = например
Контракты_музык_со_студ(Studio,BrainStorm) = контракт043;

Соответственно виртуальная машина сама бы выбирала как реализовывать, хранить все эти поля и т.п. Кстати решилось бы много проблем со сборкой мусора.

А в Common Lisp'е насколько я понял поля представлены в виде слотов и они все-таки принадлежат ровно одному объекту :( хотя может я чего-то не нашел, так как документирован он просто жестко...
15 дек 09, 15:56    [8070032]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
как страшно далека дискуссия от нужд трудового пролетариата.
кстати я для себя вывел один из надежных признаков того, будет ли язык успешным и популярным или нет.
в нормальных языках пишут так: a=2+2
а в непопулярных так: a=2 2 + или + 2 2.
и обвешайте язык хоть гирляндой монад, замыканий и еще пачкой умных концепций, но 2 2 + - убьет любое начинание. Именно поэтому, когда я я выбирал какой из ФП языков поизучать, то несмотря на восторженные отзывы о хаскеле он отправился вслед за моим любимым фортом :)
15 дек 09, 16:27    [8070308]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Ggg_old
как страшно далека дискуссия от нужд трудового пролетариата.
кстати я для себя вывел один из надежных признаков того, будет ли язык успешным и популярным или нет.
в нормальных языках пишут так: a=2+2
а в непопулярных так: a=2 2 + или + 2 2.
и обвешайте язык хоть гирляндой монад, замыканий и еще пачкой умных концепций, но 2 2 + - убьет любое начинание. Именно поэтому, когда я я выбирал какой из ФП языков поизучать, то несмотря на восторженные отзывы о хаскеле он отправился вслед за моим любимым фортом :)


Знаете если бы SQL не был бы общепризнанным и вам дали бы его в первый раз... Я думаю ваша реакция была такой же... Нежелание разбираться в проблемах технологий, а просто плыть по течению, это больше характеризует вас, а не языки... no offence ;-)

ps: хотя когда с раной борются косметикой, а не швами, ничего хорошего из этого по определению не получается
15 дек 09, 16:34    [8070369]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
antares0
Member

Откуда:
Сообщений: 247
Nitro_Junkie
Контакт Контракты_музык_со_студ(Студия, Музыкант) initial;

Соответственно обращаться как к функции (что кстати удобно если поле из первичного надо вычисляемым сделать), а записывать через оператор = например
Контракты_музык_со_студ(Studio,BrainStorm) = контракт043;

Соответственно виртуальная машина сама бы выбирала как реализовывать, хранить все эти поля и т.п. Кстати решилось бы много проблем со сборкой мусора.


А в Common Lisp'е насколько я понял поля представлены в виде слотов и они все-таки принадлежат ровно одному объекту :( хотя может я чего-то не нашел, так как документирован он просто жестко...

1. Чем представлены поля и чему принадлежат определяет метакласс.
Даже для стандартного варианта есть еще принадлежность классу.
Значение слота может принаадлежать другому слоту. Точне оба слота содержат ссылку на один и тот же объект.
2. Слот предсавляется в виде (slot-value 'класс 'слот) и обычно это детали внутрипакетной работы.
Опять же как я говорил функция.
3. Для магии типа вашей есть accessor-ы
Для примера (setf (Контракты_музык_со_сту Studio BrainStorm) контракт043)
Точнее это самая простая реализация.
Полноценная реализация на mop это магия чуть повыше, но вполне частая для реализации сложных хотелок.
Жаловаться на отсутсвие доков при наличии HyperSpec-а и AMOP?
Другой вопрос о паттернах и use-case-ах, но это другой вопрос.
P.S. Меня конечно несколько понесло, но люблю точность.
15 дек 09, 16:40    [8070432]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
antares0
Member

Откуда:
Сообщений: 247
Ggg_old
как страшно далека дискуссия от нужд трудового пролетариата.
кстати я для себя вывел один из надежных признаков того, будет ли язык успешным и популярным или нет.
в нормальных языках пишут так: a=2+2
а в непопулярных так: a=2 2 + или + 2 2.
и обвешайте язык хоть гирляндой монад, замыканий и еще пачкой умных концепций, но 2 2 + - убьет любое начинание. Именно поэтому, когда я я выбирал какой из ФП языков поизучать, то несмотря на восторженные отзывы о хаскеле он отправился вслед за моим любимым фортом :)

Еще раз встряну. В Hasskell-е по-моему как раз 2 + 2 (Хотя можно и в префиксной, на выбор)..
15 дек 09, 16:44    [8070474]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
antares0
Nitro_Junkie
Контакт Контракты_музык_со_студ(Студия, Музыкант) initial;

Соответственно обращаться как к функции (что кстати удобно если поле из первичного надо вычисляемым сделать), а записывать через оператор = например
Контракты_музык_со_студ(Studio,BrainStorm) = контракт043;

Соответственно виртуальная машина сама бы выбирала как реализовывать, хранить все эти поля и т.п. Кстати решилось бы много проблем со сборкой мусора.


А в Common Lisp'е насколько я понял поля представлены в виде слотов и они все-таки принадлежат ровно одному объекту :( хотя может я чего-то не нашел, так как документирован он просто жестко...

1. Чем представлены поля и чему принадлежат определяет метакласс.
Даже для стандартного варианта есть еще принадлежность классу.
Значение слота может принаадлежать другому слоту. Точне оба слота содержат ссылку на один и тот же объект.
2. Слот предсавляется в виде (slot-value 'класс 'слот) и обычно это детали внутрипакетной работы.
Опять же как я говорил функция.
3. Для магии типа вашей есть accessor-ы
Для примера (setf (Контракты_музык_со_сту Studio BrainStorm) контракт043)
Точнее это самая простая реализация.
Полноценная реализация на mop это магия чуть повыше, но вполне частая для реализации сложных хотелок.
Жаловаться на отсутсвие доков при наличии HyperSpec-а и AMOP?
Другой вопрос о паттернах и use-case-ах, но это другой вопрос.
P.S. Меня конечно несколько понесло, но люблю точность.


Вот честно говоря 1 не понял, можно чуть нагляднее в контексте примера пояснить.

2,3: То есть как в Smalltalk'е все поля private'ы по определению... Но это ничего не меняет, в спецификации языка нету множественных полей, конечно их можно эмулировать, но все равно все придется делать самому... И не факт что хватит статистики, ведь нужно считать количество обращений, записей отсюда выбирать размеры хэшей или вообще ordered реализации, вобщем делать все то что делают СУБД, а это нормально можно сделать только в самой виртуальной машине...

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

Откуда:
Сообщений: 247
Nitro_Junkie
antares0
Nitro_Junkie
Контакт Контракты_музык_со_студ(Студия, Музыкант) initial;

Соответственно обращаться как к функции (что кстати удобно если поле из первичного надо вычисляемым сделать), а записывать через оператор = например
Контракты_музык_со_студ(Studio,BrainStorm) = контракт043;

Соответственно виртуальная машина сама бы выбирала как реализовывать, хранить все эти поля и т.п. Кстати решилось бы много проблем со сборкой мусора.


А в Common Lisp'е насколько я понял поля представлены в виде слотов и они все-таки принадлежат ровно одному объекту :( хотя может я чего-то не нашел, так как документирован он просто жестко...

1. Чем представлены поля и чему принадлежат определяет метакласс.
Даже для стандартного варианта есть еще принадлежность классу.
Значение слота может принаадлежать другому слоту. Точне оба слота содержат ссылку на один и тот же объект.
2. Слот предсавляется в виде (slot-value 'класс 'слот) и обычно это детали внутрипакетной работы.
Опять же как я говорил функция.
3. Для магии типа вашей есть accessor-ы
Для примера (setf (Контракты_музык_со_сту Studio BrainStorm) контракт043)
Точнее это самая простая реализация.
Полноценная реализация на mop это магия чуть повыше, но вполне частая для реализации сложных хотелок.
Жаловаться на отсутсвие доков при наличии HyperSpec-а и AMOP?
Другой вопрос о паттернах и use-case-ах, но это другой вопрос.
P.S. Меня конечно несколько понесло, но люблю точность.


Вот честно говоря 1 не понял, можно чуть нагляднее в контексте примера пояснить.

2,3: То есть как в Smalltalk'е все поля private'ы по определению... Но это ничего не меняет, в спецификации языка нету множественных полей, конечно их можно эмулировать, но все равно все придется делать самому... И не факт что хватит статистики, ведь нужно считать количество обращений, записей отсюда выбирать размеры хэшей или вообще ordered реализации, вобщем делать все то что делают СУБД, а это нормально можно сделать только в самой виртуальной машине...

Отсутствие доков определяется как быстро можно найти наглядную структурированую информацию в гугле... От чистого описания синтаксиса наприме при изучении языка мне например ни горячо ни холодно... Впрочем может я на самом деле просто не умею эффективно пользоваться гуглом :)

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