Josh On Design

An open letter to language designers: please, for the good of humanity, kill your sacred cows. Yes, i know those calves look so cute with big brown eyes and soft leathery skin, but you know what? Veal is delicious!

Let me preface this by saying that I am not writing my own language. The world doesn't really want a new language, especially one from me. I made one a few years ago. While only a few dozen people were horribly maimed, I still consider it a failure and don't wish a repeat experience. The world does not want a new programming language, especially from me. But since you are hell bent on creating a new one, you might as well make it an improvement.

So open up your looking balls and point them right here. Our sacred cow wilderness safari begins now. Buckle up! It's going to be a long and awkward ride.

Lets start with the big cow, since it leads most of the ones that follow.

Cow #1: source code is ASCII text on disk.

You may think the storage of source code isn't really a language issue, but it is. A programming language isn't just the language anymore. It's the entire ecosystem around the language; including editors, libraries, source control systems, and app deployment. A language in isolation is so useless it might as well be LISP. I don't mean that to demean LISP, the badass godfather of languages. I mean it as: if you aren't thinking about a whole ecosystem then your language will mathematically reduce to LISP, so why are you bothering.

Back to the topic at hand. This is the 21st @#!% century!! Why, for the love of all things pure and functional, are we still storing our source code as ASCII text files on disk? One answer is "that's how we've always done it". Another is that our tools only work with text based code. So what?! I have a ten 1GHz devices sitting on my shelf unused and a 4 way multiprocessing laptop. Why are we being held back by the ideal of ASCII text? This cow must be shot now!

If we switch to using something other than text files, say XML or JSON or maybe a database, then many interesting things become possible. The IDE doesn't have to do a crappy job of divining the structure of your code. The structure is already saved. It's the only thing that's saved. The IDE can also store useful metadata along with the source and share it with other developers through the version control system, not through comments or emails. We could also store non-code resources, even non-text resources, right along with the code. Oh, and tabs vs spaces, style issues, etc. become moot. But more on that later.

Oh, and before you ask, putting your files in a directory structure and calling them 'packages' doesn't count. Think beyond the cow corral.

Cow #2: source code must be editable by plain text editors. IDEs should be optional and unnecessary.

Cowpatties! Unless you write your code exclusively with echo and cat, you are already using an IDE. A plain text editor is just an IDE with no useful features. We all use IDEs, the question is how much functionality does it provide you. When programmers say they shouldn't have to use an IDE, what they mean is they shouldn't be locked into using someone else's favorite IDE instead of the one they prefer. (I wouldn't mind being locked on a desert island with IntellJ, for example but I'd commit suicide if I was stranded with Eclipse).

Rejecting an required IDE is an issue of having specs and multiple implementations, not the concept of IDEs in general. I don't draw graphics in a text editor, I use Photoshop. The problem is that Photoshop has a closed file format that must be reverse engineered by Gimp. To go without an IDE is to go without 20 years worth of UI improvements. We are building a 21st century language here. Assume an IDE and plan for it. Cow dead. Yummers!

Cow #3. Less syntax is good.

No. While technically a language can express everything using just a nested tree structure (ala LISP) that doesn't mean it's a good idea. Syntax matters. Programming languages are user interfaces *for programmers*, not the computer. They let the programmers express what they want it the most convenient way possible and have the compiler talk to the computer. Certainly syntax can be too cumbersome or verbose, but that is about giving the programmer more to remember. Minimal syntax isn't the answer. The more specific the programmer can be the better. We want to give as much information as possible to the compiler so it can generate efficient binary code (where 'efficient' varies depending on the problem domain).

Minimal syntax is seductive because we like the idea of being concise and typing nothing extra. This is all very well and good. But the solution isn't to remove syntax, but rather make it optional. If the compiler can figure out what the programmer means without extra parenthesis and semicolons, then great, but let us add it back in if we want clarity. Make typing our variables optional for when we are hacking, but let us be more strict when we get to production. The syntax needs to scale with our needs, not yours. Oh, and what do you think of my nice leather wallet?

Cow #4. Holy wars: Whitespace. Indenting. Bracing. Tabs vs Spaces.

Irrelevant. Completely irrelevant. This is a style issue that can be enforced (or not) by the IDE. As long as it saves the source in a canonical format you can edit the code in any style you want. If you want to hide braces, do it. The IDE will handle the details for you. If you want to use square brackets instead of parenthesis, do it. The IDE will convert it. A funky syntax for escaping multiline text? Who cares. I can paste it into the IDE and it will deal with it. If you want to use dingbats symbols instead of keywords, do it. The IDE will handle it. (hmm. that's not a bad idea, actually. Have to think about it some more).

These are holy wars that matter unreasonably much to us but have not practical difference in the real world. Simply specify the semantic meaning and let the dev choose what they wish. Having good defaults matters, of course, but don't allow your cool new language to get trapped in the tar pit of programmer holy wars. Leave that for the cows.

Cow #5. What the world needs is a better type system.

No. The world doesn't care about yet another cool type system. You won't get programmer adoption by emphasizing how awesome your types are. No one will say: "Woah! Check out the type system on that one!". What the world needs is good modules. An escape from classpath hell. The ability to add a new module and know it will work without modification and without breaking something else. Let the compiler rewrite anything inside a module without affecting the outside. Fix versioning. These are those hard problems that need to be solved, not type systems. My code won't get magically faster and bug free through your awesome type system. Another cow bites the dust.

Cow #6. We must not let programmers extend the syntax because they might do bad things.

So?! We are adults. Let us shoot ourselves if we really want to. Let us override the syntax of the entire language if it would help us solve real world problems. Just make sure the changes are cleanly scoped, then let us have at it. The amazing success of JavaScript has been because it was so flexible that real world programmers could try different things and see what works, in the real world (seeing a common theme here?). Usage of JavaScript has evolved tremendously in the past decade, so much so that you could say the language itself has evolved (even if the syntax changes have actually been minimal).

So, no. Your language doesn't need to provide X. The language should programmers build it themselves. One more cow down the drain. Get your swim fins.

Cow #7. Compiled vs Interpreted. Static vs Dynamic.

Nobody cares. All languages are compiled at some point, the question is when. All languages live somewhere between the platonic ideals of static and dynamic. If we can get useful work done then we don't care where your language fits mathematically.

Cow #8. Garbage collection is bad.

No. Garbage collection is good. It has increased programmer productivity tremendously and eliminated an entire class of bugs (and security exploits). The problem is garbage collection isn't perfect. So grow your hair long enough to escape from your ivory tower and fix the GC, don't eliminate it.

GC systems often have bad nondeterministic performance, especially in interactive applications. They treat all objects the same. They provide the programmer with no-insight into what is actually going to happen. So improve the GC. Let us give it more hints about what we actually want. Why should the GC system treat my cached textures the same as a throwaway string. This is also a place where better IDE integration would help. If you make it easy for me to see where GC might be a problem then I, the programmer with the knowledge of what I'm actually trying to accomplish here, can provide the compiler with better information. Research modern infoviz. Get out of your pure text mindset.

We can rebuild this GC cow. We have the technology.

In memoriam

I hope I've provided a bit of guidance before you go off to your language shack in the woods and come back with type safe encapsulated 'genius'. Once again, you really shouldn't be building a new one language anyway, we have more than we need. Please, please. please, don't make a new language. Since you are determined to not heed my warnings, the least you can do is not injure the world further.

And please kill a few cows on your way out.