Read Only Languages

I recently read this article that discusses why languages like Lisp or Smalltalk don’t seem to scale to larger companies. The author posits that these languages encourage you to create a new domain specific language (DSL) to solve your problem, and while this is a great advantage for a small team it quickly becomes unwieldy as the company grows and the DSLs proliferate. This is a disappointing observation. I’d like to think that everyone could take advantage of metaprogramming, regardless of the scale of their company. But on reflection, I have seen a parallel for myself when working. I hate having to refactor a dynamically typed codebase - static types, while more verbose, are easier to understand and safer to change. I feel this also holds true for DSLs. If I need to learn a whole new language to solve a problem, I can’t be confident that my changes will have the desired effect, compared to languages that I know well.

An interesting endorsement of these complexity concerns can be seen in the design of Golang. Go’s designers created it to address different scalability concerns at Google, but the part that is most salient here is their approach to the complexity of the language itself. They intentionally excluded common language features such as generics and macros, and only included a small amount of keywords and language primitives. This makes the language surface area very small and makes it accessible for people to learn. With minimal training, anyone can read a Go codebase and easily understand what is going on, at least at a micro level.

This readability made me wonder - would it make sense to use Go as a transpilation target for more powerful languages, a “read only” language? I’m envisioning using a Lisp or some language with powerful macro functionality, and generating Go source that is readable by anyone who wants to understand what the program is doing. Many languages can compile to C, and you can always look at the assembly for hints, but Go strikes me as more understandable than either of these options. This generated Go that is packaged with the original generating source code would provide anyone who is familiar with Go the ability to read and understand what is going on in the codebase, regardless of how esoteric or unique the generating language is. This could allow teams to continue using their powerful DSLs while still making the internals readable to external teams.

Would this be useful? It is important to keep in mind that the point of doing this is not to get around any corporate policies about what languages are allowed. It is to facilitate understanding of a codebase by a wide audience, and improve engineering efficiency and maintainability. I strongly believe that it would be easier to read some verbose Go code rather than learn a complicated DSL when trying to understand a codebase. The main drawback would be that in order to make a change to the codebase, I would still need to learn the DSL instead of writing in Go. Adding in the additional steps required to transpile the code, it isn’t clear to me just how useful this would be - I would need to see some sort of empirical proof of the efficacy of this. I welcome any attempts to implement this somewhere, and am eager to hear what the results are.