LINUX.ORG.RU

[вброс]Почему объектно-ориентированное программирование провалилось?

 


2

7

http://citforum.ru/gazeta/165/

по линку многабукаф, немного для Ъ:

факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp’еров была куда убедительней и последовательней, чем сторонников ООП.

Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: “Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле”.

Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП “ускоряет разработку программ”: “Как только ты сказал слово «объект», можешь сразу забыть о модульности”.

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.

Ответ на: комментарий от www_linux_org_ru

>> Класс (== один объект класса) - не будет; набор объектов класса - будет.

этот агрумент обламывается на примере с 1. одной и 2. многими ссылками на целое число

Не вижу облома. class Item { Item* prev; Item* next; int payload; } не включает в себя ровно никаких ограничений на значения (предикатов, по-твоему). А как только ты включишь ограничения кольца и бублики, ты получишь новые типы.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

про ссылки — это уже другой пример

void swap(Some& a, Some& b) {
  a = a xor b;
  b = a xor b;
  a = a xor b;
}

Если Some это такое целое число, для которого невозможны 2 ссылки на него, то swap на нем будет работать правильно; если же возможны, то swap(x,x) просто обнулит х.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от tailgunner

тебе в твоем определении как минимум надо написать:

тип — это множество значений и множество операций над типом, над ссылками на значения типа, над указателями на значения типа (и может дальше)

а иначе получится, что типы, указатели на значения которого 1. можно копировать и 2. не нельзя копировать — это один и тот же тип, они ведут себя по-разному при swap

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Macil

Ну да, согласен, только надо немного расширить до языка. Т.е. тип - это язык, протокол, мемо для людей: программистов и аналитиков, для удобства. Ведь машина оперирует с байтами памяти напрямую, как клеточный автомат или машина Тюринга, и про типы не знает (компиллятор языка знает о встроенных нескольких типах). Реальные же типы будут гораздо сложнее. Чем например мой динамический валидатор почтовых индексов хуже? Он ведь тоже орёт, но в рантайме. И проверяет тип досконально в том числе против контрольных таблиц допустимых паттернов и делает геозапросы. Чем не тип? А когда уже валидации прошли - я уже знаю, что в поле таком-то лежат валидные индексы. И в базе данных, кстати есть аннотации. Поэтому я и говорил об аттрибутах выше. Тип - это аттрибуты для человека, чтобы не забыть, что там делалось с ним в операторе и что считается валидным почтовым индексом (на тот момент времени). Для нетехнарей-аналитиков пишут документацию в человеческой грамматике с описанием типа (чтобы знали что ждать).

anonymous
()
Ответ на: комментарий от www_linux_org_ru

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

anonymous
()
Ответ на: комментарий от tailgunner

>> А почему бы сразу не думать в терминах функции-оператора?

Вполне можно.

ну вот я и предлагаю

Ты же сам сказал «сущность» - значит, на каком-то уровне она едина. Что, конечно, не мешает ей быть набором связанных объектов.

таких сущностей сколько угодно, и множества - пересекающиеся. Какой базис выбрать? И надо ли выбирать вообще? Об этом топик. Я не против аттрибутов, а против ранней группировки их по классам! Аттрибуты и объекты - полезны только для выяснения требований. Это всего-лишь язык. Любое же раннее разбиение будет плохим (неэффективным) до полного выяснения всех деталей (что практически невозможно, ведь и спецификации меняются, понимание приходит постепенно, технологии тестируются, а нагрузка меняется). Хотя бы потому что у каждого набора параметров, размеров вводов итд - будет свой минимум (и сложности кода и скорости исполнения).

Это можно проиллюстрировать аналогией с базами данных, где Data Model - это аналог спецификации, общий язык домейна, абстрактные сущности, а вот физическая схема - может быть совсем иная. Уровень нормализации, выбор схемы (т.е. объектов) - диктуется нагрузкой и приоритетом чтения над записью, индексами, количеством/глубиной выполняемых джойнов итд. Т.е. в каком-нибудь OLTP - одни объекты/таблицы (разбиение), а в случае OLAP при тех-же данных - уже совсем другие, в сильно денормализованном виде, и представлены в виде фактов, а не тех старых привычных объектов что были вначале. Таким образом реальная имплементация - будет совсем не та какой казалась, глядя на исходные сущности и мысля о сущностях как таблицах. А может быть база вообще должна быть не реляционная, а иерархическая, или сетевая, или распределённая или поделённая на регионы. И в одном регионе будет одна схема, а в другом - другая. Итд. Т.е. привязка к объектам слишком рано - архивредно. Концепции (problem domain) не должны иметь связи с физической реализацией.

А некоторые ЮМЛьные тулы, курсы и ООП веяния - напрямую пропагандируют преобразовывать объекты домейна - в классы. Или тот же ОРМ. Вот и имеем тормоза или копирование гигабайтных данных через сеть туда-обратно для наполнения данных, в то время как надо вытащить всего лишь одно поле на несколько байт одним джойном в оптимизированной для этого базе данных.

Т.о. я не против объектов, а против раннего завязывания на конкретный базис объектов.

anonymous
()
Ответ на: комментарий от anonymous

под конец девелопмента - пусть будут объекты (так же как после стабилизации DB схемы). Можно даже всё сделать private под конец, чтобы никто не сувался. Но если сунутся - там и более других методов напортачить достаточно.

Я всегда (ещё с 98 года) использовал ЮМЛ (когда требовали) для одной цели: генерации финальной картинки, после окончания девелопмента. Только для показа основных классов, взаимодействий, модулей другим девелперам пост-фактум, после девелопмента - её ценность. Т.е. для документации и для будущих поколений. Но не для дизайна! (да и в первом многие предпочитают всё же дебаггер и сорс).

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от www_linux_org_ru

> тебе в твоем определении как минимум надо написать:

тип — это множество значений и множество операций над типом, над ссылками на значения типа, над указателями на значения типа (и может дальше)

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

а иначе получится, что типы, указатели на значения которого 1. можно копировать и 2. не нельзя копировать — это один и тот же тип

Так не получится.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> а иначе получится, что типы, указатели на значения которого 1. можно копировать и 2. не нельзя копировать — это один и тот же тип

Так не получится.

более подробно: допустим, есть конструкция newtype int_1ref where refcount(this) <= 1. Здесь int_1ref - это _новый_ тип, а refcount - функция, подсчитывающая число ссылок на объект. А вот как ты ее будешь проверять - твои личные проблемы.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Я всегда (ещё с 98 года) использовал ЮМЛ (когда требовали) для одной цели:

генерации финальной картинки, после окончания девелопмента. Но не для дизайна!

Уж сколько раз твердили миру... (с) Иван Крылов

Дизайн сложных проектов:
«снизу-вверх» - для 1 «гения»,
«сверху-вниз» - для многих «человеков».

P.S. anonymous, можешь ли ты написать софт, или организовать работу «снизу-вверх» для проектов типа полёт «Бурана»? :)

quickquest ★★★★★
()
Ответ на: комментарий от tailgunner

> Так не получится.

Да, я понял мысль — разница в поведении программ обусловлена разницей типов «указатель на Some».

Но проблема скорее всего останется, вот только щас я пока не придумал как она проявится.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от tailgunner

а вот например class Item { Item* next; int payload; } с набором разумных операций будут вести себя совершенно по-разному в конфигурации буквы О и буквы Р [[ щас подправил ]]

Класс (== один объект класса) - не будет; набор объектов класса - будет.

Проблема еще и в том, что на классе (== одном объекте класса) ты особо и операций не определишь.

Например

class Item { 
  Item* next; 
  int payload; 
public: 
  void set_next(Item* new_next); // нельзя: работает с 2 объектами класса
  void set_payload(int new_payload); // вероятно тоже нельзя: это операция не только на объекте класса, но и на int-e
  void inc ()  { payload++; } // это можно
  Item* incr() { payload++; return this; } // может и это можно
};

А на практике пишут set_next.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> Проблема еще и в том, что на классе (== одном объекте класса) ты особо и операций не определишь.

А почему это проблема? Пусть операция op(A, B) будет входить в множества операций и над A, и над B.

tailgunner ★★★★★
()
Ответ на: комментарий от quickquest

> P.S. anonymous, можешь ли ты написать софт, или организовать работу «снизу-вверх» для проектов типа полёт «Бурана»? :)

Как подсказывает здравый смысл, начинать проект, типа полёт «Бурана», разумно будет с датчиков и их обвязки, а не с концепции большой кнопки - «Сделай мне заи*ись!».

anonymous
()
Ответ на: комментарий от anonymous

>Как подсказывает здравый смысл, начинать проект, типа полёт «Бурана», разумно будет с датчиков и их обвязки

Заблуждение. Любой большой проект начинают с абстрактного «чёрного_ящика», постепенно уточняя его свойства и функции. Технические требования на датчики (масса, габариты, обвязка, ...) тебе выдали бы только после завершения эскизного проекта всего «Бурана».

При методе «сверху-вниз» конечная цель оказывает постоянное воздействие на разрабатываемые средства достижения этой цели.

При методе «снизу-вверх» мы имеем «разброд и шатание», характерное для «гнутого софта».

quickquest ★★★★★
()
Ответ на: комментарий от anonymous

>машина оперирует с байтами памяти напрямую

Какая разница. Кому какое дело как именно машина работает? Я не думаю, что в теперешних условиях правильным будет считать тип, как что-то определяющее физическую структуру данных...

Чем например мой динамический валидатор почтовых индексов хуже?


Твой динамический валидатор имеет тип Either ErrorMessage PostalAddress. Т.е. в случае ошибки возвращаем Left(ErrorMessage(...)), в случае успеха — Right(PostalAddress(...)). А потом разруливаем с помощью pattern matching и различных комбинаторов, которые по-разному склеивают разные «ветки» типа Either. Короче, полная идиома data as control structures.

Реальные же типы...


Реальные же типы будут … абстрактными. В этом плане очень хорош язык ML (SML, OCaml). В нем очень хорошо развита система модулей. Он даже типы, объявленные внутри модулей показывает как Abstract, типа не твое дело как они объявлены :). А «видишь» свой тип ты исключительно через объявленный открытый интерфейс.

Короче, идея стыренная из Модулы2, насколько я понимаю.

Macil ★★★★★
()
Ответ на: комментарий от tailgunner

>> Проблема еще и в том, что на классе (== одном объекте класса) ты особо и операций не определишь.

А почему это проблема? Пусть операция op(A, B) будет входить в множества операций и над A, и над B.

Значит set_next будет входить во множество операций над Item, а он, извините, оперирует над ДВУМЯ объектами класса Item (или точнее, двумя объектами Item*)

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

www_linux_org_ru ★★★★★
()

Плагиат

Во-первых, оригинальная ссылка этой статьи, это:

http://blogerator.ru/page/oop_why-objects-have-failed

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

Во-вторых, если большинство населения планеты - курит (как утверждает статистика), если большинство населения не имеют высшего образования, если большинство населения кричало ту самую фразу «распни его!» и т.д. и т.п., - то это вовсе не значит, что это самое БОЛЬШИНСТВО - всегда право, просто в силу своего демократического большинства. Такой же срез можно сделать и в области программеров, большинство которых просто в жизни ничего не видели кроме своей сраной ООП, и потому на таких постах их несет чисто по инерции куда-то сразу мимо, совершенно не вдумываясь в смысл написанного. Поэтому апелляции, в стиле, «лемминги просто не могут ошибаться - ведь их так много», - все идут нафиг сразу.

В-третьих. Можно конечно сказать, что главный разработчик IBM и Sun - сосет, со-разработчик С++ настолько наивен, как пишут в комментариях, что не знает просто элементарных вещей, - НО КОНЕЧНО ЖЕ _ТЫ_, ВАСЯ ПУПКИН, ЗНАЕШЬ ИХ ВСЕ!!!

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

У меня всё :)

Pleshner
()
Ответ на: комментарий от quickquest

> Заблуждение.

Да, отчетливо вижу твое заблуждение. Хочешь удивлю? Ты знаешь, что самая важная для научно-технического прогресса наука - материаловедение?

Любой большой проект начинают с абстрактного «чёрного_ящика», постепенно уточняя его свойства и функции.

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

Технические требования на датчики (масса, габариты, обвязка, ...) тебе выдали бы только после завершения эскизного проекта всего «Бурана».

Кто выдал бы? Тебе? Зачем тебе? Чисто поэкспериментировать: сколько ошибок ты допустишь при быдлокодинге? Чушь какая-то.

Ты реально полагаешь, что эскизный проект «Бурана» рисовал сначала художник, а уже потом отдал посчитать всякую мелочевку инженерам?

Технические требования на датчики

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

При методе «сверху-вниз» конечная цель оказывает постоянное воздействие на разрабатываемые средства достижения этой цели.

Блин, где ж вас таких дрессируют то, а?

При методе «снизу-вверх» мы имеем «разброд и шатание», характерное для «гнутого софта».

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

anonymous
()
Ответ на: комментарий от anonymous

> Ты реально полагаешь, что эскизный проект «Бурана» рисовал сначала художник, а уже потом отдал посчитать всякую мелочевку инженерам?

А я реально полагаю, что сначала нарисовали эскизный проект всего Бурана, а потом стали разрабатывать его узлы.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> А я реально полагаю, что сначала нарисовали эскизный проект всего Бурана, а потом стали разрабатывать его узлы.

А я _настаиваю_(!), что любой технический проект сначала ПРОСЧИТЫВАЮТ!

P.S. А ты там можешь полагать, что тебе угодно.

anonymous
()
Ответ на: Плагиат от Pleshner

>давайте внимательно прочитаем все аргументы

А нафига? Зачем читать вбросы людей, дрочачих на понятие «энкапсуляция». Причем, формально это понятие никто не определял (и не стремится).

Мне вот лично Буча сотоварищи хватило на всю оставшуюся жизнь.

Жизнь слишком коротка, чтобы читать неформальную гуманитарщину, особенно в тех областях, где формализм имеет место, и вообще — рулит.

Давайте лучше изучать решения, предложенные в ML и Scala, а?

Macil ★★★★★
()
Ответ на: Плагиат от Pleshner

> Rastafarra, пожалуйста, поправьте ссылку в новости

на 13-ой странице самое время.

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

ну... кто у кого стырил большой вопрос ;)

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от anonymous

>> А я реально полагаю, что сначала нарисовали эскизный проект всего Бурана, а потом стали разрабатывать его узлы.

А я _настаиваю_(!), что любой технический проект сначала ПРОСЧИТЫВАЮТ!

Да ради ТНБ. Только вот сначала его просчитывают весь, а потом просчитывают узлы.

P.S. А ты там можешь полагать, что тебе угодно.

А ты можешь настаивать на том, на чем тебе угодно.

tailgunner ★★★★★
()
Ответ на: комментарий от Rastafarra

йожик

Просто по дате публикации посмотри и по ФИО автора, коему принадлежит оригинальный блог. Хотя мне пофиг.

Pleshner
()
Ответ на: комментарий от Macil

>>Жизнь слишком коротка, чтобы читать неформальную гуманитарщину, особенно в тех областях, где формализм имеет место, и вообще — рулит.

Золотые слова. От местных програмерских срачей с несогласованной терминологией порой несет ГСМщиной похлеще чем из тредов астралопитеков.

mclaudt
()
Ответ на: комментарий от tailgunner

>Да ради ТНБ. Только вот сначала его просчитывают весь, а потом просчитывают узлы.

Прально! Т.к. у «Буранов» модель ЖЦ какбэ каскадная. И функциональные требования определяются с самого начала, и не меняются. Никто посредине проекта не станет превращать «Буран» в гусеничный глубоководный танк.

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

Macil ★★★★★
()
Ответ на: комментарий от Macil

> А софтом ситуация кардинально другая

Не кардинально. На самом деле, для больших систем она даже не сильно отличается.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>На самом деле, для больших систем она даже не сильно отличается.

Не согласен. Например, для экономических ИС требования постоянно уточняются и пересматриваются.


Для потребительского коммерческого софта ситуация похожа: он постоянно должен следовать «модным трендам».

Macil ★★★★★
()
Ответ на: комментарий от Macil

>> На самом деле, для больших систем она даже не сильно отличается.

Не согласен. Например, для экономических ИС

Не занимаюсь экономическими ИС, но сильно подозреваю, что даже в них архитектура определяется раз и навсегда.

tailgunner ★★★★★
()
Ответ на: комментарий от quickquest

> можешь ли ты написать софт, или организовать работу «снизу-вверх» для проектов типа полёт «Бурана»?

не вижу тз.

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от tailgunner

> сильно подозреваю, что даже в них архитектура определяется раз и навсегда.

тут ты еще хотел, _видимо_, что-то сказать про время жизни проекта, не?

жизнь такова, что «требования» меняются +/- 6-7 раз в год.

Rastafarra ★★★★
() автор топика
Ответ на: комментарий от Rastafarra

>> сильно подозреваю, что даже в них архитектура определяется раз и навсегда.

тут ты еще хотел, _видимо_, что-то сказать про время жизни проекта, не?

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>архитектура определяется раз и навсегда

Архитектура — в какой-то степени да. Но меняется законодательство, иногда достаточно серьезно. Иногда государство аццки отжыгает.

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от anonymous

>А я _настаиваю_(!), что любой технический проект сначала ПРОСЧИТЫВАЮТ!

Дык, эскизный проект - это и есть предварительний расчёт базовых характеристик изделия,
а не картинка художника.
Действует триада: НИР - ОКР - Рабочее проектирование.
НИР: «чёрный ящик» -> эскизный проект
ОКР: эскизный проект -> рабочий проект
Рабочее проектирование: рабочий проект -> готовое изделие.

Хочешь удивлю? Ты знаешь, что самая важная для научно-технического прогресса наука - материаловедение?


Удивить не сможешь, ибо самых важных наук нет!

Подождите пока материаловеды обеспечат материалы с нужными нам свойствами и мы сразу же сделаем вам датчики, удовлетворяющие вашим требованиям!


Именно так! В ВПК, где я участвовал в некоторых достаточно больших разработках, типовая система: «генерал» -> представитель_заказчика(ПЗ) -> начальник -> разработчик -> материаловед.
«Генерал» формулирует требования к «чёрному ящику», ничего не зная о возможностях материаловеда.

При методе «снизу-вверх» мы имеем, к примеру, драйвера,


Драйвер, в отличие от больших проектов, может быть написан 1 человеком «снизу-вверх», а мы обсуждаем коллективное творчество, где метод «сверху-вниз» незаменим.

quickquest ★★★★★
()
Ответ на: комментарий от Macil

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

И это известно уже лет 30-40. Давно признано, что разработка итеративна, но крупная разработка начинается именно сверху вниз.

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

Ха-ха. Более чем возможно, инфа 100%

tailgunner ★★★★★
()
Ответ на: комментарий от quickquest

опять всё смешали в кучу. Хотя нет, объектники (жаба программисты) не только почти отобрали работу у проф. дизайнеров сайтов (в начале 2000х), начав страницы лабать на JSP/JSTL/JSF, забрав и традиционные формы и css (благо ситуация с аяксом поменялась), но и желают отнять работу у бизнес-аналитиков (экспертов домена). Не слишком ли много самоуверенности?

Объясняю: определение требований пишется экспертами в виде спецификации, на языке близком к человеческому, возможно с кусками превдокода. И те знатоки домена, процессов, бизнеса - единственный кто понимает всё до мелочей. Только они могут описать что им нужно, кто-же ещё? Вот они и делают «сверху-вниз». Потом (в идеале) перед программистами кладут мануал (спек) с диаграммами, требованиями, описаниями, скетчами возможных экранов. Где программисту остаётся выбрать технологии и транслировать человеческий язык в язык машины. А программисту - гораздо проще «снизу-вверх», с этого момента.

можешь ли ты написать софт, или организовать работу «снизу-вверх» для проектов типа полёт «Бурана»? :)

см. выше. И уверен - что если бы были SDLC в то время и авто-генерация объектов из ЮМЛей - Буран бы не полетел, потому что суперсложную систему так бы и не релизнули из-за багов и невозможность их починить из-за сложности.

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

Т.е. когда я говорю о «снизю-вверх» - я говорю исключительно о девелоперах (о чём топик), а не о планировании, разработке требований, написании мануалов функциональной спецификации, технической спецификации. Последние - не для жаба-программистов, а для экспертов домена!

anonymous
()
Ответ на: комментарий от tailgunner

>>> А я реально полагаю, что сначала нарисовали эскизный проект всего Бурана, а потом стали разрабатывать его узлы.

А я _настаиваю_(!), что любой технический проект сначала ПРОСЧИТЫВАЮТ!

Только вот сначала его просчитывают весь, а потом просчитывают узлы.

Весь? Правда?

Расскажи, как? Как его просчитывают весь сразу? Или рассказывай, что ты понимаешь под словом «весь»?

anonymous
()
Ответ на: комментарий от anonymous

>определение требований пишется экспертами в виде спецификации, на языке близком к человеческому

СЖИГАТЬ! Током низкого напряжения!

домена


Предметной области, камрад.

перед программистами кладут


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

Запомни простую истину. Настоящий программист ОЧЕНЬ хорошо знает свою предметную область. На понятийном уровне гораздо круче «экспертов», потому что программисту хошь-нехошь, а формализовывать задачу придется. А «эксперты» зачастую умеют только болтать, да качественно иметь мозг и втирать очки начальству.

Macil ★★★★★
()
Ответ на: комментарий от quickquest

> Любой большой проект начинают с абстрактного «чёрного_ящика», постепенно уточняя его свойства и функции. Технические требования на датчики (масса, габариты, обвязка, ...) тебе выдали бы только после завершения эскизного проекта всего «Бурана».

Ещё раз: вы не разделяете работу бизнес-аналитиков (домейн-экспертов) и программистов - в больших проектах. Программер придёт в конце, после завершения спецификаций (в идеале) и всё напишет на удобном ему языке, используя технологии, которые впишутся в требования. И сделает он это «снизу-вверх», если нормальный программист. Либо архитект напишет работающую «козу», поймёт где какие модули, даст модули писать рядовым программистам и те свои куски тоже напишут «снизу-вверх», постоянно контролируя ситуацию в своём модуле, имея на каждом этапе работающую программу с юнит тестами.

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

Чем больше классов - тем больше рефакторинга. Классов должно быть как можно меньше. О чём я и говорил изначально. Я начинаю с минимума, вообще с процесса и обстрактной обработки (ингода сам не знаю чего), абстрактного парсинга, процессинга, репортинга итд, практически лепя темплейты. Мне и классы не нужны: это последовательность функций. По мере понимания объёма задачи, отпочковываем процедуры, которые могут быть переданы другим программистам. Но в виде последовательного, линейного пайплайма процессинга заметьте, а не сотен классов и разных методов и объяснения другим - что каждый класс делает. А именно второму учит как некое откровение ООП, разве не так?

anonymous
()
Ответ на: комментарий от anonymous

>И уверен - что если бы были SDLC в то время и авто-генерация объектов из ЮМЛей - Буран бы не полетел, потому что суперсложную систему так бы и не релизнули из-за багов и невозможность их починить из-за сложности.

Для «Бурана» был сделан советский аналог UML - «ДРАКОН».
Почитай историю создания софта для этого проекта и попробуй найти там разработку «снизу-вверх».

quickquest ★★★★★
()
Ответ на: комментарий от Love5an

В принципе, можно.

Через gensym и немного извращений.

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

quasimoto ★★★★
()
Ответ на: комментарий от Macil

> Запомни простую истину. Настоящий программист ОЧЕНЬ хорошо знает свою предметную область. На понятийном уровне гораздо круче «экспертов», потому что программисту хошь-нехошь, а формализовывать задачу придется.

Блин! Это должны были быть мои слова! Понятие формализация задачи было ключевым.

А «эксперты» зачастую умеют только болтать, да качественно иметь мозг и втирать очки начальству.

«Эксперты» необходимы. Как правило, у них есть теоретические обоснования и наработки по технологической базе.

anonymous
()
Ответ на: комментарий от Macil

> СЖИГАТЬ! Током низкого напряжения!

не всё так однозначно. Во-первых, часто бывает старая документация. Которая устаканена годами. И для новой имплементации (например, переделка из проприетарных давно ушедших технологий) - нужно всего-то добавить новые требования к первоначальным спекам. Во-вторых, в больших конторах очень много бизнес-аналитиков экспертов предмета, которые поддерживают бизнес (они не программисты!). А программистов не напасёшься. Например, сегодня веб, а со вчера из программеров только кобольщики остались. Таки надо нанимать веб-программистов, своих-то нет. Кто знает процесс? А бухи, а профессиональные математики-статистики, которые программируют на каком-нибудь SAS и всё. И научить их нормально программировать - либо займёт 20 лет, либо скорее - бесконечность.

anonymous
()
Ответ на: комментарий от Macil

> Настоящий программист ОЧЕНЬ хорошо знает свою предметную область. На понятийном уровне гораздо круче «экспертов»

А еще он не существует, настоящий.

tailgunner ★★★★★
()
Ответ на: комментарий от quickquest

уверен: это был бизнес-язык, максимум псевдо-код (по ссылкам не ходил, сорри) и он не генерил классы. Иначе бы не полетело и уж точно бы не прилетело. Ещё раз: я же не против DSL, а только за. Я - против генерации кода. Против прямого маппинга объектов предметной области на объекты языка (мой пример с DB схемой: я же не против схемы! Но любой дб спец скажет что логическая шема и физическая - это 2 разные вещи. А адепты ООП ЮМЛ кодогенерации не понимают).

anonymous
()
Ответ на: комментарий от Macil

> Запомни простую истину. Настоящий программист ОЧЕНЬ хорошо знает свою предметную область. На понятийном уровне гораздо круче «экспертов», потому что программисту хошь-нехошь, а формализовывать задачу придется. А «эксперты» зачастую умеют только болтать, да качественно иметь мозг и втирать очки начальству.

тебе не повезло с экспертами. Есть спецы, кроме SAS или экселевских макросов ни на чём не программирующих, но они - эксперты и знают область. Надо долго поработать - чтобы так знать.

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.