Note: This was published on April 1st.

For many years I’ve been advocating strong type systems. Their advantages seemed so obvious to me that I didn’t even bother doing much research in that area. But since I was being pestered by the advocates of untyped languages I finally decided to prove once and for all that strong typing is superior. Surprisingly, the task wasn’t as easy as I anticipated. More and more self-doubt started clouding my mind.

Take for instance the argument that it’s better to detect programmer’s errors at compile time than at runtime. Well, is it? We are making a huge assumption here that a correct program is better than a running program. In practice, a running program beats a correct program 99% of the time. What really matters is time-to-market (TTM), and trying to bypass a type system takes a lot of work and skill.

There is no guarantee that an incorrect program will actually fail, and even if it fails, it might fail only on a small percentage of tasks. If the bug is really annoying, it may be fixed in the next release of the product. Notice the trend in the industry to regularly push updates and bug fixes to users, who are now almost always connected to the Internet (see Windows Update, JVM, Adobe Flash, etc.). Ever since Borland’s Turbo C++ compiler, it became obvious to software manufacturers that convenience, TTM, and cute user interfaces beat reliability hands down. Putting a smiley face on an error message sells more programs than fixing the bug.


Another problem with strong typing — something that the industry has been long aware of — is that it often takes programmers with an MSc (or sometimes even a PhD, in the case of generic C++) to understand and fix type errors that are detected by the compiler. These guys are expensive to hire and they tend to be snooty and turn up their noses on less interesting jobs.

Having realized that, I started looking at weakly typed or typeless languages. They are much easier to program in. The compiler doesn’t impose its totalitarian regime on the programmer. Not having to follow strict typing rules frees the programmer to concentrate on more important creative tasks — something we humans excel at. I was almost ready to switch to JavaScript when I discovered runtime errors. Runtime errors happen when the program takes a path that was not anticipated by the programmer (after all, the programmer always tests the most common path). That makes runtime errors relatively rare, but still, they could be a nuisance for the end user.

I realized that we needed a new programming language, a typeless and extremely expressive language. I called this language JDI! (it stands for Just Do It! and is pronounced Jedi). It’s essentially untyped lambda calculus mixed with some assembly. But the real clincher is the runtime that I called SBR (Seldom-Blow Runtime, pronounced saber). I have already implemented the proof of concept version of SBR called Light SBR. I will release it to GitHub tomorrow.

The key insight behind SBR is that, when a runtime error happens, the runtime already knows why the problem occurred (null pointer, missing functionality, index out of bounds, etc.). In most cases the runtime, instead of throwing an exception, can just do something else than what the program seemed to demand.

I’m not claiming that this is an original discovery — this type of programming has been successfully applied to web applications across the board. All I’m trying to do is to extend it to the mainstream. I’m happy to announce that some industries have already expressed interest in my project. We are going to try it first on self-driving cars, autopilots, and ultimately on the new generation of nuclear power plants.