I have been working on a LISP-like environment. At some point you have to wonder, what is the right level of abstraction and terminology to solve technical problems. The LISP REPL is a great example of meta programming that I admire.

Rich Hickey's presentation provides an interesting perspective on where we currently stand with regards overall approach and technique. It seems like he believes that current programming languages are not providing the right set of functionality to solve modern programming problems.

I personally believe that a programming language needs to be concise. This is not only with respect to the terminology (syntax), but also that the design and usage of data should match effectively to the most typical requirements. For example iterating over a set of items in C++ is generally very difficult.

std::vector<int> process(const std::vector<int> & numbers) {
  std::vector<int> results;

  for (std::vector<int>::iterator i = numbers.begin(); i != numbers.end(); i++) {
    results.push_back(doSomething(i + 5));
  }
}

In this example, there is much type annotation which can be inferred and complex syntax which doesn't actually add anything to the solution. Here is the "same idea" written in Ruby

def process (numbers)
  numbers.collect{|n| doSomething(n+5)}
end

This is much more concise, and represents functionality that is far more abstract and this behaviour can work on lists of anything that support the required functionality. While Ruby (i.e. MRI) runs this dynamically, there is no reason why it couldn't be compiled using type inference, optimization, and so on. And compilation is just an optimization step anyway.

N.B. Certainly compiled languages generally have the performance edge in the real world at this point in time. I've moved projects from Ruby to C after benchmarks have shown logarithmic performance problems.

Tim Sweeny is a game programmer and his presentation is a fascinating real world perspective on what kind of features could be useful in a programming language; many which are currently not generally available in typical environments. It is always important to be humble when dealing with both theoretical and practical concerns, since while often in alignment, there are typically many differences. I think some of his ideas are certainly worth investigating.

While working on my own programming languages, I've encountered many different possibilities and techniques. I really enjoyed Writing your own toy compiler. The cost of entry into building your own language and compiler is so low these days that anyone with a new idea can try it out and produce a useful environment for solving problems. I personally think this is fantastic.

Programming languages make me excited because of the possibilities and implications. We are so lucky to be in an age where all this is accessible and I look forward to future and all the different programming languages that people are creating.