Scali’s guide to joyful programming

Another fun piece that I wrote quite a while ago. I think most of it still applies today, although Java has long been replaced by C#. Then again, as the languages are so similar, you can just replace ‘Java’ with ‘C#’ in the article below, and everything still holds. And the point of C also remains: Although I do use C++ a lot (I rarely use pure C anymore, except when developing on really old/limited platforms), from a purist point-of-view I don’t think it’s as good as C# in terms of being object-oriented. But I love C++ for the performance it can give me, where C# is not adequate.

Scali’s guide to joyful programming.

I’d like to take the liberty of sharing some of my knowledge and experience in
the field of programming with you. What brings me joy, might bring you joy
as well.
So what brings me joy? I suppose the bottom line is getting programs done, and
getting them done well.
Those are 2 completely different things… The first one is related to
quantity, the second one is related to quality. You may have discovered
already, that these things seem to be inversely proportional to eachother.
The trick is to find a good compromise, a sweet spot.

What language?

This seems to be a straightforward question… However, there doesn’t seem to
be a straightforward answer. If there was, why would there be more than 1
programming language in use in the world today?
It’s important to realise that there is no ‘best’ language. Each language has
its own advantages and its own disadvantages.
So, it’s the old story of ‘the right tool for the right job’.
This means that you should not limit yourself to 1 language. That may sound
like a lot of work, learning all these languages… However, it’s not that
bad, there’s only a few types of programming languages. Only a few programming
models, called paradigms.
All the languages based on the same paradigm, are quite similar. The concepts
are the same. So if you know one, you can pick up another in a few weeks.
It’s not necessary to know all languages, but it can be enriching to look
around a bit, and try out a few languages.
I believe that the goal here is to be ‘above the language’. That you’ll not
be limited to thinking in the language you know, but in concepts instead, in
the bigger picture. The ‘what’, rather than the ‘how’.
So ultimately, you’ll think of what you want to program first, then choose
the language, rather than choosing the language first, then figuring out how
to program it.
With the right choice of language, the ‘how’ question has a simple answer.

Luckily, the designers of most programming tools/environments have realised
all this as well… What do I mean with that? Well, most languages can interact
with modules written in other languages.
This is a very useful feature. Namely, it allows you to write different parts
of the same program in different languages.

How do you do it?

Here’s where I will lay down my personal preferences and experiences.
My favourite languages are (in no particular order) Java, C and ASM.

Let me list what I think are some of the advantages and disadvantages of these


– Very clean language, purely object-oriented, which allows you to translate
object-oriented designs to an implementation quickly.
– Nice RAD (Rapid Application Development) environments available, which allow
you to create a GUI (Graphical User Interface) in a nice and easy way.
– Vast array of libraries included in the runtime environment.

– The language is rather limited in some areas, since it is designed to be
completely platform-independent.


– Simple and powerful language, you work close to the machine, and have good
control over performance.
– C is very widespread, and you can write C in such a way that it will work
on virtually any system.
– There are very good C compilers around, which can generate very fast and/or
small code.

– It’s easy to design and program in a sloppy way, because of the freedom that
the simple language allows.
– It generally takes a lot of work to do things that should have been done
with OOP (object-oriented programming), like for example code reuse or GUI


– The most powerful language of them all. You are talking directly to the
machine. You have total control over the speed and size of your code.

– Writing ASM takes quite some time. Routines generally take a lot more lines
than they would in C.
– The total control also comes with a big responsibility… Writing ASM
generally goes with creating lots of bugs.
It takes time to find and fix these bugs, since at such a low level, you get
little help from your tools. You’re pretty much on your own.
– The code you write, is aimed at one CPU only. Unlike compiler languages,
where you can just recompile for different CPUs, or different optimization
options, with ASM, the only way is to rewrite the code.

It’s a good thing that you can use these languages together, because as you see,
they are quite different. With Java I can implement designs quickly, and with
little lines, which is fast to write, and easy to maintain and reuse. This is
mostly due to the object-oriented paradigm.
With ASM you can create the fastest and/or smallest code, but it will take the
most time.
With C you have a good compromise, doesn’t take too long, and quality is not
too bad.

I would advise you to learn these three languages, as they each teach you
different things. With Java you can concentrate on the design of a program.
This is very important for the quality of the program. The better the design,
the smaller and more efficient the program will be.

With C, you can optimize things at a lower level. Concentrate on reducing
logic, memory access, calling overhead and things like that.

With ASM, you can optimize things at the lowest level, Instruction for
instruction. Squeeze out those last few clockcycles or bytes.

Which path to take

There’s quite a few steps that you should take, when creating a program.

1) Define what you want to write.
You may think it’s obvious, but especially when working on a program with more
than 1 person, you should define things clearly, because different people have
different ideas on the same subject. You could end up with something other
than you wanted, if you didn’t specify what you wanted at an early stage.

2) Divide the program up into smaller modules.
“You can’t eat an elephant whole” as they say. Divide it up into the separate
independent components.

3) For each module, define the objects that it will work with, and for each
object, define the functions that process on it.

4) Now that you have a clear design, you can make a prototype implementation,
to verify that the entire program will work. This is optional, only required
for parts of the program that are difficult.

5) You might want to start with optimizing at the highest level.
Optimizing at this level would entail finding the fastest algorithms,
minimizing I/O and memory usage, and the like.

6) Now implement your final design in actual code.

7) You should now have a working implementation, which is sound at the higher
level, so if you want to optimize it further, it’s time to go lower level.
Time to get more creative with pointers, bitwise trickery, and eventually
assembly. And be sure to not make the mistake of optimizing the wrong parts.
Optimize the parts that form the bottleneck.

Okay, this seems very strict… You don’t have to follow this process by the
letter. Depending on the size of the program, and the number of people, you can
do some steps in your head.

Another thing… I chose Java here, for a reason. Java is a pure OOP language.
I wanted to stress that, the OOP of it all. In practice, C++ might be a more
interesting choice, because it also allows you to code C and inline ASM.
But at first, the focus should be on getting a clean, object-oriented design.
That’s why I chose Java as an example. With C++ you might be tempted to code
lower level right away. Java will simply not allow this.

As for using ASM… Well, the sad part is, compilers are very good these days.
It’s hard to beat them by hand. The only way is to train yourself well in ASM.
Try writing small programs completely in ASM. Read optimization manuals. And
code. Benchmark your code. Look at code that compilers generate. Check with
others. And try to be creative.
I think this is the only way to really get good at ASM, with lots of practice.
It may sound like a lot of trouble, but trust me, it’s fun. Fun to beat the
compiler. Fun to use the latest instructionsets. Fun to tweak your code until
it’s perfect.

Speaking of perfect code… One of the rules that I have for myself is this:
The code is never perfect.
That may sound silly at first, but think about what it says… If you assume
that your code is perfect, you will stop trying to improve it. Even when it may
not be perfect yet.
So this rule is a safeguard, you’ll never give up trying to improve your code.

Something to consider

I started to see a pattern with evolving programmers (including myself).
They’ll start out with a reasonably highlevel language. Then as they get more
confident, they will go more lowlevel… Then they generally get too confident,
and they’ll push feature-less assemblers, and programming everything in 100%
assembly. Then after a while, they will want to implement larger and more
complex stuff, and come to grips with the advantages of highlevel languages.
Then design comes into play, and eventually, well… I think they’ll agree with
most of what I’ve written here.
So if you’re sceptic about what I wrote, perhaps you have not reached the end
of your evolution yet. You don’t have to follow my advice, but give it some
thought at least. I advise only to try and make you a better programmer, and
have joy in what you do.
I hope I have succeeded in doing this.


This entry was posted in Software development and tagged , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s