В очередной раз не стал ребёнку читать детскую сказку (в которой, конечно же, кого-то убивают или съедают) и понял вот что... Довольно большая часть моих личных детских страхов была связана именно со сказками. Потерял ли бы я что-то, не знай я тех сказок в свои три года? Думаю, что кроме своих страхов ничего бы не потерял. Потому что кроме боязни они ничему и не учат. Так нафига такие сказки тогда. Пусть мои дети их и не знают. Подрастут - узнают и посмеются, а до поры - не надо.
Австралийцы вздумали проводить что-то типа всегосударственного опроса по поводу однополых браков, разрешить ли их. Это не референдум (законной силы он не имеет), но будет единый день голосования.
Из любых обсуждений сразу бросается в глаза яркое разделение людей и крайне агрессивное поведение тех, кто "за" и тех, кто "против". Но большинство - пассивно и вообще не понимает, чего эти все хотят. Таким образом, мы видим типичное в политике: активные 2% пытаются создать такую ситуацию, чтобы пассивным 86% было комфортнее примкнуть к кажущемуся "общему мнению" и таким образом создать легитимность "мы все этого хотели".
И тут уже все средства хороши: подлог фактов, оскорбление оппонентов, обзывание одних "пидарасами" других "пещерными людьми", запугивание наблюдающей публики всякими страшными последствиями. Политика - это отвратительно. У меня было своё мнение но я не хочу иметь ничего общего ни с одной ни с другой стороной.
Я вообще считаю неверным контекст этой проблемы.
Если идти дальше, то почему не разрешить брак более чем двух людей? Во многих культурах это принято. На и свингеры будут за. А почему брак обязательно - только между людьми? Я слышал, один человек завещал всё своё состояние своей кошке. И т.д.
Но настоящая проблема - в том, что устарел сам институт брака. Об этом многие говорят, но что-то делать боятся. Геям-то и так уже терять нечего, а вот нормальный человек может просто в один момент превратиться в политический труп если только заикнётся об этом.
Например, если есть договор: "обязуемся жить в одном доме, спать в одной кровати, доход переводить на общий счёт, тратить совместно и т.д.", то кого вообще будет волновать, какого пола эти люди и сколько их? Договор подписали - выполняйте. Развод? А вот тогда обращаемся к пункту "расторжение договора".
Опять вошёл в фазу разглядывания языков программирования.
R в целом выглядит перспективно, но к сожалению, не использует устоявшуюся терминологию, из-за чего в нём достаточно тяжело разбираться только из-за того, что по названию невозможно догадаться, что делает функция и как найти то, что надо.
Julia по описанию - что-то совершенно волшебное: система типов, макросы, компиляция всегда прямо в native (из-за чего по скорости уделывает всё что можно). Но ... массивы индексируются с 1. Как жаль, что вся эта красота должна умереть 😈
Честно говоря, началось это с того, что мне показалось, что R мог бы заменить для меня gnuplot. Давно хотел для себя заменить его на хоть что-то более современное, удобное и желательно, с полноценной возможностью программирования, но нет. Похоже, что пока в природе такая вещь просто отсутствует.
Gnuplot прекрасен ровно тем же, чем прекрасен Perl: простые вещи на нём делаются действительно просто, но при этом, если надо можно перейти к гораздо более сложным вещам. Это свойство создаёт действительно универсальные инструменты.
И это - инструменты, которыми хочется пользоваться. Большинство вещей начинаются как прототип и для разработки не хочется заранее думать: "а это у меня будет ерунда на выброс или большой серьёзный проект" и, исходя из этого, заранее выбирать инструмент. К тому же, "большом проекте" будет много накладных расходов и минимальный выхлоп будет стоить дорого. Гораздо интереснее - просто взять и сделать, а потом, если надо, увеличить масштаб.
{для непрограммистов: FIFO: First In - First Out, первый пришёл - первый пошёл; LIFO: Last In - First Out, последний пришёл - первый пошёл}
Началась эта история как обсуждение того, в каком порядке сервер должен обслуживать запросы и я услышал мысль о том, что есть смысл делать это не в том порядке, в котором они приходят, а в обратном.
Сначала я это воспринял как шутку, но после того, как понял, что это всерьёз, эта мысль меня больше не отпускает и я даже начинаю использовать обратный порядок для своих личных дел.
Изначально парадокс состоит в том, что FIFO выглядит "естественно" и даже "честно". Тот, кто пришёл раньше, уже ждёт дольше, его надо бы обслужить, а тот, кто только что пришёл, не так уж сильно обидится, если подождёт ещё немного.
В чём же выгода LIFO при обработке запросов или обычных своих дел?
Тут надо рассмотреть несколько факторов из реальной жизни.
1. Разница в этих алгоритмах начинает проявляться только тогда, когда дел в очереди накапливается больше одного, т.е. когда мы (или сервер) не успеваем обрабатывать дела по мере их поступления. Пока мы делаем одно, в очереди уже накопилось ещё несколько. Поэтому сразу будем рассматривать случаи, когда очередь дел у нас не пустая.
2. [Почти] У каждого дела есть дэдлайн, время, до которого оно должно быть сделано, а после оно уже не имеет смысла (но может превратиться в одно или несколько других дел). Поэтому если у нас поток запросов - такой большой, что мы заведомо с ними не справляемся, то нам так или иначе ПРИДЁТСЯ оставлять какие-то дела несделанными. Тут уже наступает ощутимая разница между FIFO и LIFO: доля несделанных дел будет ровно такая же, зато вот время на выполнение дел, которые будут сделаны, будет значительно лучше! Ведь мы выполняем дела, которые только что поступили в список. А до тех, которые там лежат давно, уже менее вероятно, что вообще дойдёт. Но если дело всё равно не будет сделано, то для результата нет и никакой разницы, в каком именно месте этого списка оно пролежало: в начале или в конце.
3. Представим, что режим работы у нас - "всплесками": мы в короткий промежуток времени получаем пачку заданий и потом у нас - тишина и времени достаточно на выполнение всего. В этом случае мы будем успевать и в режиме FIFO и в режиме LIFO, при этом СРЕДНЕЕ время выполнения заданий будет ровно одинаковым. Просто FIFO выполнит все задания в прямом порядке, LIFO - в обратном. Иногда этот нюанс бывает важным, если задания между собой как-то связаны, но если они независимы, но это всё равно. При небольшом интервале между заданиями в пакете, у FIFO будет меньше разброс во времени выполнения задачи с момента попадания в очередь; у LIFO разброс будет больше, но лучше будет минимальное время, за которое удалось справиться. Иногда минимальное время важно для отчётности.
Что мы имеем в результате? * При небольших нагрузках разницы нет * При средних нагрузках минимальное время лучше - у LIFO, максимальное - у FIFO, среднее - равно. * При высоких нагрузках однозначно выигрывает ... (тадааам!) LIFO!
Неожиданно, да? Выполнение заданий задом на перёд улучшает вашу производительность!
Кроме этого, для обычных человеческих дел тут ещё начинает играть роль психологический фактор: дело иногда откладывается и попадает в очередь по причине того, что его почему-то делать не хочется, не удобно, тяжело, [подберите отмазку]. И если человек для себя руководствуется принципом FIFO, то эти "неприятные" дела могут тормозить выполнение чего-то действительно простого - просто потому, что простые дела в списке идут "после". В случае же LIFO просмотр дел всегда начинается с новых дел и у них всегда есть шанс быть сделанными прямо сейчас!
Со времени этого открытия для меня прошёл почти год, но до меня всё продолжают доходить новые и новые замечательные свойства этого подхода.
Оказывается, когда в северном полушарии время переводят вперёд, то в южном переводят назад, т.е. разница часовых поясов зимой и летом может меняться на 2 часа.