about

Rationale

Programming skills are more and more important. However, despite stackoverflow, Wikipedia, Joel on Software, c2.com and many other online resources, it is still very difficult to learn. There is too much information, too many different frameworks, programming languages, tools, etc...

If you want to get good at programming, if you are willing to unlearn what you know and go back to the fundamentals, you will discover that everything is in fact extremely simple, and has been invented half a century ago (garbage collection, virtualization, jit compilation, etc.).

You will learn to factor code properly, avoid over-engineering and scale down software. Remember:

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." — Antoine de Saint-Exupery

You will have fun coding again because your tools won't get in your way.

Background

I started this project almost by accident. I was searching for a suitable development tool that allows me to iterate game design ideas extremely fast. I have tried almost everything: XNA (MicroSoft), Pygame (Python), Kivy framework (Python), Love2D (Lua), etc. Every single time I ended up fighting the language and framework instead of expressing my ideas.

When I could express my ideas the performance was hundreds of times below what a C compiler would produce. So I began searching for fast interpreters. That's when I began using LuaJIT, great stuff! Unfortunately if Mike Pall decides to do something else, it's pretty much game over. That and standard Lua is a pain to interface, while not having as many libraries as Python.

The revelation came when I found Forth, upon reading about the implementation of fast interpreters (Anton Ertl). I will be honest, I was a grunt producing Delphi and C# .NET code. I was not familiar with assembly code. I couldn't even understand JonesForth. But Jeff Fox arguments about increased productivity using Forth systems were too compeling.

I stuck with it for a year, reading everything about programming language design. Smalltalk, Lisp, Nim, Rust, Julia, Go, etc. I studied all of them. But the truth is all programming languages suck. And it finally clicked. I built and rebuilt the same virtual machine more than 20 times, and now I can produce a cross-platform Forth implementation, and teach people how to do it.

If you don't believe me, you can try implementing your own programming language, using recommended tools like Yacc, Flex, Bison. You can read the Dragon book, do your FFI with GLEW, and by the time you understand the whole thing, more than 2 years will have passed.

Using Forth, I get similar results in terms of performance and flexiblity after 2 months on the first try. A Forth expert would do the same in 2 weeks. It happened to me, and will happen to you to. Well, if you genuinely love programming as an art.

About real world programming

You could say this platform is meant for hobbyists / teachers, rather than professionals, that our methods aren't suitable for real work. Admittedly, there is little benefit if your only goal in life is to make money. But do not forget, the people who master their craft, are the one who love what they do, and practice day-in day-out for fun (Larry Bird is a famous example, Linus Torvalds another).

And yet, the benefits of our teachings are tangible. Understanding the fundamentals of your domain, gives you much more freedom to make better decisions, do the hard work when needed, and reuse those concepts in your daily job. By becoming a master, you are a stronger programmer for the rest of your life.

By analogy, you don't learn chess by memorizing openings. The right method is to master basic endgames, mating patterns and tactics. Simply being able to never drop material can get you close to master level. Also consider the current world champion's style. Magnus Carlsen can outplay other fellow grandmasters because he understands all positions that much better.

And that's the real drama. Modern popular programming languages suck at teaching the fundamentals of programming. They get in the way all the time with confusing syntax (Lisp parentheses, C declaration vs usage). They have many data types (even for strings), and libraries with tons of unreadable macros. I propose to show how it is done very simply one step at a time.

The profusion of programming languages and tools that get reinvented all the time is the proof that those problems aren't real. They can't be solved because the saner approach is to design the language as part of the solution. Yet almost every programming language designer seems to forget it. Well, it can be argued it's on purpose. If you teach people how to solve their own problems, you can't milk them as easily.