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."
is a blogger who thinks about stuff and posts it "news"?
C++'s strong compatibility with C was one of its strongest selling points relative to other object oriented languages back in the '80s.
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++.
Here's an idea: if you don't know shit about C++, don't post shit about C++. Save your precious insights for systemd maybe?
Obligatory XKCD
SJW's don't eliminate discrimination. They just expropriate it for themselves.
Worse is better is basically the KISS principle for software. C++ is not an example of that, but C is. This guy is an idiot.
This is my signature. There are many like it, but this one is mine.
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!
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."
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.