software engineering;  was: Is this official blog article intended as a joke?

> but IMO it's silly to leave training wheels on a bicycle forever.

It all depends on what the cost is.  If protecting yourself from

machine faults is nearly free, for example because your higher

level language enforces its abstraction model, then why not.

Parameter passing and array indexing are inherently high-level

abstractions that although they will be implemented with machine-level

code, they need not use machine-level pointer syntax.

The equivalence of code and data was a factor early in the history

of computer science, when it was believed that self-modifying code

was important, especially in AI where machine learning was thought

to require "rewiring" the brain. And LISP was ideal for self-modifying code. 

Since then, self-modifying code has fallen into disfavor, especially

with viruses taking advantage of executable stack pages in certain OS's. 

So I think the trend in CS is to as much as possible keep code and data

separate.  They can each have their own memory pages, with code pages

being read only, and data pages being non-executable. They can even have

their own separate caches in a harvard architecure.

John,

Nothing wrong with C's abstraction model.  IMO you just need to regard C as a portable assembly language that uses high-level notations.  When people think of it as a high-level language, that's when trouble begins.

You are entirely correct that if C is regarded as a portable assembly language, then it's abstraction model isn't broken.

But it's tempting for people to assume that C's variables and other abstractions are just like any other language's,

and as you say, that's what causes trouble.  I'm sure none of the following is news to you, but others may find it interesting.

I remember my first visit to a pediatrician where he did a reflex test by tapping a rubber hammer

on my knee.  I thought something's not right here.   My model of how the knee was supposed to work

was that the brain should control the knee.  I tried real hard when he tapped the other knee to kick

him with the wrong leg.

Then I was over at a friend's house and his dad was working on their car, with the engine idling

and the hood up.  My dad wasn't a mechanic and so I had very little understanding of how things

worked under the hood.  My friend's dad grabbed the throttle linkage attached to the carburetor

and revved the engine, much to my surprise.   I thought something's not right here.  There's nobody

sitting in the driver's seat, but the engine is only supposed to rev up if the driver presses the gas pedal.

Then I learned an early version of Fortran, and needed to convert a character from upper to lower case.

I found out that you could do it by declaring an integer array after the character variable, and index the array

with a negative index to obtain the integer representation of the character, and add 32 to convert to

lower case.  Something didn't seem quite right about that either.

Then I learned Pascal, where this trick was neither possible nor necessary, because array indexing

was checked, and there were intrinsic functions for converting characters to integers and vice versa.

This seemed like an improvement, although there was still a trick available of using a variant record to

subvert the type system.

In most high-level programming languages that have variables, a variable has associated with it a

value, and the fundamental rule of the abstraction model is that the value doesn't change except by

assignment to that variable, or by assignment to a parameter that is an alias of the variable.  In C,

on the other hand, a variable has associated with it an address, and the value stored at that address

can be changed by just about any code in the program, because it's trivially easy and common to

get hold of addresses and do arithmetic on them.   This makes it difficult to reason about

the behavior of a C program, whether the reasoning is done by a human or by an optimizer trying

to improve the code, or by some sort of static analysis tool trying to prove properties of the code.

coder27 wrote:

 

Then I learned an early version of Fortran, and needed to convert a character from upper to lower case.

I found out that you could do it by declaring an integer array after the character variable, and index the array

with a negative index to obtain the integer representation of the character, and add 32 to convert to

lower case.  Something didn't seem quite right about that either.

Very dangerous, since a different compiler or version might allocate the variables differently.  Much better to use EQUIVALENCE to ensure that arrays and variables are allocated on top of each other the correct way   Back in the 1970s I used EQUIVALENCE to create an arrays that were numbered from 0 instead of from 1.  I was writing an FFT and the algorithms were much simpler with arrays numbered from 0.  Fortran was actually a pretty good language for FFT at the time -- it was the only available language that had COMPLEX as a built-in type with built-in operators.

Then I learned Pascal, where this trick was neither possible nor necessary, because array indexing

was checked, and there were intrinsic functions for converting characters to integers and vice versa.

This seemed like an improvement, although there was still a trick available of using a variant record to

subvert the type system.

Variant records are a fine example of why a practical language should not be too restrictive.  You sometimes do need to bend the rules, and it's better to provide a well-defined way to do it that makes clear to someone reading the code that's you're bending the rules.

At one time I used to do a lot of programming in Pascal/VS, which was an excellent IBM mainframe extension of Pascal that allowed separate compilation of source files.  Unfortunately, it did not have a mechanism for function pointers, so when I needed to write a logic simulator I had to use C... K&R, before the ANSI improvements like function prototypes.  Awful C implementation, with 100 messages per syntax error

In most high-level programming languages that have variables, a variable has associated with it a

value, and the fundamental rule of the abstraction model is that the value doesn't change except by

assignment to that variable, or by assignment to a parameter that is an alias of the variable.  In C,

on the other hand, a variable has associated with it an address, and the value stored at that address

can be changed by just about any code in the program, because it's trivially easy and common to

get hold of addresses and do arithmetic on them.   This makes it difficult to reason about

the behavior of a C program, whether the reasoning is done by a human or by an optimizer trying

to improve the code, or by some sort of static analysis tool trying to prove properties of the code.

Modern C compilers do an excellent job of optimization.  As I understand it, if you use the address of a variable then the compiler can no longer assign that variable to a register (since registers don't have addresses in the most common computer architectures) and your performance will suffer.  If you willy-nilly increment and decrement pointers to access nearby variables, that's not defined by the semantics of the language so it's not necessary for the compiler to figure out what's the right thing to do.  Static analysis tools will give warnings about things like that, as well as warnings about many other things -- I've heard they produce lots of false warnings, and each static analysis tool generates different warnings for the same source code.

My general PG-13 rated comment about C and Asm versus "safe" programming languages like Basic is that it's a question of how many layers of condoms you want when programming.  If you don't use "safe" languages, the language won't protect you from unexpected negative consequences, and you'll need to be careful in other ways.  But it can be a lot more fun to program in "unsafe" languages, and a lot more satisfying

Very dangerous, since a different compiler or version might allocate the variables differently.  Much better to use EQUIVALENCE

Yes, that was my point, that languages that allow you to violate their abstraction models

are dangerous.

Awful C implementation, with 100 messages per syntax error

I've been noticing a lot of such cascading error messages in the Arduino forums when

for example there is a spurious semicolon before the opening '{' of a function.

http://www.element14.com/community/thread/10083?start=1138&tstart=0

Modern C compilers do an excellent job of optimization.

But the optimization suffers due to the availability of untyped memory operations

such as memcpy and memmove:

http://gcc.gnu.org/onlinedocs/gccint/Memory-model.html#Memory-model

and the difficulties of type-based alias analysis in such cases:

http://gcc.gnu.org/onlinedocs/gccint/Alias-analysis.html#Alias-analysis

But it can be a lot more fun to program in "unsafe" languages, and a lot more satisfying

you can also waste a lot of time debugging that way, because errors that would

otherwise be caught at compile time or in a run-time array bounds check, 

can turn into mysterious run-time behavior where evidence of the error may

not show up until long after the program has gotten off track.

coder27 wrote:

 

But it can be a lot more fun to program in "unsafe" languages, and a lot more satisfying

 

you can also waste a lot of time debugging that way, because errors that would

otherwise be caught at compile time or in a run-time array bounds check, 

can turn into mysterious run-time behavior where evidence of the error may

not show up until long after the program has gotten off track.

In my own programming, I rarely have bugs that could have been caught by run-time array bounds checking.  It's usually logic errors such as forgetting to handle an unusual case and the occasional dangling pointer, which is part of the price of writing code that uses (and reuses) linked data structures.  My solution is to try to keep things as simple as possible, and it works for me.  One way to keep things simple is to use a language that's well-adapted to the problem, so you don't have to encrypt the problem to fit the programming language.

My general opinion is that if you have sharp programmers, you can give them sharp tools.  If you don't, then you either need to give them "safe" tools or replace them with sharper programmers.

John Beetem wrote:

 

My general opinion is that if you have sharp programmers, you can give them sharp tools.  If you don't, then you either need to give them "safe" tools or replace them with sharper programmers.

Some programmers are sharper than others, but there are no human programmers sharp enough to fully comprehend algorithmic and state complexity in any non-trivial software system.  The disparity between programs and human capability to understand complexity and track dynamic state is vast, many orders of magnitide.  We would need IQs in the thousands (maybe millions) to program without introducing errors, no matter how many decades we've spent mastering a language.

This is why the bridges of software engineering collapse around the world millions of times each day.  It's not that the vast majority of programmers are amateurs or that the education system has failed us or that programming is a cool craft instead of an engineering discipline.  Those things could be fixed.  The underlying problem of human capability mismatch cannot be fixed, as long as we continue along the present track.

And there is little sign of anyone looking for alternative tracks, at least in practical computing.

Morgaine Dinova wrote:

 

Some programmers are sharper than others, but there are no human programmers sharp enough to fully comprehend algorithmic and state complexity in any non-trivial software system.  The disparity between programs and human capability to understand complexity and track dynamic state is vast, many orders of magnitide.  We would need IQs in the thousands (maybe millions) to program without introducing errors, no matter how many decades we've spent mastering a language...

Excellent comments, Morgaine.

You've heard me talk about this before, so the following is for others following this thread.  I believe we have complex systems because it's easier to slap together a complex system out of parts that "ought to work together" than to  think carefully through a system -- and document it -- before getting so far into the implementation that it's impossible to make fundamental changes.  I have met way too many soi-disant software engineers who hate writing software (not to mention documentation), so they mash together inappropriate modules from Edsger Dijkstra knows where.  I have also met way too many engineering managers who want something quick-and-dirty now instead of doing it right -- and then re-doing it righter after learning from the first go-around.

C.A.R. Hoare says it best, IMO:

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Actually, IMO humans are quite good at working with complex things once they have come up with good notations -- textual and graphical -- to describe them.  However, the development of those notations usually takes decades or centuries.

The solution to complexity is abstraction.  A single person can run a large company

or run a large nation, but not by doing all the jobs that a sole proprietor does.  Instead,

they operate at much higher levels of abstraction.

I don't think the analogy of "sharp tools" to "low level programming languages" works too well.

Certainly low-level features get removed from higher level languages, for example, gotos have

been removed from recent languages.  And if you focus on the loss, it may seem like your language

has gotten duller.  But that's usually not true, because new higher-level abstractions are added

as lower-level ones are removed.

In some cases, the benefits are not obvious to the programmer, but they are to the compiler

writer, because keeping lower-level abstractions around allows them to be used to subvert

the higher-level abstractions.

For example, the typical compiler intermediate language these days is based on SSA,

and that requires a control-flow graph in the form of a DAG (no cycles), which in turn requires

that you don't have arbitrary gotos, such as between branches of an if/then/else construct.

So by taking away the low-level goto, and replacing it with higher-level if/then/else and looping

constructs, you end up with a language that is no less capable, but much more suitable for

SSA-based optimization, code generation, and other analysis.

coder27 wrote:

 

The solution to complexity is abstraction.  A single person can run a large company

or run a large nation, but not by doing all the jobs that a sole proprietor does.  Instead,

they operate at much higher levels of abstraction.

Abstraction is part of the solution, but it's not sufficient by itself.  With abstraction alone, computers will continue to do exactly what we tell them to do, and will inevitably end up doing the wrong thing because it is entirely beyond our mental ability to fully understand (let alone specify) the behavior of a non-trivial system.  Removing unnecessary detail and bringing the language of specification closer to the natural language of the application domain through DSL abstraction clearly helps, but it is not enough.  The desired complex behavior still has to be defined, somewhere, and that's the problem.

Your example of the large company or nation is a very good one, but not as an illustration of the power of abstraction.  What it illustrates instead is that complex systems can work well when there is semantic commonsense built into the components of the system, so that daft commands from above don't cause an immediate collapse.  And that's what is lacking almost completely in software today.

Remember Bertrand Meyer's very insightful work on Eiffel, in which preconditions, postconditions, and invariants played such an important part?   He embedded semantic constraints into software components, although his focus was on simple design contracts at a level far below anything related to what people might call "commonsense".  Unfortunately, static constraints are fundamentally at odds with flexibility and reuse, so we see them only very rarely in practical software beyond basic assertions for defensive programming.  We are as far away as ever from the model of companies or nations working in software.

John Beetem wrote:

 

Actually, IMO humans are quite good at working with complex things once they have come up with good notations -- textual and graphical -- to describe them.  However, the development of those notations usually takes decades or centuries.

It's interesting (or perhaps sad) to contrast that with the typically short  timescales of product and company planning in the commercial software world.  One might be tempted to suggest that open source could be the answer, since it doesn't end-of-life code with quite the same degree of profit-oriented ruthlessness, but alas even open source programs bit rot and stop working owing to dependencies and changing architectures.

The long-term view just isn't there, and may not even be possible.  Things change, it's part of progress.  Whatever solutions we come up with for the software crisis, they'll need to be able to cope with the current state of technology.  I very much doubt that refinement of languages or written code over ages will help much.