Toy languages aren’t all bad
Proponents of software craftsmanship often rave about dynamic languages. Ironically the reason they do this is not because dynamic languages are inherently better than static languages, but for the exact opposite reason. Because dynamic languages cannot detect so many errors at compile-time as their statically-typed cousins, one needs to be more disciplined over testing. Good dynamic-language-based applications and libraries are therefore tested with extensive unit, integration etc tests. The lack of compile-time checks positively encourages this must-write-tests attitude. It’s a line of argument that I find odd and it has taken me a long time to come to accept it. Spending time with ruby developers though has changed my mind recently.
Lego is a toy too
I used the term toy two years ago quite deliberately as I was seeking to be deliberately disparaging toward what I saw as a rubbish language. In recent months though, I have started to wonder whether it being a toy is a problem. Lego is a toy. Kids play with their lego bricks, creating great works of fantasy. Lego has a serious side too though. Technics and Mindstorms lego can be used to teach engineering and robotics ideas and to help people learn to program. This toy can be used to build a “3D printer” that can build more lego creations from CAD drawings. People have even built working “Babbage difference engines” from lego pieces.
Toys are fun
to a .html file and open it in a browser. Job done.
Such simplicity encourages people to play with the language, to explore it’s abilities and laugh at it’s stupidities. In the process, that person starts to become a developer. There is plenty of time later in their career for them to be taught SOLID, testing strategies, static typing and many other tools of the software professional. We shouldn’t forget that playing is the best way to start learning.