Насколько помню, там всё гораздо интереснее. В конце книги, главный герой действительно, искренне начинает любить правительство, а всю предыдущую борьбу считает иллюзией и заблуждением.
Он не на python написан, а на RPython, это (синтаксически) подмножество python, но по сути Си-подобный язык (который, собственно, в си и транслируется).
Как владелец Nexus (7) могу с уверенностью сказать, что в 4.1 действительно отсутствует фича подтормаживания, но в 4.2 они исправили этот досадный баг, и 4.2 (у меня, по крайней мере) тормозит иногда похлеще, чем старенький андроидофон.
Ну вы же понимаете, что если инструмент может влиять на производительность, но зачем он нужен такой, особенно в серверной ОС, где каждый показатель может быть узким местом? В случае с Task Manager, для отображения iops'ов, необходимо, чтобы в фоне постоянно крутился счетчик производительности. Есть специальный инструменты, работающие ondemand, а именно — Performance Monitor.
Что за подход «может влиять», «может быть узким местом»? Еще раз, автор топика поменял лишь (насколько я понял) отрисовку столбцов, то есть «счетчики производительности» как крутились так и крутятся. Скрыты они были примерно так же, как закрыть глаза ладонями.
Единственно возможный сценарий, где сокрытие действительно оправдалось бы — это если в дальнейшем коде системный монитор действительно будет включать какие-то системные службы, следящие за производительностью. Но тогда это и есть «on demand», о котором вы говорили.
Насколько помню из топика на hacker news — с линуксом на ультрабуках сейчас всё плохо. Думаю, что надо подождать тотальной популярности ультрабуков, прежде чем линукс сможет «из коробки» поддерживать все прелести.
Очевидно, что я учёл момент перестраивания и пробовать писать в функциональном стиле начал не вчера.
Когда речь идёт о какой-нибудь свёртке или чём-нибудь подобном, действительно хвостовая рекурсия прекрасна (хотя обычно всё укладывается в map/reduce/filter). Но когда вычисление содержит счётчик, или же дополнительное хранилище «состояния» — вы начинаете гнуться под концепцию.
Я считаю, что хвостовая рекурсия хороша тогда, когда каждый её шаг обособлен и может быть рассмотрен в изоляции, а не содержит кучу аргументов а ля counter, i, j.
Вот как раз хвостовая рекурсия на мой вкус в большинстве случаев гораздо менее читаема, чем обыкновенный for, т.к. при хвостовой рекурсии вы, фактически, «состояние», необходимое для просчетов, распихиваете в аргументы функции. Сейчас читаю SICP и каждый раз когда нужно делать хвостовую рекурсию у меня начинает ум за разум заходить, очень не хватает for i in… родного.
Как раз наоборот, каждый шаг прост и понятен. А SQL обычно превращается в гигантский «blob-запрос», который нельзя трогать руками иначе всё сломается. Ну и здесь еще соль в том, что всё поддаётся концепции map/reduce (по сути, этот язык — надстройка над типичными операциями map/reduce), а потому все данные проходят через некоторые пайпы, а значит всё прозрачно с точки зрения памяти, необходимой для обработки данных.
> Например глюк с обновлением самого SDK, при котором он не может переписать некоторые файлы, потому что они запущены (exe-шники или dll). Не уверен, пофиксили это или еще нет, но несколько версий подряд проблема существовала и решалась либо танцами с бубном в командной строке, либо полным сносом и переустановкой всего SDK.
What To Know Before Debating Type Systems blog.steveklabnik.com/posts/2010-07-17-what-to-know-before-debating-type-systems
Что за подход «может влиять», «может быть узким местом»? Еще раз, автор топика поменял лишь (насколько я понял) отрисовку столбцов, то есть «счетчики производительности» как крутились так и крутятся. Скрыты они были примерно так же, как закрыть глаза ладонями.
Единственно возможный сценарий, где сокрытие действительно оправдалось бы — это если в дальнейшем коде системный монитор действительно будет включать какие-то системные службы, следящие за производительностью. Но тогда это и есть «on demand», о котором вы говорили.
Когда речь идёт о какой-нибудь свёртке или чём-нибудь подобном, действительно хвостовая рекурсия прекрасна (хотя обычно всё укладывается в map/reduce/filter). Но когда вычисление содержит счётчик, или же дополнительное хранилище «состояния» — вы начинаете гнуться под концепцию.
Я считаю, что хвостовая рекурсия хороша тогда, когда каждый её шаг обособлен и может быть рассмотрен в изоляции, а не содержит кучу аргументов а ля counter, i, j.
Я думал это сто лет известная проблема Windows.