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.

Leng: Type inference

I'll be using type inference similar to Scala or the new auto word in C++11. I still need to investigate the details but syntactically, I plan to be using # to replace a type that needs to be inferred.

Leng: Syntax (1)

I've got to be convinced that one of the reasons that there's so many refactoring tools out there for Java and so few for C++ is the extremely difficult that it's to write a parser for the second.

The language is charged with old compiler tagging and at the same time some features that make it really hard to parse.

Semicolon

I've been writing quite a bit of Lua lately and I keep getting surprised when I go back to C++ and the compiler starts complaining about missing semicolons. I don't want them in Leng.
Instead, the delimiting character will be the new line, with two exceptions:
- Expressions in brackets (of any type) require the closing one before finishing.
- Assignment requires at least one value before finishing
Unfortunately, that doesn't allow us to do funky stuff like:

 a = b
  + c

instead, you'd be doing:

 a = b + c
 // or
 a =
  b + c
 // or
 a = (b
  + c)

Like Lua, I plan to accept semicolons if you ever want to use them, but believe me, 99% of the time, they are just clutter that just removes clarity from the code. After two days you won't miss them at all.

Now, I don't want to follow the Lua path completely here as I feel its a bit undefined. Lua tries to look ahead the next statement to see if it could be part of the current one and kind of appends it. That can lead to unexpected results like:

function f()
 return
 assert(true, "never called")
end

What would you expect to get here? Well, tabbing is deceptive in this example. The assert does fire and the function returns true (the value that assert returns). Even though Lua makes it a syntactic error to have any statement after a return except for the end of a block, look-ahead parsing bends the rule in a rather obscure way.

Preprocessor and Templates

As you could expect, the preprocessor won't be a part of Leng. Instead, I plan to expand generic programming beyond templates. I hope this will add a new level of versatility to the language while making it safer and easier to digest (for both, tools and humans).

For templates, as much as I love the look of angle brackets <>, I'm considering replacing them with square brackets []. Replacing classic C array syntax, there would be a special templated class Array[C, N]with an overloaded operator() to access the values.

Leng: boolean expresions on conditionals

Only expressions of pure bool type (no implicit conversions) are allowed on conditions for conditional and loop structures. Pretty much like Java. Oh, and the assignment operator does not return a reference to the lvalue. Which means you cannot do:
int a, b, c, d;
a = b = c = d = 0;
Tell me the truth how many times have you really needed (or even wanted) to do that anyway?
The bool conditions are maybe a bigger loss because I'm really used to do
if(myPtr)
and now I will have to do
if(myPtr != Null)
But I think having a simpler and cleaner rule is worth the extra code.