(no subject)

[singalen]

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

Comments

[voidbent.livejournal.com]

FutureC++ - это написанное c ошибкой FeatureC++

> А ещё мне кажется, что в этой ветке ты обсуждаешь вопрос вкуса.

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

[nponeccop.livejournal.com]

Если разработчики одинаково хорошо владеют правой и левой рукой - то не зависит. Но примените объектный подход в команде процедурщиков - и вы погибнете.

Именно поэтому часто выбор средств разработки определяется имеющимися в наличии разработчиками.

Вообще успех проекта зависит в конечном итоге от квалификации исполнителей и управленцев. А "неправильная платформа/парадигма" - это из серии анекдота про плохого танцора.

[voidbent.livejournal.com]

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

[nponeccop.livejournal.com]

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

[voidbent.livejournal.com]

И поэтому можно выбрирать парадигму ориентируясь только на внешние обстоятельства и игнорируя "качество самой парадигмы"?

[nponeccop.livejournal.com]

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

[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]

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

[johndegree.livejournal.com]

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