Thursday, November 10, 2011

The Ideal Programming Language


My requirements for the ideal programming language, roughly sorted by order of importance:

  1. Can be used equally well for code that will run on the server-side (most likely targeting the JVM) and on the client-side (for now, this means compiling to JavaScript). This is key for people to be able to use the language. Nowadays, a language that also comes with its own environment is unlikely to be adopted. [Unlike Haskell; like Dart]
  2. Strongly typed, with type inference across compilation units, i.e. not to force type declarations on "public APIs" (even if having them, most of the time, might be a good idea). [Unlike Scala; like Haskell]
  3. Provide rich constructs, like case classes, traits, partial functions, continuations… The world is complex, and our programs try to model it, and the right constructs make the programmer's job easier, and the code simpler. (See the simple vs. easy distinction made by Rich Hickey.) [Like Scala]
  4. Adhere to the off-side rule. Because syntax matters. [Like Python, Haskell, CoffeeScript, F#; unlike Scala, Dart…]
  5. Provide a rich data type library. [Like Scala; unlike JavaScript]
  6. Compilation should be fast enough that developers don't feel compiling/building as an additional, lengthy step that needs to happen before they can run code. I.e. when writing code running in the browser, programmers should be able to make a change in their editor, cmd-tab to the browser, reload the page, and see the change. [Unlike Scala]
  7. Don't force "object oriented" paradigms on programmers. E.g. the standard way to write a program shouldn't necessarily be to start defining a class. [Unlike Java, Scala]

2 comments:

Erik Bruchez said...

I'm a bit confused about this: "not to force type declarations on "public APIs"", because that's exactly where you would be the most likely to put type declarations. In fact, Gilad Bracha says as much in this video you tweeted about not long ago: http://goo.gl/Vtwnj

Alessandro Vernet said...

I agree with you and Gilad: in general, it is a good idea specify types on public APIs. But what is a public API?

Java got us (or at least me) used to think in a binary way: it's either public or it is not. And as is often case, binary thinking isn't accurate: in real programs, the level to which an API is public is more often a shade of grey. Some methods are really designed to be called by 3rd parties: you think a bit more about them, document them more thoroughly, and think twice before changing them. Some methods/functions are designed to be called only within a given module. Others are maybe more low level and you want to discourage their use, even within a given module, but there might still be cases where calling them makes sense. And the list goes on.

I prefer a language that lets you choose what APIs are truly public and lets you put type declarations on those, rather than force you to have type declarations on everything that is not strictly private.