0x7BE : Alkid`s journal

Базовые функции ИИ: Анализ

Mon, 02 Nov 2009 19:04:04 GMT

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

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

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

В 1957-ом году в своей книге "Синтаксические стуктуры" лингвист Ноам Хомски ввёл понятия поверхностных и глубинных структур и трансформационной грамматики. В его концепции поверхностные структуры представляют собой конкретные синтаксические формы (предложения, словосочетания) которые мы говорим или читаем, а глубинные структуры - внутренне представление смысла, выраженного в этих синтаксических формах. Для формального описания процессов перехода от поверхностных структур к глубинным и обратно он предложил трансформационные грамматики, описывающие процесс интерпретации поверхностных синтаксических форм в виде последовательных трансформаций от отдельных слов в синтаксические конструкции, из них в боле сложные конструкции и в итоге в единую структуру, описывающую целиком всё предложение. Эту идею позже подхватили основоположники НЛП - Джон Гриндер и Ричард Бендлер. Они распространили идею о поверхностных и глубинных структурах с исключительно лингвистической области на всё восприятие и действие человека, в том числе и невербальное. По их версии в процессе перехода от поверхностных структур в глубинным на информацию действуют процессы обобщения, искажения и разрушения информации, чем и обусловлены определённые особенности человеческого восприятия и поведения. Другом важным источником идей является модель "память-предсказание", изложенная Джеффом Хокинзом в своей книге "Об интеллекте". В этой модели Хокинз делает очень важное замечание - он вводит понятие времени, т.е. восприятие в его модели оказывается привязанным ко времени. При этом, по его версии, восприятие так же носит характер иерархического абстрагирования, при котором "низшие" отделы мозга поставляют в "высшие" всё более абстрагированную инормацию.

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

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

Итак, суммируя вышеизложенное, можно сформулировать следующие тезисы:
1. Суть анализа - повышение уровня абстракции информации.
2. Абстрагируемая единица информации - паттерн, "схватывающий" отношения между элементами и заменяющих их на абстрактный элемент.
3. Паттерны образуют иерархию. Выходы паттернов уровня n могут образовывать паттерны уровня n+1. Общее количество уровней зависит от сложности обрабатываемой информации.
4. Процесс применения паттернов в общем случае недетерминистичен, т.е. может порождать множественные результаты (интерпретации). Однако по мере повышения уровня абстракции *обычно* наблюдается схождение к одному решению. Исключение - некоторые достаточно редкие ситуации, когда есть более одного решения (например, "странные картинки", часто иллюстрирующие идеи гештальт-психологии).

Формализовать эти идеи можно по-разному. Лично мне больше нравится идея обобщить принципы, положенные в основу формальных грамматик, на невербальную область, описываемую символически. Хокинз предлагает коннективистский подход, который ближе к нейросетям и "слабому ИИ" (см. модель Hierarchical Transactional Memory).

Обобщение формальной грамматики происходит путём абстрагирования природы паттерна и выражения от последовательности синтаксических элементов до множества элементов некоего алфавита, которые могут находиться в произвольных отношениях, а не только в отношениях следования. Определяются алфавиты А[0...n], где A[0] - это конкретный (входной) алфавит, а A[x], где х > 0 - абстрактные алфавиты, дающие имена паттернам. Эти алфавиты образую общий алфавит А, на базе которого могут быть определены выражения E. Далее определяются правила трансформации вида R = P -> N, где P - паттерн, а N - имя паттерна, принадлежащее одному из абстрактных алфавитов. Природа паттерна P абстрактна, т.е. я не формулирую его устройство. Правило может быть применено к выражению, породив множество решений, т.е. R(E) = {E}. Правила должны обеспечивать неубываемость уровня абстракции, т.е. N не может быть из "менее абстрактного алфавита", чем распознаваемые паттерном P. Набор правил трансформации определяет интерпретацию входной информации. Процесс интерпретации происходит до тех пор, пока не получается выражение, к которому не применимы правила.

Гештальт как концепция AI

Wed, 09 Sep 2009 16:40:52 GMT

В своих размышлениях на тему ИИ я обращаюсь к различным источникам, среди которых есть и "профильные" и не очень. Некоторое время назад я общался с одним френдом на тему психологии и он (точнее она) рассказала мне про гештальт-психологию, которая строится вокруг понятия гештальта (см en.wikipedia.org/wiki/Gestalt_psychology). Эта концепция натолкнула меня на интерсное направление в размышлении.

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

Теперь вспомним, что мы имеем дело с динамическим окружением, т.е. в следующий дискретный момент времени (напрмер, следующий ход) мы будем иметь другую картину входных данных. Скорее всего, эта картина не будет радикально отличаться от предыдущей, ибо окружение обычно имеет свойство непрерывности (спорное утвержение!). Соответственно, эти входные данные так же будут проанализированы и над ними будет построена абстрактная структура их описывающая. Возникает вопрос, как соотносятся абстракции, полученные на шаге N и на шаге N+1? Вот тут как раз может быть применена идея гештальта. Суть этой идеи заключается в следующем - в мозгу человека (или в ИИ) поступающие данные формируют некоторый устойчивый процесс (гештальт), который является отражением окружения. При этом, один раз возникнув (свойство эмерджентности гештальта), этот процесс начинает влиять на интерпретацию следующих порций информации (свойство устойчивости гештальта). Типичный пример подобного поведения у человека - интерпретация картинки с собакой из статьи по ссылке. Сначала она кажется мешаниной пятен, но когда приходит понимание (или просто кто-то скажет) того, что там изображена собака под деревом, эти пятна начинают далее восприниматься как детали известной структуры. Более того, если эту сцену начать вращать в пространстве, то человек без труда будет угадывать в новых наборах пятен ту же самую собаку и дерево. Другими словами, как только гештальт формируется, он начинает "вписывать" новые данные в свою структуру, а не анализировать их с "чистого листа".

Как эта идея может проявиться в примере с ИИ? Например, предположим, что наш кластеризатор имеет следующее встроенное правило: "группировать близкорасположенные юниты, которые движутся в одном направлении с одинаковой скоростью". Рассмотрим пример: группа юнитов движется в определённой формации до момента T1, после чего юниты меняют формацию, причём новая формация стабилизируется только после момента T2 (T2 > T1). Между T1 и T2 скорости и курсы юнитов, образующих группу, могут сильно менятся, но до Т1 и после Т2 они продолжат движение в строю в одном направлении с одинаковой скоростью.

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

В целом идея "гештальта" позволяет реализовать в ИИ восприятия времени не как набора разорванных состояний, а как единого процесса, обладающего свойством непрерывности, т.е. ИИ будет "понимать", что группа, наблюдаемая им на шаге N+1, это некая конкретна группа, наблюдавшаяся на шаге N.

P.S. В процессе размышления мне пришла в голову мысль, что подобная идея в неявном виде следуюет из модели "память-предсказание", которую Джефф Хокинз сформулировал в книге "Об интеллекте".

Встроенный язык для скриптования ИИ.

Sat, 29 Aug 2009 19:33:56 GMT

Давно меня занимает следующая идея: встроенный язык для скриптования ИИ-ориентированных задач. "Простых" скриптовых движков, пригодных для встраивания в приложения сейчас пруд пруди, но все (из известных мне) - это императивные языки. Они не очень хорошо подходят для задач скриптованяи ИИ. Основные особенности таких задач заключаются в следующем:
  1. Высокая степень недетерминизма.
  2. Весьма произвольное качество входных данных.
  3. Необходимость анализировать входные данные, повышать их уровень абстракции.
  4. Необходимость синтезировать выходные данные с понижением их уровня абстракции.
  5. Зачастую необходимость опираться на эвристики и приближённые рассчёты и модели.
  6. Необходимость представлять знания.
  (Примечание: Обратите внимание, что пункты 3 и 4 являются зеркальным отражением друг друга. Это наводит на мысль, что желательным свойством языка была бы обратимость программ a-la Prolog, т.е. формулирование программ не как отображений (функций), а как отношений (уравнений)).

Опыт программирования подобного рода задач на императивных (Pascal- и C-подобных) языках наводит на мысль, что это весьма противоестественное занятие. Необходим другой язык, более высокого уровня и такой идеологической базой, которая бы делала простым и естественным обращение с задачами описанного типа.

Пока попытки смоделировать такой язык, черпая вдохновение из известных мне языков, привели меня к следующим идеям:
1. Основа языка - недетерминистическая система преобразования термов при помощи определяемых правил с унификацией и логическими переменными. Т.е. основная единица языка - трансформационное правило, "голова" которой унифицируется с исходным выражением, порождая связи переменным со значениями, а тело подставляется вместо унифицированного терма. Один и тот же терм может быть одновременно преобразован несколькими правилами, что породждает возможность нескольких результатов трансформации, т.е. недетерминистическую прогармму.
1.1. Частичная подстановка. Даже если после унификации головы правила у неё остаются свободные переменные, вычисление может быть продолжено. Если же дело дошло до встроенных правил, которые для вывода решения не могут принмать свободных переменных (например - встроенная арифметика), соответсвующая трансформация может быть отложена или переведена в разряд ленивых вычислений.
2. Ограничения. С переменными могут быть ассоциированы предикаты, ограничивающие область возможных значений, которую переменные смогут принимать в при унификации.
3. Динамическая типизация с ограничениями. Как следствие п.2. пользователь может определять ограничения типа значений, которые могут связываться с переменными. Поскольку язык ограничений и язык программирования - один и тот же, система типов является Тьюринг-полной, т.е. програмист может описать тип произвольным образом ограничивающий область своих значений. Записи, алгебраический типы и т.п. могут быть выражены через эту базовую идею и быть оформлены как синтаксический сахар.
4. Единое представление программы и данных. Как следствие - возможность метапрограммирования.
5. Явные средства по контролю детерминизма (преобразование недетерминированных вычислений в ленивые списки результатов и списков в недетерминизм).
6. Развитые встроенные средства для обработки множеств.

За сим мысль обрывается. Из уже сделанного по этой теме - прототип движка переписывающего термы (без пряников, в виде ограничений) и обрывочные примеры программ на этом гипотетическом языке. На самом деле сделано пока мало. Мучает вопрос - а не делаю ли я велосипед? М.б. подобного рода вещи уже реализованы в виде библиотек/плагинов/компонентов. В гугле пока ничего не нашёл.

Я стал папой.

Fri, 21 Aug 2009 02:14:23 GMT

Собственно, сабж!
Сегодня утром у меня родился сын.
Началась новая жизнь. :)

О вырождении программистов из-за новых технологий :)

Thu, 09 Jul 2009 17:41:23 GMT

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

Из чего складывается сложность работы программиста? Она складывается из двух вещей. Одна из них - это фундаментальная сложность программирования, заключающейся в том, что программирование - это суть перевод с человеческого языка на формальный со всеми вытекающими последствиями (необходимость разрешать неопределённости). Причём перевод не вольный, а поставленный в рамки ограничений, как и любая другая инженерная работа. Это, кстати, ОСНОВНАЯ сложность. Другая сложность - это инструментальная сложность. По сути, столь яростно остаиваимая "элитарность" олдфажных программитстов на С/С++ и т.д. сводилась к тому, что они успешно боролись недостатками и ограничениями машин и самих инстурментов. Новые языки намного лучше скрывают эти подводные камни, чем вызывают зависть и агрессию олдфагов, поскольку делают ненужным целый пласт знаний и навыков, в которые были вложены многие силы, и которые являются предметом гордости. Это МЕНЬШАЯ сложность. Так что считать, что именно упрощение инструментальных средств делает программирование проще, означает допускать ошибку. Это делает проще КОДИРОВАНИЕ.

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

А тут IQ и желание учиться надо даже поболее, чем для того, что бы на досуге выучить С++ и поковырять операционку и пару технологий.

P.S. Недавно видел в одном форуме, как один из "программистов" авторитетно заявлял: "графы? программисту это не надо!" :)

...

Thu, 25 Jun 2009 09:30:27 GMT

Увы, чуда не случилось - вчера после операции, давшей некоторую надежду, Марсик отошёл в мир иной.

Не было печали...

Tue, 23 Jun 2009 08:02:04 GMT

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

"Обитаемый остров" Бондарчука или о том, когда вымышленные миры выглядят как настоящие (или нет).

Mon, 25 May 2009 20:05:17 GMT

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

Фильм "Обитаемый остров", несомненно, продолжил тенденцию "переплюнуть Голливуд" по части спецэффектов и сделал это весьма достойно. Взрывы, стрельба и прочая драчка выглядела весьма убедительно, костюмы были красивы, компьютерная графика тоже на высоте. При всём при этом графически мир Саракша выглядел очень слабо, как-то картонно. Т.е. получилось, что по отдельности все элементы визуального ряда (декорации, костюмы, техника, интерьеры) выглядели вполне достойно, а весь фильм в целом - сплошная бутафория. Например, первые эпизоды "Звёздных войн" выглядят намного убедительнее, хотя с чисто технической точки зрения до "ОО" им далеко - времена уже другие, Лукасу и не снилось нынешних технологий. Тем не менее... Или же "Терминатор" - сама идея пришла Кэмерону в горячечном бреду с температурой за 40, но ему удалось создать весьма интересный, захватывающий воображение образ мрачного будущего, порабощённого машинами. Даже классика советского кино - Кин-Дза-Дза - к которой само понятие "спецэффект" применимо с натяжкой, дает более "достоверную" картину.

Все эти фильмы объединяет то, что графический стиль тамошних миров выглядит ЦЕЛОСТНО. В нём угадываются какие то закономерности, какие-то правила. Что-то, что заставляет верить, что всё должно выглядеть именно так, а не иначе. Что всё так не случайно, а в силу жизненной необходимости, а, значит, достоверно. На их фоне "ОО" выглядит как дешёвая лавка сувениров - всё блестит, всё по отдельности красивое, но всё вместе - пёстрая куча бирюлек, которая и запоминается как что-то сумбурное. Он не захватывает воображение, в этот мир не хочется вернуться в своих мыслях, попытаться его "додумать" за рамкой фильма, как это бывает с действительно хорошими картинами. Этот мир настолько нереален, что вылетает из головы сразу после начала титров. Создаётся впечатление, что господин Бондарчук не пытался представить себе тот мир, который он нам нарисовал. Он не пытался в нём "жить", он не был одержим им, как был одержим Лукас своей космической сагой. Он сделал товар, подходящий под формальные требования - что бы было нужное количество спецэффектов, драк, стрельбы... Смешать, но не взбалтывать.

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

Встреча с прошлым :)

Tue, 19 May 2009 20:13:11 GMT

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

Но самое ужасное состоит в том, что на фоне того кода, с которым мне сейчас приходится иногда сталкиваться на работе (я уж МОЛЧУ про предыдущую работу) эти мои наивные поделки НЕПЛОХО смотрятся :)

Халява и говнодел как ментальность российского труда

Sun, 17 May 2009 20:22:07 GMT

Помню, когда я работал на своей первой работе, у меня был весьма интересный случай. Это было одно гос.предприятие, производившее некоторую информационную систему для некоторых государственных заказчиков. Я тогда был ещё студент, восторженно глядящий снизу вверх на старших коллег и впитывающий как губка их мудрость и опыт. С самого начала я испытывал чувство гордости от того, что теперь делаю НАСТОЯЩЕЕ дело, а не просто программирую "для себя" в плане хобби. Однако по мере получения опыта и общения с нашими заказчиками я стал понимать, что то, что мы производили - это говно, которое впаривается заказчику нерыночными способами (госзаказ!) и которое не вызывает у пользователей такого чувства восторга, которое испытывал я поначалу. Говно со всех сторон. Задумка - говно, исполнение - гавно (код одной из программ до сих пор занимает первое место в моем персональном рейтинге говнокода. А повидал я с тех пор немало!), потребительские качества - тоже говно (глючит, падает... мрак).

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

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

У Пола Грэхэма в книге "Hackers and Painters" есть хорошая глава о богатстве и деньгах, в которой он поясняет, что это не одно и то же. Богатство - это материальные вещи, которыми мы пользуемся, а деньги - это некоторая абстракция, которая лишь делает удобным обмен одного богатства и другое. Богатство относится к реальному сектору, деньги - к финансовому. Залог успеха - делать то богатство, которое нужно другим людям, что бы они с удовольствием меняли его на свои деньги. (Тут, кстати, можно сильно отвлечься в обсуждение кризиса, вызванного излишним раздуванием фин.сектора, но это отдельная тема). У нас же, к сожалению, залогом успеха считается именно умение эти деньги из клиента изъять, пусть даже обманув его, и произведя на свет гавно вместо богатства.

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

Страна получает "неконкурентноспособную экономику", народ презрительно морщит носики на отечественные товары (хотя сам делает такие же дерьмовые товары и не краснеет), требует повышения пошлин на товары иностранных конкурентов (что бы впаривать) и снижения пошлин на все остальное (ну не хочется же гавном пользоваться! дайте качественный импорт, сволочи), рассуждает о том, что бизнесу ставится много бюрократических препонов (а что еще, если вдуматься, с этой сворой обманщиков делать?), злится на свои зарплаты... Конечно, если сам не понимаешь ценности своего труда, то сложно понять его реальную стоимость. И, наверное, очень не хочется признавать, что твоя работа и тех денег не стоит. Хотя в глубине души сам прекрасно понимаешь, что...

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

Такие дела.

Yield Prolog

Mon, 02 Mar 2009 09:43:11 GMT

Покопавшись на просторах "Lamdba the Ultimate" обнаружил совершенно замечательную и остроумную реализацию языка Prolog, как встраиваемого языка. Называется Yield Prolog в честь конктрукции "yield", т.е. итераторов на продолжениях, которые поддерживаются в C#.

Страничка проекта: yieldprolog.sourceforge.net/

Звериный оскал Google

Thu, 12 Feb 2009 08:23:27 GMT

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

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

Программа как сообщение или о высоте языка программирования

Wed, 11 Feb 2009 15:42:36 GMT

Некоторые не очень связные и оформленные мысли посетили недавно мою голову во время размышлений, чего бы такого приладить к Prolog'у, что бы всем хорошо стало :) Мысли эти касаются языков программирования и программирования вообще.

Во-первых, что такое программирование и чем оно отличается, скажем, от инструктирования человека? Очень близкий к этому вопрос - чем естественные языки отличаются от языков программирования?

Во-вторых, в чём суть "высокоуровневости" языка программирования и что именно мы имеем в виду когда говорим "язык X более высокоуровневый, чем язык Y"?

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

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

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

Во второму вопросу: родилась тут у меня в голове некоторая моделька, трактующая программу как сообщение, которое программист посылает компьютеру. Основная (и весьма спорная!) идея этого умопостроения заключается в том, что информация (в широком смысле), сообщаемая компьютеру для решения некоторой конкретной задачи, инвариантна относительно языка программирования. Т.е. программируешь ты на Lisp'е или на ассемблере, ты сообщаешь компьютеру некоторый объём информации, которые он способен, пользуясь компилятором/интерпретатором, свести к встроенным в него операциям.

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

"Высота" языка программирования может быть измерена в длинне сообщения. Чем короче получается программа, тем выше уровень языка программирования. Природа тех свойств языка, которые "повышают" его уровень, позволяя короче формулировать программу - тема очень интересная и отдельная. Например очевидно, что добавление в язык предметно-специфичных свойств упрощает программы (пример - SQL), но есть свойства языков, которые нельзя назвать domain-specifiс, но при этом они определённо повышают уровнь. Можно ли считать, что логическое программирование "более высокое", чем функциональное? Попутно возникает другой интересный вопрос - существует ли верхний предел для "высоты" языка программирования?

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

О жж-иистерии

Thu, 29 Jan 2009 15:02:52 GMT

Недавно в жэжэшечке случилось очередное бурление страстей. Если кто не в курсе, по ссылке подробности: community.livejournal.com/doktor_killer/417385.html. В этой истории меня сильно заинтересовало даже не то, было ли всё так, как описано девочкой или на самом деле прав опровержитель. В этой истории меня заинтересовала реакция жж-сообщества, которое тут же бросилось аквтино участвовать в обсуждении. Большинство обывателей разделилось на два лагеря, яростно спорящих друг с другом - защитников и обвинителей авторши исходной записи. Типичный представитель каждого из лагерей обладал двумя яркими свойствами:
1. Абсолютная уверенность в своей правоте и готовность спорить.
2. Отсутствие каких-либо сведений, способных подтвердить его точку зрения.

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

Другими словами весь этот флейм можно перефразировать просто: "Не пишите такого, пожалуйста, вы разрушаете мои комфортные иллюзии!"

О декларативном и императивном

Thu, 01 Jan 2009 22:53:04 GMT

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

В последнее время в IT-сообществе наблюдается стойкий рост интереса к декларативным языкам общего назначения. Декларативные языки специального назначения существуют уже давно и не у кого не вызывают удивления. Яркий пример такого языка - SQL. Так же уже давно существуют "нечистые" декларативные языки, которые позволяют писать императивные программы. Пример - Lisp и Prolog. Каждый из этих языков можно назвать пионером в своей области (ФП и ЛП, соответственно), но они не являются строгими языками. "Последователи" этих языков - "чистые" Haskell и Mercury являются строго декларативными языками и вокруг них наблюдаются дискуссии по вопросу их применимости в реальных задачах, которые решает IT-индустрия (которую часто противопоставляют "академической" разработке). Накал этих дискуссий иногда бывает велик :) Я слышал от одного человека характеристику "хаскеллистов" как "странных людей", а один из этих "хаскеллистов" жаловался в камментах, то их троллят на форумах :) Меня лично декларативное программирование (особенно логическое) сильно привлекает своей красотой и выразительной силой, но до сих пор я вижу серьёзный разрыв между теми задачами, которые я решаю на работе и теми задачами, для которых был бы оптимален, например, Prolog. Нет ли серьезных оснований под аргументами тех людей, которые говорят, что в целом нам императивного подхода хватает, а ФП, ЛП и прочий "матан" нужны лишь для "2% задач" ((с) Пол Грхэм), где можно обойтись DSL и не вводить этот "матан" в мэйнстрим?

В чём суть этого разрыва между светлым декларативным будущим, неизбежным, как крах капитализма, и суровым императивным настоящим? Суть этого разрыва составляет то, что сама наша реальность носит пространственно-временной характер и любая работа в ней заключается в изменении состояния в течение какого-то времени. Именно от этих вещей - состояния и времени - декларативное программирование пытается абстрагироваться. Цель этого абстрагирования весьма благородна - декларативные программы в явном для компилятора/интерператора виде указывают на все взаимозависимости разных частей программы, что сильно "развязывает руки" среде выполнения в плане определения порядка выполнения. Другим полезным эффектом декларативности является то, что программист перестает думать о последовательности выполнения действий в программе. Ленивые вычисления, бэктрэкинг, возможность изменять порядок выполнения тех или иных частей программы - всё это абстрагирует программиста от того, в каком порядке и как будет исполняться работа.

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

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

Естественно, что создатели "чистых" языков общего назначения тоже были вынуждены обеспечивать возможности работы с временем и состоянием. Например, в Haskell для этого применяются монады, а в Mercury - линейные типы. Это примеры того, как теоретические фреймворки декларативного описания работы с временем-состоянием используются для того, что бы дать возможность программисту выполнять действия с состояниями, не нарушив при этом чистоту языка и максимально сократив возможности "прострелить себе ногу". В качестве контраста можно привести Lisp и Prolog, где разделение на "чистые" и "грязные" части программы (функции/предикаты) поддерживалось исключительно в голове программиста и он сам нес всю ответственность за то, что бы императивность не "прокралась" туда, где ей не место. Цена этой защиты - сложность в понимании тех теоретический моделей, которые лежат в основе языков, и снижение "хакабельности" языка (ценность последнего свойства, вообще говоря, сомнительна, но её проповедник - Пол Грэхэм). Иными словами, что бы делать некоторые вещи, которые на традиционных императивных языках делаются просто и естественно, на чистых декларативных языках делается сложно и с трудом.

В чем зключается эта сложность и чем декларативная работа с временем-состоянием отличается от императивного программирования? Составляя императивную программу мы явно указываем какие действия и в каком порядке совершить, неявно подразумевая граф зависимостей между действиями и состояниями: каждый шаг в программе зависит от некоторых состояний, которые должны быть обеспечены предыдущими шагами либо исходными условиями, и обеспечивает какие-то другие состояния, которые могут быть либо результатом работы программы, либо пререквизитом для следующих шагов. В декларативной программе все с точностью до наоборот - мы должны явно указать зависимости между операциями, а среда выполнения сама должна разобраться, в каком порядке выполнить действия. Когда мы имеем дело с "чистыми" операциями, мы имеем лишь зависимости по входам/выходам функций (это в ФП, в ЛП ситуация несколько сложнее, ибо там программы имеют свойство обратимости) и спецификация зависимостей достаточно проста. Если мы пишем f(g()), то ясно, что вызов f() зависит от результата вычисления g(). Спецификация зависимостей по состоянию сложнее, особенно если принимать в расчет внешнее состояние (файловая система, ОС, и т.п.). Для этого, во-первых, требуется разработать (разработчику языка) и потом понять понять (программисту) модель описания зависимостей. Во-вторых, описание зависимостей требует большего объема "писанины" просто в силу того, что модель зависимостей содержит в себе больше информации о намерениях программиста, чем конкретная последовательность действий. В-третьих, всегда остается опасность, что разработанная модель описания окажется слишком ограниченной для потребностей некоторых задач, что приведет к необходимости "грязных хаков" со стороны программиста. К плюсам идеи декларативного описания зависимостей можно отнести то, что она предоставляет программисту больше возможностей описать свои *намерения* и донести их до среды выполнения, которая сможет оптимизировать программу, распараллелив, например, те участки кода "с состояниями", которые на самом деле друг от друга не зависят. К слову, оптимизаторы императивных языков вынуждены пытаться выводить эту высокоуровневую информацию из императивной программы, в то время как их "декларативные собраться" живут на всем готовеньком.

Итак, немного обобщу уже сказанное:
1. Любая работа, совершаемая в компьютере, имеет характер изменения состояния во времени.
2. Есть состояния, которые нас не интересуют, а есть те, которые нас интересуют. От первых мы хотим абстрагироваться, над вторыми мы хотим иметь контроль.
3. Целиком мы можем абстрагироваться от внутренних состояний программы, но не забывая о дырявости любых абстракций. От состояния, связанного с взаимодействием с внешней средой абстрагироваться нельзя.
4. Управлять состоянием, связанным с внешней средой можно императивно и декларативно. Оба варианта имеют свои плюсы и минусы, соотношение которых - вопрос открытый для обсуждения. Как минимум разные плюсы и минусы перевешивают друг друга в разной степени в разных задачах.

On Intelligence: How a New Understanding of the Brain will Lead to the Creation of Truly Intelligent

Wed, 26 Nov 2008 14:45:41 GMT

Сейчас читаю сабжёвую книгу. Вышла она ещё в 2004-м году, но мне на глаза попалась только недавно. Если вы её не видели и интересуетесь природой интеллекта (искусственного или естественного), то крайне рекомендую. Автор - Джеф Хокинс (Jeff Hawkins). Кстати, основатель Palm Computers и лично папа модели Palm Pilot.

Книга содержит изложение его теории, обясняющей то, как мы думаем. Лично мне она показалась весьма интересной, хоть и не безупречной. Его теория уже - не совсем теория. На её базе он разработал модель Hierarchical Temporal Memory (en.wikipedia.org/wiki/Hierarchical_Temporal_Memory), которая уже имеет своё софтверное воплощение.

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

UPD: Вот что бывает, когда пишешь отзыв, не прочитав целиком книгу :) Зачёркнутому не верить! :)

Ограничения в языках программирования. Продолжение.

Tue, 11 Nov 2008 21:07:51 GMT

Продолжение предыдущего поста: 0x7be.livejournal.com/42318.html

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

Если проследить историю развития языков программрования, то можно увидеть тенденцию к внедрению таких ограничений. Например, при переходе от иперативного С к С++ (даже тому, что называют "better C", т.е. процедурному подмножеству) мы видим целую совокупность улучшений системы типов. При переходе от функционального LISP к более строгим языка типа ML или Haskell мы видим внедрение статической системы типов. При переходе от логического Prolog к Mercury мы так же видим внедрение системы типов и систему декларирования детерминизма предикатов (причём порежимно). Кстати, параллельно этой тенденции наблюдается и попытка "очистить" парадигмы языков. Например, при переходах LISP->Haskell, Prolog->Mercury прослеживается "потеря" императивных возможностей, которые существовали в LISP/Prolog на правах "запасных" возможностей для особых ситуаций. Другой пример из Java - checked exceptions. Основная суть - метод декларирует, какие исключения из него могут вылететь и не позволяет бросать из себя ничего иного. Если же хочешь вызвать что-то, что бросает какие-то "левые" исключения - сам виноват. Будь добр обложить место вызова тонной try/catch`ев.

Если попытаться обобщить эти идеи, то из можно свести к следующей, более общей: программист должен явно специфицировать определённые аспекты контракта единицы организации программы (процедуры, функции, предиката) и становится ограничен этой спецификацией. Аспекты задаются самим языком, его теоретической моделью. Самый распространённый - типы параметров и возвращаемого значения (С/С++, Java, C#, Mercury, Haskell и прочие статически типизированные языки). Другие примеры - детерминизм предиката (Mercury), спецификация исключений (C++, Java), константность метода (С++), инварианты/пред-, постусловия (языки с поддержкой design by contract). Используя эту информацию компилятор может обнаружить, где программист пытается использовать примитивы и абстракции способом, нарушающим их контракты. Так же компилятор может опираться на эти ограничения для генерации более эффективного кода.

У подобного подхода есть и недостатки. Во-первых, спецификации контракта требуется описывать, хотя они и не создают новый функционал программы. Т.е. снабжённая такая спецификациями программа становится более многословной при таких же возможностях. Системы вывода ограничений могут тут помочь. В частности, системы вывода типов (type inference: ML, C#, Nemerle) позволяют сильно сократить количество кода и сделать его синтаксически более гибким.

Во-вторых, механизмы ограничений иногда бывают слишком ограничивающими. Очень яркий пример - checked exceptions в Java. В дискуссиях об оправданности этого механизма было сломано очень много копий и существует немало людей, считающих этот механизм ошибкой разработчиков языка. Другой пример - необходимость написания обобщённых функций, которые должны обрабатывать совершенно не связанные друг с другом типы сходным образом. В языках со статической типизацией для этого приходится вводить специальные механизмы для обобщённог опрограммирования - шаблоны в C++ и generics в Java и C#. Ближе к идеалу, наверное, шаблоны С++, поскольку они обеспечивают compile-time duck typing, чего дженерики всё же делать не могут. Но та гибкость, которую дают шаблоны и дженерики, имеет свою цену. Для шаблонов это - раздувание кода при инстанциировании и строгое ограничение возможностей шаблоном временем компиляции. Дженерики (я говорю о .NET-реализации) более экономичны и их можно использовать в run-time для динамического инстанциирования, но их возможности более ограничены, по сравнению с шаблонами. Языки с динамической типизацией (Lisp, Prolog, Pure) не знают таких проблем вообще.

В-третьих, подобные системы поддержки корректности программ не всегда полностью соответствуют требованиям конкретной задачи, решаемой в рамках проекта. В одном месте проекта они могут быть избыточны, в другом - недостаточны и в целом не точно отражать потребности программистов. В итоге снижается продуктивность разработчиков и проект в целом страдает. Это, кстати, привело к тому, что появился серьёзный интерес к динамическим языкам и попытки перенести заботу о корректности программы из области самого языка в область методологии (знаменитое "strong testing, not strong typing" Брюса Экеля). Я не хочу здесь и сейчас рассматривать методологические возможности для решения описываемой проблемы и хочу сконцентрирвоаться на технических, по-этому идею об отказе от любых ограничений в языке в пользу максимальной выразительности разрабатывать не буду.

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

В итоге перед моим внутренним взором вырисовывается примерно следующая идея для языка: динамический язык, дающий программисту как можно больше свободы, поддерживающий метапрограммирование для генерации и верификации кода. В зависимости от потребностей проекта (или части проекта) программист волен самостоятельно определять правила, накладываемые на язык. Данная схема содержит свои подводны камни и непростые вопросы, на которые надо дать ответ. В частности:
1. Должна ли система верификации оперироать только с базовыми примитивами или должна иметь возможность охватывать пользовательские примитивы?
2. Не приведёт ли свобода определения системы верификации к появлению целого зоопарка несовместимых с собой систем верификации и, как следствие, модулей, написанных в рамках этих систем?
3. Возможно ли дать программисту полную свободу в определении системы верификации и в то же время эффективно использовать те гарантии, которые она даёт, для автоматический оптимизации программы?

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

Ограничения в языках программирования.

Mon, 10 Nov 2008 20:54:15 GMT

Продолжение мыслительного процесса, начатого тут: 0x7be.livejournal.com/37690.html и продолженного тут: 0x7be.livejournal.com/38538.html.

Как я уже говорил раньше, любой язык программирования что-то программисту позволяет делать, а что-то не позволяет. То, что он позволяет - это выразительная сила языка, а то, что он не позволяет - это ограничения, которые язык накладывает на программы. Например, язык С++ позволяет нам описывать классы и создавать объекты. При этом он запрещает присвоение объектов (или указателей на них) несвязанных между собой типов. Или, например, так же он запрещает осуществлять вызов метода объекта, если тип ссылки на объект метод с такой сигнатурой не описывает. Или другой пример - ассемблеры. Как правило, они тоже накладывают много своих ограничений. Например, в обычном 8086-совместимом ассемблере команда mov, осуществляющая пересылку данных, не может пересылать их из памяти в память - будьте добры использовать регистр в качестве промежуточной остановки. С другой стороны - верти байтиками и битиками как хочешь, только всё ручками пиши :)

Ограничения, которые я тут привёл в качестве примера, кое в чём неоднородны. Часть из них происходит из ограниченности возможностей языка, а часть - из желания помочь программисту в борьбе со сложностью программ путём их частичной формальной верификации. Например, запрет на вызов метода, чья сигнатура не описана в типе ссылки на объект происходит из "неумения" С++ это делать. Механизмы вызова метода в С++ так устроены, что они неспособны осуществить динамический вызов метода, даже если конкретный класс экземпляра такой метод поддерживает. С другой стороны - запрет присваивать указатели на объекты несовместимых классов является именно средством поддержки корректности программы, так как физически никто не мешает скопировать данные из одного указателя в другой (и, кстати, С это умеет делать прекрасно). Таким же средством является принуждение к const-корректности. Примечательно, что в С++ все эти ограничения можно обойти через систему приведения типов или же специальные лазейки (например, mutable-члены классов). Это целиком укладывается в философию Страуструпа - дать программисту небезопасные возможности, но требовать их явного применения, что бы избежать ненамеренных опасных действий.

Если проследить направление развития языков программирования, то можно увидеть несколько тенденций. Первая тенденция - повышение возможностей языка через повышения уровня его абстракций. Основная цель этого направления развития - устранить ограничения, накладываемые реализацией и повысить производительность программиста. Например, все высокоуровневые императивные языки поддерживают операцию присваивания, т.е. копирования данных из памяти в память, чего не поддерживают некоторые процессоры (см. выше про ассемблер). Другая цель подобного развития - борьба со сложностью программ. Пряча тонкости реализации "под капот" высокоуровневых примитивов языки освобождали внимание программиста от ненужных деталей, таких как жонглирование регистрами, диспетчеризация вызовов, управление памятью и т.п. Это сокращает количество сущностей в поле зрения программиста, что, в свою очередь, освобождает его от "микроменеджмента" и устраняет множество потенциальных мест, где программист может совершить ошибку. Естественным ограничителем для этого являются вычислительные ресурсы компьютеров. Их ограниченность требует оптимизации механизмов языка, а это накладывает свои ограничения (например, механизм позднего связывания на таблицах вирутальных функций, который применяется для реализации полиморфизма в таких языках, как С++, Java, C#).

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

Одна из форм проявления этого тренда - это ограничиение выразительной мощи языка путём удаления из языка "вредных" или плохо поддающихся анализу и контролю возможностей и концентрация на какой-нибудь хорошо проработанной идеологии. Иными словами, имеет место попытка привести многобразие возможностей языков в некий порядок, путём наложения на них некоторой выбранной парадигмы, теоретической модели. Всё, что в неё не укладывается - выбрасывается, то, что остаётся - описывается и регулируется набором правил запретительного свойства. Весьма интересен пример подобного тренда на примере языка Java. Как известно, одним из "вдохновителей" Java был С++. Но этот язык, по мнению создателей, был слишком монструозным и "неизящным". В итоге мы получили новый язык с весьма элегантной моделью, лозунгом которой был "Everything is object". Это как раз пример укладывания языка в прокруствов ложе некоторой идеологии. Здесь это - традиционное ООП в стиле Smalltalk. Авторы языка гневно отвергали разные возможности, которые, по их мнению, не укладывались в эту красивую модель. Делегаты, например. Даже засудили Microsoft, когда те своей реализации Java их реализовали. (Злые языки говорят, что после этого Microsoft плюнуло на Java и выпустило свои заготовки под брендом .NET). И что мы видим сейчас? Мы видим сейчас как в этот "чистый" язык внедряются многие из этих "гневно отвергнутых" фитч. Перечисления, например. Или функции с переменным количеством аргументов. Или дженерики. Так скоро и ненавистные делегаты включат. (Microsoft со своим C#, кстати, идёт гораздо дальше и развивает язык гораздо быстрее.)

В качестве другого примера хочу рассмотреть "конкуренцию" языков Pascal, Modula, Oberon и С/С++. Профессор Никлаус Вирт создавал свои языки исходя из очень твёрдых теоретических позиций, его языки просты и элегантны. Он гордится тем, что спецификации его языков очень лаконичны. Особенно если сравнивать со Стандартом C++. Однако его языки не получили очень большого распространения. В мэйнстрим вошёл только Pascal, да и то с кучей нововведений, которые он не благословлял (да, к фирме Борланд и их фантазиям на тему его языка он не имел никакого отношения). Зато страшный и ужасный С и, потом, С++ стали в своё время хитами и даже сейчас активно используются. Ужасный С++ создавался Страуструпом с совершенно иными философскими установками - он не хотел ради идеологической чистоты жертвовать практической применимостью. Отсюда и "тяжкое наследие С" и общая мультипарадигменность языка. Я бы даже сказал некоторая эклектичность.

Третий пример - языки Scheme и Common Lisp. Scheme - очень красивый и интересный язык (диалект LISP) интересный многими интересными свойствами (чего только стоят первоклассые продолжения!) и отсутствием "тяжкого наследия" некоторых фитч "оригинального" LISP. Увы, язык академический. Common Lisp, хоть и не сильно заметен на фоне мэйнстрима, всё же используется. Язык монструозен. Вековые наслоения фитч и атавизмы первых инкарнаций Lisp в нём сохранились до сих пор. Его спецификация, кстати, по объёму может конкурировать со Стандартом.

Эти примеры приводят к следющему заключению - попытки сделать язык на основе очень простой, элегантной, целостной и строгой модели организации программ оказываються неудачными. Основной метод создани таких языков - концентрация на какой-то хорошо проработанной парадигме (часто в её частном случае) и объявление всего остального ересью или "вредными возможностями", которые будут "провоцировать программистов на написание плохих программ". В итоге язык выходит красивым с теоретической точки зрения, но он слишком выхолощен и неудобен для использоваиня в реальных задачах, которые решаются в индустрии. Такие языки либо не выходят из ранга академических или экспериментальных со своим маленьким коммьюнити (Scheme, Modula, Oberon), либо постепенно обрастают свойствами, придающими им полнофункциональность, но размывающие изначальную чистоту и аскетичность их дизайна (Java, Pascal -> Delphi).

Собственно говоря, поиск "единственного верного" пути с отсечением всего остального - тупиковая ветвь в дизайне языков программирования. Человечество "открывает" разные полезные парадигмы и приёмы программирования, причём ни один из них не является универсальным ответом на все вопросы программирования ("серебрянной пулей"). Каждая из этих идей - это эффективный инструмент решения задач в некоторой области. Объявлять те или иные парадигмы "вредными" означает сужать поле своих возможностей. Любое средство имеет свою нишу и может быть применено там с пользой (да, даже еретический оператор goto!). И наоборот - самые разумные и добрые парадигмы могут быть использованы не по назначению и их неумелое применение может привести к хаосу в проекте. Из этого я делаю вывод, что будущее за полнофункциональными и многопарадигменными языками программирования.

Продолжение следует.

Публицистика - она как еда...

Thu, 30 Oct 2008 19:04:58 GMT

... в смысле, что приедается. Я не люблю всякие новости читать, телевизор смотреть и газеты переводить. Но как-то узнавать, что важного (ну, в смысле, могущего меня затронуть) творится в мире надо. И я читаю всякие серьёзные (как мне кажется) сайты на которых выложена всякая Аналитика. Всякая Аналитика отличается от обычных новостей тем, что она не просто рассказывается нам, что где-то случился, простите, пиздец. Она ещё рассказывает, почему он произошёл, какова его предыстория и как он дальше будет развиваться (ну это понятно - от плохого к худшему). Как вариант, Серьёзная Аналитика рассказывает нам, что в ближайшем/среднесрочном/отдалённом (нужное подчеркнуть) и объясняет, почему именно, исходя из нынешних реалий.

Серьёзная Аналитика имеет одну особенность - в зависимости от автора, фазы луны, количества осадков и солнечной активности для одних и тех же ситуаций прогнозировать совершенно разные ситуации. Ну оно и понятно - это же Серьёзая Аналитика, а не попса! Тут думать надо, панимаш! Однако несмотря на всю свою неоднозначность, она стала приедаться. Сейчас так много стало публикующихся "аналитиков", что на всех перестало хватать оригинальных мыслей и идей. Как-то так само получается, что теперь я с первого абзаца классифицирую статью и говорю себе: "ага, это очередная экологическая страшилка, можно не читать". Вместо экологической страшилки может быть и что-то другое:
1. Ядерный армаггедон, как неизбежное следствие кризиса.
2. Серьёзный западный анализ внутриполитической ситуации в Росии с медведями, балалайками и кровавой гэбнёй.
3. Серьёзный русско-патриотический анализ ситуации в США с тупыми американцами, зарвавшимся империализмом, неизбежным коллапсом США.
4. Рассуждения о том, что Европа таки уже должна объединиться.
5. Фундаментальное обоснование того, что необходимо "сдерживать Россию".

Ну и так далее. Сюр какой-то. Такое впечатление, что взяли публикации из нескольких параллельных реальностей и смешали в кучу. Хотя, в каком-то смысле так оно и есть...
Жить, мля, стало лучше! Жить стало веселее...

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

О зомбоящике и ещё немного размышлений.

Mon, 22 Sep 2008 18:01:19 GMT

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

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

Что я могу сказать о своих ощущениях после отказа от телевидения? Ощущение свежести и чистоты в голове. Правда-правда. Реклама, новости, всякие дурные передачи, которые я даже и не смотрел почти - всё это наваливало мне в голову тонны ненужной, избыточной информации. Наводнения, пожары, маньяки и т.п. Какого чёрта мне надо знать о том, что происходит с теми людьи, которых я никогда не узнаю, в тех местах, где я никогда не буду? Человек слаб. Его внимание, способность охватить вещи своим сознанием и осмыслить их ограничены. Зачем тратить их на такие ненужные вещи? Лучше я потрачу их на своих близких, на себя, в конце концов. Подумаю о жизни, о своём месте в ней. Попытаюсь понять истинную цену всем тем громким словам и красивым картинкам, которыми меня потчуют с экрана.

Однако именно это и пытается предотвратить существующая система масс-медиа. Она делает всё, что бы распылить наше внимание, впарить нам как можно больше информации, заставить нас эту информацию некритически воспринять, записать на подкорку как магнитофон и воспроизвести когда надо в виде нужных дейсвий. Политические установки, реклама, пропаганда. Всё это обёрнуто в красивую обёртку и в удобоваримом виде подаётся нам с экранов, из газет, с рекламных щитов... Раскрой рот, развесь уши и воспринимай. Отключи мозг, сделай как сказано и будет тебе щастье! Куча бабла, девушек, слава... Техники воздействия давно разработаны, приём очень неглупыми людьми. Эти техники корнями уходят в НЛП и призваны обойти барьеры сознания человека, отключить его трезвую оценку поступающей информациию. Самое страшное для этой системы, это когда человек говорт: "эй, стоп! давайте разберёмся". Этот человек неугоден системе, лучше бы его не было.

Является ли это всё мировым заговором против человечества? Нет, не является. Я вообще не сторонник таких теорий. "Не ищите злого умысла там, где можно всё объснить глупостью". Просто сейчас именно так живёт наше государство, для которого нет людей - есть электорат. Так живёт бизнес, дя которого нет людей - есть целевые аудитории и рынки сбыта. Это их modus vivendi. Не стоит бороться с этой системой, она слишком велика и всеобъемлюща. Надо лишь сказать: "эй, стоп!", выйти из этого круговорота распыления внимания. Перестать заботиться о том, о чём тебе приказано заботиться властями и корпорациями. Надо подумать о себе, о своём месте в этой жизни.

И тогда в голове появится чувство свежести и чистоты...

О самопозиционировании через отрицание (на примере чайлдфри)

Wed, 30 Jul 2008 13:48:14 GMT

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

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

Есть линуксоиды. Это не те, кто просто любят и знают Линукс. Это экзальтированные люди, активно противопоставляющие себя корпорации Майкрософт, уничижительно высказывающиеся о ней и постоянно подозревающие её во всяких гадостях.

Ну и так далее. Ладно, вернемся к чайлдфри. Я в последнее время стал регулярно захаживать в ru_childfree, что бы посмотреть на участников данного коммьюнити. Один раз я вступил в дискуссию и имел несколько интересных диалогов. В частности с одним весьма благоразумным и вежливым участником. И с одним невежливым.
Ниже приводится самая интересная часть диалога с невежливым участником:

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

Я: > всё побросать и упиваться соплями бессмысленного вопящего огрызка
Вы действительно полагаете, что уделение внимания ребёнку заключается в процитированном действии?

Она: А как иначе обозначить действие по отношению к безмозглому, ничего не понимающему куску мяса, который способен только издавать звуки и испражняться под себя? Новорожденный- это точно такой же кусок плоти, как тушка курицы, которую покупают на суп, только верещащий и исрекающий вонючими ингредиентами.

Я: >А как иначе обозначить действие по отношению к безмозглому, ничего не понимающему
>куску мяса, который способен только издавать звуки и испражняться под себя?
Почему куску мяса? Вы еще забыли кости, внутренние органы, нервную систему, наконец :) Вообще, Ваша изобретательность и креативность в употреблении эпитетов меня восхищает :) Скажите, а когда я ухаживаю за своей машиной, Вы, наверное, скажете, что я упиваюсь машинным маслом и антифризом, да? :)

Она: Скажите, а когда я ухаживаю за своей машиной, Вы, наверное, скажете, что я упиваюсь машинным маслом и антифризом, да?///////////////

Ключевое слово у вас- "наверное". Им вы оправдали выдачу собственных мыслей за мои. Мне нет дела, какие у вас интимные отношения с техникой и с каким упоением вы лобызаете сраки у младенцев. Главное, что бы вы эти особенности своей натуры не навязывали тем, у кого другие отношения с машинами и младенцами.

Я: Да боже упаси, кто Вам что навязывает? :)
Просто меня завораживает Ваша манера излагать свои мысли, с постоянно возникающей темой орального контакта с разными выделениями или выделительными органами :)

Она: Завораживает??? Ну, так бы сразу и сказали, что вы обычный извращенец.

Я: Фи. Ну вот зачем Вы сейчас меня обидели? Я разве про Вас что-то нехорошее говорил?

Она: Фу! А зачем вы меня выше по ветке обидели? Я тут сижу вся из себя такая разобиженная, а вам хоть бы хны! С вашей стороны это жестоко и бесчеловечно! Это варварский способ унизить женщину! Вы меня ненавидите, а я вам ничего плохого не делала. Вы меня преследуете с целью унизить и оскорбить! Вы агрессор! Вы попрали права слабых и беззащитных! Выражаю вашей неуёмной жестокости всяческую ноту протеста и вотум недоверия.

Я: А где я Вас обидел? Я тут ни одного слова вообще дурного не сказал И уж тем более не называл никого нехорошими словами. Если можно - приведите цитату моей фразы, Вас обидевшей.

Она: Вот! Видите? Вы уже начали выкручиваться и изворачиваться! Вы находите тысячу способов поиздеваться! Жестокосердный тиран!

Я: Так я тиран или извращенец? Вы уже определитесь пожалуйста, а то как-то неловко плолучается. И вообще, Вы оскорбили меня второй раз! Как Вам не стыдно?!

Она: Хмм.. знаете, ваше необычное пристрастие к новорожденным младенцам вкупе - такая специфическая вещъ... Вы уверены, что сообщество ЧФ то самое место, где найдется удовлетворение этой вашей страсти? Может быть имело бы смысл поискать способы для выхода подобных потребностей в каких-то... ммм... специализированных сообществах? Ну.. Есть же, наверняка, группы объединяющие людей, мучающихся подобными патологиями..
Очень волнуюсь за вас.

Я: Ах, я тронут Вашей заботой о моей скромной персоне! Право же, не стоит так волноваться. Спешу Вас успокоить - я ни одного младенца в жизни на руках не держал. Кроме того, я совершенно не могу понять, каким образом вы заключили, что я люблю детей. Это абсолютно неверное заключение. Я отношусь к ним сугубо нейтрально. Если Вы потрудитесь перечитать написанное мною в этом коммьюнити, то Вы, несомненно, придете к правильным выводам. Возможно Вы несколько поторопились приписать мне определённые взгляды только на том основании, что я не согласился с некоторыми мыслями, изложенными автором поста и Вами.

Она: Бла-бла-бла
Поди поучи жену щи варить, учитель фигов. Много вас тут таких, указчиков ходит. А мне не указывай что и как мне делать. Указка не выросла.

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

Она: Ах-ах! Какие мы нежные! Обидели суслика- в норку пукнули! Ну поплачь, поплачь.. Побольше поплачешь- поменьше поссышь!

Каюсь-каюсь, я немного троллил, но делал это очень корректно, не скрывая того, что многие вещи я говорю с юмором. Что имеем в итоге? Человек из самого факта, что я с ним о чем-то спорил вывел несколько странных фактов, не имевших места:
1. Будто я сам очень люблю детей.
2. Будто я хочу учить его жизни и указывать, что ему делать.
3. Будто я настроен по отношению к нему агрессивно.
В результате мой собеседник скатился до банального хамства. Т.е., фактически, он спроецировал на меня образ своего идеологического противника.

Данный паттерн прослеживается во поведении многих людей из описанных в начале поста категорий. Их всех объединяет наличие некоторых шаблонных черт:
1. Активное противопоставление себя своим идеологическим противникам, которые позиционируются как некоторое "большинство". Сам противопоставляющий видит себя неким нонконформистом, осмелившимся бросить вызов традициям или общим ценностям.
2. Приверженность крайним точкам зрения, неспособность к компромису или взвешенным суждениям.
3. Крайняя агрессивность по отношению к тем, кто с ним не согласен. Проецирование на всех своих оппонентов целой гаммы отрицательных черт на основании только одного факта, что они с ним не согласны.
4. Мания преследования со стороны некоего мирового заговора людей, исповедующих отрицаемую им точку зрения. Стремление везде искать и видеть факты "давления" или нарушения своих прав со стороны этих лиц.
5. Стремление группироваться с единомышленниками. Желание обсуждать с ними свои мысли и идеи.

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

Eisbrecher

Tue, 22 Jul 2008 13:52:36 GMT

Гуляючи по просторам ютуба наткнулся на совершенно замечательную штуку - немецкую грппу названием Eisbrecher (ледокол, прямо по Резуну :) ). Играют весьма забойный индастриал с электроникой. Вообщем, тащусь как удав по стекловате, доволен как слон и т.п. :)
День удался :)

(HINT: Если вам по душе творчество ВИА Rammstein, то советую послушать).

"В интернете кто-то неправ!" (с)

Sun, 20 Jul 2008 10:54:37 GMT

Вот правильно говорят, что есть люди, знающие и уважающие Linux, а есть линуксоиды. Что бы быть линуксоидом, не надо разбираться в линуксе или иметь хоть какой-нибудь опыт работы в нём. Достаточно иметь достаточный запас классовой ненависти и доступ к форумам, где Windows обсуждают :-)

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

Как это ни забавно, но Линукс всё же является неким флагом, путеводной звездой таких троллей. Последний раз я наблюдал, как один альтернативно одаренный персонаж обливал дерьмом С++ и Страуструпа лично. И что бы вы думали? Он оказался линуксоидом! :)

Мне сильно интересен психологичекий портрет таких персонажей. Ибо есть у меня смутные подозрения, что это такая попытка самоутвердиться через отстаивание своей точки зрения. Во всём споре наблюдается метаконфликт: спор формально о предмете, а реально о том, кто главный, кто круче.

Tue, 15 Jul 2008 09:04:11 GMT

Some people say a man is made outta mud
A poor man's made outta muscle and blood
Muscle and blood and skin and bones
A mind that's a-weak and a back that's strong

You load sixteen tons, what do you get
Another day older and deeper in debt
Saint Peter don't you call me 'cause I can't go
I owe my soul to the company store

I was born one mornin' when the sun didn't shine
I picked up my shovel and I walked to the mine
I loaded sixteen tons of number nine coal
And the straw boss said "Well, a-bless my soul"

You load sixteen tons, what do you get
Another day older and deeper in debt
Saint Peter don't you call me 'cause I can't go
I owe my soul to the company store

I was born one mornin', it was drizzlin' rain
Fightin' and trouble are my middle name
I was raised in the canebrake by an ol' mama lion
Cain't no-a high-toned woman make me walk the line

You load sixteen tons, what do you get
Another day older and deeper in debt
Saint Peter don't you call me 'cause I can't go
I owe my soul to the company store

If you see me comin', better step aside
A lotta men didn't, a lotta men died
One fist of iron, the other of steel
If the right one don't a-get you
Then the left one will

You load sixteen tons, what do you get
Another day older and deeper in debt
Saint Peter don't you call me 'cause I can't go
I owe my soul to the company storeType your cut contents here.

This the Bismark

Tue, 08 Jul 2008 13:50:30 GMT