(no subject)

[singalen]

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

Comments

[voidbent.livejournal.com]

Отлично! Т.е. если заказчику всё равно, и у нас под рукой имеется достаточное количество процедурных девелоперов, то можно новый проэкт начинать на процедурном языке типа С (вместо например С++) и проэкт от этого ничего не потеряет?
А почему тогда в своё время когда мы все были процедурными ООП приобрело такую популярность? Несмотря даже на то что ООП программистов и инструментов было мало. Просто реклама?

[voidbent.livejournal.com]

Да ... забыл сказать. Не просто проэкт а ЛЮБОЙ проэкт.

[nponeccop.livejournal.com]

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

Я не был процедурным :) Я родился с предустановленным Turbo Pascal 5.5

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

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

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

По поводу ажиотажа - вспомните, скажем, ажиотаж вокруг UML и моделирования. Вспомните ажиотаж вокруг Java. Подумайте о сегодняшнем ажиотаже вокруг виртуальных языковых машин, "безопасных языков" и generic programming.

Серебряной пули нет - перечитайте Брукса с Йордоном.

[voidbent.livejournal.com]

[внезапно став серьёзным] Серебрянной пули нет, но Вы из этого утверждения делаете не правильный логический вывод. Вы утверждаете что раз нету средства которое было-бы на 3 порядка лучше всего остального, то значит все средства одинаковы и можно выбирать любое случайным образом. Это, мягко говоря, не правильно. Логическая ошибка заключается в том что приниципиальная невозможность серебрянной пули тем не мение не мешает быть одним средсвам быть лучше других (не на 3 порядка конечно но всё же достаточно что-бы заметить это невооружённым глазом). UML не оправдал надежд серебрянной поли, но немного помог облегчить жизнь. То-же касается и Java, (от себя добавлю ещё XML) и прочего. В результате множество средств претендовавших на серебрянную пулю, жизнь нам всё таки облегчили заметно.

[voidbent.livejournal.com]

Кстати ... кроме всего прочего ... какая-то парадигма может оказаться на 3 порядка хуже всего остально и это тоже не будет противоречить отсудствию серебрянной пули.

[nponeccop.livejournal.com]

Вы говорите об идеальном мире, я говорю о реальном.

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

Но в реальности разница настолько мала, что в 90% проектов её перевешивают какие-либо внешние причины, и проект делается на том что придется.

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

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

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

+1

[singalen]

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