Здравствуйте, netch80, Вы писали:
N>Ну вот, вы, наверняка, и фразу "The God is real..." не продолжите
Нет не продолжу
FR>>Угу сами себе придумал 20 ФВП и сами себе отвечаем не надо?
N>Хотел бы я, чтобы это оказалось только своей придумкой... да вот увы — практика.
Угу бытие определяет сознание
А сама практика такая потому-что ничего кромее ООП ты не видишь и не хочешь видеть.
FR>>Случаи когда имено нужно тупо сгрупировать кучу функций практически никогда на практике не встречаются, обычно все разбивается и групируется в осмысленные вещи.
N>Вот я и группирую в подклассы.
Здравствуйте, FR, Вы писали:
N>>Ну вот, вы, наверняка, и фразу "The God is real..." не продолжите :) FR>Нет не продолжу :???:
И после этого комментируете Фортран. Понятно, "не читал, но осуждаю".
FR>>>Угу сами себе придумал 20 ФВП и сами себе отвечаем не надо? N>>Хотел бы я, чтобы это оказалось только своей придумкой... да вот увы — практика. FR>Угу бытие определяет сознание :) FR>А сама практика такая потому-что ничего кромее ООП ты не видишь и не хочешь видеть.
В данном случае практика иная: а именно, Вы не хотите видеть ничего кроме ФП. Вы уже который постинг подряд только и делаете, что агитируете "за советскую власть" совершенно не представляя себе специфики задач, ограничений механизма, придумываете любые фишки лишь бы доказать одно — "ФП рулез, всё остальное сакс". Вы наобум приписываете собеседникам чужие свойства (как мне что "кромее ООП ты не видишь и не хочешь видеть" — это мне-то, который до массового распространения ООП уже лет 7 был "в системе" и успел писать на всём что только тогда было), не дав себе даже минимального труда проанализировать адекватность своих "назначений".
Я с Вами не хочу больше спорить. Когда Вы научитесь вести действительно дискуссию, а не выливать потоки религиозного гона — возвращайтесь, поговорим.
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>>Так и для организации кода достаточно одних структур и методов. Зачем ООП придумали и кучу других паттернов? Непонятно :xz: Pzz>>ООП придумали для того, чтобы можно было структуруровать программу в терминах довольно больших блоков. Это нужно, в первую очередь, в связи с индустриальными методами разработки, когда над одной программой работают 50 индусов, и надо как-то провести границы, чтобы они не наступали друг другу на пятки. ГВ>Цирк. Для тех кто в это верит, поясню: привлекать неквалифицированных пользователей к формализации задачи — хорошо, привлекать неквалифицированных программистов (именно их ты имеешь в виду, говоря об индусах, правда?) — очень плохо.
Я что-то не смог найти в постинге Певзнера стремления привлечь индусов к _формализации_ задачи. Где Вы это вычитали?
Pzz>>Т.е., в первую очередь ООП — это инструмент для менеджера проекта, а не для программиста. ГВ>Вообще-то ООП зародилось из фреймов-слотов, это такой ма-а-а-алепусенький кусочек инструментария ИИ по формализации знаний. Менеджеры софтостроения там если и стояли рядом, то только стояли.
А при чём тут, откуда оно зародилось? Современная практика совсем иная, и от тех времён, когда оно рождалось — несколько крупных логических переходов (например, насколько ООП формата Simula & Smalltalk отличается от того, что из него сделали даже в Objective C, я уж не говорю про развития C и Паскаля). Фактически, разделение объектов — то, что позднее назвали "контрактным программированием", с ограничением тем, что "контракт" проводится по границе объекта ("пуля вылетает — проблемы не на моей стороне").
Другой вопрос, что такое разделение нормально возможно только при статичных спецификациях. Если они меняются — приходится пересматривать места проведения границ. А вот тут уже начинаются нюансы.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, netch80, Вы писали:
N>>А описанные Вами знания "есть такое, а есть сякое" без подкрепления забудутся после первого экзамена. N>>Поэтому я с сомнением отношусь к тем архитекторам, которые давно сами не кодируют, и к тем кодерам, которые способны только применить указанное им решение. _FR>Вот пример из личной жизни: пока писал на VB, приходилось вручную реализовывать бинарный поиск (ну нет его в стандартной библиотеке), и с обобщением написанного кода нет так всё просто в этом языке. Так вот несколько лет уже пишу на C# и, наверное, не вспомню, как его реализовать.
В данном случае я не имел в виду конкретику. Но если — по Вашему же примеру — он веб-программист (кстати, какой именно? это очень обширный класс ролей) — то должен иметь свои, специфические базовые знания.
N>>У меня лично статистики недостаточно. Но вот случай, когда обычная сортировка крайне невыгодна — каждый рабочий день на глазах, это таймерное дерево в движке событий. Оно сделано на пирамиде. _FR>В отдельных случаях может быть (и даже имеет право быть) всё что угодно. Но вот спрашивать веб-програмиста про объекты синхронизации на юниксе — гхм..?
Ну а почему нет? Какой это веб-программист? Может, он программирует какую-то CMS, в которой хранится содержимое сайта (пардон, надо говорить "портала":)) и проблемы с модификацией данных ему очень даже существенны. Не надо зарекаться, случай всякий бывает...
_FR> Вот я и говорю, что "база" у програмистов в общем смысле не в алгоритмах сортировки и прочих деталях реализации.
База всегда в своих деталях реализации, и от этого не деться.
Здравствуйте, _FRED_, Вы писали:
_FR>>>и факториал как пример рекурсии T>>Убивать за такие примеры рекурсии. _FR>За что? Только за то, что "навязло" в зубах?
За методическую некорректность. Показывание рекурсии на примере факториала, при том, что рядом он считается просто и тривиально обычным циклом — это способ показать "а вот можно ещё через левое ухо, если очень захотеть и совсем нечего делать". Этот способ годится по отношению к тем, кто интересуется математическими диковинками, или к тем, кто заранее _сознательно_ готов принимать все методические принципы преподавателя. И много Вы таких сейчас видели? обычно 1-2 на сотню. остальные — сдадут и забудут.
Если бы я показывал рекурсию на каком-то примере, первый пример был бы взят максимально практический, причём такой, чтобы его нельзя было в одной функции свести в цикл. А уже после этого — числа Фибоначчи, а собственно факториал — уже в качестве упражнения (если на лекции — вызвать кого-то к доске и заставить преобразовать).
И ещё одно — размахивание факториалом является косвенным указанием на то, что "рекурсия — это очень просто". Когда же выучивший такое сталкивается с реальной жизнью, когда перекладка алгоритма на рекурсивный лад в первую очередь крайне громоздка — следует шок.
Здравствуйте, netch80, Вы писали:
N>И после этого комментируете Фортран. Понятно, "не читал, но осуждаю".
Я не комментировал фортран, просто привел известную поговорку, там фортран можно например заменить
бейсиком и суть от этого не изменится.
FR>>А сама практика такая потому-что ничего кромее ООП ты не видишь и не хочешь видеть.
N>В данном случае практика иная: а именно, Вы не хотите видеть ничего кроме ФП. Вы уже который постинг подряд только и делаете, что агитируете "за советскую власть" совершенно не представляя себе специфики задач, ограничений механизма, придумываете любые фишки лишь бы доказать одно — "ФП рулез, всё остальное сакс". Вы наобум приписываете собеседникам чужие свойства (как мне что "кромее ООП ты не видишь и не хочешь видеть" — это мне-то, который до массового распространения ООП уже лет 7 был "в системе" и успел писать на всём что только тогда было), не дав себе даже минимального труда проанализировать адекватность своих "назначений".
Ужас меня уже записали в злобные функциональщики
Однако если вернутся к теме к локальному коду, то преимущества ФП и сопутствующего ему сахара может не видеть только слепой.
Если хочешь померятся то лучше покажи небольшой законченный кусочек кода который по твоему продемонстрирует неоспоримые преимущества наследования для задачи специализации алгоритмов, я же перепишу его в ФП стиле и сравним.
N>Я с Вами не хочу больше спорить. Когда Вы научитесь вести действительно дискуссию, а не выливать потоки религиозного гона — возвращайтесь, поговорим.
Здравствуйте, FR, Вы писали:
N>>И после этого комментируете Фортран. Понятно, "не читал, но осуждаю". FR>Я не комментировал фортран, просто привел известную поговорку, там фортран можно например заменить FR>бейсиком и суть от этого не изменится.
Изменится.
FR>Ужас меня уже записали в злобные функциональщики :)))
Как себя ведёте — туда и записываем.
FR>Однако если вернутся к теме к локальному коду, то преимущества ФП и сопутствующего ему сахара может не видеть только слепой.
Вот именно — злобный функциональщик и есть, сами согласились.
FR>Если хочешь померятся то лучше покажи небольшой законченный кусочек кода который по твоему продемонстрирует неоспоримые преимущества наследования для задачи специализации алгоритмов, я же перепишу его в ФП стиле и сравним.
На "небольшом законченном" и я одной левой смогу. Это не реальная задача.
N>>Я с Вами не хочу больше спорить. Когда Вы научитесь вести действительно дискуссию, а не выливать потоки религиозного гона — возвращайтесь, поговорим. FR>У кого трава круче еще спорно.
Я в этом заранее сдаюсь, потому что обхожусь без травы. Играйте сами.
Нет.
"писать на бейсике можно используя любой язык."
Суть же в том что недостаточно выучить синтаксис языка программирования чтобы научится на нем нормально писать.
FR>>Ужас меня уже записали в злобные функциональщики
N>Как себя ведёте — туда и записываем.
Это ты просто не видел как себя ведут настоящие злобные функциональщики
FR>>Однако если вернутся к теме к локальному коду, то преимущества ФП и сопутствующего ему сахара может не видеть только слепой.
N>Вот именно — злобный функциональщик и есть, сами согласились.
Нет и стиль и суть совсем не соответствуют
FR>>Если хочешь померятся то лучше покажи небольшой законченный кусочек кода который по твоему продемонстрирует неоспоримые преимущества наследования для задачи специализации алгоритмов, я же перепишу его в ФП стиле и сравним.
N>На "небольшом законченном" и я одной левой смогу. Это не реальная задача.
Так в топике же обсуждается именно локальный код, он по определению небольшой и соответственно совершено нетрудно привести вполне практичный примерчик.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Константин Л., Вы писали:
КЛ>>самый большой проект, в котором ты когда-либо участвовал?
MS>Я не участвую в так называемых "больших проектах", мне это не интересно.
может быть после того, как поучаствуешь, будешь говорить про мальчиков-архитекторов?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Константин Л., Вы писали:
КЛ>>самый большой проект, в котором ты когда-либо участвовал?
IT>WPF для тебя большой проект, а WinForms? Так вот, если бы там не было наследования реализации, то жизнь у прикладников была бы немного веселей.
Ну для начала McSeem2 надо было уточнить какое наследование он имеет ввиду. Да и потом, наследование реализации не самое последнее зло.
Здравствуйте, netch80, Вы писали:
N>Я что-то не смог найти в постинге Певзнера стремления привлечь индусов к _формализации_ задачи. Где Вы это вычитали?
Я имел в виду, конечно, привлечение неквалифицированных программистов к реализации, а не к формализации. Спасибо, что заметил неточность.
Pzz>>>Т.е., в первую очередь ООП — это инструмент для менеджера проекта, а не для программиста. ГВ>>Вообще-то ООП зародилось из фреймов-слотов, это такой ма-а-а-алепусенький кусочек инструментария ИИ по формализации знаний. Менеджеры софтостроения там если и стояли рядом, то только стояли.
N>А при чём тут, откуда оно зародилось?
Откуда зародилось, свойства того органично и унаследовало. Но это ни в коем случае не инструмент менеджера. Инструмент менеджера — это нормативная база, ресурсы, деньги, планы, организационные подходы... А не ООП.
N>Современная практика совсем иная, и от тех времён, когда оно рождалось — несколько крупных логических переходов (например, насколько ООП формата Simula & Smalltalk отличается от того, что из него сделали даже в Objective C, я уж не говорю про развития C и Паскаля).
Интересно, в чём же состоит крупный логический переход?
N>Фактически, разделение объектов — то, что позднее назвали "контрактным программированием", с ограничением тем, что "контракт" проводится по границе объекта ("пуля вылетает — проблемы не на моей стороне").
Ты путаешь объектную декомпозицию и спецификацию.
N>Другой вопрос, что такое разделение нормально возможно только при статичных спецификациях. Если они меняются — приходится пересматривать места проведения границ. А вот тут уже начинаются нюансы.
Что-то я не пойму — к чему ты это? Спецификации — это спецификации, объектная декомпозиция — это объектная декомпозиция. От того, что спецификация, например, будет комбинироваться в runtime ничего принципиально не меняется, кроме того, что исполняющая машина языка программирования будет подставлять не только реализацию, но ещё и спецификацию. Принципы те же, что и для абстрактных типов данных.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VoidEx, Вы писали:
VE>А сам вон сначала "программист должен уметь писать сортировку", а потом VE>"Если он при этом учится и ошибка замечена вовремя — то почему бы и нет?"
Здравствуйте, Геннадий Васильев, Вы писали:
N>>Я что-то не смог найти в постинге Певзнера стремления привлечь индусов к _формализации_ задачи. Где Вы это вычитали? ГВ>Я имел в виду, конечно, привлечение неквалифицированных программистов к реализации, а не к формализации. Спасибо, что заметил неточность.
Тогда понятно.
N>>А при чём тут, откуда оно зародилось? ГВ>Откуда зародилось, свойства того органично и унаследовало. Но это ни в коем случае не инструмент менеджера. Инструмент менеджера — это нормативная база, ресурсы, деньги, планы, организационные подходы... А не ООП. :)
Так это кроме прочего и организационный подход. Определим и формализуем, как именно связаны между собой работы разных групп и людей, и тем самым уменьшим затраты на взаимодействие при разработке. Разумеется, этот подход заметно некорректен, ну так не он же один используется...
N>>Фактически, разделение объектов — то, что позднее назвали "контрактным программированием", с ограничением тем, что "контракт" проводится по границе объекта ("пуля вылетает — проблемы не на моей стороне"). ГВ>Ты путаешь объектную декомпозицию и спецификацию.
Я не путаю, я упрощаю до уровня такого менеджера:) Спецификация взаимодействия (как при выполнении, так и разработке) является следствием декомпозиции. Это в принципе всё, что ему нужно, чтобы подход работал.
Здравствуйте, FR, Вы писали:
N>>Изменится. FR>Нет. FR>"писать на бейсике можно используя любой язык." FR>Суть же в том что недостаточно выучить синтаксис языка программирования чтобы научится на нем нормально писать.
Неее, батенька, это Вы историю с географией путаете.:))) Когда кто-то из классиков сказал "Фортран-программу можно написать на любом языке" — это был ёмкий целенаправленный образ определённого стиля, который у тогдашних поклонников "структурного программирования" ассоциировался чуть ли не с пришествием Антихриста (при том, что тогда, можно считать, было три языка программирования — Fortran, LISP и APL;) ну и где-то рядом Алгол-60 маячил на задворках). Стиль, в котором паутина из GOTO покрывала программу так плотно, что невозможно было логически выделить ни одну явную структурную последовательность; с неявным объявлением переменных и трудноуловимыми ошибками типа "P вместо R"; с адскими хаками через COMMON и EQUIVALENCE... Это кошмар, но это Стиль с большой буквы. Вот по нему и проезжались чем только могли те, кто твёрдо решил избавить человечество от этого Стиля.
Вы вот в курсе, почему космическая станция улетела куда не следует? Поясняю: строка
DO100I=1,10
в классическом Fortran является оператором цикла (по I от 1 до 10 до метки 100 включительно), а строка
DO 100 I=1. 10
является присваиванием переменной DO100I значения 1.1.
Я не шучу. Пробелы в нём были незначимы везде кроме первых 6 колонок и текстовых (холлеритовых! никаких вам апострофов) констант.
А Вы говорите, мол, "писать на бейсике можно используя любой язык"... Да всё это жалкое эпигонство. Оригинал был только один, и замены ему нет. А то так можно договориться и до того, что "писать на Haskell можно используя любой язык"... Да, можно. Написав на нём интерпретатор.;))
FR>>>Ужас меня уже записали в злобные функциональщики :))) N>>Как себя ведёте — туда и записываем. FR>Это ты просто не видел как себя ведут настоящие злобные функциональщики :)
Ну, честно говоря, вести себя в стиле Луговского тут не позволят. Но я принимаю это как конструктивное предложение к продолжению диалога. Надеюсь, в дальнейшем без завлеканий типа "пока не попробуешь — не поймёшь" :))
FR>>>Если хочешь померятся то лучше покажи небольшой законченный кусочек кода который по твоему продемонстрирует неоспоримые преимущества наследования для задачи специализации алгоритмов, я же перепишу его в ФП стиле и сравним. N>>На "небольшом законченном" и я одной левой смогу. Это не реальная задача. FR>Так в топике же обсуждается именно локальный код, он по определению небольшой и соответственно совершено нетрудно привести вполне практичный примерчик.
Я, вероятно, слишком ленивый чтобы грамотно разделить код на части, но вот функция построения дерева раутинга в объектном виде по его сжатому представлению заняла 360 строк (бОльшая часть из них — игра со взаимовлияниями значений атрибутов), а функция генерации звонка по рауту — 213 строк. И как-то разумно сжать это пока не получается (да, заранее согласен, что это у меня руки кривые и можно целенаправленно надробить кучу мелких частей — только зачем?)
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Цирк. Для тех кто в это верит, поясню: привлекать неквалифицированных пользователей к формализации задачи — хорошо, привлекать неквалифицированных программистов (именно их ты имеешь в виду, говоря об индусах, правда?) — очень плохо.
Их привлекают не к формализации, а к реализации. Хорошо ли это, плохо ли, но вот привлекают. Наверное потому, что свободных квалифицированных уже почти не осталось.
ГВ>Вообще-то ООП зародилось из фреймов-слотов, это такой ма-а-а-алепусенький кусочек инструментария ИИ по формализации знаний. Менеджеры софтостроения там если и стояли рядом, то только стояли.
Вообще-то ООП зародилось из Симулы, языка. предназначенного для компутерного моделирования. А в индустрию пришло и разрослось именно потому, что помогает раскидывать задачу по большому количеству исполнителей. Фича эта сама по себе очень ценная, но имеет отношение скорее к управлению проектом, чем собственно к программированию.
ГВ>Свежо предание... Только паттерн, это не "готовое решение", а некое собирательное название разных по существу решений. Хотя примеры могут быть и вполне определёнными. А каким же им ещё быть?!
Это, признаюсь, не моя мысль, а Пола Грэхема. В оригинале она звучала примерно в том духе, что наличие паттернов проектирования свидетельствует об отсутствии в языке нормальных макросов. Потому что если приходится из проекта в проект делать похожие телодвижения, это повод написать макрос, который эти телодвижения автоматизирует.
Я, в общем, отчасти согласен, но с той оговоркой, что некоторые вещи очень просто рассказать человеку, но при этом очень трудно формализовать до такой степени, чтобы их можно было сказать компьютеру.
Pzz>>А вот внутри самих алгоритмов if'ы и while'ы — вполне себе адекватный инструмент. Во всяком случае, все классические алгоритмы описаны в литературе именно в этих терминах.
ГВ>Это не просто "адекватный инструмент", if — это блин, базисная конструкция императивного стиля. Ну, вернее, не if, а goto. if — это уже структурный подход. Уж куда "адекватнее"!
Я как-то не уловил, почему базисная конструкция императивного стиля не может быть адекватным инструментом? Какое слово является ругательным, "базисная" или "императивного"?
Здравствуйте, eao197, Вы писали:
E>PS. В начале 90-х в Союзе у многих крышу срывало Прологом. С тех пор я думал, что именно Пролог самая крутая трава. Но, видимо, FP еще круче.
Пролог трава более крутая, но к сожалению плохо совместимая с жизнью, так как создать эффективные реализации практически невозможно, и с императивными языками не стыкуется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, netch80, Вы писали:
N>>>Какой ответ на этот вопрос Вы хотите? Можно ответить цинически — мол, есть клавишное мясо, которое не способно даже осознать, что оно теряет и почему. А можно — что пусть себе и дальше продолжает, но пусть осознаёт, где его потолок. В принципе, оба ответа правильны.
S>>У меня один знакомый считает, что тот не программист, кто не написал ни одного драйвера устройства. S>>Весьма ограниченная точка зрения, как впрочем и Ваша.
N>Вы ещё ничего не поняли толком про мою точку зрения, но уже успели приравнять её к "одному знакомому" и унизить сравнением.
netch80! Приношу извинения за сравнение Вашей точки зрения с мнением моего недалекого знакомого. Наблюдая за Вашими постами неоднократно убедился, что Вы человек опытный и очень разносторонний. После этого я переосмыслил высказывание про мясо и потолок. Мое несогласие с ним было обусловлено разницей восприятия термина мяса и уровня потолка.
Здравствуйте, AndrewVK, Вы писали:
AF>>Мне очень интересно послушать, какие в ней есть реальные проблемы.
AVK>А мне уже нет. Я уже мильен раз об этом говорил, и поднимать старый флейм нет никакого желания.
Раз миллион, то не составит труда найти ссылку хоть на одно внятное объяснение?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
