У меня есть такое замечание. Те, кто оценивают скрипт, не смотрят на его “полность”. Т. е., возможность использование результатов в дальнейшем. Возможно в определенной задаче этого не требуется, но каждая задача использует результаты из своих предыдущих вычислений. Это, в свою очередь, влияет на читабельность программы. Или сразу оговорить, что нужны просто результаты, которые не нужно сохранять.

Хорошо. Давайте разберём например как вы будете использовать в своей программе найденные пароли в дальнейшем?
Пароль это такая штука которая редко меняется. И обычно найти его нужно один раз и потом пользоваться. И в данном случае наиболее важным параметром является скорость.
Так же и с другой проблемой. Вся должно быть обосновано с точки зрения здравого смысла...
А создавать несколькор степеней абстракции только ради принципа "вдруг пригодится" ИМХО нецелесообразно.

PS Я исключаю различные "програмные движки" в которых это себя сильно оправдывает.

нет, давайте не привязываться к конкретным примерам.
Один думает надо это сделать, другой так не думает или творческая лень :-). Просто условиться чего можно не делать, или нужна делать, так как это влияет на код.
Хотя, это все выше сказанное, мое рвение к справедливости :-)

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

В решении самое главное добиться 100% работоспособности, ну и какой-нибудь понятности. Если вставлять ОФОРМЛЕНИЕ (стили, отступы, пр.), то абсолютно уверен оно не будет востребовано. Даже если кто-то возьмет решение как готовую часть своего проекта, то оформление угадать в-принципе невозможно. А вычистить его и добавить свое - двойная работа. (кстати и в оценках специально не упамяналось оформление).

Ещё замечание:
Сложность задачи (в данном случае) - понятие довольно субьективное. Я, к примеру, задачу на восстановление формы оцениваю максимум на 2, но никак не * (хотя количество решений говорит обратное, что опять подтверждает субъективность восприятия сложности). Такая же ситуация и с задачей на определение размеров: ей я дал 4 уровень, т. к. в ней используется програмистский приём (по крайней мере в моём решении), который я до конца не понимаю, но всё же успешно применяю.
Интересно, по каким критериям вы определяете сложность задач?

>Интересно, по каким критериям вы определяете сложность
>задач?
По субъективным критериям :))) Да собственно объектино оценить сложность задачи сложно.

Я считаю, что определять сложность задачи нужно уже после выкладывания решений. Выложить задание без оценки, а после просмотра всех решений делать выводы. Логично предположить, что, чем больше строк кода в решении - тем сложнее задача (первый критерий, хотя опять же не совсем точный). Почитать мнения участников и "зрителей" (второй критерий) и пр.
Или, хотя бы, голосованием постановить. :)
Какова цель этого задачника? Восполнить пробел в ваших книгах? Помочь другим начинающим, приходящим из поисковика? Думаю и то, и другое. Поэтому и оценка должна быть объективной. Думаю, новички (я имею ввиду совсем "зелёненьких") прорешав задачи первого уровня не смогут решить некоторые задачи из второго, так как они будут слишком сложные.

В этом есть смысл, я тоже подумывал об выставлении оценок пост-фактум. Хм... а вы бы не могли сами проревизовать уже существующие задачи, выставить свои критерии сложности по шкале 1 2 3 * (с обоснованием, если эти оценки отличаются), запостить их в новой теме для обсуждения - возможно к нам присоединятся другие участники и предложат свои оценки. Так на эксперной оценке можно было бы скорректировать сложность задач?

>Такая же ситуация и с
>задачей на определение размеров: ей я дал 4 уровень, т. к. в
>ней используется програмистский приём (по крайней мере в
>моём решении), который я до конца не понимаю, но всё же
>успешно применяю.
а я бы оценил сложность в 1 и рекурсия там не сложная

Сложных рекурсий (через промежуточные функции, с множественным рекурсивным вызовом и т.п.) лучше вообще избегать и не использовать.

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

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

Да нет. Просто народ наигрался. Это ожидаемо.
Те кто в состоянии это решить не находят времени, а те кто не в состоянии - не находят решения...

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

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

сложная задача - это время. А у большинства оно денег стоит.
Хотя, согласен с тем, что делать для конкурса то, что ты делаешь ежедневно - удовольствие среднее.

а времени давать, скажем, 2 недели :-) и проверяющим легче будет :-) да, они тоже могут свои решения предлагать, а мы оценим :-)

Позаковыристее? Нарисуйте фрактал Мандельброта (или хотя бы триадную крихую Кох) при помощи Gdlib. :)

По поводу объективности сложности:
Действительно, очень трудно найти объективные критерии. Как ни пытался - не смог найти такие. Единственный вариант - голосование.