Расчет количества комбинаций

В общем фишка такая что
Y может быть 15
X может быть выбран 14

это сложно посчитать в ручную, и хотелось бы запрограммить универсально, чтобы даже если Y=100, X=50 считалось, правдо цифры там будут охрененные!!! Народ, поможите кто чем может. Мона на любом языке программирования, а ещё лучше просто алгоритм

Открой любую книжку по комбинаторике. Можно не открывать, но тогда обрати внимание на то что ты привел в пример:
y1*y2*y3
y1*y2*y4
y1*y2*y5
y1*y3*y4
y1*y3*y5
y2*y3*y4
y2*y3*y5
y3*y4*y5
y4*y5*y1
y4*y5*y2

Можно сгруппировать несоклько другим образом
y1*y2*y3
y1*y2*y4
y1*y2*y5
y1*y3*y4
y1*y3*y5
y1*y4*y5
y2*y3*y4
y2*y3*y5
y2*y4*y5
y3*y4*y5

Подумав прийдем к мысли что это число сочетаний без повторений. Чуть чуть поэкспериментировав над листком бумаги и разными комбинациями x и y. Прийдем к старой доброй формуле.

Число сочетаний k элементов из n = n!/k!(n-k)!

Да фишка в том, что число комбинаций без повторений я расчитать могу, мне надо получить сами комбинации. Вот это я сделать не могу.

>делаем произведения, всего их может быть 10

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

А... каюсь невнимательно прочитал :). То есть тебя не страивает банальное умножение всех комбинаций и ты его хочешь ускорить? Если же оно тебя устраивает то посмотри как я сгруппировал элементы.

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

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

Тобишь 10 уникальных комбинаций - 10 результатов произвдений в каждой комбинации

Кстати мона ещё упростить задачу известно ещё число например 200 при 10 уникальных комбинациях

тогда на одну комбинацию будет приходится 20

тогда в результате надо получить

произвед_комб1*20+
произвед_комб2*20+
произвед_комб3*20+
произвед_комб4*20+
произвед_комб5*20+
произвед_комб6*20+
произвед_комб7*20+
произвед_комб8*20+
произвед_комб9*20+
произвед_комб10*20=???

Вообщем сам скрипт и то что нужно найти по этому адресу

http://bonb.ru/phl/systema.php

Кто захочет помочь ICQ 125328224

произв_комб8*1 это что? я так и не понял.

произв_комб8 - это одна из возможных не повторяющихся комбинаций.

*1 - это число которое получается при делении содержимиого самого нижнего текстового поля на количество комбинаций.

Тобишь это число равномерно распределяется на все комбинации.

Понятно.. то есть оно нас не колышет? Ну тогда нас интересует лишь сумма произведений чисел из сочетаний. Я так понимаю что проблема заключается в том, можно ли как нибудь свернуть эту формулу?

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


К примеру.

Есть
--------------
X=2
Y=3
Y1=4
Y2=5
Y3=10
KOL_KOMBINACI=3 (считаем через факториал)
SUMMA=60
SUMMA_NA_ODNU_KOMBINACIU=SUMMA/3
--------------

Y1*Y2*SUMMA_NA_ODNU_KOMBINACIU+
Y1*Y3*SUMMA_NA_ODNU_KOMBINACIU+
Y2*Y3*SUMMA_NA_ODNU_KOMBINACIU = 4*5*20+4*10*20+5*10*20 = 400+800+1000=2200

Вот эти 2200 и надо найти (в смысле уже нашли, но а если X=4, Y=10)
тогда получится KOL_KOMBINACI=210, а тут уже будет в ручную считать очень трудно :-)

Ну в принципе не так много перемноженийвсего то количество сочетаний*количество элементов в сочетаниях. Причем и тут можно использовать рекурсивные формулы для облегчения вычислений. Или время выполнения очень уж критично?

Тока там разделить не на 3, а на Y, но я думаю ты уже догадался. Время большого значения не имеет. Главное чтобы решалось унифицировано, для любых чисел.

Так все ж просто? По всем сочетаниям пробегаешся и находишь произвдеения, по пути их суммируя. Умножаешь на коэффициент. В чем проблема?

К примеру практически, такая задача как:

X=7 Y=15 (6435)
или
X=8 Y=15 (6435)

решаться скорее всего не будет, но мало ли, кому в голову взбредет. Так что надо предусматреть. А как видно 6435, это слишком много комбинаций

Ну поработает машинка немного.. произведет 50000 умножений. В чем проблема?

Проблема в том, что мне не известны сами комбинации. Я не знаю что на что умножать!

function f(m:array of double):Double
begin
sum = 0;
for i=1 to y-x+1 do
begin
to_use = copy_right_part(m,i+1); // копировать правую часть массива чисел начиная с i+1 позиции
sum = sum+m(i)*f(to_use);
end;
return sum;
end

P.S. Мог где то накосячить, нарисовал в уме, не пробовал вычислять.

Хм, щас попробую

Не понял как это
>копировать правую часть массива чисел начиная с i+1 позиции

Понял, щас реализуем.

Тяжко, может начнем с

Функция СчитаемРезультат(Сумма(SUMMA), Тип_Системы(X), Массив_Элементов(Y))
{
Количество_Элементов=размер(Массив_Элементов)






}

Реализовал, получаю стабильный 0, это неправильно :-)

В смысле тяжко? что не так?

Кажись, пока что мы тут с программерами консилиум устроили. Кажись нашли че да как, и в чем проблема. Как сделать. Как только будет готово, скину сюда.

Все вопрос закрыт

http://www.bonb.ru/systema.php

Посмотрел условие. Написал за 15 минут программку и задал ей страшные x=14 и y=15,
смотрю результатов маловато, потом проверил число комбинаций по формуле.

Долго смеялся когда понял, что число неповторяющихся комбинаций при выборе x=14 из y=15 всего равно 15 штук ;-))

Программка на Common Lisp со вспомогательными функциями:

;(setf *y* '(1 2 3 4 5))

;(defun factorial (n)
; (if (= n 0) 1
; (* n (factorial (1- n)))))

;(defun n-combs (n-elts len)
; (/ (fact len) (* (fact n-elts) (fact (- len n-elts)))))

;(defun find-combs (x-depth cur-prod tail fn &optional (f-;num 0))
; (if (= x-depth 1)
; (dolist (e tail f-num)
; (incf f-num)
; (format t "result[~D]=~D~%" f-num (funcall fn cur-prod e)))
; (do ((t-tail (cdr tail) (cdr t-tail))
; (t-head (car tail) (car t-tail)))
; ((null t-tail) f-num)
; (setf f-num (find-combs (1- x-depth) (funcall fn cur-prod t-head) t-tail fn f-num)))))

;(defun concat (lst elt)
; (append lst (list elt)))

;; выдает сами комбинации
(find-combs 3 nil *y* #'concat)
;; выдает результаты
(find-combs 3 1 *y* #'*)

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

Lisper

Форматирование дохнет, повтор.

Кстати данные приведены для выбора из 5 по 3, то есть x=3 y=5

Подчеркивания заменить на пробелы.

(setf *y* '(1 2 3 4 5))

(defun factorial (n)
____(if (= n 0) 1
______(* n (factorial (1- n)))))

(defun n-combs (n-elts len)
____(/ (fact len) (* (fact n-elts) (fact (- len n-elts)))))

(defun find-combs (x-depth cur-prod tail fn &optional (f-num 0))
____(if (= x-depth 1)
________(dolist (e tail f-num)
____________(incf f-num)
____________(format t "result[~D]=~D~%" f-num (funcall fn cur-prod e)))
________(do ((t-tail (cdr tail) (cdr t-tail))
____________(t-head (car tail) (car t-tail)))
____________((null t-tail) f-num)
____________(setf f-num (find-combs (1- x-depth) (funcall fn ur-prod t-head) t-tail fn f-num)))))

(defun concat (lst elt)
____(append lst (list elt)))

;; списки всех комбинаций по 3 из 5
(find-combs 3 nil *y* #'concat)
;; результаты произведения всех комбинаций
(find-combs 3 1 *y* #'*)

Lisper

По прежнему пропагаднируешь LISP?

А почему бы и нет. Он как раз хорошо приспособлен для решения таких задачек. Естественно Common Lisp, так как всякие AutoLisp существенно не дотягивают по многим параметрам.

Не согласен :). Тут слишком простой случай, чтобы прибегать к лиспу, вполне можно было бы обойтись чемнибудь стандартным. Вот если бы существовало с десяток доп.условий, то лисп бы получил преимущество.

P.S. Интересно, а что ты думаешь скажем о PROLOG?

Лисп и так стандартный, ANSI Common Lisp называется. Лисп имеет преимущества практически в любом случае, никаких доп. условий не надо.

Кстати то что в моем решении используются списки не значит, что я не могу использовать массив, но списков для этой задачи достаточно.

И что общего у Common Lisp и Пролога ? Разве что на Лиспе можно реализовать Пролог в качестве встроенного языка и использовать его в некоторых частях приложения (что и делают крупные вендоры реализаций Common Lisp). В общем пока ничего не думаю о Прологе.

В 9 случаях из 10 спорящие лишь еще больше утверждаются в своих мнениях :). Черт побери, не зная лиспа так как вы, с вами невозможно спорить.

Best regards.

А дрова на Лиспе слабо будет написать?

Знавал я одну конторку (за бугром), где как-то пытались дрова на Яве писать....

Лет этак 20 назад на Лиспе были созданы и целые операционные системы и дрова тоже были написаны на Лиспе. Почитайте про Лисп-машины, некоторые люди их до сих пор используют.

Что касается современных компьютеров, есть проекты типа LispOS, но дрова на Лиспе скорее всего никто не пишет, да и нафиг это нужно, надо же С/С++ хоть какую-то нишу оставить ;-) По быстродействию с С/С++ расхождение может быть где-то на 30%, на некоторых задачах Лисп обгоняет, используя преимущества компиляции на лету, т.е. дрова вполне можно писать.

Извиняюсь, диалетанский вопрос. А какие коммерческие продукты реализованы на Лиспе. В каких областях он получил применение?
Вот Вы его хвалите, хвалите. А где, кто и для каких реальных задач его использует.
Мне из универовского курса Лисп запомнился языком совершенно неподходящим например для GUI, Web приложений, Application серверов и вообще любых бизнес задач, только для научных целей / и разработки спец алгоритмов, хотя честно говоря я его уже забыл, наверное просто не в теме ...
Ведь помимо самого языка и его парадигмы для коммерческого использования необходима поддержка библиотеками самого разного плана. Есть ли это для Лиспа и в каком объеме?

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

Ваш вопрос настолько ёмкий, что на него сложно коротко ответить. Попробую как смогу
прокомментировать.

>Извиняюсь, диалетанский вопрос. А какие коммерческие продукты реализованы на Лиспе. В каких

>областях он получил применение?
>Вот Вы его хвалите, хвалите. А где, кто и для каких реальных задач его использует.

Ссылки:
http://www.franz.com/success - (англ) страница историй успеха
одного из ведущих вендоров Common Lisp
http://www.lisp.org/table/applications.htm - (англ) перечень приложений, написанных на Лиспе
http://www.lisp.org/table/good.htm - (англ) обзор, для чего хорош Лисп

http://www.paulgraham.com/paulgraham/avg.html - (англ) статья о суперуспешном применении Лиспа
для генерации интернет магазинов. Вообще советую
почитать все, что есть на сайте.

http://www.paulgraham.com/iflisp.html - (англ) короткая статья о том, почему Лисп не популярен
и вроде бы нигде не используется.

http://www.lispworks.com - страница еще одного ведущего вендора реализаций Common Lisp

Цитата:
"...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and

E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent

Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language,

Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are

the only things they happened to list." - Kent Pitman

http://lisp.narod.ru/msg.html - (рус) хорошая подборка заблуждений относительно Лиспа, среди
которых "Лисп - это язык функционального программирования".

>Мне из универовского курса Лисп запомнился языком совершенно неподходящим например для GUI

Интересно почему ?

Например Пример описания окна диалога с полем для ввода и списком строк:

(contain
(make-instance 'column-layout :description (list
(make-instance 'text-input-pane)
(make-instance 'list-panel :items
'(first second third)))))

Мне кажется очень удобной библиотека CAPI (Common Application Programmer's Interface)
в одной из коммерческих реализаций Common Lisp (http://www.lispworks.com). Все удобно
и логично, очень смахивает на программирование GUI в Java, однако количество строк кода
требуется поменьше.

> Web приложений

Читайте http://www.paulgraham.com/paulgraham/avg.html и надеюсь измените свое
мнение. Потому что, IMHO Лисп как раз в этой области имеет самый большой потенциал.

> Application серверов и вообще любых бизнес задач.

Странно, но похоже Лисп как раз идеален для Application серверов. Вы можете поменять любую
функцию или класс прямо в работающем в данный момент приложении без его остановки. Вы можете

добавлять функциональность в приложения 24x7 без всяких доп. интерфейсов и сложных компонентных

моделей.

>, только для научных целей / и разработки спец алгоритмов, хотя честно говоря я его уже забыл,

>наверное просто не в теме ...

Он просто хорошо подходит для сложных и особенно неизведанных задач. Но это же вроде плюс ???

>Ведь помимо самого языка и его парадигмы для коммерческого использования необходима поддержка

>библиотеками самого разного плана. Есть ли это для Лиспа и в каком объеме?

Есть много всего всего, особенно у коммерческих вендоров. Хотя недавно был топик, в котором
пришлось признать, что например для разработки риал-тайм 3D движков для игр маловато поддержки,
но одна из известных компаний умудрилась разработать свой специальный компилятор (GOAL), написать

суперский движок и создать игру на нем (для приставок!!!, у которых очень жесткие ограничения
на память и другие ресурсы):

http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml

Более того они написали на нем множество инструментов для создания будущих игр и
активно используют Лисп для предвычисления оптимальных параметров отображения сцен
по множеству характеристик.

Когда они после очередного проекта разбирали недостатки и преимущества, то выяснилось, что

единственным недостатком такой технологии в сущности являлся плохой менеджмент проекта, который

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

Получилось что один спец писал и компилятор и движок (год на компилятор и 2 года на игру), но они

вышли с игрой точно в срок и пишут, что этой точности они обязаны таки Лиспу.

По поводу использования Common Lisp в распределенных вычислениях и кластерных архитектурах
хорошая статья про ITA Software http://www.paulgraham.com/carl.html

>По поводу быстродействия. А на каких тестах сравнивается?

На всяких. Например разбор регулярных выражений, CL-PPCRE ощутимо перегоняет PERL (зависит
от реализации Common Lisp).

Честно говоря, виндовые реализации Common Lisp на примитивных тестах уступают оптимизированному
С/С++ побольше, чем на 30%, но это можно преодолеть по правилу 20/80 и оптимизировать критические
участки кода получше или сменить алгоритм (Лисп хорошо подходит для быстрой проверки идей).
Некоторые реализации транслируют в Си и требуется просто подобрать хороший компилятор (g++ из
Cygwin не выдержал соревнования с компилером из VStudio 7.1

Я из баловства сравнивал на простеньких тестах вроде сложения всех элементов матрицы 1000x1000
и бинаризации и у меня получилось расхождение порядка: VС++ ~1.5 ms. - CMU Common Lisp ~1.6 ms.
g++ выдал результат за ~14 ms (тот же результат из аналогичной программы на Лисп, транслированной
в Си ~14 ms).

>Лисп ведь функциональный язык, а те же плюсы это уже ООП.

"А мужики-то не знают!" (Цитата) У Вас явно недостаток информации по этому вопросу.
Для улучшения кругозора, наверное стоит ознакомиться с несколькими языками (помимо С++),
в первую очередь рекомендую посмотреть OCaml (http://caml.inria.fr) ,
Haskell (http://www.haskell.org) или Clean (http://www.cs.kun.nl/~clean).
Вы увидите, что ООП и ФП никак друг другу не противоречат и что объектно-ориентированный
подход не панацея, а средство имеющее свою ограниченную область применения.

Оба Ваших утверждения как минимум наполовину не верны:

1) Common Lisp - это язык поддерживающий множество парадигм программирования и Вы можете
реализовать и проверить на нем свою собственную новую парадигму. ФП, ИП, ЛП, АП, ООП - это
не полный список парадигм, которые поддерживает Лисп. Более того Лисп был первым ООП языком,
который был стандартизирован ANSI и по сей день его объектная система CLOS вне конкуренции.
Кстати Лисп - это не язык, это семейство языков, в котором помимо Common Lisp есть например
Scheme.

2) C++ - это гибридный язык и реализация идей ООП в нем мягко говоря не блестящая.
Гибридную суть С++ можно выразить фразой: "С++ is answer, what was the question ?".
Например в Common Lisp из коробки доступна множественная диспетчеризация и специализация
методов на конкретном экземпляре объекта, а также такая рулезная вещь как МетаОбъектный
Протокол (MOP), которая позволяет менять свойства классов, представляя их экземплярами
метаклассов и тем самым добавлять функциональность полностью отогонально имеющейся.
Как в C++ получить и использовать указатель на виртуальный метод ? Я знаю, что все можно
сделать/имитировать, но IMHO обертки над этими имитациями в С++ довольно тяжелы, не очевидны
в использовании (Boost, Loki, Lisp++) и не идут ни в какое сравнение с тем, что можно сделать,
используя макросы Common Lisp.

>Было бы интересно посмотреть исходники небольших тестов, чтобы оценить насколько сравнимы

>алгоритмы, т.е. действительно ли их можно сравнивать.
Честно говоря, меня уже достали сравнения микроэффективности (хотя она тоже важна).
Будь все реализации Common Lisp даже в 10 раз тормознее на каких-нибудь операциях (некоторые

реализации тормозят на массивах), я бы все равно его выбрал по причине кучи других преимуществ,

среди которых есть не встречающиеся ни в каком другом языке:

a) Макросы (не путать с макросами С/С++, в Common Lisp макросы - это программы для написания

программ). Благодаря этому, CLOS сам написан на Common Lisp (и большая часть Common Lisp тоже)
Например в стандарт Common Lisp включен (один из имеющихся) языков для описания итеративных
алгоритмов. Простенький примерчик:


(loop for E across Array
when (> E 0)
sum E into My-sum
when (evenp E)
collect E into Even-list
finally (return (values My-sum Even-list)))

Суммирует все числа больше нуля (любого типа) из массива Array,
составляет список четных чисел и, в итоге, возвращает оба значения.

Весь синтаксис этого языка итераций написан на Лиспе и Вы также можете создать свои
встроенные языки вроде Common SQL, поставляемого вместе с LispWorks:

(select [person_id] [person surname] :from [person])
(connect "personnel")

;(with-transaction
; (insert-records :into [emp] :attributes '(empno ename job deptno) ;

; :values '(7100 "ANDERSON" "SALESMAN" 30))

(update-records [emp] :attributes [deptno] :values 50 :where [= [deptno] 40])
(delete-records :from [emp] :where [> [sal] 300000]))

Примечание: в Common Lisp функция и вообще любое вражение может возвращать
несколько значений одновременно, при чем любое выражение концептуально всегда
возвращает результат, даже если он NIL, то есть все выражения можно использовать
как конструкции типа y = x > 0 ? 0 : x в Си. То есть в переводе на С++ в Common Lisp
возможны такие вещи как:

T sum_elts = { int i; T sum; for (sum=0,i=0;i

Ну во-первых большое спасибо за столь развернутый и подробный ответ.

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

>>Мне из универовского курса Лисп запомнился языком совершенно неподходящим например для GUI
>Интересно почему ?

Наверное в силу того как излагали курс. Насколько я помню на примере Лиспа мы изучали функциональное
программирование. Может быть поэтому.

>Мне кажется очень удобной библиотека CAPI (Common Application Programmer's Interface)
>в одной из коммерческих реализаций Common Lisp (http://www.lispworks.com). Все удобно
>и логично, очень смахивает на программирование GUI в Java, однако количество строк кода
>требуется поменьше.

Это интересно. Я тут мин за 20 написал небольшой примерчик ГУИ на джаве - окошко, в котором по краям
движется квадратик. Кликая на него мышкой полчаем попап с его координатами. Мне кажется этот пример
показателен - работа с рисование, обработка событий мыши. стандартные сообщения. 90 строк. См. аттач.
Интересно сколько подобный пример занимает на Лиспе.

>Странно, но похоже Лисп как раз идеален для Application серверов. Вы можете поменять любую
>функцию или класс прямо в работающем в данный момент приложении без его остановки. Вы можете
>добавлять функциональность в приложения 24x7 без всяких доп. интерфейсов и сложных компонентных
>моделей.

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

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

>Ведь помимо самого языка и его парадигмы для коммерческого использования необходима поддержка
>библиотеками самого разного плана. Есть ли это для Лиспа и в каком объеме?

>> Есть много всего всего, особенно у коммерческих вендоров. Хотя недавно был топик, в котором
>> пришлось признать, что например для разработки риал-тайм 3D движков для игр маловато поддержки,
>> но одна из известных компаний умудрилась разработать свой специальный компилятор (GOAL), написать

Особое место занимает стоимость коммерческих продуктов. Доступность -> массовость -> качество и большое
количество разнообразных библиотек.

>Лисп ведь функциональный язык, а те же плюсы это уже ООП.
> Вы увидите, что ООП и ФП никак друг другу не противоречат

Что значит не противорчат. Разные же подходы к программированию. Можно например на Java
писать как на C используя только статические методы при желании :). Но мы же про другое.

> 1) Common Lisp - это язык поддерживающий множество парадигм программирования и Вы можете
> реализовать и проверить на нем свою собственную новую парадигму. ФП, ИП, ЛП, АП, ООП - это
> не полный список парадигм, которые поддерживает Лисп. Более того Лисп был первым ООП языком,
> который был стандартизирован ANSI и по сей день его объектная система CLOS вне конкуренции.
> Кстати Лисп - это не язык, это семейство языков, в котором помимо Common Lisp есть например
> Scheme.

Это интересно. Но меня настораживает. Как это из практики уже сложилось, что чем больше универсализм,
тем неудобнее для конкретных задач.

> 2) C++ - это гибридный язык и реализация идей ООП в нем мягко говоря не блестящая.
> Гибридную суть С++ можно выразить фразой: "С++ is answer, what was the question ?".
> Например в Common Lisp из коробки доступна множественная диспетчеризация и специализация
> методов на конкретном экземпляре объекта, а также такая рулезная вещь как МетаОбъектный
> Протокол (MOP), которая позволяет менять свойства классов, представляя их экземплярами
> метаклассов и тем самым добавлять функциональность полностью отогонально имеющейся.
> Как в C++ получить и использовать указатель на виртуальный метод ? Я знаю, что все можно
> сделать/имитировать, но IMHO обертки над этими имитациями в С++ довольно тяжелы, не очевидны
> в использовании (Boost, Loki, Lisp++) и не идут ни в какое сравнение с тем, что можно сделать,
> используя макросы Common Lisp.

О реализации ООП в C++ можно много спорить :). То что он гибрид мне не нравится самому
(это чисто субъективно). Но это его особенность, в этом есть и плюсы и минусы.


С уважением
Лестор

> Переопределение любой части кода на лету прямо в работающем приложении

Опасно, ой, опасно... Этим ножом очень легко порезаться.
Пример - ООП программы на Java (объекты основаны на классах, которые сначала пишутся, потом компилируются) как правило вполне понятны и работоспособны.
Сравнимые по сложности программы на JavaScript (объекты основаны на прототипах, которые конструируюися на лету) кишат ошибками, и для их переделки нужны нетривиальные усилия.

В общем, слишком много свободы тоже бывает плохо.

>Это интересно. Я тут мин за 20 написал небольшой примерчик ГУИ на джаве - окошко, в котором по краям движется квадратик. Кликая на него мышкой
>полчаем попап с его координатами. Мне кажется этот
>пример показателен - работа с рисование,
>обработка событий мыши. стандартные сообщения.
> 90 строк. Интересно сколько подобный пример
> занимает на Лиспе.

У меня ушло больше 20 минут, так как я только начал изучать библиотеку CAPI (раньше писал свою библиотеку GUI под Corman Lisp). Опять же можно написать и компактнее и чище, но все же. См. аттач.

> Переопределение любой части кода на лету
> прямо в работающем приложении

>Опасно, ой, опасно... Этим ножом очень легко >порезаться.

Дык когдa в одной из функций найдется малююсенький косяк, а программа уже у клиента на другом конце земного шара, то эта фича как минимум позволит послать клиенту патч размером в 1К и легко закрыть дыру.

>Пример - ООП программы на Java (объекты >основаны на классах, которые сначала пишутся, >потом компилируются) как правило вполне понятны >и работоспособны.
Дык потому что особо фич для метапрограммирования никаких нет. Шаблонов нет, макросов как в Common Lisp нет. Вот и набивай одно и тоже 30 раз.

>Сравнимые по сложности программы на JavaScript
>(объекты основаны на прототипах, которые
>конструируюися на лету) кишат ошибками, и для их
>переделки нужны нетривиальные усилия.
Ну я вообще-то не совсем это имел в виду. А то что можно дописывать на ходу уже работающее приложение - переопределять функции и все что угодно не останавливая приложение. Причем тут понятность кода и прототипы ?

Ну хотя генерация и компиляция кода самими функциями в процессе работы в Commo Lisp тоже возможнa, что может ускорить операции, для которых прекомпилированный запрос будет работать быстрее, чем интерпретируемый. Но такие вещи применяются там, где без них никак нельзя.

>Ну во-первых большое спасибо за столь
>развернутый и подробный ответ.

You're welcome ;-) Вопрос действительно емкий и я даже со статьями покрыл его всего процентов на 5.

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

Лиспы повсюду и в очень разных формах, например XML - это просто другое представление S-выражений из Лиспа. В качестве языка программирования общего назначения рекомендую Common Lisp.

>Наверное в силу того как излагали курс. Насколько я помню на примере Лиспа мы изучали функциональное
>программирование. Может быть поэтому.

Да, специфика отечественного преподавания такова. Хотя надо сказать Common Lisp действительно хорошо приспособлен для ФП, но не ограничивается им ни в коей мере.

>Наверное я не совсем правильно высказался. Есть >ли сервера приложений в которых можно создавать
>сервиса на Лиспе. Возможно Лисп потенциально и >неплох, другой вопрос - а можно ли уже сейчас >разрабатывать на нем.
Думаю можно. А какого типа сервисы нужны ?

>Особое место занимает стоимость коммерческих продуктов. Доступность -> массовость -> качество и большое
>количество разнообразных библиотек.

Смотря что делать. Библиотек вроде много, но наверняка чего-то не хватает. Например какие Вас интересуют ?

>Что значит не противорчат. Разные же подходы к >программированию. Можно например на Java
>писать как на C используя только статические >методы при желании . Но мы же про другое.

Не путайте (Императивное программирование vs Функциональное программирование) с (Объектно-ориентированное программирование vs Функциональное программирование). Если первые прямо противоречат друг другу, то вторые вовсе ортогональны и никак не мешают друг другу. См. OCAML (Objective CAML) http://caml.inria.fr/

>Это интересно. Но меня настораживает. Как это из практики уже сложилось, что чем больше универсализм,
>тем неудобнее для конкретных задач.
Главный способ программирования в Лиспе - создавать небольшие встроенные языки, хорошо подходящие к проблеме, поэтому универсализм здесь только на уровне базового языка, а дальше уже конкретика, т.е. язык поднимается к приложению в то время как приложение пишется на этом языке. Таким образом, создаем удобный специализированный язык и решаем конечную задачу на нем, в то же время он будет оставаться тем же Лиспом.

С уважением
Lisper

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

Плюс еще одна строка: удаление таймера в деструкторе

Предлагаю пример. Бронирование авиабилетов онлайн.

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

Нужно сделать как минимум:

набор отчетов
веб интерфейс для клиентов.
рабочее место для продавца.
рабочее место для оператора.
рабочее место менеджера.

на самом деле список неполный.

Реализация клиент-серверного приложения предполагается в следующем виде:

клиентская часть - веб контейнеры - сервер приложений - БД

Клиентская часть может быть как ГУИ так и веб интерфейсом.
Веб контейнеры формируют отчеты, принимает и отправляют запросы клиентов.
Сервер приложений - проводит транзакции по бронированию билетов, извлекает
данные из БД и т.п.

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

Т.е. что нужно (по первой прикидке):

Веб-контейнер, в котором можно писать обработчики HTTP запросов на Лиспе.
Сервер-приложений,
Библиотека по формированию pdf, xls, doc файлов для отчетов.
GUI с html парсером (чтобы менеджер мог видеть html отчеты у себя в приложении)
Библиотека с доступом к различным БД (аналог ODBC или JDBC)
Библиотека для отсылки/приема писем (как минимум smpt и pop3)

Технология для работы ЛИСП в среде веб-приложения: HTTP запросы, пользовательские сессии, авторизация.
Разработка собственного веб-сервера не пройдет для промышленной системы. Слишком много рисков.
Библиотека для парсинга XML.

Технология для работы ЛИСП в среде сервера-приложений: HTTP запросы, пользовательские сессии, авторизация,
создания управляемых сервисов (модуля, которым мог бы управлять оператор например через веб-консоль), транзакционность
распределенных операций, механизма обмена событиями.
Разработка собственного сервера приложений не пройдет для промышленной системы. Слишком много рисков.

К каким вендорам обратиться и сколько нужно заплатить за софт, чтобы сделать такую систему?
Есть ли некоторые стандартные подходы к решению таких задач используя ЛИСП. И есть ли стандарты, которые реализованы у
нескольких вендоров, или у каждого вендора свой API для решения таких задач? Риски сокращаются, если можно менять вендора по ходу выполнения проекта.

С уважением,
Лестор.

> Главный способ программирования в Лиспе - создавать небольшие встроенные языки, хорошо подходящие к проблеме, поэтому универсализм здесь только на уровне базового языка, а дальше уже конкретика, т.е. язык поднимается к приложению в то время как приложение пишется на этом языке. Таким образом, создаем удобный специализированный язык и решаем конечную задачу на нем, в то же время он будет оставаться тем же Лиспом.

Надо бы почитать ... Звучит страшно :). Это чтобы что-то делать я для начала должен написать целый язык Пусть и маленький. А если каждый программист начнет писать свой язык, что будет с приложением объем которого хотя бы больше 40-50 тыс строк? Его вообще отладить можно будет?

>>Пример - ООП программы на Java (объекты >>основаны на классах, которые сначала пишутся, >>потом компилируются) как правило вполне понятны >и работоспособны.
>Дык потому что особо фич для >метапрограммирования никаких нет. Шаблонов >нет, макросов как в Common Lisp нет. Вот и >набивай одно и тоже 30 раз.

Правильно спроектированное приложение не нуждается в дублировании кода. За редким исключением. Если дублирование кода и возникает, то оно обычно оправдано.

> У меня ушло больше 20 минут, так как я только начал изучать библиотеку CAPI (раньше писал свою библиотеку GUI под Corman Lisp). Опять же можно написать и компактнее и чище

Позанудствую немного. Собственно мне показалось что программы практически эквивалетны. Это Лиспу плюсик. То что у меня 90 строк кода, так это просто способ расстановки скобок у меня такой, не люблю я когда код жмется. А так я убрал лишнии скобки, расставил ++ -- и т.п. в итоге получил 40 строчек. но имхо читабельность пострадала. Кстати на первый взгляд Лисп плохо читабельный язык. Или так было отформатировано.
Было бы конечно интересно поглубже копнуть Лисп. Как у него обстоят дела с более сложными вещами. Например сложно ли создать таблицу в ячейках которой расположены картинки, комбобоксы и вообще любые элементы. Java Swing в этом плане очень мощная штука и все это позволяет сделать легко.

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

Маленько поковырялся и сократил код до 37 строк
за счет совмещения ролей окна и сцены.

Наверно можно сократить еще, да и криво выглядит в некоторых местах, но все же.

>Предлагаю пример. Бронирование авиабилетов онлайн.

ОК. В success stories Franz Inc. что-то похожее проскальзывало.

>Допустим крупная авиакомпания хочет предоставлять услугу бронирования авиабилетов
>онлайн вместе с расписаниями полетов и т.п.
>Нужно сделать как минимум:

>набор отчетов
>веб интерфейс для клиентов.
>рабочее место для продавца.
>рабочее место для оператора.
>рабочее место менеджера.
>на самом деле список неполный.

Стандартный набор.

>Реализация клиент-серверного приложения предполагается в следующем виде:
>клиентская часть - веб контейнеры - сервер приложений - БД
>Клиентская часть может быть как ГУИ так и веб интерфейсом.
>Веб контейнеры формируют отчеты, принимает и отправляют запросы клиентов.
>Сервер приложений - проводит транзакции по бронированию билетов, извлекает
>данные из БД и т.п.

Так.

>Приложение должно быть масштабируемое, т.е. нужно чтобы была возможность запускать несколько веб

>контейнеров одновременно. По хорошему нужно чтобы пользовательские сессии могли реплицироваться

>между контейнерами и серверами приложений.

Естественно.

>Т.е. что нужно (по первой прикидке):
>Веб-контейнер, в котором можно писать обработчики HTTP запросов на Лиспе.

Есть несколько вариантов: аналоги Java сервлетов, HTTP сервер на Лиспе и т.п.

>Сервер-приложений,

Тут тоже есть варианты: компоненты CORBA или своя архитектура. Наверняка у Franz Inc. есть какое-то

решение.

>Библиотека по формированию pdf, xls, doc файлов для отчетов.

Взять какую-нибудь со стороны, потому что я видел только библиотеку
для формирование PDF.

>GUI с html парсером (чтобы менеджер мог видеть html отчеты у себя в приложении)

Есть.


>Библиотека с доступом к различным БД (аналог ODBC или JDBC)

Есть прямо встроенные языки для общения с БД (например у XAnalys - Common SQL)

>Библиотека для отсылки/приема писем (как минимум smpt и pop3)

Этого то добра наверняка много.

>Технология для работы ЛИСП в среде веб-приложения: HTTP запросы, пользовательские сессии,

>авторизация.

Eсть. Это наверное лучше всего реализовано. За счет свойств языка
программирование под Веб выглядит как написание настольного приложения.

>Разработка собственного веб-сервера не пройдет для промышленной системы. Слишком много рисков.

Уже есть более менее готовые веб-серверы, как минимум: Common Lisp Hypermedia Server и Allegro

Serve. Есть примочки к существующим серверам (Lisplets и mod_lisp) и т.п.

>Библиотека для парсинга XML.

Этого добра предостаточно.

>Технология для работы ЛИСП в среде сервера-приложений: HTTP запросы, пользовательские сессии,

>авторизация,

Это точно есть

>создания управляемых сервисов (модуля, которым мог бы управлять оператор например через

>веб-консоль), транзакционность
>распределенных операций, механизма обмена событиями.

Это, честно говоря, не знаю в каком объеме есть готовое.

>Разработка собственного сервера приложений не пройдет для промышленной системы. Слишком много

>рисков.

Рисков всегда много. И что такое "промышленная система" ? Красивое словосочетание, как один сказал -
"это программное обеспечение, сильное как бык и умное как автомобиль" ;-))
Какие требования к системе неизвестно, какое ожидаемое количество транзакций в единицу
времени неизвестно и т.п.

>К каким вендорам обратиться и сколько нужно заплатить за софт, чтобы сделать такую систему?

Я бы обратился вwww.franz.com для начала, и узнал, что они могут предложить. Например недавно
видел интерфейс реализованной довольно сложной системы для "clinical drug trial management",
судя по всему система полностью перенастраивается под конкретного клиента силами
самого клиента. Один из авторов утверждал (Kenneth Tilton ), что они потратили

1M$ и сделали продукт, который первосходит аналоги за 100M$.

Другая компания ITA Software заменяет мэйнфреймы авиакомпаний своими кластерами с Лиспом.
Кстати вот малюсенькая статейка в дополнение. Я думаю, что они решили даже более сложную
задачу, чем Вы здесь описали.

>Есть ли некоторые стандартные подходы к решению таких задач используя ЛИСП.
Для части задач конечно есть устоявшиеся инструменты.

> И есть ли стандарты, которые реализованы у нескольких вендоров, или у каждого вендора свой API для

решения таких задач? Риски сокращаются, если можно менять вендора по ходу выполнения проекта.

Есть стандарты вроде CORBA и т.п. которые поддерживаются всеми вендорами, но я сомневаюсь, что у всех одинаковые инструменты для более конкретных задач.
--------------------
Я бы сказал, что вопросы у Вас - сложнее некуда. Системы такого уровня на моей памяти
не проходили этап проектирования (это конечно само по себе ничего не значит). Я имею
в виду, что жизнь бывает подтверждает - там где может стоять один или два SQL сервера и работать

простая двухзвенная архитектура (масштабы среднего предприятия), иногда не стоит усложнять.

Собственно я сейчас занимаюсь довольно скромным фотограмметрическим приложением с элементами автоматической добычи знаний из эксперта, которому и не снились такие бюджеты. А Вы действительно создаете промышленные системы бронирования авиабилетов или просто интересуетесь ?

С уважением
Lisper

>Позанудствую немного. Собственно мне >показалось что программы практически >эквивалетны. Это Лиспу плюсик. То что у меня 90 >строк кода, так это просто способ расстановки >скобок у меня такой, не люблю я когда код жмется. >А так я убрал лишнии скобки, расставил ++ -- и т.п. >в итоге получил 40 строчек. но имхо читабельность >пострадала. Кстати на первый взгляд Лисп плохо >читабельный язык. Или так было >отформатировано.

Я бы не списывал со счетов, что Вы видите его в первый раз (сами сказали "на первый взгляд" ;-). Лучше компактно на 5 листов, чем читабельно, но на 50 листов.

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

Потом я не применял здесь никаких средств, за счет которых сокращается объем программ. Ведь вряд ли это можно применить в таком HelloWorld из 36 строк. То есть правило такое, чем длиннее программа, тем она короче ;-) за счет сжатия повторяющихся фрагментов базового языка в новые языковые инструменты.

>Было бы конечно интересно поглубже копнуть Лисп.
Я Вам завидую, первый раз, когда я начал изучать Лисп, это был как Диснейлэнд. И сейчас в общем-то тоже немалое удовольствие от программирования ;-)

> Как у него обстоят дела с более сложными вещами. Например сложно ли создать таблицу в ячейках которой расположены картинки, комбобоксы и вообще любые элементы. Java Swing в этом плане очень мощная штука и все это позволяет сделать легко.

Есть пара замечательных гридов для CAPI. И графики в ячейки пихают, подправлябельные мышкой, и вообще творят, что хотят ;-)
У Franz. Inc в Allegro CL есть не менее мощные гриды (правда их продукт дороговат 4.5К$ только за Professional версию).

С уважением
Lisper

>Правильно спроектированное приложение не >нуждается в дублировании кода. За редким >исключением. Если дублирование кода и >возникает, то оно обычно оправдано

1)Правильно спроектировать приложение определенного типа с первого раза довольно трудно. Что если ошибся, перекраивать всю структуру ?

2)Я имел в виду не только дублирование кода, а дублирование применения одних и тех же языковых средств, например for(i=0;i

> 1)Правильно спроектировать приложение определенного типа с первого раза довольно трудно. Что если ошибся, перекраивать всю структуру ?

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

> 2)Я имел в виду не только дублирование кода, а дублирование применения одних и тех же языковых средств, например for(i=0;i 3) В Java уже сделали шаблоны? Вроде бы обещали вот вот. Хоть что-то будет для метапрограммирования. А еще были какие-то средства для этого от третьих лиц.

Сделаны, в 1.5. Конечно, это не C++, но уже что-то.

Я целью себе не ставил минимальный объем кода. В основном на читабельность упирал. И на свой привычный стиль.
Однако за счет некоторой потери читабельности (что, однако, даже немного спорно), можно как сократить код, так и повысить производительность.
В данном случае использование inline-функций более чем оправдано, т.к. в них всего пара операторов.
Итого 42 строки.

А к чему что-то ужимать?
Тогда надо было бы вообще вытянуть в одну строку и сосчитать байты
Кстати, для справки: Ваш файл 1483 байта, мои три в сумме 1309.
И это более объективный показатель, нежели строки, согласитесь?

Хорошо, у меня теперь 29 строк и 1253 символа.
Любой лиспер прочитает этот текст с листа, тем более, что он теперь влезет на пол-листа и все в одном файле.

>Дык, это пережиток C. Для таких целей уже давно итераторы придуманы.

Итераторы имеют довольно громоздкий синтаксис. Лучше уж for e in vector { do smthg with e }

Ну что, будем продолжать?
38 строк и 1217 символов :).
Нечитабельным я б тоже не назвал :). Причем код будет понятен не только С++-программерам :).

ЗЫ: А о чем спор-то?

>À ê ÷åìó ÷òî-òî óæèìàòü?
>Òîãäà íàäî áûëî áû âîîáùå âûòÿíóòü â îäíó ñòðîêó è ñîñ÷èòàòü áàéòû

Если я вытяну все в одну строку, то получу 1104 байта и файл будет по-прежнему компилироваться,
а вы этим похвастаться можете ? ;-))

Кстати дополнение большей части идентификаторов / они довольно длинные ;-(( / и балансировку скобок для меня делает редактор, так что число нажатий кнопок на самом деле потребовалось меньше 1000.

Lisper

А смысл-то, смысл?
У меня в одну строку не вытягивается, т.к. директивы препроцессора должны занимать отдельную строку.
Но вытянув остальной код в одну строку получаем два файла общим объемом 1048 байт :). Все по-прежнему компилируется и работает.

Кстати, я пользуюсь полезной программкой VisualAssist, которая сама подставляет операторы, переменные, функции-члены, директивы препроцессора и даже некоторые стандартные конструкции типа switch (){...} после введения нескольких первых символов :).
Скобки () и {} она тоже закрывает сама.
Будем нажатия считать?

ЗЫ: У Вас что-то с кодировкой....

> Красивое словосочетание, как один сказал -
"это программное обеспечение, сильное как бык и умное как автомобиль" ;-))


> Какие требования к системе неизвестно, какое ожидаемое количество транзакций в единицу
времени неизвестно и т.п.
Что-то вроде масштабирумое приложение, с высоким уровнем надежности, позволяющее относительно легко себя модифицировать.

> Я имею в виду, что жизнь бывает подтверждает - там где может стоять один или два SQL сервера и работать.
Я тут с Вами как на семинаре по Лиспу! Просто узнал много нового. Интересно же узнать каковы возможности Лиспа. Спасибо!

> А Вы действительно создаете промышленные системы бронирования авиабилетов или просто интересуетесь ?
Просто интересуюсь

С Уважением,
Лестор.

Ну не знаю меня так не ломает написать
for (Iterator it=list.iterator(); it.hasNext(); ) {
...
}
В Java 1.5 вроде можно немного более элегантно написать. Но я 1.5 еще не гонял особо.
Гораздо больше меня привлекает наличие строгой типизации (меньше головняков с поддержкой), наличие стандартных интерфейсов и большого количества реализаций от разных вендоров, готовая технология по разработке приложений определенного типа. Так что в случае с серверным приложением я бы выбрал на данный момент Java (J2EE).

дЮ, БШЬКН ЦКСОН. гЮДЮВЙЮ ЙПНЬЕВМЮЪ Х ВЕЦН РСР ЛЕПЪРЭ. рЕЛ АНКЕЕ ЛМЕ QT РНФЕ МПЮБХРЯЪ.

Lisper

OK. I give up to fight with encodings and consider that is something wrong with forum's software. Better I'd write all in english.

Of course it was very silly to compare such helloworlds. And I like QT too. Anyway we're both finished with very short versions ;-)

With respect,
Lisper

[ГЙФБФБ]оХ ОЕ ЪОБА НЕОС ФБЛ ОЕ МПНБЕФ ОБРЙУБФШ
for (Iterator it=list.iterator(); it.hasNext(); ) {
...
}
ч Java 1.5 ЧТПДЕ НПЦОП ОЕНОПЗП ВПМЕЕ ЬМЕЗБОФОП ОБРЙУБФШ. оП С 1.5 ЕЭЕ ОЕ ЗПОСМ ПУПВП.
зПТБЪДП ВПМШЫЕ НЕОС РТЙЧМЕЛБЕФ ОБМЙЮЙЕ УФТПЗПК ФЙРЙЪБГЙЙ (НЕОШЫЕ ЗПМПЧОСЛПЧ У РПДДЕТЦЛПК), ОБМЙЮЙЕ УФБОДБТФОЩИ ЙОФЕТЖЕКУПЧ Й ВПМШЫПЗП ЛПМЙЮЕУФЧБ ТЕБМЙЪБГЙК ПФ ТБЪОЩИ ЧЕОДПТПЧ, ЗПФПЧБС ФЕИОПМПЗЙС РП ТБЪТБВПФЛЕ РТЙМПЦЕОЙК ПРТЕДЕМЕООПЗП ФЙРБ. фБЛ ЮФП Ч УМХЮБЕ У УЕТЧЕТОЩН РТЙМПЦЕОЙЕН С ВЩ ЧЩВТБМ ОБ ДБООЩК НПНЕОФ Java (J2EE). [/ГЙФБФБ]

Though Lisp is oldest of languages and become very mature and it is rich of features. It lacks some things that Java have because of massive money infusion. Such popularity has it's benefits and even C++ doesn't look so attractive in some fields that are occupied by Java today. So I was wrong when said that Lisp has benefits in any case, of course it doesn't mean anything about language itself (see Lisp Machines).

Lisper

[ГЙФБФБ]с ФХФ У чБНЙ ЛБЛ ОБ УЕНЙОБТЕ РП мЙУРХ! рТПУФП ХЪОБМ НОПЗП ОПЧПЗП. йОФЕТЕУОП ЦЕ ХЪОБФШ ЛБЛПЧЩ ЧПЪНПЦОПУФЙ мЙУРБ. уРБУЙВП! [/ГЙФБФБ]

Thank YOU for attention. I just want to say that Common Lisp is worth spending one's time on and it can simplify some complex tasks enormously.

Regards
Lisper

>>>
OK. I give up to fight with encodings and consider that is something wrong with forum's software. Better I'd write all in english.

А в чем проблема-то? Линукс?(см. аттач)

>>> Of course it was very silly to compare such helloworlds. And I like QT too. Anyway we're both finished with very short versions ;-)

Короткие --- не значит "лучшие".
Однако надо будет присмотреться к Лиспу. Странно, что я только от Вас впервые узнал о нем :).

>>> With respect

Симметрично :).

Нет не Линукс. Я пробовал писать из XP (IE 6.0 и Opera 7.02) потом перешел под Линукс и писал из под Konquror, в Линуксе замечательная руссификация и все другие форумы не косят кодировку ни там, ни под виндой. А что остается ? Провайдер что-ли при пересылке перекодирует постинги, тото я вижу там прозрачный прокси где-то виднеется ? ;-)

Я удивляюсь, почему нас до сих пор не порезали....
Темой тут давно уже не пахнет :).
А я вот Konqueror так и не сумел заставить по-русски говорить. Opera и Mozilla приручились, а вот Konqueror так и не покорился....

Говорит как миленький, причем прямо из коробки...

Не, сам-то он говорит. Вот только когда я с его помощью пытался говорить на форуме --- тут и случился косячок-с....
Дистр Мандрейк 10.

Мой дистр Mandrake 10.0 Official - все работает из коробки, да и в RH 7.2 ранее не было проблем. Может быть у Вас Mandrake 10.0 Community ?

Тот же самый, Official, на 4-х дисках. Плюс PowerPack на 2-х дисках.
Локаль установлена из коробки, русские страницы читаю без проблем, а при написании постов получались совершенно нечитабельные кракозябры....

>Если промах такой большой, что надо перекраивать всю структуру - то да, именно так. >Вообще, на западе программы давно уже пишут, как строят дома - сначала детальный проект, а потом уже реализация. Иначе большие системы никак не сделать.

А как же получился Linux ? Или он большим не считается ? Эволюционный стиль разработки часто срабатывает лучше, чем если пытаться угадать все заранее. Конечно предварительные фазы сбора требований и проектирования необходимы, но они не являются гарантией, что ПО будет построено правильно и точно в срок. Многие утверждают, что успешно выпустили продукт в срок, благодаря чем-то вроде RUP, но есть и масса обратных свидетельств. Похоже метафора строительства дома подходит только для определенных хорошо проработанных предметных областей, как только доля неизвестности повышается, предварительное детальное проектирование становится неэффективным.

Regards,
Lisper

> предварительные фазы сбора требований и проектирования необходимы, но они не являются гарантией

Да, вот с этим согласен на 100%. Не забывайте только про "необходимы". Большинство успешных проектов, которые я видел, своему успеху во многом обязаны правильному проектированию. Правильному - в первую очередь "по уму" а не "по RUP-у"

Linux, как и многие OpenSource проекты - вещь отдельная, новаторская. 90% коммерческих проектов с технической точки зрения вполне предсказуемы и планируемы.