Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, fplab, Вы писали:
_FR>Мне больше нравится линейный поиск как навык работы с массивами и факториал как пример рекурсии. Они проще И что мы получаем: есть знания и про массивы и про рекурсию, но никакого отношения к сортировке это не имеет.
Наконец-то — дождались ! Вот оно — ключевое слово: "проще". Зачем нам обезболивающие ? Деревянным молотком по голове, как в средние века: пока пациент очухается, мы ему немножко вырежем здесь и подрихтуем там
Факториал — это да, это классика. Но именно как пример. Наверное процентов 90 всех книг по программированию объясняют рекурсию на примере именно факториала. Но между теорией и практикой дистанция немалого размера. Интересно, а если надо построить дерево, а потом сделать его обход ? Понятно, что можно и без рекурсии, но вот вопрос — а стоит ли ?
А линейный поиск — вообще прелесть. Понятно, что в массиве из 100 записей "при современном развитии печатного дела на Западе" (О.Бендер) — просмотреть их плевое дело. Дураки они, что ли компиляторщики — сортируют таблицу символов, чтобы потом в ней быстро искать ? А то и вообще хэш-функции втыкают
Правда, надо сделать одно важное извиняющее замечание — если человеку так не повезло, что ему не приходилось решать по настоящему сложных (а, значит, интересных) задач, то тогда, действительно, к чему засорять мозг
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, _FRED_, Вы писали:
Pzz>>>Внутри метода — алгоритмы. Те самые сортировки и поиски, о которых книжки пишут. А снаружи — клей и упаковка. _FR>>Я как-то всегда думал, что как раз алгоритмы — это то, что очень неплохо поддаётся "библиотизации", то есть вынесением в многократно используемые кирпичи. И задумываться над алгоритмами лишний раз не приходится.
N>Приходится задумываться, очень даже. Вот возьмём ту же пресловутую сортировку. Кто из кодеров вообще слышал о каком-то методе кроме "quick sort" (и то — под его маркетинговым названием)? А условия применимости? Вот завтра придут данные с определённым на них частичным порядком вместо линейного, и опаньки — условия применимости не выполняются. А если сравнения очень дорогие и их надо минимизировать? А если данных никогда не больше 8 элементов и quicksort просто дорог в раскачке, простейший метод вставок сработает быстрее? А если надо выполнить сортировку параллельно? А если дали 100 миллиардов элементов и они даже в виртуальную память не влезут (я уж молчу, что сортировать данные толще физической памяти такой сортировкой — самоубийство независимо от того, влезло оно в виртуалку или нет)? Всё, такой кодер сдулся, независимо от того, насколько он хорошо знает STL и может задавать сортировку его средствами.
N>"Библиотизация", конечно, возможна — до определённой степени. И грустно то, что факт самих ограничений многим недоступен просто по недостатку образования и желания их узнать и осознать.
И как в решении описанных проблем поможет умение написать _реализацию алгоритма_? ИМХО, достаточно знаний о том, что есть вот такое, есть такое, которое хорошо тогда и тогда, а тут лучше это и это. Что бы провести подобные рассуждения и сделать правильный выбор для решения задачи, вовсе не требуется знание алгоритма. А уж узнав, каким молотком надо вбивать гвоздь, пойти и достать молоток (читай: разобраться с реализацией) совсем, мне кажется, не сложно.
_FR>>В первую очередь из-за того, что редко, очень редко встречаются сейчас такие задачи. N>Угу, именно так. Фактически, можно тупо рубить бабло на минимальном базисе. Впрочем, для этого нужно соответствующее усердие, которое тоже нечастый скилл.;(
Гхм… попробую так: в каком проценте задач сортировки данных вам не достаточно библиотечных реализаций? Мне кажется, эта цифра вполне подойдёт под описание "очень редкно".
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Вообще-то вопросы границ применимости встречаются постоянно. Простейший пример: парни проектируют систему миграции из инфраструктуры A в инфраструктуру B. Архитектурная идея — проста как грабли, и при этом хорошо идет в струе технологического совершенства: экспортируем все данные из A в XML, трансформируем его в понятный системе B XML при помощи XSLT, и радуемся жизни.
И тут (через, грубо говоря, полгода разработки) вдруг возникает грустный эффект: трансформация подразумевает работу с DOM моделью, а далеко не все из интересных нам систем A генерируют документы, которые умещаются в 3GB RAM. Я доступно объясняю?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Кстати, у тебя присутствует фактически следующая классификация: сам ООП это ультрамодный космический корабль, а то, что мы пишем в методах — пещерный век.
А мне кажется, что ООП — это не космический корабль. Это ржавая подводная лодка, которая медленно идет ко дну
Вот неужели ООП не предлагает средств, чтобы избавиться от всех этих switch, if/else и прочая? Разве нельзя спроектировать систему — именно спроектировать — чтобы практически избавиться от всех этих "пережитков" вкупе с out/ref и другими неприглядными вещами? Так почему же мы это не делаем?
А ответ простой. Потому что последовательно и полностью реализованная ООП концепция в большом приложении — это просто кошмар. По сравнению с этим все "неприглядности" старого структурного программирования покажутся просто детскими шалостями. Я видел, как люди, "дорвавшиеся" до всяких ООП фенек, начинали проектировать системы — вполне в соответствии со всеми, паттернами — и когда я смотрел на их творчество мне хотелось выблевать на монитор, извините. При этом я с удовольствием читал код, скажем, Sqlite — хотя мои знания C# на настоящий момент несколько лучше, мягко говоря, чем plain C.
Собственно, почему я не "проникся" Немерле. Не из-за того, что я "барик", не из-за того, что не могу оценить все прелести ФП, а из-за того, что все это очень сильно похоже на "припарки" мертвому. Я не понимаю, почему "внешняя" архитектура должны быть ООП, а "внутренняя", скажем, ФП. Если та или иная концепция не позволяет реализовать ее последовательно во всех частях программы — так ли эта самая концепция хороша? И может стоит вообще пересесть с этой подводной лодки на что-нибудь другое?
Здравствуйте, netch80, Вы писали:
N>Так, может, что-то делать по сути? Например, я думаю, что Вам надоедает таки 8 часов в день сидеть за монитором, а свои мысли надо уложить в систему. N>Объявите на фирме семинар для студентов, где-то так в пятницу 17:00-18:30, с приходом всех желающих, и рассказывайте хоть что-то, но свежее и актуальное, а тех, кто показывает понимание, заманивайте на пиво и затем на работу В принципе, неважно, что именно будете рассказывать — лишь бы умели это делать. Развесить объявления в ближайших профильных вузах и смотреть, кто приходит... После этого всерьёз воспринимать тех титанов мысли XIX века с ассемблером ЕС ЭВМ уже не станут.
F>>Только, боюсь, подавляющее большинство неофитов сие премудрые книжки "ни асилит" — проще ваять псевдомудреный код с кучей абсолютно лишних наворотов
N>Ну и не надо книжки, надо с людьми работать. Книжки потом будут.
Да стараюсь как могу За трех человек, кто прошел через наставничество, не стыдно. Одно печалит — выход мал: это все достижения за 15 лет. Оставшихся стараюсь хоть чему-нибудь да поднатаскивать.
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, netch80, Вы писали:
ВВ>>Еще задолго до C# 2.0 я писал в самом банальном жабо-скрипте: N>Ну так где ECMAscript (который Netscape зачем-то назвал JavaScript), а где C#.
А где? Каждый на своем месте. И думаю на жабо-скрипте пишут даже больше людей чем на C#.
N>Кстати, "ещё задолго до C# 2.0" тривиально было в делегат поместить метод класса, а в класс вгрузить необходимые параметры — это было то же замыкание, только сконструированное вручную. Добавка синтаксического клея во 2-й и 3-й версии сделала этот процесс доступным ширнармассам, но кто хотел — умел и раньше.
Я собственно придираюсь к хронологии. А то выглядит так — все жили в пещерах, потом пришел C# и показал всем "свет разума", а Немерле превратил этот "свет" в пожарище. Я не специалист по истории ЯВУ, но сдается мне, что все этим "замыканиям" уже сто лет в обед, и C# тут как обычно выступает лишь в роли качественного подражателя.
Здравствуйте, _FRED_, Вы писали:
_FR>И как в решении описанных проблем поможет умение написать _реализацию алгоритма_? ИМХО, достаточно знаний о том, что есть вот такое, есть такое, которое хорошо тогда и тогда, а тут лучше это и это.
Напрямую — никак. Но так уж человек устроен, что чтобы помнить о том, что есть разные методы — ему нужно с ними столкнуться лично и желательно написать хотя бы простейшую реализацию. Собственно, поэтому метод пузырька до сих остаётся в книгах, хотя он худший из того, что может быть. Альтернатива — умение запоминать большое количество абстрактных данных, с которыми не сталкиваешься и которые остаются пустым звуком, а затем через много лет — вытащить эти данные из памяти, когда нужно. Это редкое умение, противоречащее всей природе человеческой памяти, и поэтому на него ориентироваться нельзя.
А описанные Вами знания "есть такое, а есть сякое" без подкрепления забудутся после первого экзамена.
Поэтому я с сомнением отношусь к тем архитекторам, которые давно сами не кодируют, и к тем кодерам, которые способны только применить указанное им решение.
_FR>>>В первую очередь из-за того, что редко, очень редко встречаются сейчас такие задачи. N>>Угу, именно так. Фактически, можно тупо рубить бабло на минимальном базисе. Впрочем, для этого нужно соответствующее усердие, которое тоже нечастый скилл.;( _FR>Гхм… попробую так: в каком проценте задач сортировки данных вам не достаточно библиотечных реализаций? Мне кажется, эта цифра вполне подойдёт под описание "очень редкно".
У меня лично статистики недостаточно. Но вот случай, когда обычная сортировка крайне невыгодна — каждый рабочий день на глазах, это таймерное дерево в движке событий. Оно сделано на пирамиде.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Если та или иная концепция не позволяет реализовать ее последовательно во всех частях программы — так ли эта самая концепция хороша?
так ли хороша концепция подводной лодки если на ней неудобно ездить по пустыне?
ВВ>И может стоит вообще пересесть с этой подводной лодки на что-нибудь другое?
Здравствуйте, netch80, Вы писали:
N>А описанные Вами знания "есть такое, а есть сякое" без подкрепления забудутся после первого экзамена. N>Поэтому я с сомнением отношусь к тем архитекторам, которые давно сами не кодируют, и к тем кодерам, которые способны только применить указанное им решение.
Вот пример из личной жизни: пока писал на VB, приходилось вручную реализовывать бинарный поиск (ну нет его в стандартной библиотеке), и с обобщением написанного кода нет так всё просто в этом языке. Так вот несколько лет уже пишу на C# и, наверное, не вспомню, как его реализовать.
Знания забываются от отсутствия практики, а вовсе не от понимания сути. И закономерно, что в некоторых областях, где от определённых знаний толку чуть (я не говорю "совсем нет"), уровень "базы" снижается.
Например, вспоминаю анекдот про то, как старого програмиста спросили, как записать некие данные на диск, а он начал ответ со слов о том, что "перво-наперво нужно спозиционировать головку устройства". И life is good что подобного не требуется знать сейчас.
_FR>>Гхм… попробую так: в каком проценте задач сортировки данных вам не достаточно библиотечных реализаций? Мне кажется, эта цифра вполне подойдёт под описание "очень редкно". N>У меня лично статистики недостаточно. Но вот случай, когда обычная сортировка крайне невыгодна — каждый рабочий день на глазах, это таймерное дерево в движке событий. Оно сделано на пирамиде.
В отдельных случаях может быть (и даже имеет право быть) всё что угодно. Но вот спрашивать веб-програмиста про объекты синхронизации на юниксе — гхм..? Вот я и говорю, что "база" у програмистов в общем смысле не в алгоритмах сортировки и прочих деталях реализации.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, fplab, Вы писали:
_FR>>Мне больше нравится линейный поиск как навык работы с массивами и факториал как пример рекурсии. Они проще И что мы получаем: есть знания и про массивы и про рекурсию, но никакого отношения к сортировке это не имеет.
F>Наконец-то — дождались ! Вот оно — ключевое слово: "проще". Зачем нам обезболивающие ? Деревянным молотком по голове, как в средние века: пока пациент очухается, мы ему немножко вырежем здесь и подрихтуем там
Не согласен с аналогией. Зачем мне таскать тяжеленный сундук, когда у меня есть удобный рюкзачёк? Объясни, зачем для понимания рекурсии необходимо именно возиться с сортировкой и не подойдёт факториал?
F>между теорией и практикой дистанция немалого размера.
Это и есть ответ? Гхм, мне одному кажется это нелогичным? Например, правила сложения гораздо легче объяснять на примере натуральных силел, нежели комплексных (да ещё и в показательном представлении). Так и тут: для объяснения рекурсии — факториал.
F>Интересно, а если надо построить дерево, а потом сделать его обход ? Понятно, что можно и без рекурсии, но вот вопрос — а стоит ли ?
Это большой вопрос. Например, может зависеть от используемого компилятора. Где-то я с удовольствием предпочитаю рекурсии цикл.
F>А линейный поиск — вообще прелесть. Понятно, что в массиве из 100 записей "при современном развитии печатного дела на Западе" (О.Бендер) — просмотреть их плевое дело.
А если в массиве всего четыре элемента?
F>Дураки они, что ли компиляторщики — сортируют таблицу символов, чтобы потом в ней быстро искать ? А то и вообще хэш-функции втыкают
Если поиск в большом массиве делается один раз, то зачем его перед этим сортировать?
F>Правда, надо сделать одно важное извиняющее замечание — если человеку так не повезло, что ему не приходилось решать по настоящему сложных (а, значит, интересных) задач, то тогда, действительно, к чему засорять мозг
Как видишь, обсуждаемый вопрос (необходимость знания некоторых, пусть и часто используемых, алгоритмов) многогранен. Не менее многогранен и вопрос о "настоящности" и "сложности" тех или иных задач. А раз, то категоричные высказывания о необходимости того или иного — ни что иное как заносчивость.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Y>Из всего этого вывод я делаю такой, что ООП в принципе и не нужен, ФП более чем достаточно. Ну разве, что если ООП будет средством модульности. Т.е. от ООП в классическом понимании останется совсем мало.
Смотря, что считать классическим понимание ООП Если "черные ящики, обменивающиеся сообщениями"(с)Алан Кей, то ООП остается
Здравствуйте, netch80, Вы писали:
N>Приходится задумываться, очень даже.
Вы всего лишь сказали одну банальную истину. Что выбор того или иного алгоритма должен быть осознанным, т.е. надо разобраться в _характеристиках_ и выбрать то, что подходит.
Но это не значит, что я должен уметь писать каждую сортировку (и тем более, что я должен был их когда-то писать), но знать их характеристики — должен. Но и то, только тогда, когда эта сортировка мне понадобится.
Вы же не берёте для проекта библиотеку U% только потому, что она единственная вам известная. Плюсы-минусы-то надо взешивать, так это никто не отрицал.
Здравствуйте, Pzz, Вы писали:
Pzz>В библиотеках содержатся стандартные алгоритмы. Куда вы пойдете, если вам нужна не просто сортировка, а сортировка с преподвывертом? Готовую именно с нужными вам свойствами вы не найдете, свою написать вы не умеете, т.к. всегда использовали готовую.
Ваша фраза применима к любой области и любой библиотеке. Однако, вы не станете требовать от человека знание всех ГУИ библиотек, всех библиотек для работы с сетью и т.п.?
Важно, чтобы человек не бездумно брал первую попавшуюся, а выбирал лучшую, и, если таковой не нашлось, 10 раз подумать и таки написать самому.
Только причём тут важность уметь писать самому всё изначально? Понадобится — будем разбираться.
Pzz>Принесут вам код, написанный для UNIX'а и активно использующий read/write lock'и, и попросят запустить его на Windows XP. А в XP нет read/write lock'ов. Ваши дальнейшие действия?
Гоги, ты чей друг? Мой или медведя?
Почитаю соответствующую документацию, выберу решение. Или я должен всё знать заранее?
Здравствуйте, Pzz, Вы писали:
Pzz>Да помилте, какой еще нужен струмент для написаныя простых алгоритмов, кроме как раз тех самых if'ов и while'ов? Откройте любую книжку про алгоритмы, обратите внимание, на каком языке в этих книжках алгоритны расписывают.
См. квиксорт на Хаскеле и на С. Классический пример. Или там использование паттерн матчинга для красно-черных деревьев.
Оно реально выглядит красивше и понятнее.
Здравствуйте, netch80, Вы писали:
_FR>>И как в решении описанных проблем поможет умение написать _реализацию алгоритма_? ИМХО, достаточно знаний о том, что есть вот такое, есть такое, которое хорошо тогда и тогда, а тут лучше это и это.
N>Напрямую — никак. Но так уж человек устроен, что чтобы помнить о том, что есть разные методы — ему нужно с ними столкнуться лично и желательно написать хотя бы простейшую реализацию.
Т.е. я правильно понял вашу точку зрения:
1. Программист(инженер) должен учитывать характеристики составных частей при проектировании более сложной системы. Если существующие составные части не подходят, можно использовать специальные нестандартные детали.
2. Большинство программист(инженер) ленивые и потому берут первую попавшуюся деталь, если не бились ранее лбом по этой теме. Если бились, то обычно разбираются в вопросе и сразу думают, какую деталь лучше взять.
3. Если программист(инженер) не имеет знаний о сортировках, то он относится к пункту 2
3.a [с большой вероятностью].
?
С 1-м пунктом не согласиться сложно. Этой банальности учат на всех инженерных специальностях.
Со 2-м пунктом тоже сложно не согласиться. И правда ленивых немало.
C 3-им пунктом я не согласен. Во-первых, вывод просто неверен. Это логика. Множество ленивых инженеров и не знающих сортировки пересекаются, но ни одно из них не включает другое.
Во-вторых, если даже он относится к пункту 2, то он сталкивался. И либо он сразу сделал осознанный вывод (что опровергает пункт 3, так как изначально знаний он не имел), либо он таки напортачил. Зачем вам программист, который на неизвестной задаче сначала портачит, а потом разбирается?
Если вы имели в виду пункт 3.а (большинство/многие/некоторые, а не все), то я не понимаю требования знания сортировок.
Это лишь значит, что при прочих равных инженер, знающий сортировку, вероятнее окажется лучшим.
Но знание сортировок не является для этого ни достаточным, ни необходимым.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Aen Sidhe, Вы писали:
S>Вообще-то вопросы границ применимости встречаются постоянно. Простейший пример: парни проектируют систему миграции из инфраструктуры A в инфраструктуру B. Архитектурная идея — проста как грабли, и при этом хорошо идет в струе технологического совершенства: экспортируем все данные из A в XML, трансформируем его в понятный системе B XML при помощи XSLT, и радуемся жизни. S>И тут (через, грубо говоря, полгода разработки) вдруг возникает грустный эффект: трансформация подразумевает работу с DOM моделью, а далеко не все из интересных нам систем A генерируют документы, которые умещаются в 3GB RAM. Я доступно объясняю?
Конечно понятно. Моё сообщение не было издёвкой. Это было сугубо про мой опыт работы, который невелик (всего три года).
А сложные задачки интереснее, чем обычные банальные вещи, поэтому я и завидую, да.
Здравствуйте, VoidEx, Вы писали:
VE>Т.е. я правильно понял вашу точку зрения: VE>1. Программист(инженер) должен учитывать характеристики составных частей при проектировании более сложной системы. Если существующие составные части не подходят, можно использовать специальные нестандартные детали. VE>2. Большинство программист(инженер) ленивые и потому берут первую попавшуюся деталь, если не бились ранее лбом по этой теме. Если бились, то обычно разбираются в вопросе и сразу думают, какую деталь лучше взять. VE>3. Если программист(инженер) не имеет знаний о сортировках, то он относится к пункту 2 VE> 3.a [с большой вероятностью]. VE>?
Да.
VE>С 1-м пунктом не согласиться сложно. Этой банальности учат на всех инженерных специальностях. VE>Со 2-м пунктом тоже сложно не согласиться. И правда ленивых немало.
VE>C 3-им пунктом я не согласен. Во-первых, вывод просто неверен. Это логика. Множество ленивых инженеров и не знающих сортировки пересекаются, но ни одно из них не включает другое.
Речь не идёт о знании, как писать конкретную сортировку. Но о знании граничных и оптимальных условий их применения, хотя бы минимальных оценок эффективности. И о том, что лучший способ усвоения этих знаний — написать в порядке обучения хотя бы парочку.
Пусть сортировка только классический показательный пример, но программист, который решил применить quicksort на множестве ключей без линейного порядка — мягко говоря, поступает некорректно.
VE>Во-вторых, если даже он относится к пункту 2, то он сталкивался.
Почему?
VE> И либо он сразу сделал осознанный вывод (что опровергает пункт 3, так как изначально знаний он не имел), либо он таки напортачил. Зачем вам программист, который на неизвестной задаче сначала портачит, а потом разбирается?
Если он при этом учится и ошибка замечена вовремя — то почему бы и нет?
VE>Если вы имели в виду пункт 3.а (большинство/многие/некоторые, а не все), то я не понимаю требования знания сортировок. VE>Это лишь значит, что при прочих равных инженер, знающий сортировку, вероятнее окажется лучшим. VE>Но знание сортировок не является для этого ни достаточным, ни необходимым.
Точно так же как любое другое отдельно взятое знание. Реальная оценка будет идти по их совокупности.
И что мы получаем: есть знания и про массивы и про рекурсию, но никакого отношения к сортировке это не имеет.
В принципе, неважно, что именно будете рассказывать — лишь бы умели это делать. Развесить объявления в ближайших профильных вузах и смотреть, кто приходит... После этого всерьёз воспринимать тех титанов мысли XIX века с ассемблером ЕС ЭВМ уже не станут.
За трех человек, кто прошел через наставничество, не стыдно. Одно печалит — выход мал: это все достижения за 15 лет. Оставшихся стараюсь хоть чему-нибудь да поднатаскивать.
Если "черные ящики, обменивающиеся сообщениями"(с)Алан Кей, то ООП остается 
