- 1
BigInteger.ONE-
Java / Говнокод #15505
+65
Запостил:
LispGovno,
17 Марта 2014
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Объекты BigInteger иммутабельные. Зачем оллолоцировать на куче множество копий нулей и единиц, если можно закешировать их в статических полях?
что это такое?
Я думаю, всем понятно, что складывать напрямую машинное слово и длинное число нельзя. Надо сначала привести машинное слово к длинному числу. Да, жаба не предоставляет возможности вводить кастомные преобразования типов и перегружать операторы, отчего 2+2 начинает выглядеть как:
> все происходит от плохой / непродуманой системы типов
В хаскеле хорошая, тщательно продуманная система типов. Но складывать Int с Integer она не позволяет. Потому что от неявных преобразований почти всегда больше проблем чем пользы. Но там константы не имеют конкретного типа, поэтому 2 + 2 можно писать как есть.
Для того, чтобы это понять, нужно сначала четко сформулировать понятие языка програмирования. Я не буду вдаваться в подробности, ограничусь только заявлением, что ЯП сам по себе не может ни в математику, ни в обработку строк, ни в определение объектов, методов, разделение окружений выполнения. Все вышеперечисленое - АПИ системы языка.
Системы могут отличаться как количественно, так и качественно, например, система в которой есть математика по модулю но нет обычной математики просто представляет меньше АПИ, но качественно не отличается в этом аспекте. С другой стороны, система может предоставлять сборщик мусора, отладчик, различные средсва ввода-вывода, иногда даже графические примитивы, встроенные библиотеки алгоритмов, высокоуровневые конструкции языка и т.д.
Компилятор и граматика языка - такие же элементы системы, ее АПИ.
Мой предыдущий пост о том, что АПИ Ява системы ущербный и непродуманый, т.как заставляет:
1. много писать (лишнего).
2. изза непродуманости системы приводит к созданию курьезных / лишних объектов (нет и в принцыпе не может быть необходимости в BigInteger.ONE - если это же значение можно представить как уже закешированые, или не нуждающиеся в кешировании численые типы.)
В Хаскеле хорошая система типов? Лол :) В Хаскеле одни извращения. В этом языке сделано все возможное для того чтобы максимально затруднить работу с типами только ради того, чтобы компилятору с ними было легче работать.
И да, какое (хотя бы интуитивно, если определения языка нет) место в этой системе понятий занимает язык? Это сущность, охватывающая грамматику языка, систему и API (например, в книгах по Haskell рассказывают не только про буквы, но и про соответствующую математику), или же это как раз все beginы-endы, стоящие в стороне от системы (как в .NET, где можно писать на разных языках одно и то же), или что-то другое, или по-разному бывает?
Но этим описание не оканчивается, примерно так же, как на функтор между категориями можно смотреть и как на диаграму между теми же категориями, при этом, все действующие лица остаются те же, но рассматриваемый аспект - другой. Так, например, можно выделить правила граматики в отдельную групу, и рассматривать их как АПИ к языку. Это особенно актуально, если в языке есть возможность манипулировать этими правилами.
Другие примеры: предоставление доступа к памяти в которой располагается програма (или ее данные) - то же АПИ языка (указатели в разных языках - функции этого АПИ).
Исключения - так же можно рассматривать как АПИ системы языка, в очень похожем контексте, т.как они предоставляют АПИ функции по работе с control flow (хз. как по-русски).
Конкретные претензии в студию.
Все эти возможности приходится эмулировать через уебищные многоэтажные описания типов, которые не только составить сложно, но и читать потом - каждый раз глаза ломать.
Компилятору, с другой стороны - читать эти описания не сложно, он парень привычный, и вообще, он - робот. А хачкелисты умиляются глядя на груды наворочаных описаний которые они приделывают к простым понятиям, потому что эти груды делают их важными и умными в глазах неискушенного зрителя.
> Нет возможности вернуть больше одного значения.
Естественно, потому что любая функция унарна по определению функции. Переменное число аргументов или результатов — слаботипизированная динамическая ересь.
> Нет опциональных параметров.
> Нет возможности назначить значения по умолчанию аргументам
> нет возможности указать аргументы в произвольном порядке
Потому что они ломают вывод типов. Тут или крестик снять, или трусы надеть.
И главное — это всё НЕ система типов, это грамматика и синтаксический сахар. Система типов — это, например, «строгая номинативная статика без сабтайпинга с глобальным выводом типов по Хиндли-Милнеру». Учите матчасть, короче. Рекомендую начать с TaPL.
Любая програма на Хаскеле выглядит как поединок из какой-нибудь американской комедии, где боец делает десять подъемов с разгибом перед тем как ударить противника. Т.е. комичность вызваная несоразмерностью затраченного усилия и эффекта. В Хаскеле все програмы выглядят так, как будто вместо того, чтобы решить поставленую задачу програмист решил доказать теорему Пифагора пользуясь только ко-конами ко-ко-морфизмов из ко-котегорий в ко-ко-котегории. А результат получился случайно.
Публика, конечно, увидев такое мастерство, апплодирует стоя.
Не нравится, что назвали функцией - назовите процедурой, только сделайте так, чтобы оно делало то, что нужно. Бесполезные, но правильные системы бесполезны.
Ситуация очень сильно напоминает ситуацию с реляционными базами данных. Реляционная алгебра - очень простой и с претензией на глобальность математический формализм, но в жизни очень мало вещей которые хорошо описываются квадратно-гнездовым методом, и поэтому формализм не применим практически ни к одной жизненой ситуации, если к нему не пристроить костылей. Ну и, естесственно, промышленост занимается восновном постройкой костылей вместо того, чтобы более критически пересмотреть соответствие домейна и возможностей системы.
> в жизни такие функции отвественны за бесконечно маленький процент всего, что можно в жизни описать?
Наверное потому, что через функции с одним параметром можно выразить вообще все функции. Ваш Кэп.
>> Конкретные претензии в студию.
Юра, претензия всегда одна. XXX - говно, т.к. XXX не является коммон лиспом.
что посоветуете?
Если нужны подробности, с детальным обоснованием нужно читать оф. публикации, например, ГрГр или ГП (я сейчас пытаюсь разобраться с ГП).
Единственный аргумент в пользу реляционных баз данных - это то, что они хорошо исследованы. Но исследования показали, что это бесперспективная область.
Как весьма эффективно хранить и процессить однородные столбики чисел мне в целом понятно. Как эффективно хранить и обрабатывать большие графы с произвольными свойствами - совсем нетривиальный вопрос.
Что скажете про этого зверя?
Ну а если по делу, то ничего про это сказать не могу. У нас свой велик с темпоральным графом объектов, хранящийся в убогой тормозной PostgreSQL, прекрасно справляющейся с нагрузкой.
> stored in memory
The base v2 implementation acts similar to the MEMORY engine, it uses table-level locking, does not support transactions, and has no persistence.
The v3 prototype implementation acts as a shim on top of an existing storage engine (such as InnoDB), thus providing capabilities such as persistence as well as allowing larger graphs.
Если я правильно понял, то версия v2 предназначена чисто для вычислений, а в разрабатываемой v3 появится возможность хранить на диске.
Смысл очень простой, очень похож на то, как посторена куча в простеньком ВМе. Хранятся указатели в таблице, указатели все одного размера, для отдельных типов - отдельные хранилища, куда эти указатели могут указывать.
С точки зрения скорости - не сравнимо с тем же Сиквелайтом. Т.е. разница даже не в разы, а в степени.
Проблема с ней в другом: полезные абстракции.
Я не пытался сравнивать скорости серверных ДБ разных типов, т.как мне просто нигде не нужно было. Но я знаю, что ОпенКог написали на основе Беркли графовую базу, которая должна быть и очень быстрой и навороченой. И ее в принципе можно было бы просто обернуть в какой-нибудь простенький сервер, то можно было попробовать. В любом случае такие сравнения не корректны, т.как нужно как-то относиться к затратам на передачу данных, реализацию сервера и т.д. а не самой БД.
> разница даже не в разы, а в степени.
С высоты птичьего помёта не особо верится: современная рахитектура обычно очень не любит прыгать по памяти взад-вперёт при чтении.
Ну и sqlite опять же с диска всё читает и транзакции поддерживает с полным ACID. А вот белочка-то ваша в шареной памяти работает, наверняка D из ACID у неё выпадает. А сравнивать работу с основной памятью и с диском ну как-то не очень спортивно. Магии не бывает. Так что пока всё в точности как в ролике про веб-скейл.
И да, нужно понимать, что сравнивать. Так вот Сиквелайт не сможет "без транзакций" и без того чтобы с диска читать добиться той же скорости (в нем можно создать ин-мемори таблицы и с ними поработать - все равно тормоз).
Сиквел, в принципе не пригоден для какого-либо не-тривиального поиска по базе. Он умеет только извлекать информацию, если точно знать, где она находится. На задачах типа поиска, он естесственно скатывается вникуда.
> он естесственно скатывается вникуда
Любому вменяемому инженеру должно быть понятно, для разных задач нужны разные модели и хранилища. К слову, к реляционным базам нередко прикручивают вполне сносные решения с биграмными индексами для нечёткого поиска. Но они сливают специализированным системам, страдающим другими недостатками.
Если вам лично что-то не требуется, это не значит, что это никому не нужно. Голословно утверждать, что реляционная модель нинужна и тормозит означает фактически расписаться в собственной некомпетентности.
Я только говорю о сравнении в более-менее одинаковых условиях.
Нечеткий поиск - одна из миллиона вариаций поиска, и в целом ничего не меняет. Сиквел концептуально не подготовлен к тому, чтобы в нем что-то искали. От каких-то примочек ничего не изменится.
Под поиском я понимаю алгоритмы поиска, типа поиска в ширину, в глубину, первый-лучший, поиск лучем, с ограничением на глубину, с разного рода евристическими функциями, мин-макс "или" поиск и я только небольшой процент назвал.
Поиск, как и транзакции не входят в список задач решаемых реляционной алгеброй, но только почему-то отсутствие первого подается как несущественный недостаток, который вообще и не недостаток, а слабоумие и отсуствие инжинерной мысли у того, кому он нужен, а второе - несомненное достоинство и предмет гордости.
Видимо потому, что большинство инженерных задач подразумевает одновременную работу туевой хучи процессов\потоков\юзеров с базой. И недалеким людям из банков, телекомов и прочих магазинов за каким-то хреном нужны такие бесполезные свойства как ACID. И почему-то этим слабоумным глупцам не нравится, когда действия применяются не полностью, ведут себя как кот шрёдингера, мешают друг другу или вообще не сохраняются на диске при внезапном рестарте...
А если к этой красивой графовой базе привернуть full ACID - она тоже начнет лагать как говно. Хотя не спорю, задачи с графами она будет решать все же быстрее, чем реляционка :)
Но смысл то не в этом, а в том, что транзакции стали вдруг аргументом в пользу реляционных баз данных, хотя напрямую с ними не связаны.
Внезапно, но реляционка тоже не знает заранее, что именно она будет блокировать во время транзакции. Там все по принципу надейся на лучшее, готовься к худшему.
> нельзя в такой же степени навредить друг другу не заблокировав данные
Ну подумаешь граф будет немножко неправильным из-за того, что 2 потока пытались одновременно что-то поправить в нем, кого эти мелочи волнуют... Последствия неаккуратной конкуренции везде одинаково хреновы ;(
> транзакции стали вдруг аргументом в пользу реляционных баз данных, хотя напрямую с ними не связаны
А вот тут спорить не буду. Они не то что напрямую не связаны, они вообще ортогональны.
Транзакции стали агрументом конкретно в сравнении sqlite3 vs whitedb. Просто не надо говорить о проблемах в модели, когда речь на самом деле идёт о принципиальной разнице в качестве предоставляемого сервиса.
По причинам описаным выше: нельзя в такой же степени навредить, т.как нет необходимости денормализовать данные, и консистентость копий не является проблемой, т.как в принципе не может возникнуть, например.
> и консистентость копий не является проблемой, т.как в принципе не может возникнуть
С моей точки зрения тут написан полный бред.
Что именно из ACID неприменимо к графам?
Атомарность?
Как спроектировать эффективный перевод денег со счёта на счёт с записью в список совершённых транзакций на графе без атомарности?
Согласованность?
Никогда не нужно гарантировать, баланс/вес ребра в графе вдруг не стал отрицательным?
Durability?
Это нормально потерять часы работы пользователей и кучу денег при внезапном отключении питания?
> консистентость копий не является проблемой, т.как в принципе не может возникнуть
Что не может возникнуть? Консистентность не может возникнуть?
Как графовая модель может магически решить проблему репликации между нодами в датацентрах?
Например: Что из себя представляет атомарность в операции которая выполняется по циклу в графе? (бесконечно). И да, у таких операций есть применение.
Ну вот простейшая задачка, о которой выше пишет Роман. Нужно хранить состояния счетов и лог переводов, которые были между ними.
Как эту задачу решают в графовой субд?
Хранить сумму в нодах, посвященных счетам - привет, Денормализация, давно не виделись.
Не хранить сумму - привет, лаги при выяснении остатка на счету.
Или я не прав, и там есть какая-то магия, позволяющая красиво и эффективно решать подобные никому не нужные задачи?
Походу как-то так: хранить остатки в нодах с переводами, а в ноде со счетом тупо ссылку на последний перевод по нему. Это тоже денормализация, но из-за иммутабельности записей она не такая страшная.
Мы не говорим о невозможности атомарности для специфических операций. Работа с графами обладает большей выразительной силой чем реляционная алгебра, и есть ситуации в которых атомарность не применима, потому что мы не знаем когда операция закончится (и закончится ли вообще).
> Как решить такую задачу в графовой бд?
Денормализация, это не кеширование результатов запросов. Нам просто повезло, что сложение обладает такими свойствами, что нам кажется, что его результат и входящие параметры выглядат как будто бы они одно и то же. Попробуйте заменить это, например, операцией объединения множеств, или вообще какой-нибудь не-ассоциативной операцией.
Сума не является эквивалентом суммандов.
Стратегия решения, соотвественно основывалась бы на кешировании запросов, используя все те же графовые инструменты. Но не копировании данных в самой базе.
А можно мне код этого вореционного генератора?
Ну реально же как живой человек говорит. Долго тренировали-то?
Паттерны обмазываются реляционнымм норкоманами и насилуют беременных утят. Поэтому я никогда не использую C++ и собачек. Хотя, собачек ещё можно использовать, если обернуть их три раза вокруг макроса и положить за щеку.
А ты говоришь Илья Муромец, он никогда не использовал IDE и до 30 метров писал на PHP, но потом его вылечили. Вобщем, открываю я холодильник -- там показывали гоатсе, а ведь гоатсе -- это симол жизни, именно из-за него провели электричество в унитаз.
Я СОЗДАЁТ ПОМЕХИ! Я СОЗДАЁТ ПОМЕХИ! О, збс, норкоманы вцикле, положи в пакетик.
Лол, сконпелял пони из глобуса, а мистер Пропер закончился и вывел всё в консоль, ведь под лифчиком же не видно.
Как бы вам понравилось программировать на языке, где нельзя сложить больше 250 чисел в цикле?
В реляционных базах данных в любой более-менее нетривиальной задаче возникает необходимость построить граф, но она решается с помощью ключей в другие таблицы (вынужденных метаданных, засоряющих хранилище), или даже специальными таблицами для реализации много <-> много отношений. Но это только на уровне первоначального проектирования. Вдальнейшем же, приходится еще и денормализовать данные, чтобы как-то побороть перформанс. А это в свою очередь не только заставляет хранить лишние данные, а сильно усложняет схему хранения, синхронизацию, репликацию, и придает особое священное значение транзакциям.
Графовые базы в большой степени лишены этой проблемы. Денормализация данных не требуется. В определенном типе графоых баз данных (триплеты - типа АллегроГрафа, не Нео), больше шести индексов в принципе не может быть в базе, т.е. их просто не к чему прикрутить. А вот в реляционных, опять же, приходится кусая локти выбирать индексировать ли поле или нет, пытаясь предугадать будут ли в него чаще писать или читать.
Эта математическая система работала, ещё когда первые компьютеры не родились. Это потом уже напридумывали всяких ad-hoc-костылей «для облегчения жизни программиста».
Однако, чего вы опять уводите тему разговора? Речь зашла о системах типов, так вот давайте говорить о системах типов. Если, конечно, у вас есть знания и компетенция что-то сказать по теме, а не пустопорожнее бла-бла.
И, да, все вышеописаное является следствием Карри-Ховард изоморфизма, которое было положено в основание хаскилевской системы типов, равно как и реляционная алгебра - основа реляционных баз данных.
Раскройте. Что «всё», каким образом?
Ограничусь примером. Изоморфизм описывает соответствие между понятиями в логике и в програмировании. Одно из таких соответствий, это вывод (импликация) и тип функции. Т.как традиционно в логике вывод записывается как одна сущность, то и изоморфный ему тип функции тоже предполагает одну сущность. Изза чего, когда человек живущий по законам Карри-Ховарда видит, что функция возвращает больше одного значения, у него происходит разрыв всего.
Примеры-то будут? Или только-ко-ко?
> Любая програма на Хаскеле выглядит как поединок из какой-нибудь американской комедии
А вот тут одного примера не хватит, поскольку квантор всеобщности, а не существования. Доказательства в студию, кароч.
Претензия из разряда «какая идиотская штука этот микроскоп, тяжёлый, в руке держать неудобно, орех на столике не закрепляется и скорлупа разлетается...»
Структура со значениями по умолчанию и удобная нотация копирования - всё что нужно белому человеку для удовлетворения редкой необходимости параметров по умолчанию
Что ж, ждём наездов «в хаскеле для присваивания переменных приходится громоздить уёбищные этажерки из монад, тогда как в других языках это сразу сделали нормально».
Кстати в Аде тоже
это всё ок
(fixed - такого типа нет, но поддержка фиксированной запятой вшита в язык, такой тип можно определить)
и в Go тоже
Теоретически можно не импортировать Prelude и сделать свою арифметику, с блэкджеком и неявными приведениями :) http://hackage.haskell.org/package/numeric-prelude в своё время очень впечатлил (там хоть и не слабой типизации ради, а совсем наоборот, но подход иллюстрирует хорошо).
попытка использовать приспособленца?
Не понял мысль. BigInteger обычно имеет небольшой кэш (нагуглил 2 реализации, в одной было чуть более 1000 объектов, в другой - три десятка), который используется в фабричном методе BigInteger.valueOf(). BigInteger.valueOf(1) эквивалентно BigInteger.ONE, но в последнем случае нужно писать меньше букв.
> попытка использовать приспособленца?
Закрой книжку по паттернам и желательно больше никогда не открывай. Можешь её даже сжечь, только детям не отдавай. Паттерны не нужны. Когда на собеседованиях спрашивают разницу между Фасадом и Адаптером мне хотется взять и уебать с вертушки. Потому что это всё полная чушь и вообще не нужно.
Единственное, ЕДИНСТВЕННОЕ, что может сделать твой код лучше - чтение чужого (хорошего) кода, изучение алгоритмов и дизайна API. Разумеется, нужно и самому писать что-нибудь полезное при этом, на хелловордах ничему не научишься. Теоретический объектно-обфусцированный дизайн и шаблоны проектирования - это игрушки для повышения ЧСВ различных бездельников.
Идеи, которые используются во всяческих шаблонах, очень старые. И единственных способ их понять - дойти до них на практике, почувствовать необходимость в них.
Это специально для тех, кто пишет на жабе в блокноте?
>>Закрой книжку по паттернам и желательно больше никогда не открывай.
Что ж вас с крайности в крайность бросает то. Онди орут "Тру - всегда юзай", другие "некогда не юзай, сжечь,сжечь"
>>Паттерны не нужны.
Жаба нинужна и плюсы нинужны
>>чтение чужого (хорошего) кода
Поднимите руку те, кто считает, что его код плох
>>Идеи, которые используются во всяческих шаблонах, очень старые. И единственных способ их понять - дойти до них на практике, почувствовать необходимость в них.
Из этого не следует, что паттарны - унылое говно. Паттерны делались для домохозяек - да, но основной смысл все равно остается общим для всех. Один фиг как не крути инициализацию получается какой нибудь из паттернов. А критериями хорошего кода опять же выступают грасп паттерны
Ты не поверишь, но меньшее букв и скобок ещё и читается легче. Не зависимо от того, в чём оно было написано.
> Онди орут "Тру - всегда юзай", другие "некогда не юзай, сжечь,сжечь"
тут вроде все считают, что нужно сжечь
> Жаба нинужна и плюсы нинужны
согласен
> Поднимите руку те, кто считает, что его код плох
поднял
Ну это спорно. Опять же на вкус и цвет...
>>тут вроде все считают, что нужно сжечь
Ну я тоже тут, и я считаю, что не нужно горячиться. Паттерны - вещь полезная, но не панацея. Паттерн обозначает определенный подход, проще становиться обьяснить как работает эта хрень. Не будешь же ты в самом деле каждый раз говорить как у тебя классы сплетены , если можно сказать - там приспособленец - и все поймут че там примерно есть и как оно склепано. Для начинающего программиста это хороший трамплин в мир ооп - простые задачи - простые решения. Я вот начинал с паттернов. Опять же паттерны являються ответами на тот костяк задач, который является жизненно необходимым. В теории домохозяйка может освоить паттерны и писать рабочий код. Хуевый, но рабочий.
Главная проблема опять же не в паттернах, а в людях, которые копипастят их от узды.
Это если говорить о банде четырех.
Грасп же по сути является не наборам пттернов, а скорее рекомендаций. Я не думаю, что можно написать хороший код, в котором грасп не будет соблюдаться.
tl,dr
Кто такой приспособленец? Я вот, например, не знаю. Серьезно ;)
Приспособленец... Понапридумывают названий...
В технологию "сначала пилим главную логику, насував заглушек, потом заполняем заглушки" я не могу.
Естественно, я там ни одного типа стрелок не знаю, всегда догадываюсь по смыслу. И не считаю это чем-то зазорным.
Это удобно.
У тебя есть 100500 объектов, но все они на самом деле один объект: просто на него много ссылок.
Можно еще сделать тоньше, и при первой попытке изменения оного реально [color green] создавать новый объект: получится паттерн "корова" (cow -- copy-on-write). [/color]. Ну как страницы в виртуальной памяти большинства популярных ОСов.
Вопрос тебе не по теме: я тут узнал что некоторые оси детектят компорты путём проб: тупо пишут по известному адресу в scratch регистр, и читают обратно.
Считалось -- значит есть ком порт.
Я удивился что никто не берет эту инфу из ACPI: разве там нет списка портов? Почему?
Не поймут, я гарантирую это. Вот если сказать "да тут у меня кэш объектов" - все поймут. А все эти умл диаграммы - бред сивой кобылы, из них нихрена не понятно даже если знаешь нотацию.
> В теории домохозяйка может освоить паттерны и писать рабочий код. Хуевый, но рабочий.
Домохозяйка может писать такой код и без паттернов.
Один хрен у вас у всех свои паттерны в голове. Когда перед вами задачу ставят вы же прикидываете - этот кусок примерно такой будет, такую подзадачу я уже решал...
Все опять же сводится к тому - смотри какой я крутой, не нужны мне ваши жалкие паттены
почему то борманд все прекрасно понимает и не зная нотации
>>Домохозяйка может писать такой код и без паттернов
значит только это смутило - все остальное ок?)
У вас от паттернов брат умер что ли?
Практически. У меня куча времени уходит на попытки понять высеры студентов, начитавшихся про оопрахитектуры и создающие 10 интерфейсов и 20 классов для загрузки картинок из веба.
@bormand поднял лапу
Вот и выходит, что учиться у тех людей, кто считает свой код хорошим - не очень хорошая идея
@
УБИВАЙ
@
СТАВЬ ПИРАТСКИЙ СОФТ
Путин
\0
литерал "символ нуль"?
В вертикальнодеформированном пространстве.
Это важно.
Где найти хороший, понятный мне код? Он или непонятный, или прыщеговно какое-то.
стандартная библиотека на что? ладно ещё в сишке и плюсах стандартную библиотеку в глаз не вломишь (хотя изучая только интерфейс STL можно много чему научиться), но в пистоне то я уж думаю проблем с этим нет.
Опять же изучать код ради праздного интереса смысла мало, лучше вникать в то, с чем приходится работать и на месте извлекать уроки и решать, хороший это код или нет.
Все хочу написать путхон: фрактал плохого дизайна.
>понятный мне код
Он слишком хорошо вылизан.Нормальный код так не пишут. Алсо, замечал разные отступы (пробелы с табами).
А потом высечь в камне во всех ит-учреждениях и конторах.
Книги же предать огню и забвению, это единственный способ остановить заразу.
Kill it with fire. Только так можно быть уверенным наверняка.
А в .NET есть даже и BigInteger.MinusOne
говнокод соединяет страны похлеще ноклы