Common Lisp и CORBA

> Корба не нужна.

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

Нет, я конечно всё понимаю, в Lisp-парадигме «гетерогенных систем» просто не существует: всё обязано быть написано на Лиспе. Но реальность не такова. Реальность такова, что есть data processing написанный третьей стороной на C++. Он устраивает абсолютно всем: функциональностью, производительностью, временем отклика, поддержкой и своевременным добавлением новых фич по требованию. Нужно только одно: интегрироваться с этой системой. И Java справляется с этим на 100%, благодаря встроенной поддержке CORBA 3.0. А лисп не справляется. При этом вы с Архимагом (извиняюсь, два хрена с горы) пытаетесь с умным видом доказать сотне авторов и тысячам пользователей системы, что CORBA не нужна.

Может, пора вылезти из своего уютного идеалистического мирка, в реальный мир? Много нового узнаете. Например, то, что существуют и другие языки программирования, кроме лиспа, и что они занимают своё (вполне достойное) место в этом мире. И с этим надо считаться.

Поправлю: не нужна конкретно вам.

Абсолютно правильно: я не то, что сам корбу толком не юзал, я даже не знаю людей, которым с корбой приходилось где-то сталкиваться. Соответственно, я в моём бескорбовом мирке могу лабать свежий лисповый код, не заморчиваясь с интеграцией с легаси-системами на корбе.

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

> Может, пора вылезти из своего уютного идеалистического мирка, в реальный мир? Много нового узнаете. Например, то, что существуют и другие языки программирования, кроме лиспа

Чото я не понял... ты на CL пишешь или «кроме»?

> Абсолютно правильно: я не то, что сам корбу толком не юзал, я даже не знаю людей

И из этого делаете общий вывод о ненужности CORBA, в том числе в Common Lisp? Браво...

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

А ничего, что «легаси-система» датируется всего-навсего 2007 годом? И те, кто выбрал CORBA в качестве интерфейса для внешнего мира, отдавали себе в этом отчёт, уж поверьте мне. Просто они делали расчёт на мейнстрим...

Искренне жаль.

Искренне жалеть пока надо только меня, потому что у наших Java и С++ программистов, не берущих звёзд с неба, всё в порядке :)

> Чото я не понял... ты на CL пишешь или «кроме»?

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

И из этого делаете общий вывод о ненужности CORBA, в том числе в Common Lisp? Браво...

Абсолютно верно! Если корбой никто не пользуется, то она никому не нужна.

Идея использования remote objects в гетерогенных средах, в целом, провалилась из-за своей сложности. Для мессейджинга есть решения проще. Для сериализации/десериализации данных есть решения проще. Для RPC есть решения проще. Места корбе под солнцем в современном мире нет.

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

У тебя с такими требованиями любой язык будет плохой, если корбы 3.0 для него не будет.

Но, как видите, пока не очень успешно...

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

Я под виндой использую CL вместе с .NET и COM-компонентами, не говоря уже про чисто сишные библиотеки, в т.ч. собственно интерфейсы винды, типа DirectX. Так что, могу на собственном примере сказать, с интеграцией CL с другими системами проблем, в принципе, нет.

Но вот зачем нужна именно CORBA и именно 3я(вот это особенно непонятно), я понять не могу, если честно.

Да, возможно, библиотеки на эту тему нет. Но, нахрена именно оно нужно?

lovesan

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

> Идея использования remote objects в гетерогенных средах, в целом, провалилась из-за своей сложности. Для мессейджинга есть решения проще. Для сериализации/десериализации данных есть решения проще. Для RPC есть решения проще. Места корбе под солнцем в современном мире нет.

а для распределенных транзакций есть решения проще?

libpaxos

Два вопроса:

1. Насколько просто взять её и начать разрабатывать ПО для продакшена? Или надо будет на её основе реализовывать передачу ID транзакции, реализовывать 2pc протокол, и вобще заниматься несвязанными с проектом задачами?

2. Насколько она стабильная? Я увидел две версии в репозитории : rev-116 и rev-99. Это как-то даже не смешно

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

1) Относительно просто на основе построить, что тебе надо 2) Стабильней большинства библиотек CL

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

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

Относительно просто на основе построить, что тебе надо

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

Строили.

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

> Абсолютно верно! Если корбой никто не пользуется, то она никому не нужна.

Окей, я передам в комитет OMG, разработчикам Java в Oracle, в IBM, в Artemis, в Европейский Институт Биоинформатики, в Лос-Аламосскую Национальную Лабораторию, а также всем сотрудникам и разработчиками нашей организации, что они - никто :)))

Идея использования remote objects в гетерогенных средах, в целом, провалилась из-за своей сложности. Для мессейджинга есть решения проще. Для сериализации/десериализации данных есть решения проще. Для RPC есть решения проще.

Например?

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

Вы невнимательно читаете. Было написано «в той же среде». В среде, в которой Java и C++ чувствуют себя абсолютно комфортно.

> Да ты даже и не пробовал.

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

Будь у тебя хоть какая-то мотивация, вместо зелени

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

выставил корбушный интерфейс через рест.

Вы всерьёз считаете REST полноценной заменой remote objects? Для CosNaming и CosTransactions тоже предлагаете «проксю на жабке» делать?

> Но вот зачем нужна именно CORBA и именно 3я(вот это особенно непонятно), я понять не могу, если честно.

Ну сто раз же писал уже: POA, Object-by-value, Realtime, Asynchronous messaging

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

«Самый простой»? Вы себе представляете объём функциональности CORBA-сервисов, которые надо будет обернуть? И какой интерфейс тут подразумевается под «более вменяемым»?

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

Причём тут реализации? Речь идёт о стандарте.

Притом что корба 3.0 реализована только в нескольких реализациях.

> Притом что корба 3.0 реализована только в нескольких реализациях.

И что? CORBA 3.0 есть для Java и C++, это покрывает 99% потребностей enterprise

Значит cl для инткрпрайза не подходит. Теперь иди делать уроки.

Realtime

Так всё в real time работает же :) Если подразумевалось low latency, то корба такая же low latency, как луна сделана из сыра.

Asynchronous messaging

В каждом первом мессейджинге асинхронность есть.

POA, Object-by-value

Какую полезную работу выполняет POA? Что оно делает кроме того, что обеспечивает функциональность самой корбы?

А как же распределенные транзакции?

А как же распределенные транзакции?

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

Эм. А ты о каких транзакциях?

Эм. А ты о каких транзакциях?

О распределённых ;) А ты о каких?

> Значит cl для инткрпрайза не подходит. Теперь иди делать уроки.

Факт того, что CL непригоден для enterprise, разрушил ваш мир? И это вызывает вашу злобу (даже опечатываться начали) и подспудное желание оскорбить оппонента, назвав его школьником?

> Так всё в real time работает же :)

Что - всё?

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

Вы вообще когда имели последний раз дело с CORBA? Ах, да, вообще не имели... как это я забыл!

В каждом первом мессейджинге асинхронность есть.

Какую полезную работу выполняет POA?

Я что-то не понял. Я говорю: есть сторонняя система, которая использует CORBA 3.0, потому что (список фич). Надо с ней интегрироваться. Спрашиваю: как? А вы вместо ответа начинаете ставить под сомнение целесообразность использования CORBA 3.0 сторонней системой. Это что, у лисперов всегда так принято?

> Да это в любом энтерпрайз-мессейджинге с брокером есть.

Примеры приведёте?

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

Не только.

> CL непригоден для enterprise

Открою большой секрет: такой предметной области, как «enterprise» не существует. Под «enterprise» обычно подразумевают такой подход к разработке, когда во главу угла ставится необходимость освоения выделенного бюджета и обоснование необходимости его увеличения. Связать несколько решений от ведущих вендоров с помощью CORBA - безусловно отличное «enterprise»-решение. Так вот, если вам интересно применить CL для «enterprise», то посмотрите http://www.franz.com/ - там вам помогут освоить любой бюджет.

> Открою большой секрет: такой предметной области, как «enterprise» не существует. Под «enterprise» обычно подразумевают...

Вообще-то, под «enterprise» подразумевают системы, удовлетворяющие требованиям большого бизнеса по производительности, масштабируемости, безопасности, расширяемости, управляемости, надёжности, доступности.

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

Или вам просто не известно истинное значение термина «Enterprise» (чисто по невежеству, или потому что вас туда не пускают). А неизвестного человек боится, таков уж инстинкт. Вот вы и выдумали вместо «Enterprise» какое-то чучело, и занимаетесь его избиением, чтобы компенсировать внутренние страхи. Может, всё-таки пора перестать бояться? Ничего страшного в «Enterprise» нет.

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

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

> Не думаю, что юноша.

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

> http://www.franz.com/ - там вам помогут освоить любой бюджет

lol

> Факт того, что CL непригоден для enterprise, разрушил ваш мир? И это вызывает вашу злобу (даже опечатываться начали) и подспудное желание оскорбить оппонента, назвав его школьником?

Да, ты я смотрю, никак не угомонишься. Не нужен тебе CL. Ты прав. CL — говно для твох «задач». Иди-ка назад в свой уютныи ынтырпрайз и энжой.

> CL — говно для твох «задач»

уютныи ынтырпрайз

Беря в кавычки слово «задачи» и коверкая термин «enterprise», вы как бы намекаете, что задачи эти неполноценные и недостойные Common Lisp? Не поясните ли, почему вы так считаете?

Я не он, но «enterprise» настолько оброс маректоидной лапшой, что человек всерьез рассуждающий о его задачах и даже что ему (это пять, однозначно)

известно истинное значение термина «Enterprise»

как минимум забавен.

P.S. Дух К.О. говорил с вами через меня.

Если для вас производительность, масштабируемость, безопасность, расширяемость, управляемость, поддерживаемость, надёжность, доступность - «маркетоидная лапша», то нам с вами вряд ли о чём будет побеседовать.

Продолжайте жить в своём уютном мирке с анафорическими макросами и аппликативными функторами, с выдуманными врагами вроде злых маркетоидов.

> Если для вас производительность, масштабируемость, безопасность, расширяемость, управляемость, поддерживаемость, надёжность, доступность

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

Пол Грэм тоже, видимо, посчитал «масштабируемость» маркетоидным баззвордом, ага. Где теперь его ViaWeb?

> Когда устроишься на работу - узнаешь, что это таки не более чем набор маркетоидных баззвордов, да.

Вообще-то, всё вышеперечисленное - ни что иное как «нефункциональные требования» («non-functional requirements»), о которых известно каждому архитектору. Вышесказанным вы только лишь показали, насколько вы далеки от промышленной разработки ПО. Я не понимаю, зачем так позориться-то?

Или, может скажете, чего «маркетоидного» в требовании обеспечить одновременную работу 10000 пользователей (capacity), обеспечить скорость обработки запросов 1000 запросов/сек (производительность), обеспечить работу системы в течение 99.99% времени (доступность)?

> Пол Грэм тоже, видимо, посчитал «масштабируемость» маркетоидным баззвордом, ага. Где теперь его ViaWeb?

Его ВиаВеб не один год прекрасно работал и справлялся с нагрузками, что говорит об отличной масштабируемости. Безо всяких баззвордов, ага.

> Вышесказанным вы только лишь показали, насколько вы далеки от промышленной разработки ПО.

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

> По-этому спорить смысла не вижу.

Перевожу: спорол чушь, опозорился и спешит слиться :) На поставленный вопрос так и не ответили.

Я так подозреваю, что своими «практическими познаниями в области промышленной разработке ПО» вы тоже не собираетесь делиться. Жалко. Интересно было бы узнать, на каком основании вы считаете «маркетоидными баззвордами» технические требования вроде производительности, ёмкости и времени отклика. Не удивлюсь, если требования по мощности, производительности и наработке на отказ (для какого-нибудь промышленного оборудования) вы тоже относите к «маркетоидным баззвордам». С удовольствием передам это знакомому технологу на заводе, пускай посмеётся :)

> Перевожу

Хреновый из тебя переводчик. Как, впрочем, и программист. Ничего, поработаешь немного над реальными, не вымышленными проектами - перестанешь нести чушь.

Скажите, «производительность» (в литрах/сек) для какого-нибудь промышленного насоса - это тоже «маркетоидный баззворд»?

Казалось бы причем тут Enterprise и ПО

> Казалось бы причем тут Enterprise и ПО

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

А enterprise как слово перпендикулярен кокретным требованям конкретных предприятий. Кокретные инженеры будут смотреть на конкретные характеристики кокретных насосов. И идея продавать enterprise-насосы может быть и удачной с точки зрения маркетингового позиционирования, но с точки зрения инженера в лучем случае странно в худшем разводкой. На ПО аналогично можно навесить не только enterprise но и profesional, premium, но вот как это повлияет на конкретные измеримые показатели остается загадкой.

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

А где я говорил про enterprise? Я всего-лишь возражаю анонимусу, который окрестил «производительность, масштабируемость, безопасность, расширяемость, управляемость, поддерживаемость, надёжность, доступность» маркетоидными баззвордами.

в контексте «энтерпрайза» - это маркетоидные баззворды, да.