Raised in a Cellar

From a comment by Kamyar Navidan on a post at Damien Katz's blog:

I think the problem with Erlang is that it's more than 20 years old and for most of this time haven't been exposed enough to developer community at large. It's like raising a child in a cellar for all its childhood and don't let it interact and learn from his/her peers. Erlang definitely needs something like Python's PEPs.

Stairway to Heaven?

The fire escape on the Blade Building, Abbey Square, Reading, UK.  Photo taken on 2008-09-13.

Unintended Consequences

I just came across this post by Janet Stemwedel (alias Dr Free-Ride) in which she and her family attempt to teach their younger child how to 'work' a classroom behaviour reward scheme.  It is a wonderful lesson in economics and what Bruce Schneier calls the security mindset. 

That something apparently so simple can contain such complexity should be a lesson to politicians who want to introduce schemes such as charging for emptying bins.

Raw and Escaped String Literals

Start up the Glasgow Haskell Interpreter and try to display a typical Windows file path:

Prelude> putStrLn "C:\test\x41.txt"
C:      estA.txt

The result has been mangled.  The problem is that, by default, Haskell interprets escape codes in string literals.  The '\t' has been interpreted as a TAB character and the '\x41' has been interpreted as the ASCII code for 'A'.  This interpretation process can even give compile time errors:

Prelude> putStrLn "C:\work\x41.txt"
<interactive>:1:14: lexical error in string/character literal at character 'o'

In Haskell there is only one way to stop your strings from being mangled, and that is to mangle them yourself by inserting extra escape characters to prevent the backslash characters from being interpreted:

Prelude> putStrLn "C:\\test\\x41.txt"
C:\test\x41.txt
Prelude> putStrLn "C:\\work\\x41.txt"
C:\work\x41.txt

This is all rather messy and unsatisfactory.  There must be a better way.


In Python strings suffer from similar problems:

>>> print "C:\test\x41.txt"
C:      estA.txt

Python is not as strict as Haskell about unrecognized escape codes:

>>> print "C:\work\x41.txt"
C:\workA.txt

But in Python you can prevent the interpretation of escape characters by putting an 'r', for 'raw string', immediately in front of the string:

>>> print r"C:\test\x41.txt"
C:\test\x41.txt

Unfortunately, the fact that the underlying implementation is escaped strings still leaks out in that you can't have a backslash as the last character in a raw string:

>>> print r"C:\test\"
 Line 1
   print r"C:\test\"
                   ^
SyntaxError: EOL while scanning single-quoted string

Python guru Fredrik Lundh gives more explanation of this problem and how to work round it here.

However, there would be no need for all these explanations and work-arounds if raw, uninterpreted strings were the default and you had to indicate explicitly when a string was to have its escape characters interpreted.  In Haskell the latter could be implemented as a function esc :: String -> String.  Then the simple unadorned string would do what was expected:

Prelude> putStrLn "C:\test\x41.txt"
C:\test\x41.txt

And to deal with those special cases where you really need escape characters you would explicitly call the function to do it:

Prelude> putStrLn (esc "She said \"Hi!\"")
She said "Hi!"

Explicit is better than implicit, especially when it leads to less confusion.

Singularity Skeptic

A couple of quotes from a review by Scott Aaronson of Ray Kurzweil's 'The Singularity is Near':

... he knows that every exponential is just a sigmoid (or some other curve) in disguise.

... if the Singularity ever does arrive, I expect it to be plagued by frequent outages and terrible customer service.>

Read the whole thing here.