File this under that "meta-tao of hacking" or WARNING: thar be rosy language and fluff hereabouts. Walking my dog down the street at dusk today the air had a nice warmth to it and I enjoyed the pink and gold hues of the sunset (please stick with this post it does go somewhere). It's warming up here, and instead of racing home with my head down I was free to enjoy the smell of the air and the sites around me. So, I was letting this scene (dusk, pink, leaves, trees) roll around in my head trying to think how I would describe it accurately to my wife so she could somehow feel and see the light as it passed through the new leaves and buds of flowers, the warmth hitting my face, etc, etc.


Its very hard, if not impossible to achieve that type of expressiveness. Thats what makes great writers. Transferring the totally ephemeral/sensory/emotional/mooshy stuff to these semi-deterministic buckets of words and phrases that comprise our language is a real and difficult challenge that people seek to tackle every day. Even as I'm writing this I'm struggling to lay my ideas out in a way that can be understood by someone else reading them. Without even considering the gulf of perception and personal experience that separates any two people this task is almost insurmountable. In a lot of ways language designers are trying to do the same thing in reverse. They're trying to give us the tools to describe a very deterministic world using words and phrases with more meaning than their underlying implementation. We've continually abstracted farther and farther away from the on die voltage so that a more detailed and expressive version of computational reality can be recorded. As a result we get a meeting somewhere in the middle:
God/Universe => Words/Phrases => ---?--- < = Haskell <= Assembly <= 0011101001000100
As a programmer your brain bridges the gap there, further distilling your understanding of language and how to represent the world in written form into code so we can turn that last bit around.
God/Universe => Words/Phrases => :D => Haskell => Assembly => 0011101001000100

Sweet diagram bro

That gap from Words/Phrases to your language of choice is 6 dashes and a question mark wide. Plenty wide enough for anyone who hacks, or takes an interest therein, to feel proud. Thats the world we live in, striving to make our lives easier and our code more expressive. As time marches on it seems like we've worked our way towards that reality of using languages to tell the computer exactly what to do. Slowly but surely working up from hardware, to assembler, to cobol, C, Java, Ruby/Haskell/Scala/. It's gotten to the point now where its even efficient when it gets boiled all the way down! So what are some of the spoken language "idioms" we use every day when programming, and what are some other things that have yet to make their way into our programming?

merge! valid? Damn you GHCI compile my code!

I personally really like the Ruby way of using the language equivalent of tone to convey meaning in code. When you ask a question of an object and expect a boolean you can use a question mark (how novel!) and when I use the bang operator it reminds me of getting frustrated with clamshell packaging and just smashing my way into it with a screwdriver which is most definitely a destructive update. Even better is Haskell's type inference. Admittedly my knowledge of Haskell is limited to a small set of hacks that I've been toying with, and in almost every case I define a type signature for my functions, but inference is something we do every time we speak or write. My use of "their" or "there" in spoken form is immediately apparent because of the context its been wrapped in. Haskell's compiler(s) is(are) smart enough to force a type based a what can be gathered about the operations over that type within a function. Thats pretty awesome.

Stuff you should ignore

There are other places that inference could be used. Namespaces/modules for instance. For better or worse, allowing the compiler/vm to handle namespace collisions could be achieved my the inferred functionality and object contained within. This of course gives people the free reign to name their modules whatever they like, thereby confusing the poor end user who needs to use two modules with completely different functionality and the same name (I think there's already another project named RQuery).


17 Apr 2009