Вот и чудненько, что искусственный интеллект уже все забыли. Потому что что-то, да делается. В первую очередь, в весьма неожиданных областях, например, - в... искусстве.

Проект AANN (аналоговая искусственная нейронная сеть) студии экспериментальной электро-инструментальной музыки STEIM основывается на совершенно очевидной идее - сделать принципиально аналоговую, а не цифровую, модель нейрона, соединить кучу такуих моделей в сеть, и использовать получившееся в каких-то целях, в данном случае - для создания динамической скульптуры. Очень красивый проект, но тут дело даже не в красоте. Возможно, цифровая технология и искусственный интеллект - направления ортогональные. Это более чем возможно. Как и более чем возможно, что все достоинства мыслящих существ основаны именно на "несовершенстве" систем, отвечающих за реализацию процесса мышления (несовершенстве, как противоположности совершенства цифровых вычислителей - низкая точность и принципиальная нестабильность работы, исключающая идеально совпадающие реакции на одни и те же воздействия). И, вполне возможно, что следующий "большой взрыв" (после логической интегральной микросхемы) будет именно аналоговым.

"Я так думаю" (© Рубен Хачикян, Мимино).

А на сайте Бостонского детского госпиталя можн отыскать отличный интерактивный самоучитель - симулятор нейрона, только на английском, само собой, но уж очень хорошо сделан.

Мои же нейроны яростно протестуют против  разработчиков, распространящих сомнительное правило  "чем больше у программы клавиатурных шорткатов, - тем лучше"  на программы , основное назначением которых - набор текстов. Потому как набирал я себе (как обычно вслепую) текст в этот блог, и случайно нажал ctrl-что-то - прыгал по словам ctrl-стрелками, пальцем левой руки ещё не успел отпустить ctrl, а пальцы правой уже что-то начали нажимать в символьной части клавиатуры, и браузер благополучно "отъехал" на страницу назад, оставив в нигде пол часа работы.

Клавиатурные шорткаты - штука очень полезная.

Вот только всему своё место, и если не учитывать режим работы (например, - ввод текста в форму) и не блокировать в этом режиме  шорткатную активацию более высокоуровневых команд, выполнение которых вызывает необратимые последствия, - это уже никуда не годится.

Есть один интересный вопрос, в общем случае ответа на который я не знаю. А именно - "как соотносится качество конечного продукта и качество выбранного разработчиком инструментария?". Здесь нужны некоторые (весьма серьёзные) пояснения.

Во-первых, - "качество". Это что? Чем оно измеряется и, вообще, могут ли быть прямые способы его оценки?

На оба вопроса ответов я не знаю. Точнее, - могу сослаться на пару сотен статей, диссертаций и даже документов, но всё это будет не то.

Да, есть документы, в которых определены "работающие" методы прямой оценки качества программного проекта. Но работают они в столь узких и хорошо изученных прикладных областях, что, на самом деле, работоспособность их очевидна любому мало-мальски грамотному инженеру, учившему теорию надёжности.

В общем же случае нет ни одного вменяемого опеределения прямой оценки качества (программного продукта, само собой).

Косвенная же оценка может быть одной - продукт качественный, если он реально востребован. Всё.

Кстати, что это значит - "продукт реально востребован"?

Мне кажется, это означает, что, несмотря на имеющиеся у продукта недостатки (он, например, может содержать ошибки - любой нетривиальный хоть в чём-то код их содержит), несмотря на известность многих недостатков и очевидную неизвестность ещё большего их количества (период эксплуатации - это и период самого серьёзного тестирования и эволюции), пользователи выбирают продукт и продолжают выбирать именно его. По каким причинам это делают пользователи - не важно (а  если кто-то думает, что можно так проводить в Японии рекламную компанию автомобиля  "ВАЗ 2110", что все японцы сначала предпочтут эту машину своим хондам-тойотам-сузуки-дайхацу, а потом ещё и будут хранить верность своему предпочтению, этот кто-то очень плохо, некачественно думает, и лучше пусть так больше не делает).

Так вот, - продукт должен быть качественным, чтобы быть востребованным, и должен быть востребованным, чтобы становиться всё более качественным (потому что период эксплуатации - blah-blah-blah, уже было выше).

Вот, например, продукт Adobe Photoshop Lightroom. Продукт "молодой" в знаменитой адобовской линейке (достаточно взглянуть на номера версий - Photoshop 10.0.1 и Lightroom 1.3.1). И уже востребованный практически всеми, для кого цифровая фотография представляет интерес.

Главный архитектор Lightroom, Марк Гамбург (Mark Hamburg) - человек легендарный, титулованный "Архитектор Photoshop", причём титул ему присвоили в команде разработчиков, а не в журнальной статье (а это, согласитесь, огромная разница).

Гамбург знает Lightroom до мельчайшего "винтика", потому что это его детище. Вот в этом интервью (я советую прочесть и его первую часть) он рассказывает об архитектуре Lightroom и использованном инструментарии следующее (это не дословный перевод, само собой):

• 40% функциональности Adobe Photoshop Lightroom реализовано на языке Lua,

• ключевые элементы архитектуры продукта - встраиваемый интерпретатор Lua, СУБД SQLite и унаследованный от проекта Photoshop код конфертера RAW-файлов,

• код модулей сопряжения с операционной системой реализован на С++ или ObjectiveC (в зависимости от платформы)

Итого.

Есть старая-престарая статья Кернигана о том, насколько удобен сверхвысокоуровневый интерпретируемый язык-"клей" (то есть, изначально созданный для одновременного встраивания в приложение и формирования приложения за счёт расширений языка).

Таких языков на сегодня на самом деле совсем немного - разве что кроме Lua вспоминаются многочисленные реализации клонов Lisp (Scheme). О причине, почему Lua, a не Scheme, Гамбург говорит следующее:

"Lua - привлекательный баланс между простотой и мощью. Он мал, быстр, его легко встраивать в приложения. У него очень простая лицензия. Он весьма похож на Scheme, который мне нравится, - но в нём нет синтаксиса, требующего от людей слишком больших усилий (вообще-то, в оригинале - "It’s very much like Scheme language I like—but without a syntax likely to make people go running for the hills.")"

Сказанное о Lua, можно слово в слово повторить о SQLite - она тоже небольшая (да какое там - небольшая, она крохотная для своей функциональности), простая, легко встраивается, её лицензия - Public Domain.

Вот так, собственно говоря, Гамбург и дал Lightroom'ом ответ на вопрос о соотношении качества инструментария и продукта:

инструментарий должен быть простым и одновременно мощным, компактным, допускающим беспроблемное с юридической точки зрения использование, он не должен требовать от людей нечеловеческого.

Примерно так. А Lua и SQLite - действительно замечательные вещи. Я бы даже сказал - уникальные.

Началось всё с "разжёвывания" программки в несколько строк на Haskell, преобразующей запись заданного целого числа в римскую форму, например, - 9 в IX.

Собственно программка и её разжёвывание - здесь. Безусловно, можно и в каком-то смысле небесполезно (если есть свободное время) с этим примером повозиться. Но не суть и не обязательно. Билл Милл, мужчина головастый и профессиональный, в конце возни с Haskell-кодом тяжело выдохнул:

"Phew - that's an awful lot of information stuffed into a few pretty lines! I still have a hell of a time geting the types to match up so that I can write stuff like this, but that doesn't mean that I can't appreciate the beauty of how it all fits together." 

То есть, - фуххх, в этих нескольких строках столько информации! И весьма профессиональному и головастому специалисту по его же признанию требуется куча времени на освоение системы типов и приёмов программирования. Но, зато, кода красивый. С чем, в каком-то смысле, трудно не согласиться.

Немного погодя, Билл Милл попробовал сделать то же самое в том же самом функциональном стиле на Phyton - языке в общем и целом всё-таки более близком к императивным. Получилось по объёму примерно то же самое, а с учётом внесенных в обсуждении примера уточнений и модификации некоего nostrademons  - так и вообще очень изящно.

Но и это не суть на самом деле.

А суть в том, что мышка пробежала, хвостиком вильнула, яичко упало и разбилось, хоть и такое изящное и золотое "императивное исполнение" алгоритма преобразования не только яснее, оно ещё и существенно эффективнее, что в том же обсуждении убедительно продемонстрировал некто Кей Шлюе (комментарий от имени schluehk).

Вот это-то меня и смущает всё время.

С одной стороны, - "иная, функциональная ориентация" теперь для "отдельно стоящих программистов" играет роль этакого очередного золотого яичка - дед бил-бил монады, - не разбил, баба била-била лямбда-исчисление, - не разбила, ну и так далее, до мышки, которая, пробегая, походя махнула императивным хвостиком, и побежала по своим мышиным сереньким производственным делам.

Впрочем, практика покажет. В своё время Lisp был самым-самым, нынешние "функциональщики", предпочитающие языки новой волны, уже радостно его хоронят, Поглядим, что будет с новыми "самыми-самыми".

Ну а здесь покусились уже на святая святых объектного программирования - на наследование. И более чем разумно и обоснованно растолковали, почему оно "в большинстве случаев не исключительная возможность, а всего лишь упрощённый метод выражения подобия". Очень рекомендую почитать, весьма и весьма толково, и более чем очевидно, если, конечно, начинать об этом думать.

 Дальше - опять "неожиданное" открытие. Его сделал Департамент Национальной Безопасности США. С помощью созданного в Стенфордском университете сканера кода Prevent SQS и в результате масштабного сканирования (180 продуктов) выяснилось, что открытое программное обеспечение не менее "багливое", чем закрытое коммерческое.

А вывод может быть один. Ни ложки никакой нет, ни достойного  продолжения первой "Матрицы", ни серебряной пули, как её ни  называй.

Нет их.

И всё.

Так как в светлые дни праздников принято дарить ненужные вещи, степень бесполезности и ненужности которых прямо пропорциональна квадрату степени светлости праздника, вот небольшой набор совершенно замечательных подарков (настолько замечательных, что к ним и подходящий праздник придумать трудно):

Карманная википедия, то есть, - энциклоподия, на iPOD. Учитывая неповторимые врождённые способности iPOD к поддержке ввода пользователем символьной информации, программа может оказаться просто незаменимой, особенно для поиска смысла жизни, скрытого в шикарных словах вроде "культуртрегерство" и того, которое знала образованная девушка Фима Собак.

А уж тот факт, что что для работы энциклоподии требуется сменить прошивку iPOD на специальную версию Linux, не может не радовать настоящего фаната.

Потому что на такой iPOD кроме энциклоподии можно установить ещё и подлинный шедевр - компилятор языка Brainfuck, реализованный на языке Haskell c использованием техники "грамотного программирования" (literate programming) (!).

А ведь долгими грустными новогодними праздничными вечерами, когда надо смотреть долгие грустные концерты грустных долгожителей грустной эстрады, именно такими вечерами и именно на Brainfuck можно (и даже нужно) небрежно, на салфетке, писать изящные программы.

Такие, как, например, реализация классического алгоритма вычисления чисел Фибоначчи:

 >++++++++++>+>+[
    [+++++[>++++++++<-]>.<++++++[>--------<-]+<<<]>.>>[
        [-]<[>+<-]>>[<<+>+>-]<[>+<-[>+<-[>+<-[>+<-[>+<-[>+<-
            [>+<-[>+<-[>+<-[>[-]>+>+<<<-[>+<-]]]]]]]]]]]+>>>
    ]<<<
]

Так как исходный код - лучшая документация, в комментариях эта программа не нуждается, в ней всё прозрачно, даже то, что из неё не предусмотрен выход, и её надо "прибивать" вручную, не правда ли?

Кто-то может подумать, что раз у человека уже есть iPOD под Linux с википедией и компилятором Brainfuck (и с Haskell, и с Haskell!), то такому человеку уже ничего не нужно. Неправда! Во-первых, компилятор Brainfuck на Haskell получился что-то не очень быстрый (в несколько тысяч раз медленнее компилятора, написанного на C). А это значит, что ещё есть куда расти (ну это же несерьёзно, когда пацан с медленным компилятором), можно попробовать написать на iPOD Brainfuck-машину на Ada. Поэтому можно поставить на iPOD Ada-компилятор (благо, он есть "гнутый", ну, вы понимаете, - из семейства GNU).

А ещё можно взгромоздить на компьютер, к которому подключается iPOD, Очень Необходимую Программу. Само собой, - этот компьютер будет под управлением ОС MacOS X, ибо только в ней можно ощутить всю невыразимую мощь, прелесть и нечеловеческие удобства великой iTunes. Так вот, на этот компьютер можно (и нужно) в качестве праздничного подарка установить новую файловую систему... снимков экрана. Пространство запущенных приложений в ней отображается томом, каждое приложение - каталогом, а каждое окно приложения - tiff-файлом в каталоге. Если что-либо сделать с одним из этих tiff-файлов (например, открыть) автоматически будет сделан снимок соответствующего окна соответствующего приложения и помещён в выбранный файл.

И будьте уверены - после получения в подарок таких прекрасных и нужных вещей совершенно по-другому оцениваются даже унылые и прозаичные носки или лосьон после бритья. Совершенно по-другому...

Алан Куртис Кей, один из отцов объектно-ориентированного программирования, автор Smalltalk и целой кучи идей, отметивших веху, относительно до сих пор индустрия особенно никуда и не сдвинулась, рекомендует своим студентам прочесть книги вот из этого списка.

По мнению Кея (я лично склоняюсь к тому, что к его мнению стоит  прислушаться),  изучение всех этих работ нужно для того, чтобы лучше понять идеи и философские основы объектно-ориентированного программирования и Smalltalk (а также его нового, открытого воплощения, - Squeak).

А вот ещё и известный блоггер и соавтор популярной книги "Mind hacks" Мэтт Вэб отчитался перед своим "уютным дневничком" о результатах работы над собой за год - запланированные 104 книги прочитаны.

Что получается?

С одной стороны, отцы-основатели, такие, как Алан Кей, буквально пинками загоняют будущих узких специалистов на стык самых разнообразных дисциплин - технологий и медиа, обучаемости и творчества, антропологии и психологии, философии, искусства и восприятия, дизайна, естественных наук и математики, политики и экономики, и совсем чуть-чуть - компьютерных наук.

С другой, - потребности индустрии (насколько они реальны?  и кто может дать на этот вопрос 100% достоверный ответ?)  вынуждают будущих специалистов зубарить сотни флагов команд, количество которых растёт и растёт, библиотеки раздуваются (каждый год звучит "откровение", что во многих случаях программистам легче написать свою реализацию, чем изучать особенности замечательной повторно используемой, и каждый год это здвучит откровением), основную массу программистов обвиняют в низкой квалификации потому, что они не используют Самый Важный Инструментарий (например, системы управления конфигурациями ПО), при этом там, где такой Самый Важный Инструментарий используется, зачем-то содержится небольшое стадо высококвалифицированных администраторов, отдавших кусок жизни (обычно лучший) на изучение порой совершенно немыслимых идей, взбрыков и "нюансов" как Инструментария, так и заложенных в нём "воспоминаний" о его авторах. И так далее.

Ну вот простейший вопрос. Самый простой. Кто-то разве отменил "правило пяти" - человеку очень трудно управляться с запоминанием разнообразий, включающих больше пяти элементов (некоторые даже считают, что это правило должно быть более жёстким - "правилом трёх")? Никто вроде как не отменял. если речь одёт о human'е - он подчиняется этому правилу.

Но мы говорим об unhuman'ah. Наберите man ls и посчитайте число опций. Кто их помнит все? Зачем их столько? Кто проделал очевидную исследовательскую работу - "прошерстил" завалы публично доступных скриптов и выявил наиболее часто используемые и те, которые вообще не использовались за весь период наблюдения?

Да, собственно говоря, никто. Хорошо, согласен, - если звёзды зажигают, значит это кому-нибудь нужно. Пусть будет 800+ команд, у каждой - 600+ опций, и пользователь всего этого будет зачем-то  всё это учить и в качестве компенсации за "зачем-то" будет чувствовать себя unhuman'ом-сверхчеловеком. Пусть.

Но ведь, может быть, и Алан Кей прав - низкий уровень "общей"  образованности междисциплинарного специалиста может сказываться негативно?

Не так давно Вождь и Учитель призвал сообщество слушающих Вождей и Учителей не использовать операционную систему OpenBSD, потому что в портах (для незнакомых со спецификой - в репозитории портированного для этой системы программного обеспечения) ОС якобы есть "несвободные" программы.

Призыв прозвучал в традиционном стиле, начиная с заголовка - "Настоящий мужчина не нападает на пугало" (тут ещё и игра слов - "straw men" это и лжесвидетель) и достиг настоящего апогея в части мотивации призыва:

"From what I have heard, OpenBSD does not contain non-free software
(though I am not sure whether it contains any non-free firmware
blobs).  However, its ports system does suggest non-free programs...  I therefore exercise my freedom of speech by not including
OpenBSD in the list of systems that I recommend to the public."

То есть:

"Из того, что я слышал, OpenBSD не содержит несвободное ПО (хотя я не уверен, что система не содержит несвободные бинарные объекты на уровне прошивок аппаратных средств). Тем не менее её система портов предлагает несвободные программы... Поэтому я использую своё право на свободу высказываний и не включаю OpenBSD в список систем, которые я могу рекомендовать общественности".

На эту рекомендацию отреагировал Тиио де Роот (Theo de Raadt) - человек, который основал и возглавляет проекты OpenBSD и OpenSSH, а также входит в список основателей проекта NetBSD. Реакция звучит слово в слово так:

Your argument was that OpenBSD contains non-free parts in it's
ports tree.
This has been proven to be false.
Here, go have a look

It's just an entirely free scaffold of Makefiles and little patches.
Nothing more.  It is 100% source, and it is 100% free.
If you are going to go around making pronouncements from your pulpit,
you might want to go educate yourself.
But once again, you failed to educate yourself before you opened your
big fat mouth on a talk show and stated utterly uneducated and false
statements .  You have had ample opportunity to say "I was wrong", yet
you have not done so yet.
You keep argueing, and that is because you are a coward.

По-нашему это будет звучать так:

Вашим аргументом было наличие несвободных программ в дереве портов. Это доказанная ложь. Взгляните сюда:      ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/poerts.tar.gz
Это всего лишь полностью свободные строительные леса, состоящие из файлов, необходимых для сборки программ с помощью утилиты make и небольших поправок к исходным текстам. Ничего больше. Это стопроцентные исходные тексты, и они стопроцентно свободны.

Дльше я не хочу переводить - кому интересно, поймёт.

Так вот.

Как начинались все великие начинания Освобождения Человечества, так они и начинают заканчиваться - диалогами вроде: 

- а врагами у нас будут xxx, потому что Мне кажется, что xxx - наши враги...

- да прежде чем открывать свой большой жирный рот...

Прав был царь Соломон:

Что было, то и будет, и что творилось, то творится,
И нет ничего нового под солнцем.
Бывает, скажут о чем-то: смотри, это новость!
А уже было оно в веках, что прошли до нас.
Не помнят о прежнем - так и о том, что будет, -
О нем не вспомнят те, кто будут позднее.

PS

жалко, у нас нет рубрики "инвалиды дерутся"

PPS

как бы там ни было, поздравляю всех почитателей NetBSD с выходом четвёртого релиза.

Это просто смешная мелочь, конечно. Но она показывает, насколько и как мы бываем неточны, оперирую вещами даже более чем очевидными.

Итак, желающие по каким-то причинам (хихи) остаться неизвестными российский программисты наваяли чатбота, который приводит в ужас своей интеллектуальностью.

При этом чатбот не только сообразительный, но и шустрый  - он успевает "окучивать" до десяти e-лохов за 30 минут.

Ловятся несостоявшиеся контролёры результатов проверки на тест Тьюринга, как всегда, на обычном - sex,drugs, rock'n'roll.

В данном случае - на sex.

Чатбот CyberLover пользуется успехом у онлайновых страдальцев разных мастей, потому что мимикрирует в широком диапазоне - от томного романтичного ценителя Эроса до вырвавшегося в увольнение солдата срочной службы. Поэтому зарубежные специалисты, трезво оценивающие популяцию потенциальных жертв, уже начинают волноваться.

В полном соответствии с канонами жанра, CyberLover - не очень добрый Искусственный Интеллект. С другой стороны и особо злым его не назовёшь - этакий робот Бендер. Ну, пошалит немного, заманит страдальца на сайтик с вожделенными фоточками "а это я перед зеркалом - только для тебя", ну и потерпевший, максимум, отделается какой-нибудь (и явно ведь не первой, а очередной) спайварью или червяком.

В общем, - просто забавная талантливо сделанная штука, которая у меня лично никаких страхов "за будущее" не вызывает, потому что её жертвы непременно не только отыщут себе свои персональные грабли даже если ввести в сети Страшный Тотальный Контроль, но и будут на них не без увлечения наступать до полного изнеможения.

А вот смешно здесь другое.

Вот мы всё время говорим о тесте Тьюринга - дескать, Искусственный Интеллект, - это если человек общается неизвестно с кем, и не может усомниться в том, что общается с другим человеком.

Ага.

Только вот результат этого теста очень сильно зависит от участвующего в нём человека.

А то некоторых человеков послушать - так они тест Тьюринга сами с трудом проходят в весьма специфических условиях: у входа в метро "Святошино", с семками, фугасом пива и прекрасной музыкой Армина ван Бурена, льющейся из мобильного телефона.

Побитовое "исключающее или" (xor, ^) - функция, горячо любимая всеми, кто "копошится в железяках", потому как с её помощью можно сделать много чего полезного и красивого.

Свойства xor следующие:

• коммутативность: X^Y = Y^X 
• ассоциативность: (X^Y)^Z = X^(Y^Z)
• наличие нейтрального элемента: существует такое Z, что X^Z=X для любых значений X
• инверсия: для любого значения W существует такое M, что W^M=Z, кроме того, известно, что каждое значение инверсно само себе, т.е. W^W=Z

Самый известный прием использования xor - экономный обмен содержимым двух ячеек памяти (или переменных, кому как нравится), не требующий использования третьей ячейки. Обычно процедура обмена реализуется как раз через дополнительную ячейку памяти, например, надо обменять содержимое ячеек A и B:

A->C ; содержимое A копируем в С
B->A ; содержимое B копируем в A
C->B ; содержимое A из дополнительной ячейки копируем в B

Кстати, до сих пор не могу понять авторов ассемблеров - зачем для одной и той же операции пересылки использовать то мнемонику mov, то cp, то ещё что, если суть операции отлично отражается указанными символами?

С помощью xor то же самое делается так:

A^B->A ; побитовое исключающее или содержимого A и B, результат записывается в A
A^B->B ; побитовое исключающее или содержимого A и B, результат записывается в B
A^B->A ; побитовое исключающее или содержимого A и B, результат записывается в A

Почему так получается, вытекает из указанных выше свойств xor:

после первой операции в A содержится A^B
после второй операции в B содержится (A^B)^B = A^(B^B) = A^Z = A
после третьей операции в A содержится (A^B)^A = B^(A^A) = B^Z = B

Одна ячейка памяти - вроде чепуха, но не для тех, кто программирует микроконтроллеры или вообще встраиваемые вычислители.

А вот - менее известный, совершенно жуткий в каком-то смысле (и не одном) хак, но зато до чего изящный.

Двунаправленный список требует для работы хранения двух адресов в каждом элементе списка - предыдущего и следующего элементов. Мы говорим список - понимаем "динамически выделяемая память" (а иначе зачем он вообще), говорим "динамически выделяемая память" - понимаем RAM, говорим RAM - понимаем "дорогой ресурс". Причем не просто дорогой, а часто - бесценный. В микроконтроллерах, например, обычно объем RAM измеряется в сотнях слов. Соответственно, два адреса в каждом элементе списка - это может быть просто непозволительно "жирно".
В подобных случаях можно с помощью фокуса с XOR добиться экономии, и существенной, если хранить в элементе списка результат такой операции: адрес_предыдущего_элемента^адрес_следующего_элемента.

Модель всего этого дела будет такой (&X - адрес X, ну а X{} условимся считать чем-то вроде структуры X, если говорить в терминах C):

A{ссылка: ...^&B } B{ссылка: &A^&C} C{ссылка: &B^...}

Предположим, что текущая ячейка - B. Для работы алгоритма знание только текущего адреса недостаточно, надо "помнить" еще и адрес предыдущей-следующей ячейки, в зависимости от направления обхода списка. 

Тогда адрес элемента, следующего за B, находится так:

&A ^ B.ссылка

потому что &A^(&A^&C) = (&A^&A)^&C = Z ^ &C = &C

Адрес элемента, предшествующего (в списке) B, находится аналогично:

&C ^ B.ссылка

потому что &C^(&A^&C) = (&C^&C)^&A = Z ^ &A = &A

Можно оценить экономию: если максимальная длина списка - N элементов, такой метод позволяет уменьшить требуемый объем ОЗУ на N-1 слов (потому что для вычисления адресов при обходе требуется два указателя на соседние элементы, а не один). Для микроконтроллеров с RISC-ядром и разрядностью адреса, бОльшей, чем машинное слово, может получиться весьма ощутимая цифра.

Правда, отлаживать такое - ещё то удовольствие, но, например, в крохотном мониторе (ядром операционной системы подобное называть - много чести) реального времени такая структура данных может быть очень полезной.

PS

Буду потихоньку сюда записывать всякие подобные алгоритмические интересности, всё одно это полезнее, чем пугать ужасами типа Большого Брата - и тем, кто читает, и мне самому.

В СССР печатные машинки и копировальная техника подлежали обязательному учёту и регистрации в соответствующих, так сказать, органах. Времена теперь другие, но.

Эту историю и слухи ней, - о незаметном коде, который принтеры оставляют на распечатках, - слышали многие.

А вот - изучение того же, но эмпирическим путём.

Итак, некто Пауль Вейхе (?, может и не совсем правильно так, в оригинале - Paul Weihe), сделал следующее:

• взял и распечатал что-то совершенно обычное на цветном лазерном принтере Xerox DC-12, на листе  формата A4 (полиграфические настройки указаны в оригинале, нам они без надобности),
• затем отсканировал фрагмент распечатки размером 7,5 x 7,5 см. и сохранил в 260 MB файл (разрешение - 3200 dpi),
• после чего "выкрутил" насыщенность желтого цвета на максимум, увеличил контрастность изображения, и получил следующую картинку:

 Из неё видно, что некий код в распечатке действительно присутствует. Это жёлтые точки (кстати, о цвете - он выбран хорошо, потому что одновременно незаметен на белом фоне листа и относится к основным цветам, интересно, как ведёт себя принтер, когда цвет фона меняется?). Правда, он похож на инопланетные письмена, но, если исходить из предположения, что он должен содержать дату и время печати, можно в нём отыскать некоторую закономерность. А именно, - вот такую:

Итак, это фактически битовый массив, строка в котором означает вес (традиционно - положение бита в слове), фрагмент столбца - множество битов, формирующих слово определённого назначения (назначение указано в заголовках столбцов таблицы по-немецки), и всё это дополняется битами чётности.

Из этой картинки, например, видно, что документ был распечатан в 14 часов (смотрите точки в столбце Stunde и их веса: 2+4+8=14) 38 минут (столбец Minute, 2+4+32=38).

А самые интересные столбцы этого кода, - предполагаемо  идентификатор принтера Seriennummer, смысл которого пока не взломан.

Как к этому факту относиться?

Можно распечатать на большом цветном лазерном принтере табличку формата A3 "Большой Брат видит тебя" и пойти куда-нибудь помитинговать.

Поможет?

Ну, не повредит.

Есть ли реально Большому Брату дело до тех принтеров, - это никому, кроме самого Большого Брата, не известно. О прецедентах, по крайней мере, никто не слышал.

Но факт остаётся фактом - потенциально можно установить, что лист бумаги A был распечатан на принтере B, если принтер B является членом некоторого подмножества всех вообще принтеров (например, мне очень сомнительным кажется, что подобное реализовано в фотопринтерах - из-за особенности печатаемого, и в обычных чёрно-белых лазерных).

Есть такой серьёзный мужчина - Бен Коллинз-Зюссман (Ben Collins-Sussman). Он работает в Google, в том сегменте Goggle, где  занимаются не только разработкой open source ПО, но и финансированием открытых проектов.

Бен Коллинз-Зюссман написал, по моему мнению, то, что можно назвать лучшим кратким диагнозом движения open source.  

Итак, - нет никаких десятков категорий программистов. Это раз. Нравится нам это или нет - их не существует, точнее, можно придумать хоть сто категорий, но они несущественны.

Потому что в действительности есть всего две категории (кстати, не только в программировании):

1. Профессиональные альфа-самцы. Вовсе не в том смысле - это люди, для которых выбранная профессия является, по сути, смыслом жизни. Это те самые люди, которые, по словам Коллинза-Зюсмана, "устанавливали в 90-х Linux на домашние компьютеры, писали компиляторы Lisp и учили по выходным Haskell", и делали это только потому, что действительно получали от всего этого удовольствие (практически в том смысле). Благодаря такой особенности эти люди всегда "впереди паровоза" - они формируют тренды, моды, в общем, всё то, о чём говорят.
2. Просто профессионалы. Они изучили и продолжают по мере необходимости изучать требуемые инструменты в достаточном для качественного выполнения своей работы объёме. Они работают в бесчисленных коммерческих структурах и пишут бесчисленные программы для "внутреннего потребления", и эти программы вовсе не так плохи, независимо от использованного инструментария - ведь они дейтсвительно повседневно используются со вполне определёнными целями. Они используют те инструменты, которые хорошо документированы и которым легко обучиться потому, что есть доступные хорошие курсы подготовки. В общем, - это добросовестно работающие "от звонка до звонка" специалисты, в выходной день предпочитающие не ковыряться "в кишках" чьей-то программы с версией 0.01, а вообще не включать компьютер.

Для этих категорий следует указать три совершенно очевидных, но одновременно шокирующих факта:

• во-первых, - к первой категории относится всего 20% программистов;
• во-вторых, - 80% просто профессионалов формируют примерно 80% того, что и есть "индустрия программного обеспечения" во всех её проявлениях, в том числе и в реальных программных продуктах, а не в трендах, модах и поводах для разговоров;
• в-третьих, первые 20% программистов обычно "забывают" о вторых 80%.

Вот это самое в-третьих - и есть диагноз.

Бен Коллинз-Зюссман не говорит прямо о снобизме и агрессивности, но взгляните на  запись в его блоге - с чего она начинается? С фразы "Before posting an angry comment about this post...".

И это - второй диагноз.

Кстати, о "в-третьих" по версии Коллинза-Зюссмана. Ни для кого не секрет, что присущий сообществу ощутимый внутренний снобизм (ну хорошо, - упорное незамечание каких-то там 80%, состоящих из "миллионов леммингов, которые не ошибаются") весьма привлекателен для людей определённого психологического склада . Выделиться "из толпы", стать "над нею", гнать "стадо" хлёсткими фразами без намёков на деликатность и вежливость - весьма откровенные цели, которые ставили (и небездарно достигали) многие известные (да какое там известные, - легендарные) сетевые персонажи "из сообщества".

Но это только одна сторона медали. Есть же и другая. Например, - несоответствие внутреннего статуса статусу внешнему. Некто X знает  OCaml (ну или считает, что знает, - подлинное знание инструмента приходит в результате повседневного и целесообразного его использования), а зарабатывает в 4 раза меньше, чем некто Y, которому никакой OCaml ни за какие коврижки не нужен, ему хватает, страшно сказать, - Visual Basic. В таких условиях X вынужден не замечать Y. Или же всё-таки заметить, но в такой форме, что Y это точно не понравится. И это источник агрессивности в любых её проявлениях, и объяснение "Before posting an angry comment " в блоге Коллинза-Зюссмана.

И последнее. Ещё пять лет назад за такое мнение Коллинза-Зюссмана записали бы в распространители гнусного FUD'а. Но сейчас не пять лет назад, да и мы слушаем мнение человека, который получше многих из нас знает, о чём говорит.

А диагноз нехороший.

Потому что проявляется или в умышленном игнорировании, или в агрессивности, и тем самым не просто отпугивает массу людей от вполне здравых и хороших, но ещё сыроватых идей, которым просто надо пройти "обкатку" временем, "притереться" в уже сложившейся системе общественных отношений, но и вызывает адекватную реакцию.