That’s really impressive, Airborne Again!
In the 1980s I also did a multizone heating controller, Z80 based. In fact I have just dug out the source code… I guess it was an era when the “domestic scene” was waking up to what can be done with IT, and controlling heating was an obvious thing to do.
I think we all used to be much more productive back then. The distraction of the internet was missing (not even email until about 1995) and once the family+kids thing comes along the rest of one’s time just vanishes…
I think the most productive programmers today are found in Eastern Europe (e.g. descendants of the Russians who reverse engineered the VAX 11/780 
). There is a load in India but their output is of such poor quality it has to be re-done several times before it’s of any use – even then, I am told by one UK IT manager, it is still cheaper (on paper) to go to India.
To a real software pro, it really doesn’t matter which programming language or environment something is written in. No programming language or hardware platform you couldn’t master in a few days.
If you’re developing a simple software on your own, then I would agree with the above.
However maintaining a complex system, in a large development team would become quickly a nightmare with an old programming language. I read somewhere on the BBC news that the nats code has millions of lines of code, so it’s definitely not a re-write of pong. If it has accumulated years of ‘hacks’ which nobody understands any more it’s prolly a good time to modernise the code base with something everybody understands.
I think the most productive programmers today are found in Eastern Europe (e.g. descendants of the Russians who reverse engineered the VAX 11/780 ). There is a load in India but their output is of such poor quality it has to be re-done several times before it’s of any use – even then, I am told by one UK IT manager, it is still cheaper (on paper) to go to India.
Most of the development today (it’s not called programming anymore 
) is 80% communication and 20% pressing the right buttons. Doesn’t matter if you can reverse engineer the VAX 11/780 if you can’t communicate clearly and write clean readable code. Reclusive brilliant geeks do have it hard nowadays!
If it has accumulated years of ‘hacks’ which nobody understands any more it’s prolly a good time to modernise the code base with something everybody understands.
Doesn’t matter if you can reverse engineer the VAX 11/780 if you can’t communicate clearly and write clean readable code. Reclusive brilliant geeks do have it hard nowadays!
Have you ever read operating system code developed at IBM or DEC 30-40 years ago? Clean and readable code was an integral part of their culture. Even if you had no commented assembly code at your disposal, a disassembly was relatively easy to understand. I disassembled and analysed quite a few OS/370 executables in the early 1980s.
Even if application code was not quite so rigorously written, the waterfall development methodologies of those times resulted in a much lesser amount of obscure hackish code being released. A notable exception was embedded software (think space missions), where dirty tricks like self-modifying code were routinely used to save precious memory and processor time.
Have you ever read operating system code developed at IBM or DEC 30-40 years ago?
No. Wasn’t even born yet Nor did I experience a lot of the waterfall methodologies, for which I’m glad.
Anyways, without taking a dig at anyone, all I’m saying is that today’s software systems are 100x more complex than 40-50 years ago. This is not just because they need to handle more value, but because they need to present the data in a more friendly manner, communicate with 100s of different external systems, overlay various other data and additionally connect to facebook (I bet that would be fun writing it in Jovial!). Yes you can have a strict culture of writing good readable code, but it helps big time to use the right tools (i.e. a modern language).
Back to the Nats problem, which media is saying was triggered by a software bug… Does anyone know more details about the gitch?
I don’t think this 1960s software is uploading jpegs to facebook
Most likely, based on the little I know about how ATC work, it is driving a load of ticket printers over RS232 or Centronics. What the inputs are, I have no idea but probably from keyboards or custom keypads (or of course keypad emulators, with the input coming from some serial data stream). They might also be driving some alphanumeric displays, directly or indirectly.
Back in those days, code was written very well and very well commented. The lower level you program at, the more the comments matter.
This stuff is a world away from today’s GUI and web interfaces, which multiply code size 100x before you even get started. And a lot of time can be wasted chasing down obscure bugs in the supplied libraries…
Today, most big-league software cannot be done by 1 person (much of it probably could be but you can’t find good enough programmers anymore so you have to manage otherwise) and the biggest challenge in software development is making sure that the team works together and the finished product isn’t too full of bugs.
I would agree that in my experience ancient software often beats modern software hands-down for reliability. In the hospitals I work in they’re continually replacing telnet-based services e.g. for looking up lab results with web-based services that are prettier, slower, and less reliable. Quite a lot of the newer stuff is barely usable and some of it is downright dangerous e.g. randomly missing out drug on patient discharge summaries; changing the patient’s name at the top of the screen if you happen to look up results for patient B whilst writing notes for patient A.
I have to say having recently seen the Swanwick systems they look modern and high quality. No idea what is behind the interface. Sounds like the aircraft strips stopped working. I know for a fact that they train for that and the more serious loss of radar heads. This while thing is somewhat overdone. Yes, it is bad and will have caused a lot of inconvenience. But there was no safety impact. These are all incredibly complex systems. If anyone really thinks that any complex system can be made bug-fre then I would suggest they are dreaming.
I’m going to stick my neck out and say that the problem is that we’re turning out lots of “software developers” without a proper understanding of computer science and software engineering because of the idea that since basic programming is rather easy, thus software development is easy, too. Teaching “IT literacy” and programming is a good thing, but a little learning is a dangerous thing also. There is a world of difference between programming in the small and programming in the large which you don’t really appreciate until you’ve been exposed to the latter.
One analogy I use with my students (ok, so I am an associate professor in computer science) is that cooking for yourself or your family is something which almost everyone can do ok. Making the food for a banquet where 200 people should be served at about the same time is something entirely different. Cooking in a restaurant where you are supposed to turn out different dishes on order with 20 minutes or so notice is also something different altogether.
The lower level you program at, the more the comments matter.
Have to disagree on this one. Admittedly sticking my neck out, too: if a bit of code needs (a lot of ) comments, that is a clear sign that it lacks clarity in the coding. The perfect program is readable without any need for comments. Good program structure and carefully picked variable names will do 90% of that.
Regarding the comments of Airborne Again: the cooking parable is nice but not really applicable. A program that works well for one user will work well for a thousand – IF it doesn’t eat all the resources. And there is a crucial issue: today’s programmers have not enough affinity with the machine. They see and create nice screens and fanciful mouseclicks, today that is called “user experience”, bah, more baked air. How much memory or cpu power their nice constructs will eat is not of interest to them. It must be said that today’s programming languages, Java and Perl in special, encourage this mindset. There is too much distance between the programmer and the hardware, the days are indeed long gone when programmers wrote assembler code and saw, almost felt, the cpu they were working upon.
As someone said, today’s applications use far more resources, yet generally run slower, than those of 20-30-40 years ago – the only thing they have more is “prettiness”.
You could make a distinction between well-commented and copiously commented though, and I think assembly language always does call for some level of commenting.
