Здравствуйте, FR, Вы писали:
FR>>>Угу писать на фортране можно используя любой язык :) N>>Не любой. Арифметический IF не реализуется на языке без goto. FR>switch, или таблица указателей на функции?
Ну да, switch внутри while и переменная состояния условно эмулирующая счётчик команд — может спасти любую программу, когда её надо сдать преподавателю как выполненную по всем канонам структурного программирования:) Только уж если Вы вспомнили мой любимый Фортран (эх, тяжёлое детство, 32-битная игрушка ЕС1022-02...) — это уже будет не фортран. В классическом F-IV и циклов не было.
FR>>>Просто начнешь всеръез писать используя функциональщину нужный стиль сам собой выработается и окажется что наследование для специализации малополезная вещь. N>>Ну да, будем передавать вагон коллбэков. Так как всё-таки быть, если общего кода этак процентов 60? Ещё один вагон коллбэков? FR>Угу, будем, только не коллбеков, а ФВП. И в этом стиле как раз обощаемость и повторное испрользование по моему повыще чем в ООП.
... из коего и возникает синекдоха отвечания. Спасибо, я лучше "пешком постою". Передавать 20 ФВП мне как-то не очень нравится, когда есть разумная тому альтернатива. Всё равно громоздко.
FR>>>Зато декораторы очень просто и легко, и как раз для всяких прокси и т. п. предназначены. N>>Вообще-то у меня словом "прокси" называлось совсем не то, что можно предположить исходя из контекста классов.:)) FR>Не важно :)
Здравствуйте, AndrewVK, Вы писали:
F>>Правда, надо сделать одно важное извиняющее замечание — если человеку так не повезло, что ему не приходилось решать по настоящему сложных (а, значит, интересных) задач, то тогда, действительно, к чему засорять мозг
AVK>О да, без пенисометрии никак. Знаешь только, в чем проблема, особенно в этом форуме? По результатам измерений запросто может оказаться, что у кого то из твоих оппонентов длиннее.
Угу, особенно если учесть тот факт, что сравнивают тут обычно не первичные половые признаки (если следовать физиологической аналогии), а пальцы рук. И получаются занятные посылы типа "мой большой палец левой руки, длиннее и толще твоего мизинца на правой, поэтому я круче". А вот, если бы заявляющий такое, попробовал бы поковырять своим суперским большим пальцем на левой руке в своей же правой ноздре, то глядишь и проникся бы важной ролью правых мизинцев в нелегкой судьбе местных спорщиков.
Важно не насколько длинные / толстые у человека пальцы, а насколько он умеет их применять по делу и к месту. А про пенисы, я вообще — молчу
Здравствуйте, _FRED_, Вы писали:
_FR>Не согласен с аналогией. Зачем мне таскать тяжеленный сундук, когда у меня есть удобный рюкзачёк? Объясни, зачем для понимания рекурсии необходимо именно возиться с сортировкой и не подойдёт факториал?
Хотя бы потому что нормальный человек, знающий, как вычислить факториал с помощью цикла, не оценит пример с факториалом и вспомнит что-нибудь про шашечки. Объяснение рекурсии на примере факториала — это сродни (утрирование) объяснению шаблонов с++ на примере вычисления того же факториала на этапе компиляции.
F>>Интересно, а если надо построить дерево, а потом сделать его обход ? Понятно, что можно и без рекурсии, но вот вопрос — а стоит ли ?
_FR>Это большой вопрос. Например, может зависеть от используемого компилятора. Где-то я с удовольствием предпочитаю рекурсии цикл.
Казалось бы, при чем тут рекурсия и цикл? Там, где можно обойтись просто циклом, рекурсия обычно не нужна и не используется. В той же (прости господи ) быстрой сортировке рекурсия обычно используется потому, что циклом не отделаешься.
Здравствуйте, _DAle_, Вы писали:
_DA>Казалось бы, при чем тут рекурсия и цикл? Там, где можно обойтись просто циклом, рекурсия обычно не нужна и не используется.
Это вопрос предпочтений. Мне тоже так раньше казалось. Сегодня же при наличии хвостовой рекурсии я скорее всего выберу рекурсию, кроме ну уж совсем примитивных случаев.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, netch80, Вы писали:
N>>А описанные Вами знания "есть такое, а есть сякое" без подкрепления забудутся после первого экзамена. N>>Поэтому я с сомнением отношусь к тем архитекторам, которые давно сами не кодируют, и к тем кодерам, которые способны только применить указанное им решение.
_FR>Вот пример из личной жизни: пока писал на VB, приходилось вручную реализовывать бинарный поиск (ну нет его в стандартной библиотеке), и с обобщением написанного кода нет так всё просто в этом языке. Так вот несколько лет уже пишу на C# и, наверное, не вспомню, как его реализовать.
_FR>Знания забываются от отсутствия практики, а вовсе не от понимания сути. И закономерно, что в некоторых областях, где от определённых знаний толку чуть (я не говорю "совсем нет"), уровень "базы" снижается.
Есть такие программисты вроде меня, которые просто не могут понять, ну как можно "не вспомнить", как реализовывать бинарный поиск. Ну это же простейший кирпичик, который многие дети придумывают сами в школе на уроках информатики. Не знаю, наверное, круг общения у меня исторически такой что ли среди программистов, но я действительно не могу понять, как люди, которые не могут написать бинарный поиск, могут написать маломальски сложный код. Ведь вроде бы это настолько просто..
Но, в общем-то, как там у Малдера.. "I want to believe", то есть я заставляю себя верить, что есть отличные программисты в своих областях, не знающие таких вещей, но понять этого не могу. И таких, как я, довольно много, и флеймам этим нет счета..
Здравствуйте, _DAle_, Вы писали:
_DA>Есть такие программисты вроде меня, которые просто не могут понять, ну как можно "не вспомнить", как реализовывать бинарный поиск.
Можно не вспомнить как релизовать бинарный поиск, а можно просто не помнить, что такое бинарный поиск. Между этими вещами большая разница, что, тем не менее, не мешает многим их путать.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
_DA>>Есть такие программисты вроде меня, которые просто не могут понять, ну как можно "не вспомнить", как реализовывать бинарный поиск.
IT>Можно не вспомнить как релизовать бинарный поиск, а можно просто не помнить, что такое бинарный поиск.
Тем более что в школе его у нас называли поиском методом половинного деления.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _DAle_, Вы писали:
_DA>>Есть такие программисты вроде меня, которые просто не могут понять, ну как можно "не вспомнить", как реализовывать бинарный поиск.
IT>Можно не вспомнить как релизовать бинарный поиск, а можно просто не помнить, что такое бинарный поиск. Между этими вещами большая разница, что, тем не менее, не мешает многим их путать.
Я хотел сказать, что я лично не понимаю, как можно помнить, что такое бинарный поиск, и не выразить это в коде без особых усилий.
Здравствуйте, FR, Вы писали:
DM>>Вот задачка: есть семейство алгоритмов (та же компенсация, допустим), которые теперь отличаются не одной функцией, а пятью (при этом имеют по 10 общих). В случае ООП и наследования все просто — общие функции в базовый класс, различные — в наследников.
FR>А у тебя тут не ожидается комбинаторного взрыва наследников?
Если реализовывать все возможные комбинации — ожидается. К счастью, в данной задаче все возможные не нужны, достаточно нескольких определенных.
DM>> Т.е. все детали специализации пошли в замыкание, и по сути, мы получили некий аналог объекта из ООП, но с меньшим числом степеней свободы.
FR>В общем да так и будет, только наоборот на объектах и будет корявое подобие с ограниченым числом степеней свободы
Последнее мне пока неочевидно: и там, и там есть сочетание кода и данных, но в объекте данные могут быть доступны для чтения и даже изменения, а в замыкании — обычно нет. Т.е. с объектом можно больше всего делать.
Здравствуйте, D. Mon, Вы писали:
DM>Последнее мне пока неочевидно: и там, и там есть сочетание кода и данных, но в объекте данные могут быть доступны для чтения и даже изменения, а в замыкании — обычно нет. Т.е. с объектом можно больше всего делать.
Не вижу разницы. У замыканий есть другое название — захват контекста. Объект — это фактически контекст, замыкание тоже контекст. В чём разница?
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, netch80, Вы писали:
N>Ну да, switch внутри while и переменная состояния условно эмулирующая счётчик команд — может спасти любую программу, когда её надо сдать преподавателю как выполненную по всем канонам структурного программирования Только уж если Вы вспомнили мой любимый Фортран (эх, тяжёлое детство, 32-битная игрушка ЕС1022-02...) — это уже будет не фортран. В классическом F-IV и циклов не было.
К счастью меня фортран заднл только по касательной
FR>>Угу, будем, только не коллбеков, а ФВП. И в этом стиле как раз обощаемость и повторное испрользование по моему повыще чем в ООП.
N>... из коего и возникает синекдоха отвечания. Спасибо, я лучше "пешком постою". Передавать 20 ФВП мне как-то не очень нравится, когда есть разумная тому альтернатива. Всё равно громоздко.
Угу сами себе придумал 20 ФВП и сами себе отвечаем не надо?
Случаи когда имено нужно тупо сгрупировать кучу функций практически никогда на практике не встречаются, обычно все разбивается и групируется в осмысленные вещи.
Здравствуйте, _DAle_, Вы писали:
_DA>Казалось бы, при чем тут рекурсия и цикл? Там, где можно обойтись просто циклом, рекурсия обычно не нужна и не используется. В той же (прости господи ) быстрой сортировке рекурсия обычно используется потому, что циклом не отделаешься.
Так обратное еще вернее там где можно применить рекурсию циклы часто невозможны или слишком сложны
Тем более часто рекурсия и читабельнее даже когда заменяет простой цикл. Ну и учитывая что современные
компиляторы (C++ про шарп и ява не в курсе) нормально оптимизируют хвостовую рекурсию, то и для оптимизации
циклы не так уж и нужны.
Здравствуйте, Pzz, Вы писали:
IT>>Так и для организации кода достаточно одних структур и методов. Зачем ООП придумали и кучу других паттернов? Непонятно
Pzz>ООП придумали для того, чтобы можно было структуруровать программу в терминах довольно больших блоков. Это нужно, в первую очередь, в связи с индустриальными методами разработки, когда над одной программой работают 50 индусов, и надо как-то провести границы, чтобы они не наступали друг другу на пятки.
Цирк. Для тех кто в это верит, поясню: привлекать неквалифицированных пользователей к формализации задачи — хорошо, привлекать неквалифицированных программистов (именно их ты имеешь в виду, говоря об индусах, правда?) — очень плохо.
Pzz>Т.е., в первую очередь ООП — это инструмент для менеджера проекта, а не для программиста.
Вообще-то ООП зародилось из фреймов-слотов, это такой ма-а-а-алепусенький кусочек инструментария ИИ по формализации знаний. Менеджеры софтостроения там если и стояли рядом, то только стояли.
Pzz>Что касается паттернов, их существование объясняется только тем, что люди решают похожие проблемы похожими способами, и похожих проблем встречается довольно много. В принципе, никаких паттернов быть не должно, раз уж люди постоянно делают одно и тоже, готовое решение должно стать библиотечной функцией (макросом, классом, темплейтом, ... — не важно).
Свежо предание... Только паттерн, это не "готовое решение", а некое собирательное название разных по существу решений. Хотя примеры могут быть и вполне определёнными. А каким же им ещё быть?!
Pzz>А вот внутри самих алгоритмов if'ы и while'ы — вполне себе адекватный инструмент. Во всяком случае, все классические алгоритмы описаны в литературе именно в этих терминах.
Это не просто "адекватный инструмент", if — это блин, базисная конструкция императивного стиля. Ну, вернее, не if, а goto. if — это уже структурный подход. Уж куда "адекватнее"!
P.S.: Не ставьте лошадь позади телеги, коллеги. Совсем уже свихнулись на "инструментах", "адекватности" и прочих "проблемах". Хех, ООП — инструмент менеджеров. Насмешил, спасибо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, D. Mon, Вы писали:
DM>Если реализовывать все возможные комбинации — ожидается. К счастью, в данной задаче все возможные не нужны, достаточно нескольких определенных.
Так тогда и для функции конструктора будет достаточно всего нескольких и никакой громоздкости не будет.
FR>>В общем да так и будет, только наоборот на объектах и будет корявое подобие с ограниченым числом степеней свободы
DM>Последнее мне пока неочевидно: и там, и там есть сочетание кода и данных, но в объекте данные могут быть доступны для чтения и даже изменения, а в замыкании — обычно нет. Т.е. с объектом можно больше всего делать.
Зато в замыкание можно засунуть абсолютно разное поведение, и легко комбинировать это замыкание с другими ФВП, например делать кеширование или фильтрацию не трогая основной код а просто применив к нашему замыканию стандартную ФВП. Кроме того рефакторинг для функционального стиля делается гораздо проще так как инкапсуляция выше.
Здравствуйте, IT, Вы писали:
IT>Не вижу разницы. У замыканий есть другое название — захват контекста. Объект — это фактически контекст, замыкание тоже контекст. В чём разница?
В доступных операциях.
После того, как мы передали в конструктор вагон колбеков и получили замыкание, реализующее наш сложный алгоритм, можем ли мы потом узнать, какие функции были переданы и что-то изменить? Обычно такие вещи совершенно непрозрачны, в отличие от объектов.
Здравствуйте, FR, Вы писали:
DM>>Если реализовывать все возможные комбинации — ожидается. К счастью, в данной задаче все возможные не нужны, достаточно нескольких определенных.
FR>Так тогда и для функции конструктора будет достаточно всего нескольких и никакой громоздкости не будет.
Согласен.
DM>>Последнее мне пока неочевидно: и там, и там есть сочетание кода и данных, но в объекте данные могут быть доступны для чтения и даже изменения, а в замыкании — обычно нет. Т.е. с объектом можно больше всего делать.
FR>Зато в замыкание можно засунуть абсолютно разное поведение, и легко комбинировать это замыкание с другими ФВП, например делать кеширование или фильтрацию не трогая основной код а просто применив к нашему замыканию стандартную ФВП.
Все то же самое можно делать с объектами, если они поддерживают нужные интерфейсы.
FR> Кроме того рефакторинг для функционального стиля делается гораздо проще так как инкапсуляция выше.
Здравствуйте, D. Mon, Вы писали:
FR>>Зато в замыкание можно засунуть абсолютно разное поведение, и легко комбинировать это замыкание с другими ФВП, например делать кеширование или фильтрацию не трогая основной код а просто применив к нашему замыканию стандартную ФВП.
DM>Все то же самое можно делать с объектами, если они поддерживают нужные интерфейсы.
Угу только писанины намного больше. И больше искусственных конструкций ненужных для непосредственного решения задачи, и что совем плохо эти исскуственные конструкции гораздо хуже обобщаются чем в случае с ФВП.
FR>> Кроме того рефакторинг для функционального стиля делается гораздо проще так как инкапсуляция выше.
DM>А можно обосновать?
Так выше уже обосновано — инкапсуляция плюс прозрачность по ссылкам, она позволяет легче менять реализации так как явного изменямого состояния нет.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, IT, Вы писали:
IT>>Не вижу разницы. У замыканий есть другое название — захват контекста. Объект — это фактически контекст, замыкание тоже контекст. В чём разница?
DM>В доступных операциях.
Операций доступно одинаково, просто в ФП декомпозиция другая.
DM>После того, как мы передали в конструктор вагон колбеков и получили замыкание, реализующее наш сложный алгоритм, можем ли мы потом узнать, какие функции были переданы и что-то изменить? Обычно такие вещи совершенно непрозрачны, в отличие от объектов.
Угу и часто это плюс.
Хотя при желании можно без проблем возвращать несколько функций с нужными операциями для доступа к замыканию, или как в схеме и лиспе использовать вызов по имени, и получим те же объекты.
Здравствуйте, FR, Вы писали:
N>>Ну да, switch внутри while и переменная состояния условно эмулирующая счётчик команд — может спасти любую программу, когда её надо сдать преподавателю как выполненную по всем канонам структурного программирования:) Только уж если Вы вспомнили мой любимый Фортран (эх, тяжёлое детство, 32-битная игрушка ЕС1022-02...) — это уже будет не фортран. В классическом F-IV и циклов не было. FR>К счастью меня фортран заднл только по касательной :)
Ну вот, вы, наверняка, и фразу "The God is real..." не продолжите :)
FR>>>Угу, будем, только не коллбеков, а ФВП. И в этом стиле как раз обощаемость и повторное испрользование по моему повыще чем в ООП. N>>... из коего и возникает синекдоха отвечания. Спасибо, я лучше "пешком постою". Передавать 20 ФВП мне как-то не очень нравится, когда есть разумная тому альтернатива. Всё равно громоздко. FR>Угу сами себе придумал 20 ФВП и сами себе отвечаем не надо?
Хотел бы я, чтобы это оказалось только своей придумкой... да вот увы — практика.
FR>Случаи когда имено нужно тупо сгрупировать кучу функций практически никогда на практике не встречаются, обычно все разбивается и групируется в осмысленные вещи.
Если нам не помогут, то мы тоже никого не пощадим.
) быстрой сортировке рекурсия обычно используется потому, что циклом не отделаешься.
