Здравствуйте, VladD2, Вы писали:
VD>Ясно. Опять много слов и никакого дела. Другого и не ожидал, если честно.
Ну а что я могу на подобное ответить? Учитывая, что "внятное" — характеристика в большей степени субъективная, то мне остается только признать — да, вероятно я не в состоянии дать внятное для тебя объяснение.
VD>ЗЫ
VD>За других тоже не стоит говорить. Особенно за Синклера.
А я за него нигде и не говорил, вообще то (в отличие от кое кого, кто тут решил поговорить за меня). Просто предложил почитать его сообщения, бо с его точкой зрения в тех флеймах я в общем и целом согласен.
VD>Может быть мне конечно и показалось, но он в некоторый момент как-то резко переменил риторику.
Ну и кто из нас тут говорит за Синклера?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pzz, Вы писали:
ГВ>>Цирк. Для тех кто в это верит, поясню: привлекать неквалифицированных пользователей к формализации задачи — хорошо, привлекать неквалифицированных программистов (именно их ты имеешь в виду, говоря об индусах, правда?) — очень плохо.
Pzz>Их привлекают не к формализации, а к реализации. Хорошо ли это, плохо ли, но вот привлекают. Наверное потому, что свободных квалифицированных уже почти не осталось.
Это и есть — плохо.
ГВ>>Вообще-то ООП зародилось из фреймов-слотов, это такой ма-а-а-алепусенький кусочек инструментария ИИ по формализации знаний. Менеджеры софтостроения там если и стояли рядом, то только стояли. Pzz>Вообще-то ООП зародилось из Симулы, языка. предназначенного для компутерного моделирования.
О точных прародителях ООП и календаре его развития можно спорить, но это не слишком важно. Важно то, что к менеджменту ООП не имеет никакого отношения. К структуризации знаний — да, к менеджменту — нет.
Pzz>А в индустрию пришло и разрослось именно потому, что помогает раскидывать задачу по большому количеству исполнителей. Фича эта сама по себе очень ценная, но имеет отношение скорее к управлению проектом, чем собственно к программированию.
Всё не так. Первоначально рассуждали о том, что ООП позволяет существенно расширить возможности одного программиста, благодаря тому, что способ представления абстракций лучше адаптирован к человеческому мышлению, чем, скажем, процедурная абстракция. То есть один из тезисов, послуживших распространению ООП прямо противоположен приведённому тобой: предполагалось в некотором роде сокращение числа программистов. Понимаешь? А распределять программирование на массу народу умели задолго до появления даже языков высокого уровня. Почитай того же Брукса.
ГВ>>Свежо предание... Только паттерн, это не "готовое решение", а некое собирательное название разных по существу решений. Хотя примеры могут быть и вполне определёнными. А каким же им ещё быть?! Pzz>Это, признаюсь, не моя мысль, а Пола Грэхема. В оригинале она звучала примерно в том духе, что наличие паттернов проектирования свидетельствует об отсутствии в языке нормальных макросов. Потому что если приходится из проекта в проект делать похожие телодвижения, это повод написать макрос, который эти телодвижения автоматизирует.
Ну, Грэхем в своём репертуаре. Только нужно, как бы, это... Разделять призывы и "идеологемы", и технически реализуемые штучки. Корни паттернов на самом деле в особенностях мышления человека вообще и технических специалистов в частности. Они выходят очень далеко за пределы языков программирования.
Pzz>Я, в общем, отчасти согласен, но с той оговоркой, что некоторые вещи очень просто рассказать человеку, но при этом очень трудно формализовать до такой степени, чтобы их можно было сказать компьютеру.
Ну, я тоже согласен с тем, что повторяющиеся действия нужно загонять в компьютер. Другое дело, что не все действия туда загоняемы и кроме того, даже будучи загнанными они снова упорядочиваются в некие паттерны и так до бесконечности.
Pzz>>>А вот внутри самих алгоритмов if'ы и while'ы — вполне себе адекватный инструмент. ГВ>>Это не просто "адекватный инструмент", if — это блин, базисная конструкция императивного стиля. Pzz>Я как-то не уловил, почему базисная конструкция императивного стиля не может быть адекватным инструментом? Какое слово является ругательным, "базисная" или "императивного"?
"адекватный инструмент" Абсурдна сама формулировка. Ну, что-то вроде: "капли — адекватный инструмент дождика". Вот такое же.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, netch80, Вы писали:
N>>>А при чём тут, откуда оно зародилось? ГВ>>Откуда зародилось, свойства того органично и унаследовало. Но это ни в коем случае не инструмент менеджера. Инструмент менеджера — это нормативная база, ресурсы, деньги, планы, организационные подходы... А не ООП.
N>Так это кроме прочего и организационный подход. Определим и формализуем, как именно связаны между собой работы разных групп и людей, и тем самым уменьшим затраты на взаимодействие при разработке. Разумеется, этот подход заметно некорректен, ну так не он же один используется...
Погоди. Вот опять, не ставь лошадь позади телеги. Сначала инженеры определяют структуру проекта, потом они же определяют структуру работ по проекту. Полученный граф передаётся менеджеру, который отдаёт под козырёк и начинает следить за исполнением графика. Если инженеры определят структуру исходя из принципов функционального программирования, то менеджер точно так же "сделает под козырёк" и будет отслеживать движение работ. Менеджер, в общем, инвариантен структуре интерфейсов.
Чуть-чуть вольных рассуждений:
В истории ООП было много всего интересного и неинтересного, но ИМХО, лучше всех подсуетился на ниве популяризации (читай: продажи) принципов ООП небезызвестный Гради Буч сотоварищи. Его RUP (унифицированный процесс фирмы Rational) настолько плотно поселился в индустрии, что сейчас почитается чуть ли не за нечто само собой разумеющееся. На мой взгляд, это связано прежде всего с тем, что RUP очень удачно оседлал терминологию. По-моему, нет такого слова, относящегося к IT-индустрии, которое не встречалось бы в полной спецификации RUP. "Роли", code review, test case, use case, это вот всё как раз было объединено под крылом RUP. Поскольку Буч параллельно проталкивал именно объектно-ориентированное программирование, то вполне естественно и то, что раньше или позже ООП и RUP должны были превратиться в сиамских близнецов в мозгах пресловутого "среднего менеджера". И таки да, так и произошло. Чуть позже начала активной раскрутки ООП его стали повсеместно называть "методом анализа", а потом уже и "способом организации работ". Больше того, даже итеративную разработку (по принципу: сделали-посмотрели-переделали) намертво связали именно с ООП, хотя в сущности, связи тут никакой, кроме того, что RUP определил "итерацию", как шаг развития проекта.
N>>>Фактически, разделение объектов — то, что позднее назвали "контрактным программированием", с ограничением тем, что "контракт" проводится по границе объекта ("пуля вылетает — проблемы не на моей стороне"). ГВ>>Ты путаешь объектную декомпозицию и спецификацию.
N>Я не путаю, я упрощаю до уровня такого менеджера Спецификация взаимодействия (как при выполнении, так и разработке) является следствием декомпозиции. Это в принципе всё, что ему нужно, чтобы подход работал.
Прости, но этому подходу лет больше, чем ООП. Совершенно классический способ реализации крупных программных проектов: разделить систему на подсистемы, формализовать и зафиксировать интерфейсы, дальше — поскакали. Относительное новшество языков спецификаций, встроенных в язык программирования заключается в том, что появилась возможность автоматически (компилятором) верифицировать спецификации. Спрашивается, при чём тут менеджмент?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>PS. В начале 90-х в Союзе у многих крышу срывало Прологом. С тех пор я думал, что именно Пролог самая крутая трава. Но, видимо, FP еще круче.
VD>Пролог трава более крутая, но к сожалению плохо совместимая с жизнью, так как создать эффективные реализации практически невозможно, и с императивными языками не стыкуется.
Это почему это не стыкуется? Очень даже стыкуется. Посмотри тот же интерфейс SWI Prolog. Всё стыкуется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, fplab, Вы писали:
AVK>>О да, без пенисометрии никак. Знаешь только, в чем проблема, особенно в этом форуме? По результатам измерений запросто может оказаться, что у кого то из твоих оппонентов длиннее. F>Вот тут, коллега, вы сами себе противоречите Выше, если не ошибаюсь, вы указали мне на использование некорректных приемов. Может, будем последовательными ?
Правильно, давай будем последовательными и не будем заниматься пенисометрией и выяснением того, кто и насколько крутые задачи решал.
P.S.: А то глядишь, линейку на одно место намотают. Здесь с этим просто.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
Pzz>>Их привлекают не к формализации, а к реализации. Хорошо ли это, плохо ли, но вот привлекают. Наверное потому, что свободных квалифицированных уже почти не осталось.
ГВ>Это и есть — плохо.
Плохо. Предлагаете их взрывать целыми офисами? Никакого другого способа борьбы с этим печальным явлением я не вижу...
Хотя нет, можно вернуться к программированию на ассемблере. Тогда индусы вымрут сами собой
ГВ>О точных прародителях ООП и календаре его развития можно спорить, но это не слишком важно. Важно то, что к менеджменту ООП не имеет никакого отношения. К структуризации знаний — да, к менеджменту — нет.
Скорее для структуризации умений
Вот скажем, пишете вы сетевую программу. Всю возню с сокетами вы, конечно, засунете в какой-нибудь класс. Но вот знание о том, что сеть не всегда доступна и имеет тенденцию иногда отваливаться у вас будет распределено по всей программе. Не важно в каких терминах, в виде кода ошибки, который возвращает send(), или в виде нотификации о событии, на которое можно подписаться — это в любом случае знание, которым должны обладать многие части программы.
Зато ООП неплохо подходит, чтобы разграничить зону ответственности между людьми. При условии, что вы позаботитесь о том, что они обладают необходимыми общими знаниями. А разграничение зоны ответственности — это задача из области управления проектом, о чем я уже и говорил.
Я имею ввиду, конечно, техническое руководство, а не то, чтобы у всех были исправные стулья и соблюдались сроки
ГВ>Всё не так. Первоначально рассуждали о том, что ООП позволяет существенно расширить возможности одного программиста, благодаря тому, что способ представления абстракций лучше адаптирован к человеческому мышлению, чем, скажем, процедурная абстракция. То есть один из тезисов, послуживших распространению ООП прямо противоположен приведённому тобой: предполагалось в некотором роде сокращение числа программистов. Понимаешь? А распределять программирование на массу народу умели задолго до появления даже языков высокого уровня. Почитай того же Брукса.
И много программистов с тех пор сократилось? Давайте пропустим маркетинговый буллшит.
ООП как способ представления абстракции хорошо подходит для одних задач, средненько для других, и совсем не подходит для третьих. Например, для написания парсера гораздо лучше подходит BNF-грамматика, а не ООП, а для описания сетевого протокола вы бы предпочли инструмент, позволяющий описывать конечный автомат в естественных для него терминах состояний, событий и переходов между состояниями.
Сама организация человеческого мышления зависит и от мыслителя, и от предмета размышлений, и от дискурса. Слабость ООП заключается в том, что предлагается распихать все по коробочкам заранее, когда еще ничего не понятно, еще до начала, собственно, мышления. А к тому моменту, когда все становится понятно, ставки уже сделаны и уже поздно все перераспихивать. В то время как для человеческого мышления не является чем-то невозможным посмотреть на проблему по-другому, в других терминах.
Другая проблема ООП — оно хорошо работает, когда есть много относительно простых и понятных коробочек, но плохо работает, когда коробочек немного, но они сложны сами по себе. Например, ООП ничем вам не поможет, если ваша задача — разработать криптографический алгоритм.
ГВ>Ну, Грэхем в своём репертуаре. Только нужно, как бы, это... Разделять призывы и "идеологемы", и технически реализуемые штучки. Корни паттернов на самом деле в особенностях мышления человека вообще и технических специалистов в частности. Они выходят очень далеко за пределы языков программирования.
Да. Когда моя мама работала конструктором, это называлось "типовой проект". Теперь вот паттерны придумали, чтобы умнее казаться
Pzz>>>>А вот внутри самих алгоритмов if'ы и while'ы — вполне себе адекватный инструмент. ГВ>>>Это не просто "адекватный инструмент", if — это блин, базисная конструкция императивного стиля. Pzz>>Я как-то не уловил, почему базисная конструкция императивного стиля не может быть адекватным инструментом? Какое слово является ругательным, "базисная" или "императивного"?
ГВ>"адекватный инструмент" Абсурдна сама формулировка. Ну, что-то вроде: "капли — адекватный инструмент дождика". Вот такое же.
Ну это не моя формулировка, я реагирую на чью-то реплику выше по треду.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Их привлекают не к формализации, а к реализации. Хорошо ли это, плохо ли, но вот привлекают. Наверное потому, что свободных квалифицированных уже почти не осталось.
ГВ>>Это и есть — плохо.
Pzz>Плохо. Предлагаете их взрывать целыми офисами? Никакого другого способа борьбы с этим печальным явлением я не вижу...
Нет. Я этого не предлагаю.
Pzz>Хотя нет, можно вернуться к программированию на ассемблере. Тогда индусы вымрут сами собой
И этого я тоже не предлагаю. Я только констатирую, что привлечение низкоквалифицированой "рабочей силы" не есть хорошо. А ориентация на неё в некотором идейном смысле — вообще ужасна.
ГВ>>О точных прародителях ООП и календаре его развития можно спорить, но это не слишком важно. Важно то, что к менеджменту ООП не имеет никакого отношения. К структуризации знаний — да, к менеджменту — нет. Pzz>Скорее для структуризации умений
То есть? (Просьба: обращайся ко мне на "ты", пожалуйста.)
Pzz>Вот скажем, пишете вы сетевую программу. Всю возню с сокетами вы, конечно, засунете в какой-нибудь класс. Но вот знание о том, что сеть не всегда доступна и имеет тенденцию иногда отваливаться у вас будет распределено по всей программе. Не важно в каких терминах, в виде кода ошибки, который возвращает send(), или в виде нотификации о событии, на которое можно подписаться — это в любом случае знание, которым должны обладать многие части программы.
Чего-чего? Во-первых, никто не мешает мне сделать какой-нибудь "permanent socket", который один раз получает параметры связи, а потом восстанавливает её по мере исчезновения. Во-вторых, распределено не знание, а управляющий сигнал от одной подсистемы к другой. Этих сигналов может быть ещё сто тыщ. В-третьих, если говорить о сокетах, то структурирование знаний здесь — само описание взаимодействия с сетью в виде "сокета".
Pzz>Зато ООП неплохо подходит, чтобы разграничить зону ответственности между людьми. При условии, что вы позаботитесь о том, что они обладают необходимыми общими знаниями. А разграничение зоны ответственности — это задача из области управления проектом, о чем я уже и говорил.
Ну так для этого подходит вообще любой метод структурирования программы, подразумевающий мало-мальскую модульность. По твоему выходит, что все они придуманы для загрузки больших коллективов?
"Управление проектом" только подхватывает эту самую структуризацию и придаёт ей некоторую административную силу. Ничего больше. В сущности, управление прекрасно справится со своими задачами и без ООП.
Pzz>Я имею ввиду, конечно, техническое руководство, а не то, чтобы у всех были исправные стулья и соблюдались сроки
Так ты не путай одно с другим. "Техническое руководство", это такая штука, которая к "менеджменту" вообще никакого отношения не имеет, кроме лексического подобия.
ГВ>>Всё не так. Первоначально рассуждали о том, что ООП позволяет существенно расширить возможности одного программиста, благодаря тому, что способ представления абстракций лучше адаптирован к человеческому мышлению, чем, скажем, процедурная абстракция. То есть один из тезисов, послуживших распространению ООП прямо противоположен приведённому тобой: предполагалось в некотором роде сокращение числа программистов. Понимаешь? А распределять программирование на массу народу умели задолго до появления даже языков высокого уровня. Почитай того же Брукса.
Pzz>И много программистов с тех пор сократилось? Давайте пропустим маркетинговый буллшит.
Нет, не пропустим. Соображение о повышении индивидуальных способностей программиста было весьма действенным фактором распространения ООП. И кстати, в некоторой части вполне подтвердилось. Естественно, что к рассуждениям о "сокращении количества" относились по большей части скептически, но если бы ООП проталкивалось под флагом вовлечения массы людей — сопротивление было бы сумасшедшим. Да ООП вообще бы из пробирки не вылезло, не смотря на все позывы индустрии.
Pzz>ООП как способ представления абстракции хорошо подходит для одних задач, средненько для других, и совсем не подходит для третьих. Например, для написания парсера гораздо лучше подходит BNF-грамматика, а не ООП, а для описания сетевого протокола вы бы предпочли инструмент, позволяющий описывать конечный автомат в естественных для него терминах состояний, событий и переходов между состояниями.
Никто и не говорит, что ООП — серебряная пуля. Да я и сам так не считаю. Я спорю с вот этой репликой:
А в индустрию пришло и разрослось именно потому, что помогает раскидывать задачу по большому количеству исполнителей. Фича эта сама по себе очень ценная, но имеет отношение скорее к управлению проектом, чем собственно к программированию.
Это не просто буллшит, это полная каша в голове. Вот я тебе и объясняю — кто на ком на самом деле стоял.
Pzz>Сама организация человеческого мышления зависит и от мыслителя, и от предмета размышлений, и от дискурса. Слабость ООП заключается в том, что предлагается распихать все по коробочкам заранее, когда еще ничего не понятно, еще до начала, собственно, мышления. А к тому моменту, когда все становится понятно, ставки уже сделаны и уже поздно все перераспихивать. В то время как для человеческого мышления не является чем-то невозможным посмотреть на проблему по-другому, в других терминах.
Ну, я уж не знаю, откуда ты извлёк мысль, что ООП предполагает "распихивание по коробочкам" до начала размышлений. По моему опыту и наблюдениям это далеко не так, а по моему убеждению это так и быть не может.
Pzz>Другая проблема ООП — оно хорошо работает, когда есть много относительно простых и понятных коробочек, но плохо работает, когда коробочек немного, но они сложны сами по себе. Например, ООП ничем вам не поможет, если ваша задача — разработать криптографический алгоритм.
Естественно, не поможет. К алгоритмическим задачам ООП имеет весьма слабое отношение. К криптографическим алгоритмам — в том числе. Но ты не учитываешь того, что IT-индустрия довольно таки сильно подвержена влиянию мифов и убеждений разных порядков. Вот ООП "разрослось" и пролезло во все щели как раз по тем соображениям, о которых я тебе сказал. Можешь мне не верить, твоё право, но именно так дела и обстояли.
ГВ>>Ну, Грэхем в своём репертуаре. Только нужно, как бы, это... Разделять призывы и "идеологемы", и технически реализуемые штучки. Корни паттернов на самом деле в особенностях мышления человека вообще и технических специалистов в частности. Они выходят очень далеко за пределы языков программирования. Pzz>Да. Когда моя мама работала конструктором, это называлось "типовой проект". Теперь вот паттерны придумали, чтобы умнее казаться
Аналогия довольно поверхностная, надо сказать. Типовой проект содержит уже просчитанные элементы конструкций, с паттернами немного не так. То есть паттерны — это не завершённые конструкции. Скорее, это просто графы, своего рода наброски структур.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Константин Л., Вы писали:
КЛ>может быть после того, как поучаствуешь, будешь говорить про мальчиков-архитекторов?
У тебя есть разум, надо только научиться им пользоваться. Почему все приходится разжевывать? Понимаешь, нет в этом моем высказывании ничего уничижительного. Я просто хотел сказать, что бывают разные задачи по самой сути. Для меня — это придумать алгоритм и отдать его "мальчикам-архитекторам" и прочим. И меня не интересует размер проекта, это их забота (про разделение труда слышал?) Поэтому, можно сказать, что я и не участвую в этом проекте. При этом архитекторы могут считать меня неким мальчиком-алгоритмистом и в этом тоже нет ничего уничижительного.
Бывали и казусы. Однажды архитекторы так запроектировали некий модуль обработки данных, что он требовал квадратичного времени выполнения как ты ни кодируй (а надо и можно было обойтись линейным.) В результате, по самым оптимистичным прогнозам, данная архитектура на реальных объемах данных требовала бы не меньше 500 лет для обработки. Зато все было очень красиво.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Вопрос к головастому товарищу, много ли он на ваяет современных многоэтажных домов если ему дать один топор? VD>Как ни одного? А тогда к чему вся эта пышная демагогия?
Вопрос к другому головастому товарищу — сколько комплексов в Кижах ему удастся сделать с помощью крупнопанельных блоков ?
Здравствуйте, prVovik, Вы писали:
V>Испугал. Пишем для одной этой системы SAX трансформатор. Делов то
Ага. Только придется всю архитектуру перетряхивать
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
Pzz>Я имел ввиду, что поскольку знания, в которые вы вкладываетесь, в основном состоят из перечня интерфейсов той технологии, которую вы сейчас считаете современной, то они по природе своей полностью устаревают за несколько лет, и вам приходится переучиваться. В 50 лет это будет сделать значительно сложнее. В том числе и по организационным причинам: никто не возьмет 50-летнего дядьку "на вырост", лучше возьмут студента.
Очень сильное утверждение. А какие знания вы считаете несводимыми к перечню интерфейсов технологии?
Я вот регулярно спорю в этих же форумах со "старой гвардией", которая делает аналогичные высказывания. А потом выясняется, что для этой гвардии интерфейс строки — это ровно ASCIIZ. И человек, гордящийся умением написать по памяти поиск бойер-мура, совершенно не в состоянии написать эффективный алгоритм конкатенации строк, потому что в его ментальной модели не у всех строк есть длина. Я понятно объясняю?
Или, к примеру, совершенно невозможно объяснить такому человеку, что сравнение двух строк не сводится к сравнению байт, потому что есть суррогаты, есть нормализация, есть case sensitivity, есть accent sensitivity, и что пунктуация должна сравниваться с другим приоритетом, чем alphanumeric.
Тем не менее, такой человек считает себя безмерно круче окружающих и позволяет себе смеяться над людьми, которые выучили только интерфейс к string.Compare().
Тем не менее, с точки зрения, скажем, менеджера, эти наивные молодые люди куда полезнее старой гвардии: они, по крайней мере, могут правильно сравнить строки, когда нужно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, McSeem2, Вы писали: MS>Это вряд ли. Насколько мне известно, премия Нобеля не распространяется на математические области. Но это чисто так, придирка.
Для придирчивых есть премия Тьюринга.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали:
IT>За 30 лет развития традиционных языков программирования (Fortran, PL/1, COBOL, Pascal, C/C++, Java, C#) принципиально изменился только мир вокруг метода. Мы получили наследование, инкапсуляцию и полиморфизм, компонентность и контрактность, шаблоны/дженерики и атрибуты, массу паттернов проектирования, подходов и отходов, методологий и прочих вещей, призванных организовать код в нечто более менее управляемое.
Ничего мы не получили. Все вышесказанное относится к организации кода и только. А сам код каким был, таким и остался. И если не согласен — напиши, пожалуйста, какой-либо более или менее серьезный алгоритм иным способом. Ну, к примеру, ту же сортировку, хоть быструю, хоть пузырьковую. Сам напиши, а не метод вызови.. Тут как-то сразу забываешь про инкапсуляцию с полиморфизмом и про все паттерны, потому что надо код писать, а не организовать. Алгоритм реализовать то есть.
А вот роль организации кода резко повысилась по сравнению с фортрановскими временами, да. Но это не столько с новыми приемами связано, сколько с характером задач. В значительной степени нынешний код — код без алгоритма . Это не реализация какого-то алгоритма, заложенного в задачу, а набор обработчиков разных событий. Программу для обработки битовых карт не превратишь в программу для обработки текста, алгоритмы тут совсем разные. А программа типа — ввести данные с формы — записать в БД практически индифферентна к тому, что вводить с формы и что писать в БД. Отсюда и все эти паттерны, фреймворки, библиотеки и т.д.
IT>Что же изменилось внутри метода? Да почти ничего. Как и 30 лет назад мы имеем if/else/switch, несколько циклов, команды выхода из цикла и метода, операции, присваивание и ещё немного по мелочёвке.
А не возникала ли у тебя мысль — а может, ничего и не надо ? Базовые конструкции потому и называются базовыми, что они , во-первых, не упрощаются, а во-вторых, их набор минимален и не всякое туда пустят, просто для того, чтобы не нарушать стройность и логику — иными словами, по принципу бритвы Оккама. Это как аксиомы Евклида — за 2000 лет никаких новых аксиом туда не добавили и не добавят . И три классические формы — следование, выбор, повторение — так и остались, и четвертому Риму похоже, не бывать
Здравствуйте, russian_bear, Вы писали: _>Пример хороший и я согласен — преимущества у LINQ очевидные, но опять же есть одно но. Если исходные данные будут браться из базы данных, то надо очень четко следить, чтобы вот такой вот наворот: _>не наворотил тучу запросов к базе данных вместо одного/нескольких. Серъезно? Ну-ка, ну-ка, и как же нужно модифицировать этот запрос, чтобы он наворотил тучу SQL запросов? Хочется подтвердить эту небезынтересную гипотезу реальным ахтунг-примером.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>За 30 лет развития традиционных языков программирования (Fortran, PL/1, COBOL, Pascal, C/C++, Java, C#) принципиально изменился только мир вокруг метода. Мы получили наследование, инкапсуляцию и полиморфизм, компонентность и контрактность, шаблоны/дженерики и атрибуты, массу паттернов проектирования, подходов и отходов, методологий и прочих вещей, призванных организовать код в нечто более менее управляемое.
PD>Ничего мы не получили. Все вышесказанное относится к организации кода и только. А сам код каким был, таким и остался. И если не согласен — напиши, пожалуйста, какой-либо более или менее серьезный алгоритм иным способом. Ну, к примеру, ту же сортировку, хоть быструю, хоть пузырьковую. Сам напиши, а не метод вызови.. Тут как-то сразу забываешь про инкапсуляцию с полиморфизмом и про все паттерны, потому что надо код писать, а не организовать. Алгоритм реализовать то есть.
PD>А вот роль организации кода резко повысилась по сравнению с фортрановскими временами, да.
Знаешь что ты только что сказал? Примерно следующее:
(я) — я думаю, что 2 * 2 = 4
(ты) — нифига ты, мужик, не понимаешь. 2 * 2 — ЭТО ЧЕТЫРЕ!!!!! Запомни, будешь знать!
IT>>Что же изменилось внутри метода? Да почти ничего. Как и 30 лет назад мы имеем if/else/switch, несколько циклов, команды выхода из цикла и метода, операции, присваивание и ещё немного по мелочёвке.
PD>А не возникала ли у тебя мысль — а может, ничего и не надо ? Базовые конструкции потому и называются базовыми, что они , во-первых, не упрощаются, а во-вторых, их набор минимален и не всякое туда пустят, просто для того, чтобы не нарушать стройность и логику — иными словами, по принципу бритвы Оккама. Это как аксиомы Евклида — за 2000 лет никаких новых аксиом туда не добавили и не добавят . И три классические формы — следование, выбор, повторение — так и остались, и четвертому Риму похоже, не бывать
Даже не хочется на это отвечать. Знаешь, если всё же открыть дверь, то мир может оказаться совсем не таким, каким он видится через замочную скважину.
Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее.
Здравствуйте, IT, Вы писали:
IT>Знаешь что ты только что сказал? Примерно следующее:
IT>(я) — я думаю, что 2 * 2 = 4 IT>(ты) — нифига ты, мужик, не понимаешь. 2 * 2 — ЭТО ЧЕТЫРЕ!!!!! Запомни, будешь знать!
Что-то чересчур много экспрессии и мало смысла.
IT>Даже не хочется на это отвечать. Знаешь, если всё же открыть дверь, то мир может оказаться совсем не таким, каким он видится через замочную скважину.
Ну и не отвечал бы.
IT>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее.
IT>1. http://www.rsdn.ru/forum/message/2102148.aspx
Все же, если не сложно, сделай, пожалуйста, в разы проще, понятнее и эффективнее сортировку — любую. Или, скажем, какой-нибудь графический фильтр. Или создание и управление неким сложно организованным файлом на диске. Или математический алгоритм — матричную алгебру, к примеру. Или что угодно еще, но только не использование классов, а написание методов класса с нуля, и при этом желательно ну хоть на порядок сложнее вычисления процентов Вот тогда и поговорим. А пока в качестве аргумента приводится вычисление процентов — говорить не о чем, потому как меня совсем не интересует, как сделать вычисление их в разы проще, понятнее и эффективнее.
Только нужно, как бы, это... Разделять призывы и "идеологемы", и технически реализуемые штучки. Корни паттернов на самом деле в особенностях мышления человека вообще и технических специалистов в частности. Они выходят очень далеко за пределы языков программирования.
Если нам не помогут, то мы тоже никого не пощадим.
