Здравствуйте, samius, Вы писали:

Pzz>>Сочинению или изложению, не важно. Допустим, написание одной сортировки эквиавалентно одному изложению. Тогда ненаписание ни одной сортировки эквиавалентно ненаписанию ни одного изложения, не так ли? Логика, однако...
S>С этой фразой я могу согласиться только, если слово "сортировка" здесь употреблено в фигуральном смысле. Потому как если человек что-то писал кроме сортировки в буквальном смысле, то это не эквивалентно ненаписанию ни одного изложения.

Я согласен заменить слово "сортировка" словосочетанием "классические алгоритмы". Квиксорт и бинарное дерево к ним относится, SQL-запрос на 3 экрана текста — нет.

Pzz>>Я немного передергиваю, но не очень сильно. Замените слово "сортировка" словом "классический алгоритм". Просто так уж повелось, что сортировки оказываются первыми в списке кандидатов, наряду с поисками. Ну не на алгоритмах же IP-роутинга учить программированию, в самом деле
S>В школе — может быть и с сортировки. Лично меня в ВУЗе учили на численных методах, уравнениях матфизики, методах дискретной оптимизации. После ВУЗ-а еще много чего было.

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

S>Вы думаете, что я облажаюсь с пузырьком?

А на квиксорте не облажаетесь?

Здравствуйте, fplab, Вы писали:

F>Опуская всю пургу, что все мы — и я не исключение — по мере сил наваяли (видимо, пятница, финансовый кризис и прочая, прочая, прочая) я всего лишь скромно хотел обратить ваше внимание, что использование (простите!) слова "пени%%%%%рия" — это и есть некорректный прием :)

Я знаю, что пребывание в Fido наносит необратимый отпечаток (это я про себя;)), но для меня это просто стандартный мем, давно потерявший свой буквальный смысл. Думаю, употребивший его собеседник понимает точно так же.

F> Просматривая топик я не заметил, чтобы кто-то еще из уважаемых участников, не смотря на раздирающие душу эмоции, скатывался до гениталий :xz:

Вы "гуртовщиков мыши" почитайте:) Там есть гениталии на гусеничном ходу:)

Здравствуйте, IT, Вы писали:

IT>Я сразу начну писать код прямо в методе Main и только когда почувствую дискомфорт, озабочусь иерархией классов.

Слушай, Игорь, но почему именно "озабочусь иерархией классов"? Что, без наследования в современном мире не прожить? Лично я считаю парадигму наследования самым противоестественным самодурством какого-то одного горе-теоретика, типа авторитета, которому удалось запудрить мозги всем и надолго. Я это уже говорил что инкапсуляция и полиморфизм — 256 раз да! Наследованию — отказать. Парадигма наследования в программировании компьютеров — это пожалуй второй по величине фуфлоид.

IT>Делать это сразу я не стану, т.к. считаю это бесполезной тратой времени, потому что не знаю, что меня ждёт впереди.

Согласен! Лично для меня первична алгортмическая сущность — на уровне получится или нет и что можно выжать из этого именно на алгортмическом уровне. Это для меня — самая сложная и самая интересная часть задачи. А уж обернуть в классы и иерархии, плюс кодовая оптимизация — это рутина, этим пусть мальчики-архитекторы и мальчики-кодеры занимаются. Я всегда готов их проконсультировать и объяснить сущность алгоритма.

Здравствуйте, IT, Вы писали:

IT>Предлагай. Насколько мне известно, на сегодняшний день всё уже придумано, но не всё пока реализовано в мэйнстриме. Если ты придумаешь что-то новое, что будет круче всего, что уже есть, то Нобелевская премия тебе гарантирована.

Это вряд ли. Насколько мне известно, премия Нобеля не распространяется на математические области. Но это чисто так, придирка.

Здравствуйте, IT, Вы писали:

IT>Давай попробуем сделать так. Представим, что ФП и ООП это не целые парадигмы, а просто набор паттернов. Ну там ООП — это инкапсуляция, наследование и полиморфизм, а ФП даже лень перечислять. Так вот теперь ответь на вопрос, какие из этих паттернов между собой несовместимы.

Угу совместимы тот же Ocaml да и величайший из языков на букву N это демонстрируют. Но совместимы только на том уровне который ты сейчас рекламируешь, а вот если идти выше то уже нет, притом скорее и не отрицают и не дополняют друг — друга а просто совершено различны.

Здравствуйте, Pzz, Вы писали:

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

Вы флеймер? Не надо нам приписывать слова, которых никто не говорил.
И таки ответьте на моё сообщение, ссылку на которое я давал 2 раза.

Здравствуйте, AndrewVK, Вы писали:

_>>Все то, что входит в библиотеки. Как пример библиотеки — .NET Framework. Внутри как и всегда логика.

AVK>То есть внутри методов будут только вызовы методов фреймворка и больше никаких синтаксических конструкций, так?

Если писать на Smalltalk без проблем

Здравствуйте, McSeem2, Вы писали:

MS>Слушай, Игорь, но почему именно "озабочусь иерархией классов"? Что, без наследования в современном мире не прожить?

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

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

MS>Парадигма наследования в программировании компьютеров — это пожалуй второй по величине фуфлоид.

А первый какой?

Здравствуйте, FR, Вы писали:

FR>Угу совместимы тот же Ocaml да и величайший из языков на букву N это демонстрируют. Но совместимы только на том уровне который ты сейчас рекламируешь, а вот если идти выше то уже нет, притом скорее и не отрицают и не дополняют друг — друга а просто совершено различны.

Уровень выше это для тех кто всосал FP с молоком матери, а особо продвинутым оно передалось вообще по трубочке ещё в чреве. Я к ним, к счастью, не отношусь.

Здравствуйте, D. Mon, Вы писали:

DM>Например, у меня есть несколько алгоритмов компенсации движения, отличающиеся лишь способом поиска похожего блока. Наследование позволило обойтись без дублирования кода, лишних if'ов и указателей на функции (которые, по сути, изоморфны VMT).

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

Здравствуйте, IT, Вы писали:

IT>Уровень выше это для тех кто всосал FP с молоком матери, а особо продвинутым оно передалось вообще по трубочке ещё в чреве. Я к ним, к счастью, не отношусь.

Достаточно чтобы ООП не был впитан с молоком матери или еще раньше
Я как раз и отношусь к таким (большое влияние форта на неокрепший еще мозг ).

Попробую продемонстировать на простом надуманном примере. Допустим у нас есть некоторая коллекция, которая отличается только способом сортировки.

Насколько я понял, проблему ты решаешь таким ООПшным способом:

    abstract class MyBaseCollection<T>
    {
        protected List<T> collection = new List<T>();

        public void Insert(T item)
        {
            collection.Add(item);
        }

        public abstract void Sort();
    }

    class MyConcreteCollection<T> : MyBaseCollection<T>
    {
        public override void Sort()
        {
            collection.Sort();
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            MyBaseCollection<int> coll = new MyConcreteCollection<int>();
            coll.Insert(3);
            coll.Insert(2);
            coll.Insert(1);

            coll.Sort();
        }
    }

Теперь попробуем ее решить в стиле ФП:

    class MyCollection<T>
    {
        List<T> collection = new List<T>();

        public void Insert(T item)
        {
            collection.Add(item);
        }

        public void Sort(Func<List<T>, List<T>> sortFunc)
        {
            collection = sortFunc(collection);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            MyCollection<int> coll = new MyCollection<int>();
            coll.Insert(3);
            coll.Insert(2);
            coll.Insert(1);

            coll.Sort(l => { l.Sort(); return l; });
        }
    }

Правда чем то STL напоминает?
Я думаю плюсы минусы обоих подходов проанализировать не сложно самому.

Здравствуйте, yumi, Вы писали:

Y>Правда чем то STL напоминает?
Y>Я думаю плюсы минусы обоих подходов проанализировать не сложно самому.

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

Здравствуйте, D. Mon, Вы писали:

DM>Например, у меня есть несколько алгоритмов компенсации движения, отличающиеся лишь способом поиска похожего блока. Наследование позволило обойтись без дублирования кода, лишних if'ов и указателей на функции (которые, по сути, изоморфны VMT).

Ну я уже говорил где-то. Это классический пример полиморфного поведения — перегрузка виртуальных функций. Это нормально, но это не наследование, это, дети, называется специализация. Что не нормально, так это расширение функциональности. А особенным идиотизмом является наследование от классов типа std::string или std::vector.

MS>>Парадигма наследования в программировании компьютеров — это пожалуй второй по величине фуфлоид.

DM>А первый какой?

Первенство по идиотизму до сих пор устойчиво держит фуфлоид под названием Венгерская Нотация.

Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, D. Mon, Вы писали:

DM>>Например, у меня есть несколько алгоритмов компенсации движения, отличающиеся лишь способом поиска похожего блока. Наследование позволило обойтись без дублирования кода, лишних if'ов и указателей на функции (которые, по сути, изоморфны VMT).

Y>Если я правильно тебя понял, то нужно было написать один generic алгоритм компенсации движения, и в него при создании конкретного экземпяра передавать функцию поиска похожего блока.

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

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

Здравствуйте, netch80, Вы писали:

N>А на практике окажется, что из ~100 методов отличаются у потомков 20, и этого достаточно, чтобы действие "передать функцию поиска похожего блока" вылилось в извращение типа "передать структуру функций, специфичных именно для этой реализации". И всё это с костылями вроде приведения типов.

Если на практике ~100 методов, то эту практику нужно прекращать немедленно
А костыли эти появляются из-за того, что языки не поддерживают higher-order functions & functions as first class objects. Вы кажется про С++, да, он этого не поддерживает, придется обходиться функторами, а это действительно костыли. А в C# 3 уже есть некоторая поддержка ФП и этих костылей не будет, не говоря уже о более развитых языках.

N>Нет, конечно, использовать такое порой можно и нужно. Но в общую практику я бы рекомендовал наследование. Конечно, у него есть свои проблемы (вспомним множественное наследование и его эффекты). Но это проблема любого подобного механизма — можно загнать в ситуацию, когда перестанет работать.

Наследование реализации сама по себе одна большая проблема.

Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, netch80, Вы писали:

N>>А на практике окажется, что из ~100 методов отличаются у потомков 20, и этого достаточно, чтобы действие "передать функцию поиска похожего блока" вылилось в извращение типа "передать структуру функций, специфичных именно для этой реализации". И всё это с костылями вроде приведения типов.

Y>Если на практике ~100 методов, то эту практику нужно прекращать немедленно :)

А давайте Вы немедленно прекратите:)) практику рассказывать подобные вещи тому, кто последние 4 года плотно писал на Питоне и разнообразными лямбдами, встроенными def'ами и list comprehensions пользуется куда лучше, чем STL'ем и прочими крестатостями.

Я пользуюсь разными средствами. И first class functions. И duck typing. И наследованием. Всему своё место, и у наследования — своё, заметное и положительное.

Y>А костыли эти появляются из-за того, что языки не поддерживают higher-order functions & functions as first class objects. Вы кажется про С++, да, он этого не поддерживает, придется обходиться функторами, а это действительно костыли. А в C# 3 уже есть некоторая поддержка ФП и этих костылей не будет, не говоря уже о более развитых языках.

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

N>>Нет, конечно, использовать такое порой можно и нужно. Но в общую практику я бы рекомендовал наследование. Конечно, у него есть свои проблемы (вспомним множественное наследование и его эффекты). Но это проблема любого подобного механизма — можно загнать в ситуацию, когда перестанет работать.
Y>Наследование реализации сама по себе одна большая проблема.

Нет, не проблема. Если не относиться к ней как к панацее.

Здравствуйте, netch80, Вы писали:

N>Я пользуюсь разными средствами. И first class functions. И duck typing. И наследованием. Всему своё место, и у наследования — своё, заметное и положительное.

Ну может расскажете где место наследованию?

Y>>А костыли эти появляются из-за того, что языки не поддерживают higher-order functions & functions as first class objects. Вы кажется про С++, да, он этого не поддерживает, придется обходиться функторами, а это действительно костыли. А в C# 3 уже есть некоторая поддержка ФП и этих костылей не будет, не говоря уже о более развитых языках.

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

Верить я тебе на слово не буду, извини. Я незнаю как там в вашем Питоне, может там и действительно хреново получается делать функциональную декомпозицию, а вот по крайней мере в Хаскеле (и Лиспе тоже) это делается очень естесственно.

Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, netch80, Вы писали:

N>>Я пользуюсь разными средствами. И first class functions. И duck typing. И наследованием. Всему своё место, и у наследования — своё, заметное и положительное.

Y>Ну может расскажете где место наследованию?

Там, где у множества возможных реализаций общие черты, удобно реализуемые общим кодом.

Y>:)) Верить я тебе на слово не буду, извини. Я незнаю как там в вашем Питоне, может там и действительно хреново получается делать функциональную декомпозицию, а вот по крайней мере в Хаскеле (и Лиспе тоже) это делается очень естесственно.

Приведите пример. А я посмотрю, насколько он реален, а насколько — сферический в вакууме.

Здравствуйте, yumi, Вы писали:

Y> Верить я тебе на слово не буду, извини. Я незнаю как там в вашем Питоне, может там и действительно хреново получается делать функциональную декомпозицию, а вот по крайней мере в Хаскеле (и Лиспе тоже) это делается очень естесственно.

В питоне также естественно.
ФВП полноценные плюс динамика и утиная типизация.
И кстати как раз в питоне можно совсем без наследования прожить.