Здравствуйте, Klatu, Вы писали:
K>Я бы тебе даже поверил, если бы не знал абсолютно точно, что это неправда
Да пожалуйста, ходи дальше обиженный, во беда :-D
K>Есть ряд компаний, где такие задачи — это официальная политика, жестко прописанная в правилах. Включая упомянутые тобой гугл и майкрософт. Так что есть два варианта — или ты не знаешь, о чем говоришь, или тебя персонально взяли по блату.
Я даже пример задачки из гугла дал, а не пронимает. До свидания и удачи
Здравствуйте, aik, Вы писали:
aik>Да пожалуйста, ходи дальше обиженный, во беда :-D
На дураков не обижаются, не так ли?
aik>Я даже пример задачки из гугла дал, а не пронимает. До свидания и удачи
Гугл широко известен своими мозголомными задачками, равно как и майкрософт, о чем в инете есть масса обсуждений. Расскажи свои сказки кому-нибудь другому
Здравствуйте, Klatu, Вы писали:
K>Есть ряд компаний, где такие задачи — это официальная политика, жестко прописанная в правилах. Включая упомянутые тобой гугл
В московском гугле никаких гномов и канализационных люков не замечено. Задачки исключительно по IT. Списки, хеши, алгоритмы и т.д.
Вообще, ни разу на интервью не парили мозг чем-то подобным. Сдается мне, плотность гномов среди работодателей сильно преувеличена.
Здравствуйте, Donz, Вы писали:
K>>Есть ряд компаний, где такие задачи — это официальная политика, жестко прописанная в правилах. Включая упомянутые тобой гугл D>В московском гугле никаких гномов и канализационных люков не замечено. Задачки исключительно по IT. Списки, хеши, алгоритмы и т.д.
Вообщееееее, списки-хэши — это как раз "гномы" и есть. Ну, реально, никто списками нынче не мается, зачем такие вопросы? Или алгоритмы — я их же, в Гугле спросил — что, каждый день такое? "Нееее", говорят, "какое там, и не каждый квартал даже". "Но зачем тогда таким мучать людей?". "Фиг знает, так заведено".
Но — с другой стороны — другие офисы Гугла собеседуют иначе, друг поиграл в эту игру.
Здравствуйте, aik, Вы писали:
aik>Вообщееееее, списки-хэши — это как раз "гномы" и есть. Ну, реально, никто списками нынче не мается, зачем такие вопросы?
"Отучаемся говорить за всех". Может кто-то и не мается, потому что просто не знает теории коллекций?
У меня сейчас самая что ни на есть типовая задача: получить данные, сравнить, сохранить. Буквально вчера применил этот самый "никому не нужный" хеш-мап, уменьшив сложность алгоритма с n^2 до n.
Поражаюсь. Люди, работающие в сфере информационных технологий, утверждают, что им не нужны азы науки об информации.
Математики против чисел, уборщики против моющих средств.
Уже не раз спрашивал. А что нужно то программисту? Увеличивать показатель "количество проставленных хибернейтовских аннотаций маппинга в минуту"? Так ведь там тоже теория нужна. И даже POJO объекты без понимания хеша насоздавать не получится.
Здравствуйте, Donz, Вы писали:
aik>>Вообщееееее, списки-хэши — это как раз "гномы" и есть. Ну, реально, никто списками нынче не мается, зачем такие вопросы? D>"Отучаемся говорить за всех". Может кто-то и не мается, потому что просто не знает теории коллекций? D>У меня сейчас самая что ни на есть типовая задача: получить данные, сравнить, сохранить. Буквально вчера применил этот самый "никому не нужный" хеш-мап, уменьшив сложность алгоритма с n^2 до n.
Применил или реализовал? Разные вещи, мягко говоря.
Здравствуйте, Donz, Вы писали:
D>Буквально вчера применил этот самый "никому не нужный" хеш-мап, уменьшив сложность алгоритма с n^2 до n.
Ну вообще интереснее услышать насколько это повысили производительность приложения, чем сложность неизвестного алгоритма. Может он там раз в год запускается, или еще забавнее бывает n если n<5, вплоть до того что использование мапы тормоза может создавать.
Здравствуйте, Donz, Вы писали:
D>Здравствуйте, aik, Вы писали:
aik>>Вообщееееее, списки-хэши — это как раз "гномы" и есть. Ну, реально, никто списками нынче не мается, зачем такие вопросы?
D>"Отучаемся говорить за всех". Может кто-то и не мается, потому что просто не знает теории коллекций?
Что за теория коллекций? Гугл про нее тоже не знает.
Здравствуйте, Donz, Вы писали:
D>Поражаюсь. Люди, работающие в сфере информационных технологий, утверждают, что им не нужны азы науки об информации. D>Математики против чисел, уборщики против моющих средств.
D>Уже не раз спрашивал. А что нужно то программисту?
Дело не в том, что эти знания не нужны, а в их сложности и важности. Знать базовые принципы по работе с структурами данных, конечно, надо, но обучить этим базовым принципам можно за пятнадцать минут. А вот как обучить человека решать задачи максимально просто и с минимумом сущностей, соответственно получая понятный и легко поддерживаемый код, в общем случае непонятно и уж точно займет обучение не пятнадцать минут и даже не месяц. Но при традиционной форме собеседований почему-то всех интересует то, чему человека можно элементарно обучить, зато умения, которые собственно и определяют способность человека программировать никого не интересуют.
Здравствуйте, aik, Вы писали:
D>>У меня сейчас самая что ни на есть типовая задача: получить данные, сравнить, сохранить. Буквально вчера применил этот самый "никому не нужный" хеш-мап, уменьшив сложность алгоритма с n^2 до n. aik>Применил или реализовал? Разные вещи, мягко говоря.
Применил. Потому что знаю стоимость вставки и получения элементов из хеш-мапа. И также знаю принцип, по которому сделана реализация HashMap. И также понимаю, что у объектов-ключей должна быть хорошая дисперсия хеш-функции, и как хеш-функция вообще должна быть реализована.
Непонимание любого из условий может привести к увеличению, а не уменьшению, сложности алгоритма.
Здравствуйте, vb-develop, Вы писали:
D>>Буквально вчера применил этот самый "никому не нужный" хеш-мап, уменьшив сложность алгоритма с n^2 до n. VD>Ну вообще интереснее услышать насколько это повысили производительность приложения, чем сложность неизвестного алгоритма.
600 итераций против 22500.
VD>или еще забавнее бывает n если n<5, вплоть до того что использование мапы тормоза может создавать.
Ты только что сформулировал еще один аргумент в пользу того, что надо знать, как устроена конкретная мапа.
18.05.2011 13:11, Donz пишет:
> просто не знает теории коллекций?
Дожились. Новая теория появилась — теория коллекций.
> У меня сейчас самая что ни на есть типовая задача: получить данные, > сравнить, сохранить. Буквально вчера применил этот самый "никому не > нужный" хеш-мап, уменьшив сложность алгоритма с n^2 до n.
А время выполнения не увеличил?
Это действительно было узким местом вашего продукта?
У вас все разработчики 50% времени занимаются подобными задачами?
Кто тогда создает эти узкие места?
Здравствуйте, Undying, Вы писали:
U>Дело не в том, что эти знания не нужны, а в их сложности и важности. Знать базовые принципы по работе с структурами данных, конечно, надо, но обучить этим базовым принципам можно за пятнадцать минут.
За пятнадцать минут обучить человека, который ни сном, ни духом в теории алгоритмов и структурах данных? С объяснения, как устроена та или иная коллекция, плавно перейдем на методы класса Object, потом объяснение, что такое хеш вообще, потом базовый курс теории информации и т.д.
Зачем нужен программист, который не имеет знаний в своей профессиональной области? Человек, который несколько лет проработал в сфере информационных технологий, но при этом не интересовался даже базовыми вещами. Это даже не сапожник без сапог, а сапожник без умения забить гвоздь.
U>А вот как обучить человека решать задачи максимально просто и с минимумом сущностей, соответственно получая понятный и легко поддерживаемый код, в общем случае непонятно и уж точно займет обучение не пятнадцать минут и даже не месяц. Но при традиционной форме собеседований почему-то всех интересует то, чему человека можно элементарно обучить, зато умения, которые собственно и определяют способность человека программировать никого не интересуют.
Никто не говорит, что эти навыки не нужны. Их тоже надо проверять. Но они не отменяют базисных знаний.
Здравствуйте, Vzhyk, Вы писали:
>> просто не знает теории коллекций? V>Дожились. Новая теория появилась — теория коллекций.
Иногда не стоит воспринимать фразу как устойчивое выражение, которое обязательно должно появляться только в такой форме. Если соединить смысл двух слов, то можно догадаться, что речь о теории структур данных с конкретизацией в виде коллекций.
V>А время выполнения не увеличил?
Не увеличил.
V>Это действительно было узким местом вашего продукта?
Это было бы вероятным узким местом одного из типовых сценариев.
V>У вас все разработчики 50% времени занимаются подобными задачами?
Откуда взялись 50%? И какая разница, как часто приходится этим заниматься? Тут все просто:
1)Нет соответствующих знаний -> потенциальная проблема с производительностью -> потеря времени тестировщиками на выявление проблемы -> потеря времени разработчиком на фикс -> потеря времени в разработке проекта.
V>Кто тогда создает эти узкие места?
Разработчик, который работает исключительно с ArrayList, мог бы создать потенциально узкое место. Это, по-моему, очевидно.
Видишь, в чем проблема. Если человек не имеет понятия о структурах данных и оценки сложности алгоритма, то для него это действительно показалось бы преждевременной оптимизацией. Для человека со знанием использование ArrayList по сложности не отличается от использования HashMap, и для него это не преждевременная оптимизация, а просто выбор правильной коллекции.
Не знаю, с чем корректно сравнить. Это как программер, знающий только одну сортировку пузырьком. Для него использование быстрой сортировки — оптимизация. Для нормального программера, это само собой разумеющийся выбор. И даже наоборот, увидев пузырек, он задумается, а не проводится ли в этом месте хитрая оптимизация.
Здравствуйте, Donz, Вы писали:
D>Здравствуйте, vb-develop, Вы писали:
D>>>Буквально вчера применил этот самый "никому не нужный" хеш-мап, уменьшив сложность алгоритма с n^2 до n. VD>>Ну вообще интереснее услышать насколько это повысили производительность приложения, чем сложность неизвестного алгоритма.
D>600 итераций против 22500.
VD>>или еще забавнее бывает n если n<5, вплоть до того что использование мапы тормоза может создавать.
D>Ты только что сформулировал еще один аргумент в пользу того, что надо знать, как устроена конкретная мапа.
Да я и не говорил никогда что этого знать ни в коем случае нельзя. Просто бездумные преждевременные оптимизации, часто со стороны людей, не имеющих представления о том что может создавать тормоза в продакшне, которые к тому же затрудняют чтение и понимание кода — бывает напрягают. До тех пор пока не выявлены ботлнеки, и не померена вся цепочка модулей, где какие просадки происходят — при выборе быстрый алгоритм/красивый код я отдам предпочтение последнему.
Здравствуйте, vb-develop, Вы писали:
VD>До тех пор пока не выявлены ботлнеки, и не померена вся цепочка модулей, где какие просадки происходят — при выборе быстрый алгоритм/красивый код я отдам предпочтение последнему.
Полностью поддерживаю. Но для некоторых программистов, как я понимаю, появление в коде коллекции, отличной от ArrayList, автоматически означает некрасивый и непонятный код. Вот, собственно, для их отсеивания и спрашивают про Collection API.
18.05.2011 15:04, Donz пишет:
> Не увеличил.
ОК.
Буду добивать дальше.
> > V>Это действительно было узким местом вашего продукта? > > Это было бы вероятным узким местом одного из типовых сценариев.
Т.е. это было только вероятным местом, причем только одного из сценариев.
Какова вероятность этих событий?
Сколько времени ты потратил на эту правку?
Не лучше-ли было потратить свое не дешевое время на что-то более важное
для проекта?
Но кто-то у вас же создал это узкое место? (предположим, что оно
действительно узкое). Учитывая, как ты проводишь собеседования, кто-то
не очень грамотный к вам просочился, пройдя твое собеседование.
> > 1)Нет соответствующих знаний -> потенциальная проблема с > производительностью -> потеря времени тестировщиками на выявление > проблемы -> потеря времени разработчиком на фикс -> потеря времени в > разработке проекта.
Нет, в этой цепочке нет следствия между высказываниями.
> > Разработчик, который работает исключительно с ArrayList, мог бы создать > потенциально узкое место.
Но сэкономить много времени в разработке, а вероятность возникновения
события выше не известна.
18.05.2011 15:29, Donz пишет:
> Полностью поддерживаю. Но для некоторых программистов, как я понимаю, > появление в коде коллекции, отличной от ArrayList, автоматически > означает некрасивый и непонятный код. Вот, собственно, для их отсеивания > и спрашивают про Collection API.
Не знаю .NET.
На, например, в том же с++ часто неочевидно, что лучше сортированный
вектор или мап. И оценить что выгоднее, можно только проведя
профилирование и убедившись, где бутылочное горлышко.
Поэтому, я по рукам бью всегда преждеоптимизаторам, пусть лучше напишут
лаконичный и понятный и рабочий код.
Да, подозревал, что просто приведя пример пользы HashMap из личной практики начнется полный разбор полетов людьми, которые вообще ничего не знают и не могут знать об этом конкретном случае.
V>Т.е. это было только вероятным местом, причем только одного из сценариев. V>Какова вероятность этих событий?
100%, что сценарий будет регулярно использоваться. 100%, что двадцать тысяч операций намного хуже пятиста особенно при выполнении сложного метода equals.
V>Сколько времени ты потратил на эту правку?
Это не правка, это я сразу так код написал. Ну секунды две в мозгу потратил, чтобы подсчитать сложность алгоритма решения в лоб, и с хэш-мепом.
V>Не лучше-ли было потратить свое не дешевое время на что-то более важное V>для проекта?
Нет, не лучше.
V>Но кто-то у вас же создал это узкое место? (предположим, что оно V>действительно узкое). Учитывая, как ты проводишь собеседования, кто-то V>не очень грамотный к вам просочился, пройдя твое собеседование.
И дальше продолжаешь свой полет фантазии, подменяя факты своими домыслами. См. выше. Никто узкое место не создавал. Я сразу написал код так, что он гарантировано не сделает это место узким.
>> 1)Нет соответствующих знаний -> потенциальная проблема с >> производительностью -> потеря времени тестировщиками на выявление >> проблемы -> потеря времени разработчиком на фикс -> потеря времени в >> разработке проекта. V>Нет, в этой цепочке нет следствия между высказываниями.
Где именно не видишь следствия?
V>Но сэкономить много времени в разработке, а вероятность возникновения V>события выше не известна.
Ага, я сэкономил бы две секунды. Для тебя вероятность неизвестна, потому что судишь, ничего не зная о проекте. Для меня известна.
Уже писал ранее. Возможно, для тебя использование не ArrayList'а — это преждевременная оптимизация. Для меня выбор правильной коллекции — норма. А еще я шурупы заворачиваю отверткой, а не всегда использую молоток. Хотя шуруп, забитый молотком, тоже будет держаться.
Вообще я жавист, но это не имеет отношения к делу.
V>На, например, в том же с++ часто неочевидно, что лучше сортированный V>вектор или мап. И оценить что выгоднее, можно только проведя V>профилирование и убедившись, где бутылочное горлышко. V>Поэтому, я по рукам бью всегда преждеоптимизаторам, пусть лучше напишут V>лаконичный и понятный и рабочий код.
И правильно делаешь. Если из-за неподтвержденной оптимизации потрачено значительное время, и код стал хуже читаться, то надо бить по рукам или требовать подтверждения.
Мой случай не из этих.
