(no subject)

[singalen]

Прочитал про "младшего брата" слова RTFM, STFW. Забавно. Кстати, чудесный текст.
Мне сказали, что корпоративные информсистемы на .NET пока что не особо успешны, и это из-за отсутствия хорошего аппсервера. Интересно, почему так? И зачем обязательно сервер приложений?
Не боясь показать чайниковую сущность, спрошу: почему вообще важен аппсервер? Скажем так: это же фреймворк. Если не делать inversion of control, а добиться тех же функций от библиотеки, скажем, персистенции от Hibernate-а-не-EJB, IPC от CORBA-а-не-SOAP, и так далее - то серверный процесс будет сам себе application server, вернее, сервером бизнес логики.
Пошёл учиться, учиться и учиться, как завещал Ленин. И делать STFW.

Comments

[nponeccop.livejournal.com]

Через некоторое время становится всё равно. Процедурное и объектное программирование отличаются только на первый взгляд. На самом деле если вы будете передавать в C указатель this явным образом, будете эмулировать наследование агрерацией, а виртуальные методы - указателями на функции, то сможете любой "объектно-ориентированный" код на C++ перевести в "процедурный".

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

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

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

Другое дело, что некоторые задачи на Перле получится сделать проще чем на PHP или Java. Поэтому на совещаниях по выбору платформы я буду голосовать за Perl. Но если окажется, что Перл в команде почти никто не знает, конечный пользователь не может устанавливать Perl или если просто заказчик ненавидит Перл - буду писать на чем прикажут. Ежик плакал, но продолжал есть кактус.

[voidbent.livejournal.com]

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

[nponeccop.livejournal.com]

Что вы подразумеваете под "сквозной функциональностью"? Давайте к ней прицепимся ради примера.

На этапе бизнес-модели я могу какие угодно квадратики и облачка рисовать. Могу смешать в одну кучу entities, processes, states, activities... Она будет практически одна независимо от того как я потом это по файликам с исходным текстом разложу. То есть иетодология имеет какое-то влияние на этапе дизайна, а на этапе анализа никакого программирования нет, не то что методологии.

[voidbent.livejournal.com]

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

[nponeccop.livejournal.com]

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

[voidbent.livejournal.com]

Конечно-же я сказал слово "файлы" только для большей понятности. Только для того что-бы не вникать в тонкости АОП. ООП, со своим пресловутым сокрытием реализации, просто непозволит вашим требованиям "нужно логирование всех вызовов всех методов и всех бросаний эксцепшинов" выполниться и это остануться просто требования на листке бумаги. Особенно если Вы используете библиотеки написанные не Вами - Вы просто не имеете права лезть внутрь, всё что внутри - это их реализация, Вам-же остался для созерцания только интерфейс. Точно так-же у вас возникнут проблемы контроля этих требований даже в вашем коде. Как проверить что каждый throw и каждый вызов метода залогирован?
АОП позволяет совсем немного приоткрыть завесу секретности имплементации и эти требования в терминах АОП можно выполнить за пол часа. (Правда ни на что другое АОП не годиться но это уже отдельный разговор)

[voidbent.livejournal.com]

> На самом деле если вы будете передавать в C указатель
> this явным образом, будете эмулировать наследование агрерацией ...
> Но это на нижнем уровне.

Угу. Знаем. А ещё уровнем ниже машина Тьюринга на которой можно сэмулировать ява машину и которою можно сэмулировать на ява машине.

Но я всё-таки предпочёл бы програмировать ява машину а не машину Тьюринга :)

[nponeccop.livejournal.com]

Вы посмотрите на код Апача. Он написан на Си с применением объектно-ориентированной методологии.

Загляните ко мне в ЖЖ и найдите там пример функционального программирования на Перле.

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

[voidbent.livejournal.com]

Загляните ко мне в ЖЖ и найдите там пример функционального программирования на Перле.

[смеётся] Ну да :) А я в детстве видел как в цирке медведь ездит на велосипеде :) Но делать из этого утверждение что "медведи и велосипедисты ездят на велосипедах одинаково хорошо" я бы не стал :) А так же я бы не стал советовать отправить медведя на олимпиаду по велоспорту мотивируя это тем что серебрянной пули нет.
Увы ... Медведь ездит на велосипеде так-же плохо как и Перл позволяет програмировать на себе в функциональном стиле.

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

[nponeccop.livejournal.com]

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

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

Я говорю о том что заказчик может ЗАХОТЕТЬ ИМЕННО МЕДВЕДЯ НА ВЕЛОСИПЕДЕ, велосипедисты его не устраивают. И об этом пытался вам сказать, а не о том что медведи хорошие велосипедисты.

И про серебряную пулю Вы всё перекручиваете. К чему здесь серебряная пуля?

[singalen]

по ключевым словам, не имеющим к Вите никакого отношения

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

[nponeccop.livejournal.com]

Вот видите! Виктор против того, чтобы Вы забирали у него посетителей.

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

Так что давайте здесь. Впрочем, "там" уже тоже достаточно нафлеймили.