Leng design guidelines

1. make the common case the default.
2. make the less error-prone the default.
3. add special syntax for the uncommon.

Interactive Exploration

Some earlier work from Bret Victor, this is one of those ideas I came across a while back but I regularly think about.


Interactive Exploration of a Dynamical System from Bret Victor.

Leng is still in my mind

Even though the last post on Leng was last year, it doesn't mean I've given up on the idea at all. Quite the contrary, I even started implementing a parser using ANTLR3 and some mockup source files. The plan is to get to a stable syntax for a basic language as first iteration, implementing the front end of the compiler on ANTLR3* and the back end using LLVM. Anyway, I was incredibly busy at work, finishing a project last summer and jumping through another couple since then, so I've had very little chance and energy to make some actual work on this beyond thinking and reading about other programming languages. And with the advent of big life changes including a new job, it looks like that'll continue to be the trend in the near future.

*I don't think I'll move to ANTLR4 until they release a C++ runtime.

What's the output?

I've been recently doing C++ tests on the internet. I'm usually quite good at these but with something as complicated as C++, you'll always come across a new detail of the language that surprises you. In my case it was the following code:

#include <iostream>

struct B
{
  virtual int shift(int n = 2) const { return n << 2; }
};

struct D : public B
{
  int shift(int n = 3) const { return n << 3; }
};

int main()
{
  const D d;
  const B *b = &d;
  std::cout << b->shift() << std::endl;
  return 0;
}

What's the output?
Solution:
Well, it turns out that while virtual invocations are evaluated at runtime, default arguments are assigned at compile time. If you think of it from a compiler programmer point of view it makes sense but for the user it's, in my opinion, completely counter-intuitive.

CUDA

So after the great experience with the Scala course on coursera, I've decided to give a go to other courses. I've recently come across udacity, which has quite a few less courses but most of them are focused on computer science and seem to be of quite high quality.

I've signed up for Introduction to Artificial Intelligence, taught by  Peter Norvig himself, author of Artificial intelligence: a modern approach, a real classic on AI, which I hope will help as an easy refresher on the theory of AI. I'm also enrolled on the future Interactive 3D Graphics, which will be taught by Eric Haines, one of the authors of Real-Time Rendering, which is a real gem on computer graphics.

But boy, what I'm really enjoying right now is this one: Introduction to Parallel Programming. It's a collaboration with some guys from Nvidia and they are teaching parallel programming on the GPU using CUDA. Now, I did some basic MPI programming for clusters in C at university and have some professional experience writing multi-threaded code but this is an entirely different world. It's giving me the chance to learn some new concepts and get hands my dirty with a new technology, which is really fun. I was also hyper excited when they started talking about Map and Reduce operations, which I got to deal with during the Scala course.

Concurrency in C++11

Today, I've watch two talks on concurrency. I wasn't specifically look for that topic, they just happened to pop up in my google reader list. One of them was from the Go programming language blog, the other from Herb Sutter's blog on C++11. Herb is an amazing lecturer but unfortunately for him, I watch his second.

I don't know Go (and don't particularly like its syntax) and I do know some C++ (and I've watched a few videos and read a few articles on C++11 already), but even I can see a qualitative jump when understanding a simple concurrent algorightm in a language that was thought from the ground-up with those concepts in mind. Think of the classic discussion where a C programmer argues how you can do anything that C++ does in C, and the C++ programmer replies that you can do anything that C does in assembly, but that's not the point, the point is simplicity. Richness of expression in simple terms means less code. Less code to write, less code to read, less code to maintain. Less code is good. Sure, I still see the point on being able to tune every tiny detail to squeeze the last bit of performance, but could it have been done in a more clear syntax? Stroustrup said that C++11 feels like a new language and language advocates quote him with proud. But to me it sounds backwards.  If you are writing a new language, write a new language. The new syntax is compatible with older C++ in order to keep millions of existing C++ programmers in the boat. But these programmers will not use C++11 in a new way because it feels like a new language, and if all those features (like lambdas) are really the way to go and they want to try a new language that offers them, they would just learn one that doesn't require training your brain not to melt when looking at all those [[=&]].

Anyway, these are just a few thoughts. I'm actually quite curious about C++11 and I'm looking forward to experiment a bit with it.

I need to think a bit more about this, and should consider if leng should have concurrency built-in..

Scala

I'm really enjoying this free online course on Scala:
https://www.coursera.org/course/progfun

It's taught by Martin Odersky himself (inventor of the language) and it's really making me understand the beauty behind functional programming (lots of ideas for Leng coming up of course)

Unlike most of other Coursera courses, you do get a certificate signed by the instructor at the end. The course is on it's sixth week so if you hadn't heard of it until now it's probably too late to get the certificate, but you can still sign up and look at the lectures and work through the assignments.