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."
It's true. I read it in AC's blog.
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.
Obligatory XKCD
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.
"Technical Debt is a thing, people"
.
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.
And that compatibility still is important today. For one thing, APIs can be written in C (starting with the POSIX API) and be used by programs written in either C or C++ or in language X, or language Y, or language Z.
FTFY. This is due to calling conventions, not due to a 'language compatibility'
Here's an idea: if you don't know shit about C++, don't post shit about C++?
Here's an idea: If you don't know shit about the basics of programming, don't post, like, at all. Especially avoid calling others idiots when you're at the same time making clear you're even less competent.
CLI paste? paste.pr0.tips!
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.
Seems like someone (or a consortium of someone's) should take C++, drop the C compatibility requirement, make whatever "cleanup" changes that allows, and call it C+++. Just make sure there's a module ready to go for gcc.
Yeah and basically you also clean up the syntax since if you're breaking compatibility then you may as well make it parsable. What you get is D or Rust.
Both of them seem like fine languages.
Howeve, I end up always reaching for C++, because then I can reuse my old code and keep using my libraries. Some code in there hasn't been touched since 2004 and it still works perfectly. Why would I want to write and debug it again?
SJW n. One who posts facts.
Wrong.
C++ has zero problem dealing with structs as function parameters (usually pointers to structs) which have arbitrarily complex internal structure, including embedded pointers. Since C does not provide OO encapsulation, it is often useful for calling code to manipulate pointers directly.
In Perl, you've got to wait until someone provides a binding for these complex cases... or, yeah, "why don't you do it yourself? It's open source."
Haven't looked at D in any detail, but I was under the impression it was more different than C++ than what I had in mind. I was imagining C+++ as staying as close as possible to C++ but with whatever modest improvements are enabled by the omission of C compatibility. But maybe that's in fact what D is.
Does anyone have any idea of the hacks he's talking about?
Since C++ is intended to and has always been a superset of C, how could there be any problems and hacks caused by compatibility with C? How could it be any better by discarding part of the language itself?
A problem I've been seeing lately is that everyone seems to think software is carved in stone. In the past 3 or 4 years I've heard a LOT of excuses why some flaw in one system or another made a feature impossible. In these cases, fixing the flaw would be pretty trivial. Instead of doing THAT, people just build another layer of crap on top of the previous layer of crap and try to kind-of get something working. Code is not immutable. If it doesn't do something you need it to do, MAKE it do what you need it to do. Write a library, redesign a layer, simplify an interface, whatever. Don't just wring your hands and make the problem worse! Code is made to change. No design is ever perfect right from the start. If you try to make your design perfect from the start, you'll just end up paralyzed, afraid of doing anything because you might do it wrong. Start with a design that seems reasonable and adjust it as needed. Write small, decoupled libraries that can support that, and write unit tests to insure that each component behaves as expected. It's really not that hard, people!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
How did breaking compatibility worked out for python 3?
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
If being perfect means not having critical core features then you're confused about what is and is not perfect. Compatibility is important. In many applications it is vital. Period - end of story. Does maintaining compatibility make the project more complicated? Yep. Coding is hard.
Next issue.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Ordinarily, it doesn't. But the thing is, there are two things called GCC: the GNU C compiler (which handles C) and the GNU Compiler Collection (a set of compilers which, though they share the same backend, are still separate entities).
GCC, the C compiler, cannot handle Fortran. GCC, the set of compilers, can handle it via g77 (the old compiler) or gfortran (the new one), but the C compiler can't. This is considered the traditional way of doing things.
What makes C++ different from many languages is that its maintainers insist that C++ compilers must be able to handle C code. It's not enough to have a different compiler in the set, the way GCC does: it must be doable with the C++ compiler itself, in the same application. And so g++ can do it too, because that's what the standard requires of it.
That's what makes the difference. Ordinarily, as you say, a compiler's ability to handle multiple languages shouldn't affect any of the languages in it. But C++ was defined in a way that not only makes those effects possible: it makes them mandatory.
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'.
I phrase I picked up years ago seems to apply here, 'standard is better then the best solution'. It is not a culture of 'worse is better', but of competing interests where the pure joy of developing languages is not the primary metric for determining what the best course of action is.
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.
To accuse the C++ community of not having engaged in "reasoned discussion" about backwards compatibility is silly. Chiusano may not like the tradeoffs that C++ makes (I don't), but they are the result of a glacially slow and tedious community process and discussions. Whatever C++ is, it is by choice and reflection. Furthermore, "worse is better" refers to keeping things simple by cutting corners, and you really can't accuse C++ of keeping things simple.
(Charges about too much backwards compatibility are ironic from someone who promotes Scala, a language that makes many compromises just in order to run on top of the JVM and remain backwards compatible with Java.)
Have gnu, will travel.
On one hand, I can see where you're coming from. Breaking changes should not happen in this way. At the very least, it should detect that you're trying to open an old file and either continue to work the way it did on the old system without the new features, or have an automated upgrade tool that does the work of upgrading the file for you.
On the other hand, I would say that's what you get for using something like Access or FoxPro as a tool for developing ongoing projects. They are great for things like whipping up a quick program because you need some numbers and a quick report for this afternoon, but they fail when you have to use the resulting application on a day-to-day basis.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Try compiling this as both C and C++. It's completely valid in both languages, but the output will be different in each.
I am TheRaven on Soylent News
I started developing software for a living in 1990, I used to teach C programming to second year engineering students. I'm not offended when someone displays their ignorance, and there's no shortage of arrogance in the software industry. Truth is, we all look at the code and think "surely there's a simpler way than this". Experience teaches you that there usually isn't.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Neat, but what's the problem? The code is valid in both languages and the output is correct in both cases.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.