The Idea Behind Basus

To understand the idea behind Basus, you have to know a bit about me, Sverre, the Basus author. I was born in 1968, in Norway. As a son of a ham radio operator (LA3YU), I was raised with the smell of soldering irons in my nostrils. During the very early 1980's, my god-like (to me) techno-dad bought a ZX-81 (look it up on the web) assembly kit, and put it together. The very first affordable household computer. Pure magic. Despite his god-like understanding of technology, my dad wasn't able to make it load a program from the tape drive. But I was, by finely tuning the volume control, and that was my first experience of mastering technology beyond what would be expected by the gods. I must have been about 12 years old, and the happening made me set out on a quest to master the computer domain.

Problem was, I was completely on my own. Since no other kid had a geeky dad like mine, none of them had a computer. And just forget about school teachers back then; computers were totally Science Fiction (if they were at all familiar with that term). I was nevertheless able to teach myself programming in the Basic programming language just by reading a couple of books and studying programs made by others. And I even learned a second language along the way; most books were written in English. As the years went by, I was able to tech myself both assembly, Pascal, C, Perl, and more programming languages just by reading books. But it wouldn't have been that easy if it wasn't for Basic, the language that started it all for me.

Fast forward to the present. A master degree in Computer Science and several programming languages have passed. During my years as a professional computer programmer, I've met many people with similar childhoods. They grew up in the early 1980's home computer boom with ZX-81, VIC-20, Commodore 64, Oric-1, Dragon 32 and whatnot. And all these now grown-ups, once kids, were able to teach themselves programming without any supervision. We're a generation of geeks, and it appears we're the first and only such generation. You don't see this kind of kids anymore, at least not in the great numbers from the early 80's.

I have a couple of kids, both of whom I've shown today's high level programming languages without luck. They don't get it. I have a couple of theories that would explain why the programmer explosion died out, one of which we can't do anything about, the other we hopefully can.

We Can't do Anything About This

Kids use computers for playing games. Period. Oh, add chatting nowadays, maybe. Today's games are not anything like in the early days. Today's games contain 3D graphics not unlike special effects in movies. Motion capture and all, requiring millions worth of equipment. And game music is recorded in studio with world class orchestra. You have directors, cut scene editors and, well, most of the stuff you find in the movie world. There's no way a lone, geeky teenager can compete with today's off-the-shelf games.

Not so in the golden days. After teaching themselves programming for a few months, most geeks were quite capable of programming games that could almost compete with the stuff people bought on cassette tapes in the stores.

We cannot do much about this. It's evolution, and it is exciting for those of us who enjoy the modern games.

What we Can Do Something About

As the need to create more advanced programs has evolved, programming languages have evolved in accordance. The traditional "Hello, World" program, a program that just displays a greeting, can no longer be written in just a line of code in most modern programming languages. You need to add syntactic sugar that is not easily understood by beginners.

If we want to raise a new generation of computer geeks, I think we need to go back to the days when creating simple programs was easy. We should not have to write ten or twenty lines of code to have "Hello, World" displayed. We should not have to know the difference between integers, real numbers, strings and booleans until we have to. We should not have to type a cryptic compiler command to have the program translated, and then another command to have it run. We should do as we did in the 1980's: Tell the computer what to do, and make it do it.

That's the idea behind Basus: Make it simple again.

And with the idea implemented comes the disclaimer: Basus is not a programming language to stick to. It's much too simple. Basus should be used until there's an understanding of variables, control statements, sequential execution and such. Once this threshold is overcome, the modern geek should move on to a modern programming language.

In other words: Basus is a tool for introduction to programming, and that's it.