светало. пели птицы. я искал EBNF для EBNF...

UPD: нашёл, пункт 8.1 документа ISO-14977

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

Урсула К. Ле Гуин, "Резец Небесный"

"...вне нормальной области поведение Q будет "сумасбродным", характеризуясь бурными реакциями даже на регулярные конфигурации...патологическое функционирование сети N может быть вызвано сенсорными входными сигналами, превышающими некоторый стрессовый уровень...самый простой вид лечения - это, естественно, изоляция Q от сенсорных воздействий : y(t) = 0 - лечение изоляцией..."

Ульф Гренандер, "Лекции По Теории Образов (Том 2, Анализ Образов)"

...выключите меня

"...DOLIST is similar to Perl’s foreach or Python’s for. Java added a similar kind of loop construct with the “enhanced” for loop in Java 1.5, as part of JSR-201. Notice what a difference macros make. A Lisp programmer who notices a common pattern in their code can write a macro to give themselves a source-level abstraction of that pattern. A Java programmer who notices the same pattern has to convince Sun that this particular abstraction is worth adding to the language. Then Sun has to publish a JSR and convene an industry-wide “expert group” to hash everything out. That process—according to Sun—takes an average of 18 months. After that, the compiler writers all have to go upgrade their compilers to support the new feature. And even once the Java programmer’s favorite compiler supports the new version of Java, they probably still can’t use the new feature until they’re allowed to break source compatibility with older versions of Java. So an annoyance that Common Lisp programmers can resolve for themselves within five minutes plagues Java programmers for years..."^(c)

dark_aurel показал прекрасное из PCL. в принципе фраза хорошо выражает и моё отношение к Java

"...persistent data structures. Until this research, it was widely believed that amortization was incompatible with persistence. However, we show that memoization, in the form of lazy evaluation, is the key to reconciling the two. Furthermore, as noted by Kaplan and Tarjan, functional programming is a convenient medium for developing new persistent data structures, even when the data structure will eventually be implemented in an imperative language. The data structures and techniques in this thesis can easily be adapted to imperative languages for those situations when an imperative programmer needs a persistent data structure..."^(c)

начал читать Криса Окасаки - хорошо пишет, интересно. чувствую что без проработки этой книги дальше работать с ФП будет проблематично. параллельно набрал несколько статей по ADT, в частности :

"on the design of algebraic data structures with the approach of abstract data types"
"from abstract data types to algebraic development techniques: a shift of paradigms"

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

столкнувшись в своё время с оптимизационными трюками, связанными с применением шаблонного метапрограммирования в C++ (в частности с шаблонами выражений), задавался вопросом : почему ни один из существующих ЯП (корректней будет - известных мне на тот момент) не поддерживает более читаемого способа донесения до компилятора информации о потенциально возможных оптимизациях ? весь процесс использования TMP так или иначе сводился к жуткому раздуванию пары-тройки простых указаний - касательно тех участков кода, которые никак не могли бы быть соптимизированы автоматически; так почему бы просто не вынести некоторое множество этих указаний в специализированный язык общения с компилятором, который был бы хоть сколько-нибудь человекочитаемым ? главное здесь - чтобы этот язык изначально проектировался для выполнения данной задачи, содержал необходимую и достаточную именно для неё семантику, и выражался в простом для чтения (и понимания) синтаксисе
и вот сегодня, совершенно случайно (в процессе борьбы за оптимизацию своего кода на Haskell) столкнулся нос к носу с подобной технологией : GHC RULES Pragma. выглядят эти указания компилятору практически так же, как и остальной код :

{-# RULES
  "treeFold/treeMap"  forall f b g t.
  treeFold f b (treeMap g t) =
    treeFold (\l x r -> f l (g x) r) b t
 #-}

выдержки из дискуссии в комментариях к записи :

"...note that this is only valid in a pure functional language like Haskell! If we were working in ML or Lisp, then f and g might have side effects, and we couldn’t safely combine the two passes without doing a lot more work..."

"...I disagree with the premise that you need the compiler to validate the side-effect-freeness of your functions. I would rather have the programmer make explicit assertions that there are no side-effects that matter..."

"...it’s true, you could achieve quite a bit with manual annotations of purity. But to get any kind of consistent optimization, you’d need to use a lot of them, and do so correctly. You’d also need to write your code in a largely functional style, or have some scary loop-fusion support...an alternate approach would be to use a compiler with robust inter-procedural analysis. LLVM, for example, can do a lot of optimizations along these lines...once you start treating programs like an algebra, you can do all kinds of crazy things: automatically infer rewrite rules using Wadler’s free theorems, optimize tricky concurrent code, exploit rank-2 types—the list goes on and on. now, for many programmers, functional purity might seem a ridiculously high price to pay. But there’s a surprisingly large number of functional languages out there already: query languages like SQL, OQL and LINQ; vertex and fragment shaders on your GPU; and even some hardware modeling languages (if you squint at them right)..."

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

альтернативный подход к подобного рода оптимизациям (в целом аналогично основывающийся на свойствах ФП) - использование Template Haskell, как, например, здесь (Optimising Embedded DSLs using Template Haskell, статья в PDF) - но эта магия в чём-то уже сродни тому самому C++ TMP, о котором я говорил в начале. что ж, будем попробовать оба подхода

что касается моего болотца, тот тут пока что царствует Parsec 3.0, ByteString, Strict Fields - и попытки заставить всё это работать хоть немного быстрее. а в оставшееся время играюсь с Join, просто потому что красиво. возможно в ближайшем будущем будет повод опробовать его на прочность - там и поглядим, что к чему

"...о себе сказал я в дороге на небеса,
сам себя записал, сам себе проделал глаза,
сам себя засосал в бестелесные словеса

нет дороги назад, есть дорога - полный вперёд,
либо полный обсад, либо столь же полный пролёт,
либо хавай прасад, либо слизывай сладолёд

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

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

привет !

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

"...somewhere in the city somewhere in the room
a silent man a work undone a plan that went astray
somewhere in the limetime of a yearning reverie
words have lost their meaning on the frangle stage of fame

the sky is starless for the ones who have failed
going nowhere nowhere to go
life has no kindness for the ones who have failed
going somewhere anywhere but home..."

и вот вам ещё немного хорошей музыки, что ли

Sieges Even - прог-рок, с совершенно чудными текстами и бесподобной ритм-секцией; остальное - арт/прог/авангард, но потяжелее, местами с грим-вокалом и тяжёлыми гитарами - однако слушается легко и на одном дыхании. собственно хотел выложить именно Subterranean Masquerade, однако в процессе переслушивания понял, что же он мне до боли в печени напоминает - и добавил ещё и Estatic Fear

( Sieges Even - The Art Of Navigating By The Stars (2005) )

( Subterranean Masquerade - Suspended Animation Dreams (2005) )
( Estatic Fear - A Sombre Dance (1999) )

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

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

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

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

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

забыли коды комманд, и старых трюков запас
и только ненависть к Windows порою у нас
зажигает огонь в глазах как индикатор хард-диска..."

подумалось...

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

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

в результате та технология, на которой я остановился в данный момент - совмещение высокоуровневого программирования на Haskell с кодогенерацией в более низкоуровневые Тьюринг-языки. построение дополнительного барьера в разработке, использование Haskell в том качестве, в котором обычно программисты используют IDE. тем более что в качестве IDE мне всегда хватало пары-тройки Emacs'ов. генерируемый язык - C, уже хотя бы потому, что я до отвратительного плохо знаю ассемблеры. возможно в дальнейшем смогу перейти на что-то вроде BitC/nesC - там видно будет. во всяком случае хочется верить, что такой подход сработает

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

я продал душу за третью заповедь IBM

фраза одного PM'а о нашем отделе : сидит пятёрочка человек и чего-то там колопуцают...

P.S. за душою моей безденежье, да постылое багоборчество...

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

если когда-нибудь я напишу книгу, то называться она будет именно так : aut nihil
это самый сложный выбор - выбор из одного варианта
но как правило их всё же больше

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

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

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

P.S. и, между прочим, ко мне можно прийти в гости на партию в Го ;)

"...to write programs that are useful as well as beautiful, the programmer must, in the end, confront the Awkward Squad, a range of un-beautiful but crucial issues, generally concerning interaction with the external world..." ^(c)