Thursday, April 10, 2014

Modern programming...

What I would like - hell! What I would absolutely fucking LOVE is for software products to have to include an ingredients list... if it uses open source garbage it should say so on the packaging in a great big warning label. The proportion of the source-code that the "author" hasn't even fecking well looked at, let alone understood, should be stated so that people have an idea how little the vendor knows about what they're selling.

It really REALLY pisses me off that there's no public distinction between the software written by people who have a clue what they're doing and the integrity not to use random garbage and the utter tripe that's thrown together by mindless, clueless garbage collectors, who go bin-diving in the open-source sewer and pile up sludge until they have enough to call it a product... except that image is far too kind for what clueless modern programmers actually do; there are really no ways to describe or conceptualise the extent of their miserable incompetence.

It sickens me to be thought of as belonging to the same profession as modern programmers. It utterly, utterly sickens me.

[later, after watching more news about the latest exploit found in open-sewer security software]

Whenever I see some turd of a programmer extolling the "virtues" of open-source software, using the lie that "anyone can see the source so it gets reviewed", as if many of the modern programming crowd have the competence to judge anything or anyone has the time to wade through the hundreds of millions of lines of code that get dragged into every project these days, I want to kick the lying shit out of them.

[muses] It would be unfair (and inaccurate) not to acknowledge that there are some very skilled programmers involved with writing open-source code, and most of the people who do it have good intentions. But the problem is that, like a chain, the weakest link is what determines the overall quality of any project, not the strongest, or even the average.

Writing reliable code involves far more than enthusiasm and the willingness to become involved; it's a real skill, it takes time to acquire and not many people have the right mindset, patience and consistency to do it even if they have the willingness to try, and few do - there's far less glamour in carefully writing a solid reliable application than there is in dashing something QAD (quick and dirty) out and then scampering on to something new and exciting, leaving behind a trail of half-finished projects for others to clean up.

But never mind... I have discussed this subject many times over the years and to do it justice requires more time and effort than I'm prepared to spend on it on facebook; I could and probably should write books on the subject. It's hard enough to get people to understand how to write code that can be tested, let alone expect them to try to test code that wasn't written with testing in mind by someone else who doesn't understand the process, who has a different coding style and skill level and like as not was introducing new problems while trying to deal with others and working on a completely different hardware platform... so the oft-mentioned concept of open-source generating reliability by peer-review and the process of bug detection/removal is childishly, painfully naive. 

I predicted over twenty years ago that we should expect software to stop behaving like an all or nothing digital system that either works or doesn't, but instead to experience a combinatorial explosion of unreliability until computing environments behave in an analog fashion with multiple degrees of failure of varying severity following an exponential decay curve slowly approaching - but never reaching - a stable state. I pretty much nailed that one, unfortunately.


  1. Absolutely agree with you...
    A lot of the poor programming standards are driven by what is being taught in our Universities and Colleges, often by people who have never completed a structured programming project in their lives. (Garbage In, Garbage Out.)
    There is a way to resolve this issue though: Make each programmer undertake a course in Electronics, to at least A-Level standard.
    If the would be programmer understands the hardware they are writing software for, the more likely a high quality product will be the outcome. By understanding, I mean down to the CMOS level. ;). The Electronics course should at least introduce the trainee to the art of Assembly programming, preferably on a Z-80 based computer they are forced to design and build themselves. Each student should have to create an Assembler and Debugger before graduating.
    Physics and Mathematics as well as logical analysis of issues should be taught and stressed as well. Physics and Mathematics will introduce the trainee to many little 'tricks' that are invaluable when programming. Logical analysis would stress a top down approach to solving programming tasks.
    The Structured, not Object Orientated, approach to programming should be stressed. OOP software is just a way of legitimising Spaghetti Junk programming.
    Anyone caught teaching OOP should be catapulted into the next County, minus safety net for the amusement of the public.
    While we are at it, how about basic English/Life Skills to assist the trainee programmer as to the correct way to document both their work as well as instructions in the use of the software they author?

  2. I think CMOS and Z80's are all very well, but for true excellence make the bastards do it with relays.