Причина популярности очень простая — дешевизна по сравнению даже с экспортируемыми Россией свежепроизведенными патронами (Wolf etc), не говоря уже об американских. На сегодня, советские патроны — это самые дешевые патроны в США по абсолютной стоимости, дешевле даже всех пистолетных. Дешевле только мелкашка .22 LR.
По этой же причине, кстати, популярно и советское/российское оружие под них — мосинки, Сайга, АК. Мосинки вообще периодически продают ящиками — вот, например, $2500 за ящик с двадцатью винтовками. Местные выживальщики в восторге.
В гладкоствольном оружии гильзы, как правило, пластмассовые — а исторически их вообще делали из бумаги.
При этом надо заметить, что пока все напечатанное оружие было именно гладкоствольным, хотя и стреляет винтовочными либо пистолетными патронами. Парень, который делает Liberator, начал экспериментировать с нарезкой, но там проблема в том, что материал ствола мягче материала пули — и она просто стесывает эти нарезы.
Очень жаль, что XMPP «не взлетел» как универсальный IM-протокол (пусть даже и без federation между серверами). Какое-то время была реальная надежда, что он таковым будет — когда GTalk и Facebook сделали его основным, а потом подтянулся и VK. Но гугл отказывается от него в Hangouts, теперь вот и VK… FB на очереди? Проприетарщина победила. Грустно все это.
Да, не только. Быть обвиненным в дискриминации легче белому мужчине. Но это компенсируется описанными выше вещами, так что я бы не стал так категорично говорить о том, кому там труднее всего. Вот вы лично согласитесь отдавать ползапрлаты в обмен на иммунитет к обвинениям в дискриминации?
На самом деле это байка от нелюбителей толерантности, не более того. Статистика её не подтверждает — белые (и азиаты) мужчины-натуралы средних лет в США по-прежнему в среднем зарабатывают больше всех остальных при прочих равных — т.е. та же должность, опыт, стаж etc.
Белым женщинам платят в среднем на 25% меньше, при этом примерно половина этой разницы может быть объяснена объективными факторами (такими, как разница в уровне образования, в среднем меньший опыт etc), а вот другая половина — это уже чисто «налог на неправильный пол» в пользу работодателя. Латиноамериканкам платят в среднем на 35% меньше, чем белым мужчинам. Негритянкам — на 50%. Такие дела.
Браузеры — это вообще отдельная категория приложений. Там один бинарь, который может работать и в десктопном режиме, и в полноэкранном (система ему говорит, в каком режиме запускаться), и даже в последнем у него больше привилегий, чем у обычного приложения — что, в частности, позволяет иметь общие с десктопом закладки, историю etc, а также делать вещи, недоступные обычным Store-приложениям, такие, как JIT-компиляция JS. Вот здесь (.docx) есть детальный разбор этой модели.
Из Store при этом такому браузеру ставиться нельзя.
Внезапно, серверные сокеты там для того, чтобы писать серверы :)
Ну и вы же понимаете, что проверки — проверками, а правила — правилами. О нарушении последних может написать и ваш конкурент, например. И будет очень грустно раскрутить приложение до популярности, а потом внезапно быть вынужденным его убрать, потому что вся его соль может быть реализована только с нарушением правил сертификации.
С технической точки зрения можно много чего. Например, можно дать Store-приложению полный доступ к какой-либо части файловой системы, открыв таковой доступ роли «ALL APPLICATION PACKAGES». А те же пайпы используются VS для работы дизайнера XAML.
Проблема в том, что кроме чисто технических ограничений есть и ограничения Store. В которых четко прописано, что Store-приложение не может каким-либо образом завязываться на другое приложение, в т.ч. и на десктопное. Т.е. если вы честно опишете, как работает ваша система, то вы просто не пройдете сертификацию. А если умолчите и пройдете, то это рано или поздно вскроется потом…
Кстати, абсолютно такая же ситуация с большим количеством Win32 API вызовов, которые, если верить MSDN, «are not available in Windows Store apps» — вы зачастую можете их позвать, и они даже будут работать, но WACK будет на них ругаться.
Скорее всего, это относится к общим гарантиям языка, которые не зависят от реализации. Например, это будет справедливо в Jython, IronPython, или другой реализации, не использующей подсчет ссылок, и основанной на стороннем GC, не гарантирующим финализацию объектов при выходе процесса. Как написано в самом начале этой же страницы документации:
«Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether — it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable.»
Разница между str во втором питоне и bytes в третьем на самом деле не такая большая. По сути и то, и другое — неизменяемый массив байт. Более того, у них даже С-реализация идентичная между 2.6 и 3.3 вплоть до имен полей в структуре. Если все время использовать явные преобразования к юникодным строкам через encode, и индексировать только срезами, то вполне можно писать переносимый код.
В наиболее распространенном русском переводе «The C++ Programming Language» этой теме был посвящен довольно-таки большой параграф во вступлении от переводчиков. В той книге они использовали для перевода «statement» слово «инструкция». Я думаю, достаточно большое количество русскоговорящих разработчиков на C++ начинали именно с этой книги, или, во всяком случае, читали её на каком-то этапе — так что в плане терминологии её можно использовать как некоторого рода стандарт.
Проблема в отсутствии типов в том, что тогда пропадает автодополнение на возвращаемых значениях. Т.е. скажем:
checkbox = qtgui.QCheckBox() # ok
parent = checkbox.parentWidget() # автодополнение показывает метод, но не его параметры/результат
parent. # тип parent неизвестен, не показывается ничего
RC будет нескоро :) но багфиксы мы выкладываем в репозиторий на CodePlex сразу, как только они реализуются, так что он там будет в понедельник (сейчас праздники и все в разъездах). Зависимости для сборки у нас минимальны — для ядра продукта, если не собирать всякие там HPC или Kinect, нужен только VS SDK.
Попутно еще немного поигрался с PySide. С фиксом code completion в PTVS для него работает на достаточно примитивном уровне — есть списки модулей, в них классы, и в классах члены. Но никакой информации о типах аргументов и возврата уже нет, что и понятно — все функции определены в нативных модулях, поэтому про type inference можно забыть. Попробовал в PyCharm — там вроде бы та же картина.
В связи с этим возник вопрос: есть ли интерес в добавлении фичи, которая позволила бы подключать внешную информацию о типах для произвольных модулей, которую можно было бы автоматически генерировать для библиотек типа PySide/PyQt (т.к. там исходный API типизирован), или писать руками для других библиотек?
Она не то что бы принципиально другая, но в десятке было достаточно много новых API, на которые мы завязались. Кроме того, в коде также активно используются возможности .NET 4 (например, TPL), а для 2008 нужно писать на 3.5 SP1.
Так что в итоге, да, овчинка выделки не стоит. Но если нет необходимости работать с многоязыковыми проектами, то как вариант всегда есть бесплатный VS Shell.
7.62x54
5.45x39
Причина популярности очень простая — дешевизна по сравнению даже с экспортируемыми Россией свежепроизведенными патронами (Wolf etc), не говоря уже об американских. На сегодня, советские патроны — это самые дешевые патроны в США по абсолютной стоимости, дешевле даже всех пистолетных. Дешевле только мелкашка .22 LR.
По этой же причине, кстати, популярно и советское/российское оружие под них — мосинки, Сайга, АК. Мосинки вообще периодически продают ящиками — вот, например, $2500 за ящик с двадцатью винтовками. Местные выживальщики в восторге.
При этом надо заметить, что пока все напечатанное оружие было именно гладкоствольным, хотя и стреляет винтовочными либо пистолетными патронами. Парень, который делает Liberator, начал экспериментировать с нарезкой, но там проблема в том, что материал ствола мягче материала пули — и она просто стесывает эти нарезы.
Белым женщинам платят в среднем на 25% меньше, при этом примерно половина этой разницы может быть объяснена объективными факторами (такими, как разница в уровне образования, в среднем меньший опыт etc), а вот другая половина — это уже чисто «налог на неправильный пол» в пользу работодателя. Латиноамериканкам платят в среднем на 35% меньше, чем белым мужчинам. Негритянкам — на 50%. Такие дела.
Из Store при этом такому браузеру ставиться нельзя.
Ну и вы же понимаете, что проверки — проверками, а правила — правилами. О нарушении последних может написать и ваш конкурент, например. И будет очень грустно раскрутить приложение до популярности, а потом внезапно быть вынужденным его убрать, потому что вся его соль может быть реализована только с нарушением правил сертификации.
Проблема в том, что кроме чисто технических ограничений есть и ограничения Store. В которых четко прописано, что Store-приложение не может каким-либо образом завязываться на другое приложение, в т.ч. и на десктопное. Т.е. если вы честно опишете, как работает ваша система, то вы просто не пройдете сертификацию. А если умолчите и пройдете, то это рано или поздно вскроется потом…
Кстати, абсолютно такая же ситуация с большим количеством Win32 API вызовов, которые, если верить MSDN, «are not available in Windows Store apps» — вы зачастую можете их позвать, и они даже будут работать, но WACK будет на них ругаться.
«Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether — it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable.»
RC будет нескоро :) но багфиксы мы выкладываем в репозиторий на CodePlex сразу, как только они реализуются, так что он там будет в понедельник (сейчас праздники и все в разъездах). Зависимости для сборки у нас минимальны — для ядра продукта, если не собирать всякие там HPC или Kinect, нужен только VS SDK.
Попутно еще немного поигрался с PySide. С фиксом code completion в PTVS для него работает на достаточно примитивном уровне — есть списки модулей, в них классы, и в классах члены. Но никакой информации о типах аргументов и возврата уже нет, что и понятно — все функции определены в нативных модулях, поэтому про type inference можно забыть. Попробовал в PyCharm — там вроде бы та же картина.
В связи с этим возник вопрос: есть ли интерес в добавлении фичи, которая позволила бы подключать внешную информацию о типах для произвольных модулей, которую можно было бы автоматически генерировать для библиотек типа PySide/PyQt (т.к. там исходный API типизирован), или писать руками для других библиотек?
Так что в итоге, да, овчинка выделки не стоит. Но если нет необходимости работать с многоязыковыми проектами, то как вариант всегда есть бесплатный VS Shell.