If you don't see sharp you'll be flat

Visual C# is a strongly typed, object orientated and managed programming language. As opposed to the computer's native computer assembler which is not typed, orientated or managed at all.

If I've lost you already, it's likely to only get worse so, if I were you, I'd go find something else to do.

The point I am making is that IMHO the education of all serious programmers ought to start with assembler before moving on to a high level languages like C#. Because otherwise they will inevitably fall into the traps of unnecessary obfuscation, abstraction, bloating, redundancy, and other such anti-Occam's Razor-isms that force the rest of us to buy ever increasingly complex computers.  The young people of today won't believe you when you recall surprisingly complex software that used to run within the MSDOS memory limit of 640Kbyte. Not that complexity is bad per se - nature is full of it!

"Managed" means the language depends on, in this case, the gargantuan Microsoft .NET framework and cannot run without it. Which means the programmer does not have full control of the machine and the very simplest program still needs all that framework code.

The objects in "Object orientated" are packages of code that are called by the main program rather like subroutines of assembler-speak but with many more bells and whistles which are nice but only when needed. C# forces the programmer to use objects even when something less heavy would be more efficient all in the interests of readability and self documentation.

"Strongly typed" means that every quantity is forced to be of a specified type. Like when Mickey Mouse is doing his homework and asks "what is 3 + 4?" and Pluto replies "Is it apples or bananas?"

The computer itself only knows about "bits" aka binary digits that are either "on" or "off".  Groups of these can represent either instructions or data according to context. The computer doesn't care if the data describes apples or bananas. That's the programmer's job. Just as it is the mathematicians job to decide how to use an algebraic symbol or the what to use the digits 0 to 9 for. So when C# insists that a symbol must describe e.g. apples, that distinction is purely in the mind of the compiler (the software that converts a high level language like C# into assembler).

Which is all fine and dandy until it gets out of hand.  Like when the QuickBooks SDK interface which I have been working with requires me to use their programmer's name for a value that, to the computer, is just an integer and woe betide if I spell or capitalise it wrongly.

This morning I read a news article reporting how, when a certain Jennifer Null tries to buy a plane ticket, she gets an error message on most websites. This is a prize example of the point I am making. There is no reason why a programming language should not define a special value to mean that a variable or database field has not yet been assigned, but to confuse a string of characters "Null" with that value is unforgivable.

I came across a new word recently that describes this nonsense nicely: cruft = badly designed, unnecessarily complicated, or unwanted code or software.

Occam's razor

Eric Isaacson programmer par excellence

Occam's razor in the vernacular might be "Keep It Simple Stupid!".  William of Ockham was a 14th century logician and Franciscan friar. He wrote in latin but, roughly translated, Wikipedia has it as a principle of parsimony, economy, or succinctness used in logic and problem-solving.

I try to apply the principle in my work as an electronics design engineer. I often use Microchip PIC processors in my designs, mostly 8-bitters, and typically code in assembler. Recently I have tried my hand at 'C' (just the ANSI flavour) - apparently it is the "way to go" and, anyway, one's hand is forced by the need to use C-friendly libraries.  But I hate the verbosity and obfuscation of 'C'. What requires little thought and a few simple statements in assembler can consume hours of research and require far more typing in 'C'. In short it contravenes Occam's razor.

OK - I like the way 'C' encourages good structure and offers ready made functions to save one having to re-invent the wheel. But couldn't these good things have been provided in a simpler, more intuitive way? So I figured I would create a new language and call it 'Occam' - but I am too late - Occam already exists but is not at all the 8-bit job I was looking for.

'C' poses itself between low level (i.e. assembler) and high level languages. It's not that I have anything against high level languages - they have their place - just that I hate unnecessary verbosity, and not only in the field of programming.

Long ago in the heyday of MSDOS I purchased and used A86, an assembler for the PC. The author Eric rightly claims that A86 "is the finest assembler available, at any cost under any terms, for the Intel 86-family of microprocessors". No painful setup red-tape is required - you write your assembly statements, assemble and, hey presto you have an executable.  That's as good an example of Occam's razor as you'll get.


Shalom is often translated as 'peace' but means much more - well-being, completeness, wholeness, health, soundness, tranquility, prosperity, fullness, rest, harmony, the absence of agitation or discord. How is 'shalom' encoded in brain neuron-patterns?  Similarly, a high level programming language command like "draw a 3D cube with rendering" – who cares how it is encoded? Except that you do care at the hardware level I work at. I care about every bit and every micro-second and, for some applications, only assembler will fit the bill.