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

E>Кстати, а решение с разворачивающейся в цикл хвостовой рекурсией примешь?

Не знаю. Надо обсуждать.

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

E>С другой стороны, во многих случаях, этот код и есть правильный.

Ни в каком случае этот код не есть правильный.

E>Он надёжный

Не надежнее нормального

E>, безопасный

Чем он безопасный?

E>Поддержка опять же прямее...

Почему?

E>А разворот списка на месте -- неготовая к исключениям и непотокобезопасная преждевременная оптимизация таки...

Это не оптимизация, а при чем тут потокобезопасность вообще непонятно.

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

E>Вроде что-то в код комлите такое упоминалось...

E>Впрочем ты можешь взять базу багов за последний год, например, или там ещё какой период, выбрать багов 500 и быстренько поклассифицировать в типовом коде они были или нет, потом сопоставить скока того и другого у вас есть и прикинуть правда это или нет ДЛЯ ВАШИХ УСЛОВИЙ...

При равном выходном качестве нужно сравнить время на разработку, которое, вобщем, сильно зависит от количества багов. Покажи базу багов которая даст такую инфу.

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

E>С другой стороны, во многих случаях, этот код и есть правильный.

Смотря с какой стороны правильность мерять. С тз. "вот код, только отъ..сь", то это почти абсолютно правильный, почти идеальный код.

E>Он надёжный, безопасный, по времени всего в два раза хуже правильного, по памяти, да, тратит пропорционально длине списка, конечно, но если это не гигабайты, то и пофигу часто, зато просто, прямо, на неизменяемых данных каждый шаг из двух делаем...

Этот код страшен, как пивной бодун Он длинный и сложнее более короткого варианта, с перестановкой на месте.

Проще == лучше, особенно, если ты в команде а не сам по себе.

E>Поддержка опять же прямее...

Где именно прямее ? Два цикла вместо одного и ровно те же приседания с индексами и ссылками ?

E>Так то это, в современных критериях, -- хороший код!
E>А разворот списка на месте -- неготовая к исключениям и непотокобезопасная преждевременная оптимизация таки... Так что тут надо тщательнее смотреть что кто как и почему программирует-то...

Код который тебе понравился такой же неготовый к исключением и непотокобезопасный, только длиннее, сложнее и ест память.

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

I>При равном выходном качестве нужно сравнить время на разработку, которое, вобщем, сильно зависит от количества багов. Покажи базу багов которая даст такую инфу.

Я думаю, что твой оппонент имел в виду число багов в уже разработанном и закомиченном коде, а не во время разработки. Понятно, что если разрабатывают что-то нестандартное, то будет куча всего, в том числе и "планово неработоспособные эксперименты", например, но число багов в коде, про который разработчик сказал : "оно готово" определяется иными причинами...

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

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

I>>При равном выходном качестве нужно сравнить время на разработку, которое, вобщем, сильно зависит от количества багов. Покажи базу багов которая даст такую инфу.

E>Я думаю, что твой оппонент имел в виду число багов в уже разработанном и закомиченном коде, а не во время разработки.

И это неправильно, т.к. время расходуется в основном пропорционально количеству ошибок.

>Понятно, что если разрабатывают что-то нестандартное, то будет куча всего, в том числе и "планово неработоспособные эксперименты", например, но число багов в коде, про который разработчик сказал : "оно готово" определяется иными причинами...

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

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

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

Он говорит о другом. Что если код долго живёт, то цена поддержки очень большая, и она мало зависит от того, нужны ли были исследования при разработке этого конкретного куска кода или он был "типовым", если, конечно, всё делать одинаково качественно...

Впрочем лучше спросить у него.

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

I>Код который тебе понравился такой же неготовый к исключением и непотокобезопасный, только длиннее, сложнее и ест память.

1) Если есть такое требование, его проще сделать безопасным.
2) Мутабельные данные вообще по природе своей ограничивают потоко-безопасность и готовность к исключениям. Так что сама поставновка задачи не того.

Мы же подход человека хотим протестить? И подход "в каждом месте пилим максимально эффективный хитрый/неочевидный код" против "пытаемся писать максимально стандартно, а мудрим там, где скажет профайлер" не факт что самый общепринятый...
Я бы, как минимум, если бы просил людей разворачивать списки, явно указал бы, что надо без памяти и быстро Или хотя бы что по возможности так.

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

I>>Код который тебе понравился такой же неготовый к исключением и непотокобезопасный, только длиннее, сложнее и ест память.

E>1) Если есть такое требование, его проще сделать безопасным.

Если ты начал реализовывать такие требования не прояснив актуальность то тебе в дверь для джуниоров.

E>2) Мутабельные данные вообще по природе своей ограничивают потоко-безопасность и готовность к исключениям. Так что сама поставновка задачи не того.

А задать вопрос на собеседовании религия мешает ? Или же тебя религия заставляет писать только максимально потокобезопасный код устойчивй к любым сбоям, даже если это не требуется ?

E>Мы же подход человека хотим протестить? И подход "в каждом месте пилим максимально эффективный хитрый/неочевидный код" против "пытаемся писать максимально стандартно, а мудрим там, где скажет профайлер" не факт что самый общепринятый...

Нет, мы сравниваем "пилим любой, который пришел в голову, код, не пытаясь думать" против "минимально необходимый, простой и понятный код"

E>Я бы, как минимум, если бы просил людей разворачивать списки, явно указал бы, что надо без памяти и быстро Или хотя бы что по возможности так.

И тем самым ты понизишь уровень задачи ниже плинтуса.

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

E>>Я бы, как минимум, если бы просил людей разворачивать списки, явно указал бы, что надо без памяти и быстро Или хотя бы что по возможности так.
I>И тем самым ты понизишь уровень задачи ниже плинтуса.
Слушайте, не надоело еще?
Все определяется только одним, предложением программистов и спросом на них. Сейчас спрос меньше предложения, по крайней мере в Минске. Отсюда работодатель может как угодно развлекаться, когда набирает народ.
Было бы наоборот, не до развлечения с соискателями было бы, брали бы тех, кто хоть что-то умеет и доучивали бы.

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

I>А задать вопрос на собеседовании религия мешает ? Или же тебя религия заставляет писать только максимально потокобезопасный код устойчивй к любым сбоям, даже если это не требуется ?

Ну вы же с НС ждёте от чего-то максимально эффективного? Откуда известно, что именно его?..

Я бы, кстати, по умолчании, дал бы тот ответ, который ждал НС, но его логика, что дубовое решение плохое, а хитрое нет мне не ясна. Если считать, что это головоломка то понятно, что вряд ли тупое решение просят, если это реальный код, то всё от целей зависит...

I>Нет, мы сравниваем "пилим любой, который пришел в голову, код, не пытаясь думать" против "минимально необходимый, простой и понятный код"

Второе значительно дороже в разработке, а часто ещё и в поддержке...

Кстати обе обсуждаемые версии простые и понятные, так, которая вам не нравится, даже понятнее, IMHO...

Мало того, она легко обощается на любую перестановку элементов, скажем отсортировать так тоже можно так же трудно будет...

I>И тем самым ты понизишь уровень задачи ниже плинтуса.

Ну иначе это тест на телепалку, а не на навыки программирования.
И тот и другой код хорош, просто для разных целей. Ваши цели известны тока вам, пока вы их не озвучили...

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

V>Слушайте, не надоело еще?
V>Все определяется только одним, предложением программистов и спросом на них. Сейчас спрос меньше предложения, по крайней мере в Минске. Отсюда работодатель может как угодно развлекаться, когда набирает народ.
V>Было бы наоборот, не до развлечения с соискателями было бы, брали бы тех, кто хоть что-то умеет и доучивали бы.

Так и делаем — берем и доучиваем. Но отфильтровать людей которые не хотят включать голову, не мешает. Если люди не включают голову на простых вещах, то странно ждать, что она включится на сложных.

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

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

I>>А задать вопрос на собеседовании религия мешает ? Или же тебя религия заставляет писать только максимально потокобезопасный код устойчивй к любым сбоям, даже если это не требуется ?

E>Ну вы же с НС ждёте от чего-то максимально эффективного?

Кто тебе такое сказал ? Я так понимаю, если товарищ напишет тебе сортировку за O(N^3) или O(N!), ты этот код одобриши на том основании, что не было никаких требований про производительность ?


I>>Нет, мы сравниваем "пилим любой, который пришел в голову, код, не пытаясь думать" против "минимально необходимый, простой и понятный код"

E>Второе значительно дороже в разработке, а часто ещё и в поддержке...

Ну да, простыни легче и дешевле майнтейнить, ога

I>>И тем самым ты понизишь уровень задачи ниже плинтуса.

E>Ну иначе это тест на телепалку, а не на навыки программирования.
E>И тот и другой код хорош, просто для разных целей. Ваши цели известны тока вам, пока вы их не озвучили...

Если девелопер не умеет задавать вопросов, он или джуниор, или никому не нужен.

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

I>Так и делаем — берем и доучиваем. Но отфильтровать людей которые не хотят включать голову, не мешает. Если люди не включают голову на простых вещах, то странно ждать, что она включится на сложных.
О боже. Не программисты — это странный народ. Вот один из них уже научился определять, что человек включает или выключает голову. Ты фильмов в зомби не пересмотрел?

З.Ы. А вообще от такого бреда про включение/выключение головы уже не смеяться, а плакать хочется. Все что вы делаете — это придумываете себе деятельность, которая по сути является киданием монетки, но с учетом, что тебе нравятся случаи, когда монетка падает вверх решкой.

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

V>З.Ы. А вообще от такого бреда про включение/выключение головы уже не смеяться, а плакать хочется. Все что вы делаете — это придумываете себе деятельность, которая по сути является киданием монетки, но с учетом, что тебе нравятся случаи, когда монетка падает вверх решкой.

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

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

E>>Ну вы же с НС ждёте от чего-то максимально эффективного?

I>Кто тебе такое сказал ?
Ну то решение, которое не нравится НС, если его сделать более или менее по уму, оно всего в два раза медленнее + одна-две аллокации под буфер массива, что на GC полная фигня, как бы...

E>>Я так понимаю, если товарищ напишет тебе сортировку за O(N^3) или O(N!), ты этот код одобриши на том основании, что не было никаких требований про производительность ?

Нет. Не одобрю. Это очень плохой показатель, а у обсуждаемого "неправильного" кода, показатели-то не такие уж и плохие же. Просто тратит память, но не факт, что это проблема.
Да, и сортировку пузырьком, если не просил чего-то иного я приму, но спрошу, как селать быстрее.

I>Ну да, простыни легче и дешевле майнтейнить, ога
Почему простыни? Там всего два простых цикла.
Скопировали туда, а потом обратно.

Мало того, представь, что завтра надо буде не обращать порядок, а, например положить сначала все чётные, а потом все нечётные, как будешь править тот и как иной вариант?..

I>Если девелопер не умеет задавать вопросов, он или джуниор, или никому не нужен.
не никому, а вам...

Я, же, собственно, про это уже писал, что давая такие мутные задания, ты предоставляешь грамотному соискателю показать тебе тот или иной подход ПО ЕГО ВЫБОРУ, что легко может привести к тому, что ты пропустишь способного человека, а их реально мало, в отличии от придурков, которые могут обратить список хот так, хоть сяк

Ну то есть ты оптимизируешь тест так, что типа умный его скорее пройдёт, а глупый скорее нет, а лучше, ну во всяком случаее с моей т. з., оптимизировать так, что бы умных не терять. Дураков можно отфильтровать многиме способами же, не на этом сфейлится, так на ином. Если твоя цель найти тех, кто в принципе не умеет решать такие задачи, то сразу так и говори, что хочу без доп. памяти, а если тех, кто не знает что вам надо и гадает, то ты всё правильно делаешь Только это всё те же самые головоломки, тока в профиль, неэффективности которых для набора программистов и посвящено стартовое сообщенеи темы

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


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

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Ни в каком случае этот код не есть правильный.
Это очень сложный вопрос. От целей и задач зависит.
Вот, например, давай я задам тебе похожую, но другую задачу? Она ещё и зания алгоритмов будет тестить за одно?

Есть твой список и надо его на месте отсортировать...

Я бы вот принял и правильное решение в духе, делаем массив ссылок, сортируем, потом делаем из него список, и в духе сортируем на месте сляиниями, например. А ты?..

//----------

E>>А разворот списка на месте -- неготовая к исключениям и непотокобезопасная преждевременная оптимизация таки...

НС>Это не оптимизация, а при чем тут потокобезопасность вообще непонятно.

Ну, как бы вот представь, что на предыдущем собеседовании нормального кандидата завернули на том, что он пишет непотокобезопасно, например...

В целом это был пример варианта обоснованой негативной оценки твоего решения и твоего задания.

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

E>1) Если есть такое требование, его проще сделать безопасным.

Безопасным относительно чего? Сам по себе метод вполне безопасен, так как не использует внешнее состояние совсем.

E>2) Мутабельные данные вообще по природе своей ограничивают потоко-безопасность и готовность к исключениям. Так что сама поставновка задачи не того.

Какой такой задачи? О чем ты?

E>Мы же подход человека хотим протестить? И подход "в каждом месте пилим максимально эффективный хитрый/неочевидный код" против "пытаемся писать максимально стандартно, а мудрим там, где скажет профайлер" не факт что самый общепринятый...

Правильный ответ, он не только сильно лучше по процессору и памяти, он еще и самый простой.

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

E>Ну вы же с НС ждёте от чего-то максимально эффективного?

Ничего подобного я не жду. Я жду другого — умения работать со ссылками, я это уже миллион раз в топике написал. На эффективность мне, вобщем то, плевать. Единственная причина, почему пишут тот код, что я привел выше, это то что человек не может или не умеет с этими ссылками работать.

E>Я бы, кстати, по умолчании, дал бы тот ответ, который ждал НС

И любой вменяемый программист тоже.

I>>Нет, мы сравниваем "пилим любой, который пришел в голову, код, не пытаясь думать" против "минимально необходимый, простой и понятный код"
E>Второе значительно дороже в разработке, а часто ещё и в поддержке...

Обоснуй.

E>Кстати обе обсуждаемые версии простые и понятные, так, которая вам не нравится, даже понятнее, IMHO...

Обоснуй.