Здравствуйте, Lazy Cjow Rhrr, Вы писали:
E>>Ты будешь сильно удивлен. E>>Заодно, если ты так уж не веришь в надежность C++ програм, то можешь терять аппетит, покой и сон. И заодно место на кладбище заказывать. Поскольку, если этот код будет глючить, то всем нам кирдык.
LCR>На мой взгляд с существованием супернадёжного (или просто надёжного) софта на C++ никто не спорит. Просто этот софт очень дорогой (или просто дорогой).
Мне кажется супернадежный софт будет очень дорогим не только на C++. И вполне возможна что его цена такова что вполне позволяет написать специализированный язык только для одной программы, как например тут Еще про ОС
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>На мой взгляд с существованием супернадёжного (или просто надёжного) софта на C++ никто не спорит.
На мой взгляд, это как раз не так. Некоторые не только спорят, но прямо таки вопят о том, что это невозможно.
LCR>Просто этот софт очень дорогой (или просто дорогой).
Надежный софт не может быть дешевым просто по определению.
Имхо, язык программирования в таких задачах добавляет в общую стоимость совсем небольшой процент. Причем этот процент может быть компенсирован наличием предшествующего опыта и имеющихся разработок.
Чуть в офтопик. Когда-то давно, году в 93-м попалась мне статья в каком-то компьютерном журнале. В ней рассказывалось о конференции, посвященной созданию надежного программного обеспечения. Во время одного из выступлений докладчик предложил слушателями прочувствовать на себе, что значит разработка надежного софта для опасных производств. Нужно было набросать реализацию контроля температуры парового котла с реакцией на выходы температуры за пределы нормы. Оказалось, что из всех примерно пятнадцати предложенных решений только одно или два были корректны. Подавляющее большинство решений имели серьезные просчеты. В частности, автор статьи ошибочно предположил, что температура котла не может быть отрицательной. Вывод состоял в том, что для создания надежного ПО критически важно создать адекватную модель предметной области. Что и составляет основную сложность. А уже перенос этой модели на конкретную реализацию во многом является делом техники. Кроме того еще более важную роль, чем язык и технология программирования, будет являться система верификации, тестирования и приемки в эксплуатацию.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
E>Надежный софт не может быть дешевым просто по определению.
Тут хорошо бы услышать определение "надёжный".
E>Имхо, язык программирования в таких задачах добавляет в общую стоимость совсем небольшой процент.
Это заблуждение. Язык программирования, точнее платформа, играет самую непосредственную роль в соотношении качество/цена/сложность. Например, решения на опасных языках вполне может быть надёжным. Но, либо совсем простеньким, либо запредельно дорогим.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
IT>Wikipedia does not have an article with this exact name
Закрывающая круглая скобка не попадает в URL (тем не менее он правильный).
Попробуй так или так. Только похоже, что именно сейчас Wika в дауне.
IT>По крайней мере вы с викой точно не одного мнения
Откуда ты знаешь, ты же не читал?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[44]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, alexeiz, Вы писали:
VD>>Сделаем вид, что я не заметил перехода на личности и просто проигнорируем эту детскую демогогию.
A>Я не виноват. Эту детскую демагогию начал ты своими бесмысленными заявлениями.
Если у тебя проблемы с вменяемостью, то у нас есть средство поставить тебя на место.
Достаточно мне или другому модератору заметить твои переходны на личность. Так что предлагаю не доводя до помывочных мероприятий вернуться в конструктивное русло.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
E>Может быть это от незнания того, что такое Application Server?
Точно! Ты угадал!
E>Так вот SObjectizer сервером приложений не является: E>
E>1.5.3 SObjectizer не является сервером приложений
E>SObjectizer не является сервером приложений. Он не является готовым продуктом
E>промежуточного слоя (middle tier). SObjectizer — это инструмент для разработки
E>приложений, в том числе и распределенных. Но SObjectizer не имеет готовых средств
E>для обеспечения развертывания (deployment) приложений и не обеспечивает, например,
E>таких сервисов промежуточного слоя, как безопасность (security), маршрутизация
E>запросов и балансировка нагрузки (load balancing), доступ к корпоративным данным,
E>долговременное хранение состояний объектов (stateful objects), восстанавливаемость
E>(fail-over) и пр.
Наба, странные у тебя понятия о том, что такое сервер приложений. Ни одна из перечисленных возможностей не является обязательным для него. Это общий класс софта, а не спецификация.
Вобщем, можешь дальше заниматься поисками слов для докапывания и других весомый аргументов для того, чтобы закрывать глаза на тот факт, что выбранные тобой инструменты явно не для твоего бютжета.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexeiz, Вы писали:
VD>>>Сделаем вид, что я не заметил перехода на личности и просто проигнорируем эту детскую демогогию.
A>>Я не виноват. Эту детскую демагогию начал ты своими бесмысленными заявлениями.
VD>Если у тебя проблемы с вменяемостью, то у нас есть средство поставить тебя на место. VD>Достаточно мне или другому модератору заметить твои переходны на личность. Так что предлагаю не доводя до помывочных мероприятий вернуться в конструктивное русло.
что и тебе советую вместо того, чтобы прятаться за нравоучениями.
Re[42]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
E>>Может быть это от незнания того, что такое Application Server?
VD>Точно! Ты угадал!
Это было не сложно.
E>>Так вот SObjectizer сервером приложений не является: E>>
E>>1.5.3 SObjectizer не является сервером приложений
E>>SObjectizer не является сервером приложений. Он не является готовым продуктом
E>>промежуточного слоя (middle tier). SObjectizer — это инструмент для разработки
E>>приложений, в том числе и распределенных. Но SObjectizer не имеет готовых средств
E>>для обеспечения развертывания (deployment) приложений и не обеспечивает, например,
E>>таких сервисов промежуточного слоя, как безопасность (security), маршрутизация
E>>запросов и балансировка нагрузки (load balancing), доступ к корпоративным данным,
E>>долговременное хранение состояний объектов (stateful objects), восстанавливаемость
E>>(fail-over) и пр.
E>>(Е.Охотников, SObjectizer-4 Book) E>>
VD>Наба, странные у тебя понятия о том, что такое сервер приложений. Ни одна из перечисленных возможностей не является обязательным для него. Это общий класс софта, а не спецификация.
Ни одна не является обязательной, но называть сервером приложений инструмент, который не предоставляет вообще ни одной из перечисленных возможностей можешь, вероятно, только ты. И, кстати, лично я не представляю себе сервер приложений, который не обеспечивает deployment-а.
Если погуглить, то получается интересная подборка определений: 1.
Application Server: A software platform that provides the services and infrastructure required to develop and deploy middle-tier applications. Middle-tier applications perform the business logic necessary to provide web clients with access to enterprise information systems. In a multi-tier architecture, an application server sits beside a web server or between a web server and enterprise information systems. Application servers provide the middleware for enterprise systems.
Application server. Also called an appserver. A program that handles all application operations between users and an organization's backend business applications or databases. Application servers are typically used for complex transaction-based applications. To support high-end needs, an application server has to have built-in redundancy, monitors for high-availability, high-performance distributed application services and support for complex database access.
An application server is a component-based product that resides in the middle-tier of a server centric architecture. It provides middleware services for security and state maintenance, along with data access and persistence.
* Naming and Directory — allows programs to locate services and components through the Java Naming and Directory InterfaceTM (JNDI) API
* Authentication — enforces security by requiring users to log in
* HTTP — enables Web browsers to access servlets and JavaServer PagesTM (JSP) files
* EJB — allows clients to invoke methods on enterprise beans
EJB Container
Enterprise bean instances run within an EJB container. The container is a runtime environment that controls the enterprise beans and provides them with important system-level services. Since you don't have to develop these services yourself, you are free to concentrate on the business methods in the enterprise beans. The container provides the following services to enterprise beans:
Не мог бы ты показать, по каким признакам SObjectizer попадает хотя бы под одно из этих определений?
VD>Вобщем, можешь дальше заниматься поисками слов для докапывания и других весомый аргументов для того, чтобы закрывать глаза на тот факт, что выбранные тобой инструменты явно не для твоего бютжета.
Можно ли раскрыть мысль об "инструментах не для моего бюджета"? А то я смысла последней фразы совсем не уловил.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[41]: Tcl как обоснование ненужности поддержки компонентно
E>Ни одна не является обязательной, но называть сервером приложений инструмент, который не предоставляет вообще ни одной из перечисленных возможностей можешь, вероятно, только ты.
Да, нет. Класс, если не ошибаюсь более точно называется "MOM Message Oriented Middleware".
Ну, да спорить о термирах мне не интересно. Готов называть его хоть горшом при условии, что мы сойдеся на том, что это серверный софт разрабатываемый в условиях очень ограниченных ресурсов.
E> И, кстати, лично я не представляю себе сервер приложений, который не обеспечивает deployment-а.
Хм. Таких хватает. MSMQ, например, не обеспечивает. Ему и не надо. Его задача сообщения пересылать.
E>Можно ли раскрыть мысль об "инструментах не для моего бюджета"? А то я смысла последней фразы совсем не уловил.
Думаю ты его и сам понимаешь. Серверный софт на С++ требует огромных вложений на тестирование и разработку (ведь какое количество обвязки прийдется создать). Я уже не говорю о вложениях в разработку интерфейса к массовым средствам разработки прикладных решений. Ведь если твое ришение не является приклдным, то решения создаваемые с его использованием являются таковыми. И как я понял из твоей статьи, ты предпологашь создавать их тоже на С++. А это себе уже мало кто может позволить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
VD>Да, нет. Класс, если не ошибаюсь более точно называется "MOM Message Oriented Middleware".
Не более точно, а по другому. MOM и Application Server-а -- это два разных типа продукта. Хотя в Application Server может входить и поддержка MOM. Например, в виде реализации спецификации JMS в EJB контейнерах.
MOM -- это действительно ниша, с которой SObjectizer довольно сильно пересекается. Пока что больше всего общих черт у SObjectizer обнаружилось с TIB/Rendezvous, краткое сравнение можно найти здесь
. Более полное и подробное сравнение сделаю когда дочитаю документацию по Rendezvous.
VD>Ну, да спорить о термирах мне не интересно. Готов называть его хоть горшом при условии, что мы сойдеся на том, что это серверный софт разрабатываемый в условиях очень ограниченных ресурсов.
Сам по себе SObjectizer не является серверным софтом. Он может использоваться для создания серверного софта. А может для создания вычислительных распределенных приложений (вместо MPI или VPM). А может и для создания standalone приложений, например, софта для работы с каким-нибудь оборудованием вроде SmartCard-ридеров.
E>> И, кстати, лично я не представляю себе сервер приложений, который не обеспечивает deployment-а.
VD>Хм. Таких хватает. MSMQ, например, не обеспечивает. Ему и не надо. Его задача сообщения пересылать.
MSMQ это не сервер приложений.
E>>Можно ли раскрыть мысль об "инструментах не для моего бюджета"? А то я смысла последней фразы совсем не уловил.
VD>Думаю ты его и сам понимаешь. Серверный софт на С++ требует огромных вложений на тестирование и разработку (ведь какое количество обвязки прийдется создать). Я уже не говорю о вложениях в разработку интерфейса к массовым средствам разработки прикладных решений. Ведь если твое ришение не является приклдным, то решения создаваемые с его использованием являются таковыми. И как я понял из твоей статьи, ты предпологашь создавать их тоже на С++. А это себе уже мало кто может позволить.
Это все так (за исключением слишком больших затрат на тестирование, тестирование и Java приложений требует аналогичных вложений). Поэтому SObjectizer и не применяется для разработки ПО, для которого предназначены те же самые J2EE технологии. Однако не только Enterprise нуждается в server side решениях.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: [Benchmark] Еще раз про Аккерман на разных языках
Ежели кому интересно, сегодня проверил еще на альтернативном компиляторе для D
GDC (front-end от Digital Mars, back-end от GCC)
gdmd.pl akk.d -O -release -inline -ofakk-gdc.exe
Вот результаты с апдейтом (усредненные по 10 запускам и отсортированные по времени):
1) MS C++ : 830.5 ms
2) Nemerle : 844.4 ms 3) GDC : 913.4 ms
4) GCC : 990.4 ms
5) MS C# : 1567.4 ms
6) DMD : 2247.3 ms
7) Nemerle-decl : 3134.6 ms
Так что проблема в плохо оптимизирующем back-end от Digital Mars.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[42]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, IT, Вы писали:
IT>Кстати, а вдруг твой метод вернёт true, а в переменной окажется null Вот веселуха начнётся.
Кстати, только вчера нарвался на аналогичные чудеса.
Вызываем IXMLDocument::selectSingleNode().
Проверяем его результат на SUCCEEDED.
Пытаемся работать с out-параметром.
Упс! Оказывается, эти орлы возвращают S_FALSE, который считается успешным результатом. Ну и получаем классической ASSERT p!=0.
Коды ошибок — отстой.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[58]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
E>Было бы любопытно услышать, что по этому поводу думают сторонники properties.
Все очень просто. Дело в том, что с точки зрения теории кристалла, у объекта есть состояние (скрытое) и поведение (публичное). Инкапсуляция требует, чтобы о состоянии объекта (например, значениях его приватных полей) можно было узнать только через его поведение (методы).
Ну вот рассмотрим объект Вася. У него есть метод Подшутить. В полном соответствии с ООП его поведение в ответ на этот метод (некоторые предпочитают трактовать метод как посылку Васе сообщения "шутка") зависит от его состояния. Предположим, что Вася может находиться только в двух состояниях: "веселый" и "злой". Внешнему наблюдателю не дано узнать о состоянии Васи напрямую, зато он может узнать о нем опосредованно: "веселый" Вася в ответ засмеется, а "злой" обидится и даст шутнику в репу.
Это все здорово и правильно, и нас уже тридцать лет обучают не лазить грязными руками прямо в Васино настроение, а изменять его только через взаимодействие с публичным интерфейсом.
Но дело в том, что практика показала частое наличие потребности все же управлять состоянием объекта. Возьмем, к примеру, автомобиль. У него довольно сложное состояние, которое управляется более-менее широким интерфейсом. Но мы можем выделить некую относительно изолированную часть состояния, например bool "двигатель запущен". И возникает желание добавить к публичному интерфейсу автомобиля способ получать и менять это состояние. И вот такое поведение объекта, служащее для контроля за изолированной частью состояния, и есть свойство. Это ничему не противоречит. Во-первых, эта часть состояния вовсе не обязана соответствовать никакому физическому полю. Это абстракция. Во-вторых, в отличие от физического поля, попытка изменить состояние не является нарушением инкапсуляции.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[67]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, Cyberax, Вы писали:
C>Внимание вопрос! Что произойдет, если при сериализации восстановится C>сначала поле с процентом?
А вот этот вопрос — прямое следствие заблуждения. Почему-то некоторые люди доводят утверждение "Свойство — это интерфейс объекта, отвечающий за управление изолированной частью его состояния" до абсурда: "Всё состояние объекта полностью описывается его свойствами". Из этого фундаментального заблуждения сразу же следует еще одно: "Для сериализации обхекта достаточно сериализовать значения всех его свойств".
Ребята, сериализация как таковая не имеет никакого отношения к свойствам. Это же всего лишь превращение состояния объекта в поток байт.
Иногда полезно иметь свойства ортогональными. Но это не обязательно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Если нам не помогут, то мы тоже никого не пощадим.
Вот веселуха начнётся.
1.1.4 stable rev. 510
