On the other hand, a note on drugs that make you smarter…

Monday, March 10th, 2008

A snippet of the book-in-progress:

 Triangular wheels have always been much more entertaining, and when some of their scent managed to find its way down to the lowly lands of earthlings, they have even been some of a chick magnet. I’ve always been desperately interested in things that are way too complex for me to handle superficially. I basically lost the only real intimate relationship I had with a woman to functional programming, and I shall not bore you today with the fascinating intrincacies of Bird-Merteens calculus, Martin-Löf types and Girard logics because I wish to drone on to an anecdote that’s much more relevant to the case at hand because it involves directly atypical bipolar mania in all of its atypical manifestations, with atypical grandeur, atypical delirium and borderline atypical psychosis. [...]

Guido is wrong! for loops, declarativeness and Charlie Mingus

Saturday, February 10th, 2007

<

ol>

  • Guido is wrong:

    brain-computer.jpg

  • <li>"<em>Each jazz musician when he </em> <a href="http://dayvancowboy.org/2007/02/guido-is-wrong-for-loops-declarativeness-and-charlie-mingus/#more-202" class="more-link">(more...)</a>
    

    Some probabilistic text generation

    Friday, February 9th, 2007

    In the spirit of keeping a hacking blog journal — and toning the “functional john dvorak” tone — we exhibit a silly probabilistic text generator I worked on this morning.

    module Main where import Probability import Data.Char import Control.Monad

    Probabilityis Martin Erwig’s Probabilistic Functional Programming. I’m cleaning it up, haddockizing it and might cabalize it sometime soon. The stock copy will work for now, as I haven’t made any API changes yet.

    This function takes some text and returns a list of pairs of consecutive chars. For example, pari "some text" == [('s','o'),('o','m'),('m','e'),('e',' '),(' ','t'),('t','e'),('e','x'),('x','t')]

    pari xs = zip (firsts xs') (thens xs') where xs' = (map toLower . filter (\x->isAlpha x|| isSpace x)) xs firsts = take ((length xs) - 1) xs' thens = tail xs'

    Finally, we produce a probability distribution over the letter frequencies in a given string:

    distro xs = uniform $ pari xs

    We omit here the large goal string we used. It’s an arbitrary assemblage of text pasted from blog blog journal s linked at reddit. This function picks a pseudo-syllable: a pair of letters used in that order in the original text

    one =do { (a,b) <-pick goal; return [a,b];}

    Finally, we iterate (tee hee) over that:

    many n = fmap concat $ sequence $ take n $ repeat one

    Here is some of the deep abstract poetry produced by our program:

    for Whom The Bell Tolls

    Friday, February 9th, 2007

    The debate about adding closures to Java has spawned a curious debate about the role of explicit loops, recursion and higher-order list combinators. I wonder why no one has stepped up in defense of GOTO yet.

    Misguided Java snob Elliot Harold harangues fist and teeth against progress in computer languages:

    I don’t know what it is some people have against for loops that they’re so eager to get rid of them. This isn’t the first or even the second time CS theorists have revolted against for loops (or equivalent).

    This isn’t even the most proeminent below-the-belt jab at new expressive techniques. Take blog blog journal spot.com/2007/02/whats-wrong-with-for-loop.html”>oh, but wait, the traditional Bird-Merteens/Standard Prelude functions are kinda expressive too, you know. Which is fine and quite useful for bystanders trying to evaluate this debate on merit alone. I myself should repackage the section in this blog blog journal spot.com/2007/02/whats-wrong-with-for-loop.html”>oh, but wait, the traditional Bird-Merteens/Standard Prelude functions are kinda expressive too, you know. Which is fine and quite useful for bystanders trying to evaluate this debate on merit alone. I myself should repackage the section in this Reddit, which is where I get my daily dose of blog journal — functional programming is frankly on the rise. Part of it probably is due to OOP’s failure to materalize its promise of easy-to-maintain, flexible, reusable code. Part of it is also the rise of FP-centered languages around relatively recent developments in theoretical computer science — like the MLs and Haskell, a little further away from academia, Erlang. There’s finally the visible hand of Moore’s Law making high-level languages ever more practical.

    Also judging from the blog blog journal s there’s a distinct zeitgeist of rejecting “static” languages in favor of “dynamic” ones. This is partly an artifact of fast computers finally making serious work in dynamic languages feasible, but also a rejection of the Big Architecture discipline of the C ++/Java weltanschauung.

    Being as easy as it is to make noise with a blog blog journal , this has led to a lot of uninformed ranting. Even Steve Yegge, who’s supposed to be a smart programmer with a track record that shames mine, has done his share of pointless rambling on how “static” languages compile to ‘hardware’, to ‘Pinocchio’-like wooden boys that aren’t “real”, while dynamic languages yield “living” software somehow.

    This, of course, makes absolutely no sense.

    The Either/Or approach to classifying computer languages

    First of all, this dichotomy mixes up type-checking strategies with evaluation models. Dynamically-typed languages check types at runtime, while statically-typed languages do some form of type-checking that ensures no type error will arise once a program manages to compile. On the other hand, statically-compiled languages yield an executable that does what it needs to do, while dynamic languages are either interpreted — that is, require a separate runtime environment that parses source in text form — or allow some form of pseudocompiling that mangles source into some form of object code and bundle a runtime environment.