The Go language at Soundcloud:
Go has been described by several engineers here as a WYSIWYG language. That is, the code does exactly what it says on the page. It’s difficult to overemphasize how helpful this property is toward the unambiguous understanding and maintenance of software. Go explicitly rejects “helper” idioms and features like the Uniform Access Principle, operator overloading, default parameters, and even exceptions, on the basis that they create more problems through ambiguity than they solve in expressivity. There’s no question that these decisions carry a cost of keystrokes—especially, as most new engineers on Go projects lament, during error handling—but the payoff is that those same new engineers can easily and immediately build a complete mental model of the application. I feel confident in saying that time from zero to productive commits is faster in Go than any other language we use; sometimes, dramatically so.
7 thoughts on “transparency in programming language design”
Looks very interesting. Maybe this is very much the kind of language I’m looking for so have started learning it now. Thanks for sharing.
Totally relevant to our conversation. I’m going to try to get to know it too.
For any language, you need a good compiler, but you also need a good linter which conforms to best practices. Different people may use different linters – just as different people may use different compilers – based on the best practices to which they wish to conform. This is an paradigmatic/organizational thing, not a syntagmatic/syntactic thing
I started with BASIC because it was there, and then was educated using Pascal, which didn’t make sense to me specifically because it *was* very explicit… as soon as I started working with C, things clicked, and I feel the same way about JS.
Scheme or Lisp are also very explicit, transparent and literal, and completely obscure to most people.
Did you do a Khan Academy course on JS even though you already know it, Piers?
That makes me realize how much about JS I don’t really own. Which makes it relatively opaque.
Prototype hammering is a form of monkey patching and is IMO highly opaque.
I have written a lot of plain old C. I found the language very clear, such that I very rarely didn’t understand the code. But the programs it creates are another story.
With very high level languages like BASIC, the DWIM philosophy leads to baffling debugging because the compiler is deliberately inconsistent.
I’ve been following along with the happenings with Khan Academy because of John Resig’s involvement – but previously I had been looking for something I could use to demonstrate how stuff on the web works to my kids, and fell on the idea of simplified JS because it’s clear and easily available. I tend to leave out the semicolons now.
I honestly think prototypal inheritance is easier to grok than classical, but that’s probably just me.
Coffescript is intriguing.
About Coffeescript, my bet is that the good parts will be absorbed into JS proper and CS itself will only be remembered as a precursor, along the same lines as the B language.
I agree with you on both points.
Flexibility is a common problem too though; whenever you have two ways to accomplish the same task within a language, you really need a best practice supported by somebody to tell people how, when and why to code it. There are two ways to reduce scope – by limiting the commands which are provided by a language, or by formalizing design patterns.