|Why Do We Try To Make Programming Like Something Else?|
|Written by Mike James|
|Thursday, 31 January 2019|
Page 2 of 2
Programming is different because it is dynamic. Mutable assignment means that the core of our subject is keeping track of state - not getting rid of it. What could be crazier than to adopt the full philosophy of Rest and a typical web page and abandon all stateful operations?
We need to recognize that state is a part of programming, that change is a part of programming and that the time evolution of the systems that we create isn't something easily ducked. If you do duck it then you pay the price somewhere else.
Software is complex and brittle in the sense that small changes break it easily, but it is very easy to change. Get the design of a bridge wrong and you don't get a second chance to put things right.
"Oh wait we need to refactor the bridge before anything can use it."
Which bridge is easier to fix? The real thing or Apple's attempts at mapping software?
In this sense the agile approach gets it right by recognizing the one huge strength of code - its is easy to change.
We need more of the agile approach, and not just the silly dogma of stories, smells and pair programming. We need to think hard about how code is easy to change and use this in our systems with languages that are more tolerate of mistakes. We need to make software less brittle by making it more sloppy in its execution.
This sounds like heresy, but it really is an overstatement of the idea that a programmer's job isn't done when the first error occurs.
So you have a number crunching program and it gets a divide by zero error; an unrecoverable error. So what does your program need to do? Well the obvious answer is that if it is an unrecoverable error you simply don't recover - throw some sort of exception or allow the language to terminate the code as quickly as possible.
You see my point?
Code is brittle because we allow it to be.
If you go into battle with a set of unrecoverable errors in mind then of course code is brittle. If you go in with the conviction that there is no unrecoverable error and you just keep the program going to serve the user as best it can, then software begins to look more like real machines. Real machines do fall apart to the point where they are unusable, but in most cases they can be coaxed to do some of the job they were designed for.
So here is a manifesto for the campaign for real software:
These are not easy maxims - but who said they would be?
or email your comment to: firstname.lastname@example.org
|Last Updated ( Thursday, 31 January 2019 )|