все так и пишут.
но:
— надо заводить свою переменную cache и свою версию *_cached() на каждую такую функцию
— надо не забыть переправить все вызовы f на f_cached, если кэширование прикручивалось не сразу
— для асинхронных функций, как в примере выше, все чуть сложнее, там callback тоже декорировать надо.
Навскидку:
— мемоизация: кэширование результатов вызова «чистой» функции (зависящей только от аргументов и не имеющей побочных эффектов), например, автодополнение поиска с подгрузкой вариантов, пользователь набрал, а потом стер символ — показали уже загруженный чуть раньше результат
— логгирование
— в целом, перехват всех вызовов любой функции с любым исправлением «на лету» аргументов и возвращаемого значения
пример:
Смысл в том, что:
— не надо менять код ни самой функции, ни мест ее вызова
— не надо копипастить однотипные куски кода для использования такого расширения в разных функциях, декоратор достаточно написать один раз и потом использовать, строки 3-5 примера выше превратятся в такое:
порешайте прошлые раунды Code Jam, small-версии тамошних задач, как правило, не требуют особых знаний, в крайнем случае рядом есть разборы.
ограничений по времени работы в practice mode нет, решение пишется на чем угодно, компилируется и запускается локально, на проверку отправляется только файл с ответом.
В свое время размер jQuery (что-то около 9k в gzip) стал для меня определяющим преимуществом перед монстрообразными фреймворками типа prototype.js, да и перед собственными велосипедами, которые не сильно легче jQuery получались, а умели много меньше.
Печально видеть, что она сама плавно превращается в такого монстра.
Ждем очередного популярного микрофреймворка, который напишут без оглядки на древние браузеры и совместимость с древними версиями самого себя.
(от собственного нано-велосипеда или урезанной сборки jQuery щастья не будет, потому что важна база сторонних плагинов)
Все подобные флеймы (повторяющиеся стабильно дважды в год) сводятся именно к тому, что считать «удобным».
Есть три возможных критерия «удобности»:
1. «Время должно совпадать с солнечным, то есть полдень — это 12:00 а не 13:00 и уж тем более не 14:00»
2. «Хочу вставать в светлое время суток»
3. «Хочу чтобы время подъема непременно называлось 7:00, я всю жизнь так жил»
Каждое предложение по отдельности разумно, но все вместе, увы, в принципе невыполнимы в условиях короткого светового дня, максимум два из трех.
Соответственно, каким-то одним приходится пожертвовать, и все споры ведутся уже о том, каким именно.
Лично мне кажется наименее логичным третье, на практике вовсю жертвуют первым (в этом и есть идея как DST, так и нынешнего постоянного сдвига вперед), аргументы за и против каждого разобраны по 100500 раз.
Но все это не имеет отношения к топику, в котором рассматривается вопрос «что делать», а не «кто виноват и виноват ли вообще».
Зачем конкретно в JS нужны классы а-ля жава?
У языка хватает недостатков, но, скажем так, альтернативный взгляд на ООП к ним вряд ли относится.
Вообще, зачем из скриптовых языков с таким упорством пытаются сделать жаву?
Получается объединение недостатков обоих подходов — тяжеловесность и ынтырпрайзнутость кода с одной стороны, и при этом заведомо невысокая производительность в виду скриптовости (ну и лишнего слоя абстракции при «компиляции» в JS) и отсутствие compile-time проверок типов с другой стороны.
Жава в браузерах уже была в виде апплетов, да закономерно сплыла на свалку истории.
Никогда не понимал этой глупости с «b это плохо, strong наше все».
То, что текст в них когда-то обязательно выделялся жирным — это какое-то тяжелое наследие 90-х, по недоразумению дожившее аж до 2011.
Они абсолютно одинаково стилизуются через css как угодно, чем одно «семантичее» другого?
99% авторов статей, текстов и постов не будут разбираться в таких тонкостях, и уж точно границу между «семантичным» и «несемантичным» выделением каждый проводить будет по-своему (см. комментарии выше)
В свою очередь, это означает, что поисковики и любой другой краулящий софт индексировать их будут одинаково.
То есть разницы ни в каком смысле нет.
Замкнутый круг.
это сильно зависит от набора задач.
на некоторых контестах ограничения такие, что скриптовые языки действительно присутствуют «для галочки».
в обсуждаемом же соревновании на питоне спокойно писались квалификации и минимум половина задач с отборочного раунда.
на финале да, он скорее остался чисто по инерции.
я в качестве запасного языка использую java (для трудоемких задач, или если питон запрещен)
участник не обязан писать все задачи на одном языке.
прикинув сложность решения, можно понять, имеет смысл писать его на питоне или нет.
простые задачи на питоне пишутся короче и быстрее, а скорость написания важнее скорости работы, лишь бы последнее укладывалось в лимит.
(если что, я однажды выходил в финал Google Code Jam, используя только питон)
тормоза флеша самого по себе кажутся преувеличенными.
что, сляпанные на коленке жаваскриптовые анимашки будут греть процессор меньше сляпанных там же флешовых аналогов?
сейчас хоть можно flashblock поставить и находиться в параллельной от них вселенной.
убьют флеш, так надо будет изобретать jQuery.animate-block какой-нибудь (иногда кажется, что уже пора)
я про это комментарий выше писал.
да, в самом php деревьев нет, они на тех объемах, с которыми обычно работает php, просто не нужны.
но вы неявно используете деревья всякий раз, когда пишете «order by key» или «where key > const»
использование деревьев вместо хэшей там, где свойства деревьев не нужны — это дурь, как и использование in_array() вместо isset() для поиска во множестве с заранее известными элементами.
последнее повсеместно встречается, особенно доставляют такие проверки в цикле, привет O(N^2) и тормозам уже на паре тысяч элементов.
статья как раз для того написана, чтобы выбирали то, что надо, а не что первое вспомнится.
как я понял, речь о деревьях шла как о способе реализации Map<K,V>, декартовы и прочие деревья это отдельная история для более специализированных задач.
да, вот как раз из-за отсутствия описания итерации по Map из статьи вообще непонятно, зачем, казалось бы, нужны деревья, когда есть хэши. (O(logN) против O(1)).
а нужны они затем, что перечислять элементы Map (или Set) можно хотеть:
— в любом, негарантированном порядке (HashMap, встроенные хэши в некоторых скриптовых языках)
— в порядке добавления (LinkedHashMap, встроенные хэши в некоторых других скриптовых языках)
— в порядке возрастания ключей + возможность перебрать только ключи в заданном диапазоне
и вот для последнего случая альтернатива деревьям — только полная сортировка всей коллекции после каждого изменения или перед запросом.
что долго и печально для больших коллекций, но вполне работает для небольших — поэтому в скриптовые языки деревья особо и не встраивают.
4. почему у вас множества только immutable бывают?
«заморозить» любую коллекцию можно, а множества в виде стандартных типов (java.util.HashSet, set() в python) вполне себе изменяемы.
их можно упомянуть как упрощенный вариант map, где не надо хранить значения.
в том же php множеств нет, но они при желании эмулируются через array('key1' => true, ..);
insert_after: O(N), если вставляется последний элемент, то время может быть O(1) — потому обычно пишут Amort. O(1).
смешаны в кучу две разные операции:
— вставка в конец (append) — амортизированное O(1)
— вставка куда угодно еще — O(N) без всяких амортизированных оценок.
смысл амортизированной оценки в том, что хотя заранее неизвестна сложность одного append-а (O(1) или O(N)), гарантируется, что суммарная сложность N append-ов — O(N), а не N*O(N) = O(N^2).
про обычную вставку это утверждение не выполняется.
2. про это не написано ни слова, но хэши в разных языках чуть отличаются, например, array в php еще содержит внутри список ключей, благодаря чему можно их обходить в порядке добавления.
(парадоксально, но тут php оказывается удобнее, несмотря на отсталость в поддержке прочих коллекций)
в остальных языках таких гарантий «по умолчанию» нет, в python 2.7+ есть отдельный тип OrderedDict, в java — LinkedHashMap.
многие реализации js тоже сохраняют порядок добавления, но насколько я помню, это не специфицировано.
бесконечная прокрутка — это как регенерация здоровья в современных шутерах.
модная фишка, которая вначале удивляет, но когда ее принимаются совать повсюду, начинает раздражать.
вот я на днях при проблемах с инетом решил заглянуть на сайт провайдера через резервный канал (gprs) на предмет наличия каких-либо объявлений.
разумеется, вырубив картинки.
за те несколько минут (!), что грузилась страница, испытал лютую НЕНАВИСТЬ к любителям засунуть лишние пару сотен кило жаваскриптового говна ради какой-нибудь ерунды типа выпадающей менюшки (которую и без js спокойно можно было сделать).
подход «у кого 10+ мегабит анлима со 100% аптаймом нет — уже недочеловек» должен умереть, по крайней мере для обычных сайтов (речь не идет о сложных приложениях типа google docs)
у этого «от кого» обычно два варианта — utf-8 и 1251, различить их и исправить неправильный вариант несложно — редкий осмысленный текст в 1251 случайно окажется валидным utf-8.
а толку от этой визуальности?
картинки смотреть? ну так к тому же фару есть плагины быстрого их просмотра.
разные типы файлов удобно различать цветовой кодировкой их имен, а не малюсенькими иконками.
но:
— надо заводить свою переменную cache и свою версию *_cached() на каждую такую функцию
— надо не забыть переправить все вызовы f на f_cached, если кэширование прикручивалось не сразу
— для асинхронных функций, как в примере выше, все чуть сложнее, там callback тоже декорировать надо.
— мемоизация: кэширование результатов вызова «чистой» функции (зависящей только от аргументов и не имеющей побочных эффектов), например, автодополнение поиска с подгрузкой вариантов, пользователь набрал, а потом стер символ — показали уже загруженный чуть раньше результат
— логгирование
— в целом, перехват всех вызовов любой функции с любым исправлением «на лету» аргументов и возвращаемого значения
пример:
Смысл в том, что:
— не надо менять код ни самой функции, ни мест ее вызова
— не надо копипастить однотипные куски кода для использования такого расширения в разных функциях, декоратор достаточно написать один раз и потом использовать, строки 3-5 примера выше превратятся в такое:
где «logged» — это тот самый декоратор:
Декоратор мемоизации пишется аналогично и больше не надо писать унылые:
во всех местах, где оно надо.
ограничений по времени работы в practice mode нет, решение пишется на чем угодно, компилируется и запускается локально, на проверку отправляется только файл с ответом.
Печально видеть, что она сама плавно превращается в такого монстра.
Ждем очередного популярного микрофреймворка, который напишут без оглядки на древние браузеры и совместимость с древними версиями самого себя.
(от собственного нано-велосипеда или урезанной сборки jQuery щастья не будет, потому что важна база сторонних плагинов)
Есть три возможных критерия «удобности»:
1. «Время должно совпадать с солнечным, то есть полдень — это 12:00 а не 13:00 и уж тем более не 14:00»
2. «Хочу вставать в светлое время суток»
3. «Хочу чтобы время подъема непременно называлось 7:00, я всю жизнь так жил»
Каждое предложение по отдельности разумно, но все вместе, увы, в принципе невыполнимы в условиях короткого светового дня, максимум два из трех.
Соответственно, каким-то одним приходится пожертвовать, и все споры ведутся уже о том, каким именно.
Лично мне кажется наименее логичным третье, на практике вовсю жертвуют первым (в этом и есть идея как DST, так и нынешнего постоянного сдвига вперед), аргументы за и против каждого разобраны по 100500 раз.
Но все это не имеет отношения к топику, в котором рассматривается вопрос «что делать», а не «кто виноват и виноват ли вообще».
У языка хватает недостатков, но, скажем так, альтернативный взгляд на ООП к ним вряд ли относится.
Вообще, зачем из скриптовых языков с таким упорством пытаются сделать жаву?
Получается объединение недостатков обоих подходов — тяжеловесность и ынтырпрайзнутость кода с одной стороны, и при этом заведомо невысокая производительность в виду скриптовости (ну и лишнего слоя абстракции при «компиляции» в JS) и отсутствие compile-time проверок типов с другой стороны.
Жава в браузерах уже была в виде апплетов, да закономерно сплыла на свалку истории.
То, что текст в них когда-то обязательно выделялся жирным — это какое-то тяжелое наследие 90-х, по недоразумению дожившее аж до 2011.
Они абсолютно одинаково стилизуются через css как угодно, чем одно «семантичее» другого?
99% авторов статей, текстов и постов не будут разбираться в таких тонкостях, и уж точно границу между «семантичным» и «несемантичным» выделением каждый проводить будет по-своему (см. комментарии выше)
В свою очередь, это означает, что поисковики и любой другой краулящий софт индексировать их будут одинаково.
То есть разницы ни в каком смысле нет.
Замкнутый круг.
на некоторых контестах ограничения такие, что скриптовые языки действительно присутствуют «для галочки».
в обсуждаемом же соревновании на питоне спокойно писались квалификации и минимум половина задач с отборочного раунда.
на финале да, он скорее остался чисто по инерции.
я в качестве запасного языка использую java (для трудоемких задач, или если питон запрещен)
прикинув сложность решения, можно понять, имеет смысл писать его на питоне или нет.
простые задачи на питоне пишутся короче и быстрее, а скорость написания важнее скорости работы, лишь бы последнее укладывалось в лимит.
(если что, я однажды выходил в финал Google Code Jam, используя только питон)
что, сляпанные на коленке жаваскриптовые анимашки будут греть процессор меньше сляпанных там же флешовых аналогов?
сейчас хоть можно flashblock поставить и находиться в параллельной от них вселенной.
убьют флеш, так надо будет изобретать jQuery.animate-block какой-нибудь (иногда кажется, что уже пора)
да, в самом php деревьев нет, они на тех объемах, с которыми обычно работает php, просто не нужны.
но вы неявно используете деревья всякий раз, когда пишете «order by key» или «where key > const»
использование деревьев вместо хэшей там, где свойства деревьев не нужны — это дурь, как и использование in_array() вместо isset() для поиска во множестве с заранее известными элементами.
последнее повсеместно встречается, особенно доставляют такие проверки в цикле, привет O(N^2) и тормозам уже на паре тысяч элементов.
статья как раз для того написана, чтобы выбирали то, что надо, а не что первое вспомнится.
а нужны они затем, что перечислять элементы Map (или Set) можно хотеть:
— в любом, негарантированном порядке (HashMap, встроенные хэши в некоторых скриптовых языках)
— в порядке добавления (LinkedHashMap, встроенные хэши в некоторых других скриптовых языках)
— в порядке возрастания ключей + возможность перебрать только ключи в заданном диапазоне
и вот для последнего случая альтернатива деревьям — только полная сортировка всей коллекции после каждого изменения или перед запросом.
что долго и печально для больших коллекций, но вполне работает для небольших — поэтому в скриптовые языки деревья особо и не встраивают.
дальше читаем =)
3. почему оценки для деревьев амортизированы, когда они вполне себе worst-case?
4. почему у вас множества только immutable бывают?
«заморозить» любую коллекцию можно, а множества в виде стандартных типов (java.util.HashSet, set() в python) вполне себе изменяемы.
их можно упомянуть как упрощенный вариант map, где не надо хранить значения.
в том же php множеств нет, но они при желании эмулируются через array('key1' => true, ..);
смешаны в кучу две разные операции:
— вставка в конец (append) — амортизированное O(1)
— вставка куда угодно еще — O(N) без всяких амортизированных оценок.
смысл амортизированной оценки в том, что хотя заранее неизвестна сложность одного append-а (O(1) или O(N)), гарантируется, что суммарная сложность N append-ов — O(N), а не N*O(N) = O(N^2).
про обычную вставку это утверждение не выполняется.
2. про это не написано ни слова, но хэши в разных языках чуть отличаются, например, array в php еще содержит внутри список ключей, благодаря чему можно их обходить в порядке добавления.
(парадоксально, но тут php оказывается удобнее, несмотря на отсталость в поддержке прочих коллекций)
в остальных языках таких гарантий «по умолчанию» нет, в python 2.7+ есть отдельный тип OrderedDict, в java — LinkedHashMap.
многие реализации js тоже сохраняют порядок добавления, но насколько я помню, это не специфицировано.
модная фишка, которая вначале удивляет, но когда ее принимаются совать повсюду, начинает раздражать.
разумеется, вырубив картинки.
за те несколько минут (!), что грузилась страница, испытал лютую НЕНАВИСТЬ к любителям засунуть лишние пару сотен кило жаваскриптового говна ради какой-нибудь ерунды типа выпадающей менюшки (которую и без js спокойно можно было сделать).
подход «у кого 10+ мегабит анлима со 100% аптаймом нет — уже недочеловек» должен умереть, по крайней мере для обычных сайтов (речь не идет о сложных приложениях типа google docs)
картинки смотреть? ну так к тому же фару есть плагины быстрого их просмотра.
разные типы файлов удобно различать цветовой кодировкой их имен, а не малюсенькими иконками.
не нравятся шрифты и синюшная панель «привет из 90-х»? да, мне она тоже не нравится, но есть conemu, с ним хоть полноцветную обоину на фон поставить можно.
решение конечно не для каждого, но пользоваться вместо проводника более чем можно =)