Вашими устами да мед пить.
(не я минуснул, если что...)
В большом проекте не раз видел, как крутые разработчики ипытывали разные эмоции.
Первая неделя — энтузиазм.
Вторая неделя — озабоченность.
Третья неделя — иллюзия, что вот вот и решу задачу, стоит только попотеть.
Четвертая неделя — отчаяние, но надежда еще есть.
Пятая неделя — сплошные возмущения, но дело уже сдвинулось на миллиметр.
Шестая неделя — начал понимать все извращение, но психика уже покалечена.
…
Особенно забавно, когда dll совмещается с ООП. Один модуль компилится с одной версией класса, другой модуль — с другой. Потом один модуль вызывает другой и все падает.
Эта студия с открытыми исходниками. Иногда глючит. Было бы интересно дописать API для этой неё, чтобы можно было и сети строить программно и диалоги вызывать.
… ага, а потом еще и фотошоп. Только нормальные фотографы сначала пару лет по галереям ходят, смотрят шедевры, учатся в худ. школах. Посмотрите, например, как к делу подходит Андрей Сахаров.
но если вы хотите так сравнить два алгоритма, вам надо будет оба закодить?
Закодить один, но проверить, — на каком количестве он дает выигрыш. А то может и его не надо было кодить, так как количество объектов в системе такое, что вполне обрабатывается тупым методом. Вы например, можете назвать число элементов, на котором quck sort дает выигрыш? Я не думаю, что есть универсальное число. На каждой реализации надо измерять.
Пишу потому что очень много народа загипнотизировано умными словами. Но отводить гипноз — дело неблагодарное, как показывает практика.
разработчики анализируют асимптотику
Для теории хорошо, но на практике лучше проверить с таймером.
алгоритм с лучшей асимптотикой работает 20 минут
Был просто случай. Посоветовал мне один профессор библиотеку, которая строит пространственный индекс. Хотел валить на защите за то, что я не использую индексы. Библиотека хорошая, но у меня тупым перебором матрицу инцедентности строило за несколько секунд простым перебором для миллиона объектов. А хитрый индекс оказался слишком долгим. Я до этого не подозревал, что тупые методы тащат за счет меньшего количества накладных расходов на весьма большом количестве объектов.
Я так понимаю, минусуют потому, что всё очевидно, а на практике никто не проверяет. Сравните график ln(N) и N. На довольно большом участке ln(N) > N и простой перебор работает быстрее, чем создание или гуляние по дополнительным структурам.
Ребята, прежде, чем городить вспомогательные структуры для ускорения поиска сначала убедитесь, что они не замедляют поиск. Это делается простым измерением времени.
А то бывали случаи, когда простой перебор занимает секунду, а построение структуры — 20 минут
Многие критикуют подобные вопросы. Интересно было бы узнать их мнение — как с определенным процентом уверенности убедиться, что пришедший на собеседование программист достаточно компетентен?
Один из вариантов — дружить с программистом заранее, устраивать конференции, учебные курсы и тп чтобы товарищи могли себя проявить.
У Java много проблем никто не спорит (многословность, костыли обратной совместимости), но в данном случае у вас полно придирок и неточностей, лень все разбирать, но пример
Просто к тому времени, как она появилась (год 95й), я уже несколько лет программировал на С++ и pascal. Сейчас решил перескочить на что-то более удобное. Но впечатления неоднозначные. Особенно с отсутствием контроля переполнения арифметики и кучей «удобств», которые сначала задумывались как лучше, а получилось как всегда. Молодым может и норм, но мне хотелось бы не ходить по кругу, а получить качественный инструмент не хуже того, что я использовал до этого.
(не я минуснул, если что...)
В большом проекте не раз видел, как крутые разработчики ипытывали разные эмоции.
Первая неделя — энтузиазм.
Вторая неделя — озабоченность.
Третья неделя — иллюзия, что вот вот и решу задачу, стоит только попотеть.
Четвертая неделя — отчаяние, но надежда еще есть.
Пятая неделя — сплошные возмущения, но дело уже сдвинулось на миллиметр.
Шестая неделя — начал понимать все извращение, но психика уже покалечена.
…
Если интересно, почитайте мой рецепт, как в таких проектах писать самодиагностирующиеся программы.
habrahabr.ru/post/342302
Я даже делал для своих коллег пошаговую инструкцию, как распознавать пиктограммы 10х10.
goo.gl/dRkzfL
Закодить один, но проверить, — на каком количестве он дает выигрыш. А то может и его не надо было кодить, так как количество объектов в системе такое, что вполне обрабатывается тупым методом. Вы например, можете назвать число элементов, на котором quck sort дает выигрыш? Я не думаю, что есть универсальное число. На каждой реализации надо измерять.
Для теории хорошо, но на практике лучше проверить с таймером.
Был просто случай. Посоветовал мне один профессор библиотеку, которая строит пространственный индекс. Хотел валить на защите за то, что я не использую индексы. Библиотека хорошая, но у меня тупым перебором матрицу инцедентности строило за несколько секунд простым перебором для миллиона объектов. А хитрый индекс оказался слишком долгим. Я до этого не подозревал, что тупые методы тащат за счет меньшего количества накладных расходов на весьма большом количестве объектов.
А то бывали случаи, когда простой перебор занимает секунду, а построение структуры — 20 минут
Один из вариантов — дружить с программистом заранее, устраивать конференции, учебные курсы и тп чтобы товарищи могли себя проявить.
Почему тогда effective final в java вычисляется без проблем? Это ж по сложности вычисления примерно одно и тоже, что и константные выражение.
Просто к тому времени, как она появилась (год 95й), я уже несколько лет программировал на С++ и pascal. Сейчас решил перескочить на что-то более удобное. Но впечатления неоднозначные. Особенно с отсутствием контроля переполнения арифметики и кучей «удобств», которые сначала задумывались как лучше, а получилось как всегда. Молодым может и норм, но мне хотелось бы не ходить по кругу, а получить качественный инструмент не хуже того, что я использовал до этого.