Category: it

Category was added automatically. Read all entries about "it".

horror

Program evolution

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

Итак, по этапам:

  1. Самый сложный. Проектирование общей архитектуры приложения, обычно на этом этапе рисуется только большой овал без каких-либо конечностей, дальше овал разделяется на области (классы), и устанавливаются связи между ними.
  2. Начало написания кода. Овал приобретает глаза и усики (взаимодействие с API операционной системы), появляются первые варианты реализации методов класса, т.е. ножки.
  3. Итеративный процесс разработки. Первоначальные варианты реализации методов улучшаются и видоизменяются, ножки удлиняются.
  4. Ножки (методы) обретают законченный вид. Если всё хорошо, то уходим на 5 шаг, в противном случае — на 3.
  5. Рисуем интерфейс (круги на брюхе), раскрашиваем GUI (разные цвета), добавляем поддержку шкурок. Программа баг готова!
Оригинал изображения вероятно выглядит так.
horror

Brain API

Для чего не существует ещё API в этом мире? Такое ощущение, что написали уже всё, от количества интерфейсов просто кружится голова, к примеру, только для работы с файлами XML, кода написано – на всю жизнь хватит читать перед сном. Вот и фирма Google недавно выпустила новую платформу Android с полностью отличным набором библиотек: пиши – не хочу.

А зачем они нам, тем более мне? Сейчас бы API для своего тела найти, почувствовать себя Демиургом, управлять входами/выходами своих нейронных сетей.  Насколько я знаю, библиотек таких ещё нет (ещё бы), прежде всего, ввиду слабых разработок в аппаратной части, где же ты Brain Hardware

Вот я и начал ломать голову, как такую библиотеку, назовём её Brain API, можно реализовать.

Сразу разберёмся, что программисту глупо предоставлять отдельные функции по работе со своим телом: getTemperature(), getPressure(); тогда бы программы превратились в обычные последовательности действий или алгоритмы, которые в принципе ничего полезного не могут делать (разве что плановое обслуживание больных, например, контроль того же давления), и были бы просто опасны для здоровья, особенно после такого вот кода:

    for (int i = 0; i < 100; ++i) {
        body.increasePressureByOne();

    }

Конечно же, подобные функции должна поддерживать аппаратная часть. Уже представляю вирусы и червей нового поколения.

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

У нас есть три класса: EyeHandler, EarHandler и BodyHandler, которые наследуют класс EventHandler. Ядром является класс Brain, он должен обновляться каждый tick времени: раз 10 в секунду. Функция tickCount() может содержать любой пользовательский  код, который должен выполняться в каждый момент, а getStatus() – это просто функция, возвращающая полезную информацию.

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

Стоит подумать о полезности всего этого. Самое банальное и простое, что можно вычудить с обработчиком videoUpdate(), к примеру, так это распознавание образов. Конечно, в этом деле мозг самого человека лучший кандидат, но и более медленный. Предположим, что мы изучаем китайский язык, тогда модуль памяти, встроенный в Brain Hardware, может содержать базовые иероглифы китайского языка. При чтении текста, в реальном времени будет вызываться videoUpdate(),которая распознаёт данный иероглиф и уже на зрительные сенсоры человека обратно выводит текстовую информацию с расшифровкой самого «значка».

всё это очевидный бред, просто написать было нечего
horror

Философия программ

Наверное, язык определяет то, о чём человек в принципе может подумать. Плохой язык ограничивает, такому языку обычно не присуща какая-либо внутренняя красота, и, конечно же, он не приносит никакого эстетического удовольствия. Без сомнения, всё это касается и языков программирования. Многие из них давно уже переросли самих себя, перестали быть просто инструментами. Не зря же в разговорах иногда фигурируют такие фразы как «философия С++» или «философия Java»…

Создатель С++, Бьерн Страуструп,  невероятный человек. Хотя бы потому, что он действительно подвёл под своё детище целую философскую систему. Об этом можно прочитать в его книге «Дизайн и эволюция С++». Вот цитата (программистам обязательна к прочтению ;)

/*
Говорят, что структура системы отражает структуру организации, в которой она была создана. В общем и целом я поддерживаю это мнение. Из него также следует, что если система есть плод работы одного человека, то она отражает склад его лич­ности. Оглядываясь назад, я думаю, что на общую структуру С++ мое мировоззре­ние наложило такой же отпечаток, как и научные концепции, лежащие в основе от­дельных его частей.

Я изучал математику, в том числе прикладную, поэтому защищенная в Дании кандидатская диссертация была посвящена математике и информатике. В результате я научился любить красоту математики, но предпочитал смотреть на нее, как на инструмент решения практических задач. Я искренне сочувствовал студенту, ко­торого Евклид, по преданию, выгнал за вопрос «Но для чего нужна математика?» Точно так же мой интерес к компьютерам и языкам программирования носит в основном прагматический характер. Компьютеры и языки программирования можно оценивать как произведения искусства, но эстетические факторы должны дополнять и усиливать их полезные свойства, а не подменять их.

Collapse )

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

При обсуждении философских вопросов, равно как и возможностей языка лег­ко скатиться на чрезмерно серьезный и нравоучительный тон. Если так произош­ло со мной, примите извинения, но мне хотелось объяснить свои интеллектуаль­ные пристрастия, и думаю, что это безвредно - ну, почти безвредно. Да, кстати, мои литературные вкусы не ограничиваются только произведениями вышеназван­ных авторов, просто именно они повлияли на создание С++.
*/

horror

Генератор слов

Когда у меня спрашивают про моё любимое число, то всегда отвечаю 23. А когда вопрос расширяют до "числа", то, конечно же, числа Фибоначчи.

Увидел вот такую задачу:
С помощью автомата, изображённого на рисунке, строятся слова некоторой последовательности. Начальным состоянием автомата является 1, а допускающие: {1, 2}. Нужно определить сколько различных слов N(n) допускаются автоматом, в зависимости от длины слова n.

Таким образом может быть получено лишь одно слово длиной 1 "a", два слова длиной 2 "aa" и "ab", три слова длиной 3, пять слов длиной 4...

Задача детская. Сгенерированное слово может оканчиваться как на "а", так и на "b". В последнем случае можно просто отбросить последний символ "b" и получить слово длиной n-1, и, соответственно, N(n-1) вариантов. Если же слово оканчивается на "a", то предпоследний символ обязан быть также "а", поэтому можем отбросить два символа с конца и получить N(n-2) вариантов. Значит,
    N(n) = N(n-1) + N(n-2), N(0) = N(1) = 1,
т.о. количество слов длиной n соответсвует n-ому числу Фибоначчи.

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

Напрягся и вспомнил, что в unix этому автомату соответствует такое регулярное выражение: '\(a\+b\)\+' .