SICP free content

I have to recommend the amazing MIT Structure and Interpretation of Computer Programs (SICP) lectures and book.
It gave me a whole new understanding of software and programming.
It continually inspires me.
The ideas have helped me to understand new technologies, languages and frameworks and put them into a larger context.

Just try not to be scared off by the lisp ;)

The book is available for free :
http://mitpress.mit.edu/sicp/full-text/book/book.html

You can even watch the video lectures:
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/

Other notes on the course are here:
http://mitpress.mit.edu/sicp/

code that will hack your mind

I've been reading an excellent book mind hacks on my kindle recently.

It describes the mind as a collection of parallel sub-processors which work together to form the conscious mind.
For instance there is a part of the brain which identifies shadows, and this processing is done very early in our visual processing. It is an over simplified process which helps to identify possible threats very quickly. A much more accurate process works on shape recognition, but this is also a slower process. This is a rational for people jumping at shadows, but quickly recovering.

The processing is done in parallel, but some results override others. A good experiment (illusion) to show this edge case is the colour and words recognition problem .
One sub-process of our mind is reading the words, (and normally brings the sound of each word into our mind as we read them).
Another part is recognising the actual colour of the text, and converting that colour sensation into a word.
In this case the illusion is caused by the sub-process that is reading the words overriding the colour recognition sub-process.
This collision shows the importance of these automatic processes in how we read and understand text.
There are other sub-processes which can collide with our word recognition, one of which is for recognising shapes. Our mind automatically looks for a meaningful shape in the image, which seems to have a white background and black foreground. It is only when our word recognition sub-process comes in that you can see the white word on black background. Once your mind has locked onto the word, it's difficult to see the amorphous black shape that you originally saw.

Now, we've all seen optical illusions before and it seems hard to believe that any of this affects you in your normal day to day life. These edge cases (illusions) are rarely seen in reality, mostly because when we're reading any substantial body of text (like this blog), it's pretty much always in black and white, and any images are nicely separated from the text. Even the structure of the text, the shape of each line and paragraph is pretty standardised. This ensures that our shape recognition sub-process doesn't interfere with reading, except when scanning through a body of text for a particular section. That's all true for almost all natural language that we encounter.

It is not the case for programming languages though.

This is the real reason that programmers get into so many arguments of tabs-vs-spaces and IDE wars over code auto-formatting, and syntax highlighting. It also explains why different languages are fought over so vehemently when it seems to outsiders like the similarities are greater than the differences between them. I want to show why all of this stuff really does matter.

It's all about hacking our minds.

The following points may seem stupidly obvious, or obviously wrong, but since there hasn't been any research into this that I know of, they're have to be assumptions.

1. When reading code, the mind uses same processes as when reading natural language.
2. Some part is trying to recognise whole words, and define the meaning of the word.
3. Some part of brain is trying to say each word (token) out load, with punctuation either ignored or used to structure the rhythm of the word sounds.
4. Some part is looking for meaningful shapes in the code, to determine relatedness and structure.

 This has some implications for source code.

2. implies that words (tokens) must have meaningful names, which sounds stupidly obvious; but it's something people still ignore. They must be obvious and simple names that we recognise instantly. Otherwise we work against the automatic word recognition our minds have.
3. implies that our source code should be pronounceable. Actually speak your code out loud. Does it make sense to someone else if you say it out loud? Does it flow properly, or does it have a stunted rhythm.
4. implies that blocks of code should have a meaningful shape. People are aware of this when it's done badly, but it's rarely seen as an image problem. Usually it's treated more like structuring paragraphs, when we should be using the source code and punctuation to show pictorially what the code means.

I would really like to have some code examples here, but that would actually require getting this stuff right. Which means lots of experimentation.

I will,

if I get time,

... later.

Religion Poisons Everything

I may have to get this book:

God is not Great

This excerpt is clearer than most things I've read from Dawkins or Harris.

One great quote : "Religion spoke its last intelligible or noble or inspiring words a long time ago"

the unreadable book?

According to steve yegge no one can finish Gödel, Escher, Bach: An Eternal Golden Braid

I have.


It's pretty heavy going, and I'm not really a fan of the Achilles and the Tortoise dialogues.
But I did finish reading it.

I particularly enjoyed the section which described the function of DNA as a self replicating program.

code complete 2 sucks

I've been on a bit of a non-fiction book bender recently.

After reading a number of the books on Coding Horror's Recommended Reading for Developers including:
The Mythical Man Month
Peopleware
The Pragmatic Programmer
as well as:
Facts and Fallacies of Software Engineering
As well is the often referenced Godel Escher Bach,
All of which I've enjoyed, and found relevant to my work and software interests.

I thought, Code Complete 2 would be worth a look.

I can't believe how wrong I was.

After reading something as deep an complex as GEB on the train to and from work everyday, I figured I could read anything.

Again, I can't believe how wrong I was.

I've found it dull, obvious, pointless and most of all overly specific.
Maybe the book just isn't aimed at me. I've had a few years of full on develpopment in a number of OO languages, with pretty comprehensive testing layers.
I haven't been able to get passed the third chapter due to extreme bordem.

I would not recommend this book to experienced developers.

Being a fanboy really does work

I've recently realised that I am a scala fanboy.

When people complain about some problem in their chosen language/framework, my first thought is, "in scala they've solved that problem with _ .".
When I was writing the above sentence, my first instinct is to use the underscore character _ to match whatever scala feature it was I was thinking of. ( _ is a scala idiom which matches anything)
During a "Design patterns" study group, my reaction when I start to understand a pattern is, "oh, that's how people get around not have scala_feature_x".

But it was when I started vocalising these thoughts, that I realised that I was a fanboy.

The suprising thing is:

it actually works.

People are actually listening to my constant "scala, scala scala".

There's at least 4 solid Java developers I know who are now interested enough to start playing around with the language.

I always thought that fanboys were people who just didn't understand that noone else cared about what they cared about, but it turns out that there are people out there listening to fanboy rants.

The other alternative is that I'm actually a scala 'evangelist', but I think you have to get paid for it to be called an evangelist.

anyway, read this:
http://www.codecommit.com/blog/scala/roundup-scala-for-java-refugees

and this excelent book:
http://www.artima.com/shop/programming_in_scala

I'll probably have to buy the t-shirt, AND the mug; but I'm not quite ready for the hat though:
http://www.scala-lang.org/shop

oh yeah, scala rocks!

Update:
While I was writing this, yet another of my Java Developer colleges showed interest in scala, and mentioned having to look at it further :)