Выскажу свое «фи». Иллюстрация scala-way на примере «быстрой» сортировки просто ужасна. Вы отдаете себе отчет, что в такой реализации на один вызов qsort происходит 4 раза создание и копирование массива? Конечно, это всего лишь пример, и он не обязан быть оптимальным, но зачем учить новичков наступать на самые большие грабли скалы — бездумное использование «красивых» методов, за которыми часто скрыты «лишние» операции.
На мой взгляд, лучше было бы придумать пример, который демонстрирует красивое рекурсивное решение, с использованием красивых фич скалы, при этом по перформансу не уступает императивному подходу. То есть, tail recursion, O(1) list prepending, List immutability, и т.д. Например, у Мартина Одерски в курсе все примеры были как раз такие.
Хамелеоны темнеют от UV. В помещениях свет, проходя через оконное стекло, почти целиком теряет UV сотавляющую. То есть, в помещениях хамелеоны не темнеют.
Лазерная коррекция подходит для относительно небольших диоптрий. Когда у тебя миопия высокой степени, она, во-первых, не может быть полностью скорректирована, во-вторых сопровождается кучей осложнений, которые являются противопоказаниями к лазерной коррекции.
Я еще вчера решил. Кстати, интересно, как составлялся этот кроссворд, вручную или с помощью программы? Там в процессе решения в каждый момент времени довольно мало букв можно однозначно определить.
Если вы чего-то не делаете, это свидетельствует скорее о вашей ограниченности, а не о том, что делать это — неправильно. Очень частый пример использования поиска/замены по тексту — это как раз рефакторинг legacy кода. Когда в коде есть куча похожих сущностей и из них надо сделать массив/enum. Или, например, вы пишете какой-то тест и нужно захардкодить какие-то пары expected-actual значений (если их недостаточно много для того, чтобы заводить отдельный файл).
Это навскидку, а таких примеров очень много.
Ха, я тоже писал программу для этой головоломки из «Братьев Пилотов», правда, не игровую, а для поиска решения (тогда не знал алгоритма). Уже не помню, на чем писал, скорее всего, тоже паскаль или QBasic.
Безотносительно задач и их сложности. Очень видно, что задачи писались и оформлялись разными людьми. И после никто не потрудился привести их к какому-то одному стандарту. В половине задач ввод-вывод из файла в файл, в другой половине из stdin в stdout.
К тому же, при составлении задач очень хорошо бы продумывать удобный формат входных данных, если, конечно, их чтение не является частью задачи. Например, лично для меня не очевидно, как «красиво» и просто прочитать вход для задачи O:
На вход подаются числа от 1 до 200000000, не более 10000000 штук. Из них различных не более 100000.
Здесь логично было бы первым числом давать количество чисел N.
Или я не понял ваше решение, или оно не верное. В приведенном куске кода что хранится в массиве Versions? А еще лучше, пожалуйста, приведите код решения целиком (clear, put и get).
На мой взгляд, лучше было бы придумать пример, который демонстрирует красивое рекурсивное решение, с использованием красивых фич скалы, при этом по перформансу не уступает императивному подходу. То есть, tail recursion, O(1) list prepending, List immutability, и т.д. Например, у Мартина Одерски в курсе все примеры были как раз такие.
Знакомые строки :)
Вы же знаете про BigInteger, не правда ли?
Это навскидку, а таких примеров очень много.
К тому же, при составлении задач очень хорошо бы продумывать удобный формат входных данных, если, конечно, их чтение не является частью задачи. Например, лично для меня не очевидно, как «красиво» и просто прочитать вход для задачи O:
Здесь логично было бы первым числом давать количество чисел N.
По поводу head() — тут поможет связывать элементы двусвязным списком и хранить ссылку на голову. Да, хорошее дополнение.