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

>>Пример - ООП программы на 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% коммерческих проектов с технической точки зрения вполне предсказуемы и планируемы.