тема безусловно интересная и похоже, что автор обладает поистине энциклопедическими знаниями в этой области. однако читать такой поток сознания с картинками совсем не просто. :)
допустим, голосуют двое:
5, 4, 3, 2, 1 — первый
1, 2, 3, 4, 5 — второй
хотя у каждого проголосовавшего в отдельности порядок предпочтений определен, в сумме получается, что все претенденты набрали по 6 баллов, и определить объективного победителя невозможно. как я понял, в этом и состоит «парадокс Кондорсе».
ага, и так необходимая всем минеральная вода отсеялась уже бы в первом туре. (
«много туров» адекватно работает, например, в спорте, где участники состязаются между собой в решении какой-то объективной задачи, результат решения которой можно измерить (например, кинуть что-нибудь дальше всех, или проплыть быстрее) — т.е. дать ему формальную оценку. но это принципиально отличается от случая с демократической политой, где у участников нет объективной задачи, а сама оценка одновременно является и результатом, за который идет «борьба». отсюда все заморочки. систем голосования, различной степени сложности, придумана масса, но приемлемого результата нет (в статье есть ссылка на теорему Эрроу). возможно сама постановка порочна.
на интуитивном уровне, от систем голосования хочется формализации некоего чувства справедливости. если она может давать иные результаты, это неправильная система. в системе с простым большинством голосов результат может не отражать основные предпочтения избирателей. это показывает пример.
второй тур может еще сильнее исказить картину. допустим, втором туре победит «квас», как оппозиция тех кто против «водки». но будет-ли этот результат справедлив — ведь истинных любителей кваса, как показал первый тур, только двое (20%)? данная система на этот вопрос ответ не дает. единственный плюс таких систем — результат есть всегда.
Кондорсе, решая эту проблему предложил, систему, где голосующие должны не просто выбирать одного из кандидатов, а ранжировать претендентов согласно своим предпочтениям. в ней результат может сильно отличаться от «абсолютного» (скажем, может победить «минеральная вода», если она окажется у всех на втором месте как самая востребованная — алкоголики лечат печень, трезвенники уталяют жажду, кто-то бадяжит квас и т.п.) но сам же нашел парадокс в возможности ситуации, если голоса оказываются симметричны, то сделать выбор становится не возможным.
кажется, пример с напитками, скорее, иллюстрирует одну из ключевых проблем мажоритарной системы голосования, нежели сам парадокс (возможность ситуации когда голоса, в сумме, получаются противоречивы). поэтому хочется продолжения. спасибо за то, что подняли интересную тему.
Подписываем наши функции на рассылки:
>>> subscribe('insertors', fun)
>>> subscribe('insertors', bar)
ммда, такие примеры можно называть паттернами, в каком-то узком смысле, просто потому, что они достаточно типичны. но на роль хороших архитектурных приемов, они, по-моему, не годятся уже лет как тридцать.)
как выше заметил bolk, в статье перепутаны ФП и процедурное программирование — практически во всех примерах видны все стандартные грабли этого подхода, связанных с плохо инкапсулированным состоянием. как раз ООП с этим и борется, за счет «развесистых схем классов», а в ФП состояния не должно быть как такового (во всяком случае в таком совсем уж явном виде).
абстракция является одной из основных концепций программирования. поэтому что угодно можно написать на чем угодно. в С тоже можно программировать в ООП стиле, думая про классы, наследование и т.п. и в JavaScript ни кто не мешает эмулировать классы через прототипы и клонирование.
в остатке остается лишь чисто инженерный вопрос — вычислительная стоимость подобных развлечений. оптимизация на уровне мета-модели стоит дорого, а зачастую и вовсе не реализуема — поэтому получается хоть и похоже, но на порядок медленнее. вот и вся разница. :)
расскажите, что вы называете термином «Остров»? обычный сниппет выдаче это остров? или остров это некоторая группа сниппетов? а может быть остров это представление сайта в поисковой выдаче где есть интерактивная форма? а врезка это остров?
потому, что трюк с переименованием не сработает для неподконтрольного нам (библиотечного) css, а у нас такого вагон. плюс есть общие стандарты, где нет ничего про scss. тут проще sass закастомайзить, но пока меня этот вариант немного пугает (какой sass? какая кастомизация? ведь хочется лишь source maps для объединенного css чтобы сделать разработку еще чуть проще).
не собирать все в один файл это оффтоп, т.к. source maps в таком случае вообще не нужны )
вот и хочу узнать ответ на этот вопрос. :) навскидку, утилита sass не применяет к css файлам всяческие полезности scss, скажем не инлайнит import. а менять css на scss не вариант, т.к. это куча, в том числе стороннего кода.
любопытно, можно-ли эту штуку адаптировать для более простого (и думаю распространенного) случая, когда результирующий CSS собирается по кусочкам из отдельных CSS-файлов? вроде как SASS это надмножество CSS.
может есть какая-то генерилка sourcemap для такого случая и если есть получится-ли воспользоваться функциональностью хрома?
чудо-поиск, индексация и прочий автокомплит в ST2 нормально работают лишь с локальными файлами. работать с реальными проектами, поверх сетевых файловых сиситем, мне показалось непрактичным (может сеть такая :()
механика плагина sftp в этом смысле вполне адекватна — саблайм работает с локальными файлами, а плагин предоставляет кучу ручек для разных вариантов синхронизации с удаленной машинкой. но если при синхронизации падает соединение, то, действительно, спасает лишь перезапуск саблайма. а еще он ацкий тормоз при копировании большого количества файлов. было бы круто, если бы они запили в качестве транспорта rsync, вместо костылей над sftp.
еще можно повесить github.com/axkibe/lsyncd. правда в этом случае синхронизация выполняется асинхнонно, и при кодинге сильно не хватает обратной связи со стороны редактора (не понятно, файл синхронизировался с удаленной машинкой или еще нет).
Модель Солоу или модель Солоу-Свана — неоклассическая модель экономического роста Роберта Солоу, основанная на неоклассической производственной функции (например, на производственной функции Кобба-Дугласа) с учетом экзогенного нейтрального технического прогресса
вот почему в русскоязычной wiki сначала идет куча непонятных терминов и формул, а где-то в конце статьи можно найти пару прикладных выводов. а в анлоязычной — сначала прикладное описание, а формулы в конце? %)
5, 4, 3, 2, 1 — первый
1, 2, 3, 4, 5 — второй
хотя у каждого проголосовавшего в отдельности порядок предпочтений определен, в сумме получается, что все претенденты набрали по 6 баллов, и определить объективного победителя невозможно. как я понял, в этом и состоит «парадокс Кондорсе».
«много туров» адекватно работает, например, в спорте, где участники состязаются между собой в решении какой-то объективной задачи, результат решения которой можно измерить (например, кинуть что-нибудь дальше всех, или проплыть быстрее) — т.е. дать ему формальную оценку. но это принципиально отличается от случая с демократической политой, где у участников нет объективной задачи, а сама оценка одновременно является и результатом, за который идет «борьба». отсюда все заморочки. систем голосования, различной степени сложности, придумана масса, но приемлемого результата нет (в статье есть ссылка на теорему Эрроу). возможно сама постановка порочна.
второй тур может еще сильнее исказить картину. допустим, втором туре победит «квас», как оппозиция тех кто против «водки». но будет-ли этот результат справедлив — ведь истинных любителей кваса, как показал первый тур, только двое (20%)? данная система на этот вопрос ответ не дает. единственный плюс таких систем — результат есть всегда.
Кондорсе, решая эту проблему предложил, систему, где голосующие должны не просто выбирать одного из кандидатов, а ранжировать претендентов согласно своим предпочтениям. в ней результат может сильно отличаться от «абсолютного» (скажем, может победить «минеральная вода», если она окажется у всех на втором месте как самая востребованная — алкоголики лечат печень, трезвенники уталяют жажду, кто-то бадяжит квас и т.п.) но сам же нашел парадокс в возможности ситуации, если голоса оказываются симметричны, то сделать выбор становится не возможным.
ммда, такие примеры можно называть паттернами, в каком-то узком смысле, просто потому, что они достаточно типичны. но на роль хороших архитектурных приемов, они, по-моему, не годятся уже лет как тридцать.)
как выше заметил bolk, в статье перепутаны ФП и процедурное программирование — практически во всех примерах видны все стандартные грабли этого подхода, связанных с плохо инкапсулированным состоянием. как раз ООП с этим и борется, за счет «развесистых схем классов», а в ФП состояния не должно быть как такового (во всяком случае в таком совсем уж явном виде).
в остатке остается лишь чисто инженерный вопрос — вычислительная стоимость подобных развлечений. оптимизация на уровне мета-модели стоит дорого, а зачастую и вовсе не реализуема — поэтому получается хоть и похоже, но на порядок медленнее. вот и вся разница. :)
если все равно нужно что-то вызывать, в чем преимущество по сравнению с тупо «bower install»?
не собирать все в один файл это оффтоп, т.к. source maps в таком случае вообще не нужны )
может есть какая-то генерилка sourcemap для такого случая и если есть получится-ли воспользоваться функциональностью хрома?
читал по диагонали. охренел. %)
механика плагина sftp в этом смысле вполне адекватна — саблайм работает с локальными файлами, а плагин предоставляет кучу ручек для разных вариантов синхронизации с удаленной машинкой. но если при синхронизации падает соединение, то, действительно, спасает лишь перезапуск саблайма. а еще он ацкий тормоз при копировании большого количества файлов. было бы круто, если бы они запили в качестве транспорта rsync, вместо костылей над sftp.
еще можно повесить github.com/axkibe/lsyncd. правда в этом случае синхронизация выполняется асинхнонно, и при кодинге сильно не хватает обратной связи со стороны редактора (не понятно, файл синхронизировался с удаленной машинкой или еще нет).
вот почему в русскоязычной wiki сначала идет куча непонятных терминов и формул, а где-то в конце статьи можно найти пару прикладных выводов. а в анлоязычной — сначала прикладное описание, а формулы в конце? %)
при таком способе формирования регулярки, подставляемые значения нужно re.escape()'ить.