Slashdot Mirror
Fighting the Culture of 'Worse Is Better'
An anonymous reader writes: Developer Paul Chiusano thinks much of programming culture has been infected by a "worse is better" mindset, where trade-offs to preserve compatibility and interoperability cripple the functionality of vital languages and architectures. He says, "[W]e do not merely calculate in earnest to what extent tradeoffs are necessary or desirable, keeping in mind our goals and values -- there is a culture around making such compromises that actively discourages people from even considering more radical, principled approaches." Chiusano takes C++ as an example, explaining how Stroustrup's insistence that it retain full compatibility with C has led to decades of problems and hacks.
He says this isn't necessarily the wrong approach, but the culture of software development prevents us from having a reasoned discussion about it. "Developing software is a form of investment management. When a company or an individual develops a new feature, inserts a hack, hires too quickly without sufficient onboarding or training, or works on better infrastructure for software development (including new languages, tools, and the like), these are investments or the taking on of debt. ... The outcome of everyone solving their own narrow short-term problems and never really revisiting the solutions is the sea of accidental complexity we now operate in, and which we all recognize is a problem."
He says this isn't necessarily the wrong approach, but the culture of software development prevents us from having a reasoned discussion about it. "Developing software is a form of investment management. When a company or an individual develops a new feature, inserts a hack, hires too quickly without sufficient onboarding or training, or works on better infrastructure for software development (including new languages, tools, and the like), these are investments or the taking on of debt. ... The outcome of everyone solving their own narrow short-term problems and never really revisiting the solutions is the sea of accidental complexity we now operate in, and which we all recognize is a problem."
This sounds a lot like the mantra of the FreeDestkop.org folks and/or Redhat with the "moving Linux into the 21st century". I'm not going to call it a 'planted' article, but you know.
Back in the day. The clue is in the name. If it wasn't compatible but simply similar then it would have been called something else. Java perhaps.
It's easy for a programmer to say "We should stop worrying so much about compatibility and interoperability" when they don't have to deal with customers, support, or actually selling the end product. When a customer calls up and says, "Hey, how come this new version of Windows doesn't work with any of my old Windows software?" you can't just tell them "Because our programmers thought it was better to get a fresh start."
SJW's don't eliminate discrimination. They just expropriate it for themselves.
So.. preserving backwards compatibility and interoperability across versions is a bad thing? If he's unhappy with the feature set of C++ (and I wouldn't blame him for that), then how about simply picking up a different language instead? That's what a new, non-compatible C++ version would be in any case.
Look at how great it has worked out for Python. It's been six years since the only mildly incompatible version 3 was released, and it has still not managed to become dominant over the legacy version 2. A more radical break would almost certainly have had an even tougher road ahead.
Trust the Computer. The Computer is your friend.
.
So he thinks that compatibility and interoperability are not features which he likes. OK, I'm OK with that.
However, that is his opinion, nothing more, nothing less.
There are reasons why interoperability and compatibility are desired. It is not the easiest path to provide those characteristics, on the contrary, it is easier to just say, ~screw compatibility, screw interoperability~, and you'll probably finish your task more quickly.
So then the question becomes, why do people invest extra effort in order to assure interoperability and compatibility?
...which we all recognize is a problem....
And now he presumes to speak for everyone....
Overall it sounds like he just got out of a bad meeting in which someone told him that his opinions are not worth the air used to utter them, and now he's trying to convince the world that he is right and the world is wrong.
Once upon a time, I wrote "clever" code. Truly beautiful, almost poetic in its elegance. Note I said "elegance", not "simplicity".
I don't know who to credit for this (probably read it on Slashdot), but a single perspective completely changed the way I view coding:
It takes substantially more effort to debug than it does to write code in the first place. If, therefore, I write code as clever as I possibly can - I can't effectively debug it (without investing far more time than I should) if something changes or goes wrong.
Now, that doesn't mean "worse is better"... I can still produce good code; I can even still write the occasional clever function when performance demands it. But for the 99.9% of code that has almost no impact whatsoever on performance, I can just say "if X then Y else Z" rather than using cool-but-cryptic bitmasking tricks to avoid executing a conditional instruction. And hey, whaddya know, I can actually read it at a glance six month later, rather than praying I didn't forget to update my comments.
On the flip side of this, a few weeks ago I helped a friend put together a spreadsheet with a few complex formulas in it. I love me some IFSUMS, arguably the best new feature of Excel in the past decade. Note that clause, "in the past decade". This weekend, she called me because her nice helpful spreadsheet wouldn't work - On Excel 2003. It seems that while 2003 has IFSUM, MS didn't add IFSUMS until 2007. The choice of one seemingly harmless backward-compatibility-breaking function made the whole thing useless in a given context. Now, in fairness, I can hear you all screaming "just upgrade already!"... But in the real world, well, we still have people using Windows 95.
How did breaking compatibility worked out for python 3?
Backward compatibility isn't just important, it's paramount. It's not 1957.
Nobody wants to upgrade their build system to a newer version of the language and find out it breaks the code all over the place. Nobody has time for that. New versions of the same language need to ONLY
(1) fix errors
(2) add new features that you invoke with new code that would be rejected by the old version's parser.
If you change how old code will behave, that's not a new version. It's a new language.
Likewise other systems, such as operating systems and even user-exposed interfaces, because ultimately programs depend on them working a certain way.
I would assert precisely the opposite. "trade-offs to preserve compatibility and interoperability" do not cripple the functionality to users-- failures to engineer compatibility and interoperability is what cripples functionality.
The number of times that there's been a new feature and I've said "oh, excellent, it's true that my old files no longer work, but this is so wonderful I don't care" has been very close to zero. The number of times there's been a new feature and I've said "those assholes, I have twenty thousand files that don't work any more, what in the world were those idiots thinking?" is decidedly not zero.
http://www.geoffreylandis.com
This is why Python3 is still struggling. It is great if you are writing new stuff from scratch, but a real pain if you have an existing code base that is doing work. Incompatible compiler changes increase the barrier to upgrading since developers (and schedules) need an increasingly large incentive to justify the time and energy, esp when even minor (supposedly compatible) updates are already risky and potentially time consuming endeavors.
It's a combination of 'Standards are never finished being implemented' combined with features never being explicitly declared.
Both C and C++ have been hobbled for years not by their backwards compatbility, but rather than features that are intentionally ambiguous or undefined because those are 'Implementation specific details', without regards to the effect of those lacking declarations effects on both cross platform compatibility as well as auditability of the resulting code. If there is no guarantee as to the functional equivalency of code produced by two compilers on the SAME arch (nevermind on different ones) how can you expect there to be the opportunity to 'start over' by dropping legacy support without a stable and documented legacy codebase for the new designs to be developed on?
Just as an example: Look at K&R, ANSI, C90, C14, etc. Many of these standards were never fully implemented in any particular compiler. K&R was supported in early gcc releases but deprecated and then dumped in gcc-2.95->early 3.x releases. Many of the later releases break features of the earlier ones piecemeal despite the original standard never having had a 'stable' release that could properly generate code for all applications (While rare, there are still many corner cases, even in perfectly 'valid' C programs that thanks to developer error, or mistake implementation of standard features resulted in code generation bugs. Some of which weren't fixed before a standard was deprecated or altered for compatibility with C++ for instance in a manner that broke a formerly 'conforming' application.)
Point being: Lots of compatibility has been thrown by the wayside in the name of forward progress, but it hasn't SOLVED anything because nobody seems willing to bother taking time out from their new features to ensure a stable and standard complete/compliant codebase from which to iterate into the next generation. The result of this is a constant churn of mostly working code with all sorts of corner cases resulting in unexpected operation, security errors, or simply some 'end user' being unable to compile an old version because the new compiler can't bootstrap the old one, the old one requires since-lost voodoo to compile the new one, and the amount of work and digital archeology to determine what changed in the standards to make the old code properly operate under the new ones may not be worth the expense in time/knowledge to do so.
Apologies if this is overly verbose, meandering, or obtuse. I figure if nothing else this might provide a basis of concepts someone more articulate can turn into an acceptable discourse on the shortcomings of the 'development culture'.
Since when has slashdot ever been news? Its masthead may be "news for nerds" but its news is seldom very new. It's about seeing one's fellow nerds' views on that topic.
Free Martian Whores!
So far, I don't think I've seen a single comment here that got the point of the essay.
He's not talking about incremental "improvements" to existing languages, he's pointing out that the common attitude of "we'll make this language easy to learn by making it look like C" is a poor way to achieve any substantial progress.
This is true but everyone who's invested a substantial amount of time learning the dominant, clumsy, descended-from-microcode paradigm is reluctant to dip a toe into anything requiring them to become a true novice again.
I've long been a big fan of what are now called "functional" languages like APL and J - wait, hold on - I know that started alarm bells ringing and red lights flashing for some of you - and find it painful to have to program in the crap languages that still dominate the programming eco-system. Oh look, another loop - let me guess, I'll have to set up the same boilerplate that I've done for every other loop because this language does not have a grammar to let me apply a function across an array. You want me to continue doing math by counting on my fingers when I've got an actual notation that handles arrays at a high level, but I can't use it because it's "too weird". (end rant)
There have been any number of studies - widely ignored in the CS world - going back decades (see this http://cacm.acm.org/magazines/...) - pointing out how poorly dominant programming memes mesh with the way most people think about problems and processes. Meanwhile, the 1960s called - they want their programming languages and debugging "techniques" back - "printf", anyone?
I would assert precisely the opposite. "trade-offs to preserve compatibility and interoperability" do not cripple the functionality to users-- failures to engineer compatibility and interoperability is what cripples functionality. The number of times that there's been a new feature and I've said "oh, excellent, it's true that my old files no longer work, but this is so wonderful I don't care" has been very close to zero. The number of times there's been a new feature and I've said "those assholes, I have twenty thousand files that don't work any more, what in the world were those idiots thinking?" is decidedly not zero.
And this is why there are so many programming languages with massive overlap in usage. Because once you start down a path, you can never, ever, everver change. If you want something that 42 years down the road that breaks with convention, go create a new language.
The two languages are not incompatible
That's vague. The real question is whether C++ is a strict superset of C. Answer: it is not.
Some constructs valid in C are invalid in C++. Some valid C code is also valid C++, but behaves differently.
See Section 1 and Section 2 of this Wikipedia article.