Development quotes of the week

[Posted August 12, 2020 by coogle]

It doesn't take much work to make the code look nice. Writing pretty code is always a good idea because then people assume you know what you're doing.

— Dan Carpenter (thanks to Gaston Gonzalez)

Make no mistake: no matter what programmers tell you or what people whisper in your ear, the behavior of C’s governing body is very clear. We will not introduce warnings into your old code, even if that old code could be doing something dangerous. We will not steer you away from mistakes, because that could shake the veneer that what your old code does is, in fact, wrong. We will not make it easier for new programmers to write better C code. We will not demand that your old code is held to any Standard. Every new feature we add we will make optional, because we cannot possibly imagine holding compiler writers to a higher standard nor expect more out of our Standard Library vendors.

— JeanHeyd Meneide

Development quotes of the week

Posted Aug 15, 2020 22:06 UTC (Sat) by willy (subscriber, #9762) [Link] (6 responses)

C absolutely has broken backward compatibility in the past. The gets() function was removed from C 2011. 25 years late, but who's counting?

Development quotes of the week

Posted Aug 16, 2020 19:31 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (5 responses)

Yeah, but that's a function no one could have possibly used correctly. strcpy is in an adjacent "very sharp and dangerous functions" bucket but it still exists because one could potentially not screw up length calculations ever. But I'd rather just see it gone too, but it never will be.

Development quotes of the week

Posted Aug 16, 2020 19:41 UTC (Sun) by willy (subscriber, #9762) [Link] (4 responses)

You can't "yeahbut" this. He said "We never do anything to disturb old code", but here's a counterexample. That's the thing about always/never assertions. It only takes one counterexample to disprove them.

So, there is a level of misdesign that's worth breaking backward compatibility for. Apparently gets() rises to that level, but strerror()s lack of const doesn't.

I feel this decision by the C standards committee to be a bad one.

Development quotes of the week

Posted Aug 17, 2020 13:38 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

In general, yes, I agree. However, in specific instances, removing old behaviors which have no good use case (and trivial replacements) can be justified. Plus, even if the standard removes it, doesn't mean that in practice it is actually gone because implementations usually have even higher guarantees.

As another example, even the kernel will remove old, bad, or insecure interfaces at times. Sure, it takes just a single (hopefully involved) user to say "I was using that" to have a strong argument for restoration, but I've not seen (or looked for) anyone screaming that `gets` is gone. Though if it gets them to port away from C in anger…maybe their project will just be better for it anyways ;) .

On a somewhat related note, I actually find it an interesting phenomenon that we're creating with expiration of things like digital signatures and the like. We have these really old programs which don't/can't/won't change written decades ago. But in 10 years, things from today are likely to have expired mechanisms surrounding them. So eventually we could be in a situation where running a century-old binary will be easier than running a 40-year-old binary because the latter cares about the date either to run or to communicate with the world[1]. So removing interfaces that were introduced later may actually be easier because "no one" would be able to run any software that was made while the interface in question was available and recommended (the best/easiest solution would likely to find a contemporary version of the platform rather than try and run it on a modern version).

[1]Sure, time namespaces are looking to be a thing, but that doesn't help my TOTP generator or TLS-using program from communicating with the world.

Development quotes of the week

Posted Aug 19, 2020 22:57 UTC (Wed) by flussence (guest, #85566) [Link] (2 responses)

The software industry is currently going through the “disposable plastic” crisis the physical world went through in the mid-20th century (and is still paying down the debt for). You can run software from 1980 or 2005 on a modern desktop without too much hassle, but anything between there and 2-3 years ago? Black hole of fad frameworks and brittle dependencies. Computer Archaeology is going to become a full-time job.

Development quotes of the week

Posted Aug 20, 2020 23:38 UTC (Thu) by rietta (guest, #133698) [Link] (1 responses)

I really find this perspective intriguing. 1980 to 2005 was the golden age of standalone software. Get the emulation right and you can run it. 2006 to 2020 is the age of SaaS, meaning that the life expectancy of the software is the period of time its financially beneficial to the original developer to provide an ongoing service. This even applies to open source, where maintainers loose interest and leave. It's not reasonable to expect an entire graph of dependencies to remain stable for the long term.

Development quotes of the week

Posted Aug 21, 2020 1:00 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

That's not so different from hardware. Given full blueprints, you can reasonably rebuild any machine from 19-th century from scratch, no matter how complicated. Even if you start from raw materials.

It's not feasible anymore. You won't be able to just take Apollo project blueprints and build your own rocket. You'll likely find that there are no modern alloys that perfectly replace the ones used back then, that some substances might be banned entirely (e.g. carbon tet fire extinguishers or PCBs in transformers), or that some tools are no longer produced.

The solution here is to move forward and standardize ever larger components, so it would be easier to keep them working. E.g. HTML for UI description is becoming such a standard.