Hacker News Reader

Comment by simula67 | Hacker News Reader

He seems to be arguing that in order to weed out poor engineers he prefers to keep things complicated. As hard as it would have been for me to accept this a few years ago, I think there might be some truth to this argument.

For example, I would think that the best Java engineers are probably much more productive than the best C++ engineers. However, the market is probably full of poor Java engineers that the average Java engineer is probably a lot worse than the average C++ engineer.

C++ is such a complicated language that if you are a professional C++ engineer and still employed, you must be fairly skilled. So, for example if you start a tech company or an open source project it might be better to choose C++ as the implementation language even though Java might make you more productive.

Funnily enough, Linus does not apply this logic to C vs C++ debate and has come to the opposite conclusion : http://harmful.cat-v.org/software/c++/linus

View on HN

> He seems to be arguing that in order to weed out poor engineers he prefers to keep things complicated.

I don't know whether this is his goal (he does make it sound like it), but I think the consequence is another: In order to manage not having a debugger, things are by necessity kept simple. It reminds me of a quote from Brian Kernighan:

> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Since simplicity has other positive consequences apart from ease-of-debugging, there might sometimes be advantages to not using the fanciest tools all the time.

> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

By taking twice as long to debug it ?

By not having to debug complicated situations most of the time. Because you lacked the tools that would have allowed you to get in such a bad situation in the first place.

Phone a friend ? Hire a consultant... handicapping yourself seems questionable unless playing a week opponent.

> if you are a professional C++ engineer and still employed, you must be fairly skilled.

Nah. Many of the C++ gigs I've had were at places which only used fractions of the language. There are a lot of bad C++ programmers. I'm not disagreeing with your overall point about ratios though.

Supporting annecdata: I’ve seen some C++ where entire classes were copy-pasted (including `//TODO: deduplicate method` comments), because the author didn’t want to use inheritance. And when they insisted their code was fully optimised, it turned out to be doing an unnecessary O(n^2) operation.

>Many of the C++ gigs I've had were at places which only used fractions of the language.

I don't think any project or person uses or even knows the entire language. I think even Bjarne himself said that no human can possibly know all of C++.

Seriously, in every C++ project I've seen, it seems like whoever's in charge picks some subset of the language to confine themselves to, and uses that. One of C++'s strengths is that you can do this; it's adaptable to your project and style.

I'm not sure this correctly characterizes Linus' opinion. It seems more that he's saying debuggers cause a kind of myopia by putting a specific failure under a microscope, and that he wants developers who are willing to undertake the harder task of understanding the failure at a system level. Not that he wants to impose complexity for its own sake to cull out weaker developers.

By simple statistics, most people are, on average, about average. This is true for any population large enough. I don't buy your assertion that C++ developers are better than Java developers, and all else being equal, bad Java code doesn't blow up in as destructive a way as bad C++ code.

Deliberately keeping a working environment hazardous and unsafe doesn't give you a breed of superhumans that never let accidents happen, it just leads to a lot of unnecessary accidents.

I think the main problem with a lot of high level language software developers (Java, ...) is that they often fail to consider the consequences of the fact that their software runs on real world hardware -> Memory access, Cache, Network Latency, Bandwith (Memory and Network), etc. Instead its all about artificial constructs as Design Patterns, OOP, etc. which often results in bloated, slow and therefore unusable software.

> By simple statistics, most people are, on average, about average.

I'm pretty sure this isn't true. Averages can be skewed by outliers. It's likely that most people are better/worse than average. Consider how the average life expectancy was horribly skewed by infant mortality.

You're right, it isn't true. It doesn't even require outliers, just the curse of dimensionality. See for example https://www.thestar.com/news/insight/2016/01/16/when-us-air-...

You just made the exact opposite argument of Paul Graham's "Blub" article:

http://paulgraham.com/avg.html

The "Blub Paradox" argues you should hire developers using the most productive tools, even if those tools are unpopular, because that naturally selects for the best developers.

You are arguing that you should hire the developers using the least productive tools, because if they can get anything working at all with those tools, they must be pretty talented.

No he didn't, because "productive" != "(not?) difficult", they're mostly orthogonal. LISP is productive according to PG because it has a kind of unlimited amount of abstraction, I don't think he would say that LISP is difficult. LISP/smalltalk: PG-productive, not difficult Java: PG-unproductive, not difficult C++: PG-unproductive, difficult (Forth? Haskell?): PG-prodictive, difficult

So there are points in all 4 quadrants I think.

Reformatted your list so it's easier to read:

LISP/smalltalk: PG-productive, not difficult

Java: PG-unproductive, not difficult

C++: PG-unproductive, difficult

(Forth? Haskell?): PG-prodictive, difficult

That's not what is says at all. The article claims that you should use the most 'powerful' language available when writing application software (that meets your performance requirements), and that doing so will result in the greatest productivity.

The "Blub Paradox" is the claim that you can only understand how powerful languages are in terms of the powers the languages you know have. So if you understand Python and C++ and not Lisp, you are unable to estimate the power of Lisp.

Weeding out is useless because there are far more "poor" or "average" developers than there are "great" developers. This means that you're catering to the tail end of a distribution and are way more likely to progress at a significantly slower rate because you're looking for the 10% of the population that is "the best". Also, that scale is quite subjective and opinionated.

While I didn't get this opinion from my read of Linus's post, Linus seems to want to make things unnecessarily hard and somehow fails to see how that could be bad because of lack of arguments while simultaneously claiming making things easy would just be bad outright with little supporting arguments for it.

I was under the impression that software should be made as simple and easy to understand as possible. So for example, should I make some esoteric bit manipulation to multiply a number by 2^n or should I just use a library function? It may make sense if performance and memory are limited, but that's about the only reasons I can think of. Otherwise, you should have the code explicitly state your intent. It makes me think the kernel is a garbled mess they way its talked about in that post with not very easy ways of maintaining it.

> This means that you're catering to the tail end of a distribution and are way more likely to progress at a significantly slower rate because you're looking for the 10% of the population that is "the best".

It seems like he'd exactly agree. He goes on to say he doesn't want to add all those features, he'd rather go slower and his biggest job is to say "no" to new features.

But Linus is not god and is prone to his own biases. The fact that he's at the top and reviews all the commits is simply a product of history more than anything. I'm sure there have been several "average" developers that have worked on kernel code and submitted it just by the shear effort needed to maintain such a large code base.

I guess, my original point is, there will be "average" developers committing to the kernel just by statistics alone.

Have you actually looked at the kernel code or worked with it? It's some of the cleanest code I've ever seen. It does have to do some things very differently due to it being kernel code rather than userspace, and it is a VERY large codebase (esp. when you add in all the driver code), but aside from that it's quite nice IMO.

Most commercial projects I've worked on really were a "garbled mess" by comparison, and far less maintainable.

I've looked at some of it. But its been a long time.

Not a C++ engineer here, but I would think that the vast majority of C++ gigs around are legacy systems - in which case most of the work would probably be bug triage, that likely doesn't call for more than "fix my immediate problem" thinking.

Obviously there's still a lot of greenfield C++ work out there too, but I would expect that it's no longer the lion's share (C# is very much getting to this stage of it's life too).

I would guess that the top-level C++ folks have by-and-large moved on to those greenfield projects naturally as it's where their skills are most required, and where the most money is available to pay for them (e.g. fintech).

Embedded is huge for C/C++ and there are still many greenfield projects. Embedded (real-time, safety critical) usually requires GCless languages, which already rules out the vast majority of super productive new languages.

I wish we moved to Rust (or even Ada), because most of the bugs I see occurring couldn't happen there. But embedded compilers are usually lagging a bit.

Obviously there's still a lot of greenfield C++ work out there too, but I would expect that it's no longer the lion's share (C# is very much getting to this stage of it's life too).

Given that C# is the go-to language for new development on Windows, and with Microsoft now officially supporting cross-platform C# and .NET, I find that very hard to believe.

What’s the trajectory of - say - new Github projects that use C#/.NET?

Sure there is a lot of legacy work but I'm not sure it's the "vast" majority - at least, not out of proportion with other older general purpose languages.

It's still used in a lot of new embedded work. It's still the best option for a lot of HPC and numerics. Some of this work ends up being targeted mostly for inclusion in another language runtime, sure, but it's still new work.

Reply on news.ycombinator.com