This past week has been a good one from a work point of view. Lots of actual hands-on coding, which I enjoy more than the more mundane aspects of development works (tweaks to config files, and tedious manual testing of dodgy third-party applications). I am exploring, building, playing, and solving puzzles. What more can one ask for?

I’ve been learning a whole new language – a specialised one that was developed internally at our company. It was created for a specific audience and a specific domain, and has never been distributed outside the firm. This has led to great freedom and thus some quirky developments. I can’t really say much about the interesting technical features of the language, mostly because I know too little about it, and because it would just be too complicated to explain… But the technical side is just a small part of it. The culture and management of the language are at least as interesting.

On the plus side, the language is flexible, open to change, and evolves all the time. Anything that needs to be changed, can be changed, since we own and control it. And it can be changed quickly, because the language and the management processes around it were developed by a firm who needs to be nimble to stay in business.

The flip side of this malleability is that people only change that which they want/need to change. If there are a dozen cases to consider, but you only need one to work, you implement the one, and ignore all the others. If you’re feeling generous, you leave a comment in the code about this. This is exactly what I encountered in my project this week. And of course I will only implement the one addition I need, and leave the remaining ten for someone else!

Another, related weakness is the documentation (lack of). It is an easy step to skip when working towards a tight deadline. So documentation is scarce, brief and mostly auto-generated. Some basic things appear to be completely undocumented; you just need to figure it out on your own. I still haven’t found a categorised list of built-in functions, for example. On the other hand, because the language was developed internally and is used very actively, there is a large pool of knowledge about it, and it is easily accessible. It is much easier for me to get hold of a senior developer responsible for the core features of this language than, say, Java, for example!

The lack of documentation is also offset by transparency. All source code is stored centrally, so anyone can access all of it – and it’s all searchable, of course. This makes it a lot easier to learn the language. It also contributes to the flexibility and changeability of the language: if I find 15 date-handling functions but not one that does just what I need, I can easily add it using the 15 as examples. And if the code doesn’t behave as expected, I can debug (and possibly fix) each and every part of it. It is quite exciting to get to dive so deeply into the core parts of a large code library.