Warning: I disappear for weeks, and when I come back it’s a geek post. Sorry.
There’s an old saying: “Real programmers use C”. If you mention this in the wrong circles, it will degenerate into a pointless “four Yorkshiremen” contest, in which someone eventually awards themselves the crown of being the most “real” programmer because they used to write programs by hand-blowing vacuum tube valves.
Still, nowadays C is about as close as most programmers get to ‘bare metal’ programming. Some get closer to the metal by coding in CPU-specific assembly language, but increasingly that’s specialist work. Most graduate computer scientists write a few dozen lines of assembly as one minor module of their degree, and never touch it again.
Meanwhile, I have recently found myself using something that may appear to be the polar opposite of C. Software AG’s WebMethods product has its own language, named ‘Flow’, in which a program (a ’service’) is created by dragging steps into a window from a pallette. A flow step has inputs and outputs, and you can drag a line to join an output to an input.
So, for example, if you wanted to write (a + b) * c in Flow, you’d create a service, and define inputs a, b, c, along with an output ‘result’. Then you’d browse through the available built in services, find the ‘add’ service, drag that in. You’d join ‘a’ and ‘b’ to the inputs of ‘add’. You’d find the ‘multiply’ service. You’d drag ‘c’ to one of ‘multiply’s inputs, and the output of ‘add’ to the other. Why, it’s all so easy, even a business analyst could do it!
Flow makes programming easy by doing away with all that tricky typing, and all those difficult concepts ‘real programmers’ waste their time with. Concepts such as datatypes, scoping, exception handling, function signatures, information hiding, and so on.
But here’s the problem: that’s good stuff that Flow has thrown out. If you pass that (a+b)*c service a=1,b=2,c=3, it’ll behave nicely and give you 9. But if you pass it a=1,b=2,c=”banana”? What if you leave out b altogether? Nasty things happen *at run time*: things that even a C compiler would have forced the programmer to deal with. Scale that up to serious applications, and you have a recipe for absolute disaster.
Yet, criticise Flow, and people come out of the woodwork with that ‘it’s easy enough for business analysts’ argument.
Let’s dedicate a paragraph to being polite to business analysts. Anyone clever enough to be a worthwhile business analyst is definitely clever enough to use a conventional programming language. Indeed, the analytical mind you need to do the job probably means they’d be among the first to appreciate the value of conventional language features. So let’s reword the claim. Flow, it is claimed, gets away with being how it is, because ‘it’s easy enough for people who aren’t clever enough for conventional languages’.
This is so very, very wrong.
Real programmers - by my definition - in 2009 - will often choose not to use C. A real programmer will seek out a language that will allow them to get the job done quickly, comfortably, and with as few errors as possible. Depending on the job at hand, sometimes that’s C, sometimes it’s Java, increasingly often it’s a scripting language, or a mixture. If WebMethods Flow were so easy, it would be popular with real programmers.
Experienced programmers can deliver seriously faulty Flow code, because it lacks the sanity checking they’re used to. With Flow, you have to be almost as careful as if you were writing assembly. As basic as C’s image is, it has more safeguards than Flow.
Inexperienced programmers are in a worse position yet. They are dropped into a friendly looking world in which pretty much anything they do is accepted as runnable. They are given an awful lot of rope with which to hang themselves.
Beneath the simple facade presented by Flow, there’s quite a complicated interaction between data structures. There are some quite common circumstances in which really subtle nuances to do with Java object references create behaviour which the Flow programmer does not intend.
These inexperienced programmers are ill-served by a language that does not rein them in.
When a conventional language tells you “you can’t divide a word by another word”, that’s not being harsh - that’s being helpful.
When a conventional language says “you can’t refer to a variable named ‘paramter’ because you never defined one”, that’s not being unfriendly, that’s pointing out a spelling mistake and anticipating a more serious problem.
These are things that were known in the 1970s or earlier.
Computer scientists didn’t invent these things just to be clever, or fancy. They invented them because they make programming easier. I contend that any language that dispenses with them is not easier, but more difficult.
What I need is a ruthless copy editor…