Saturday, November 20, 2010

System programming languages are creeping

C++ compilation speed up.
One of the problem surrounding C++ is a lack of refactoring tools. The reason for this is a sophistication of the language. To tackle this Apple started CLANG project - which is a C++ compiler front end. Up to 60% of compilation time goes into preprocessing stage; remaining time is consumed by parser and semantic analysis. The prominent idea is that if compiler is used as part of IDE in compile-fix-compile mode (contrast it with usual batch compilation mode), a preprocessor's ouput can be cached thus providing 60% compilation time speed up[1].

Abstract syntax tree (AST) of C++.
The library structure of CLANG makes it easier to create code transformation tools... in theory. In practice, the dependency between components and unobvious initialization requirements make it nontrivial.

BitC programming language.
BitC has lisp-like syntax and provides low level access to system resources.  The goal is to push to the limits compile-time program verification. The author of a language, Jonathan S. Shapiro, was hired by Microsoft and then fired after not so long time. Odd stuff was going on.

D programming language.
D has pretty syntax, garbage collection, simplifies templates meta-programming. Walter Bright, the author of D language, says that game programmers love this language. Nice.

Heron programming language.
Heron is in a prototype mode and was introduced by Christopher Diggins here.

Rust programming language.
Rust is under development... by Mozilla.

Requirements to any system programming language.
Here are free-style requirements. The idea is "do not sacrifice performance".

Joe Duffy's thoughts about C# and performance:
If I could do it all over again, I would make some changes to C#. I would try to keep pointers, and merely not allow you to free them. Indirections would be explicit. The reference type versus value type distinction would not exist; whether something was a reference would work like C++, i.e. you get to decide. Things get tricky when you start allocating things on the stack, because of the lifetime issues, so we’d probably only support stack allocation for a subset of primitive types.

There is a design trend of implicit composition of components. In C++ we have templates, in Go there is an implicit interface implementation; duck typing in dynamic languages is everywhere. I am curious if C++ concepts will allow implicit realization.

[1] Presentation of LLVM 2.0 (particularly 40 min).