IIRC, that's precisely what Nozick is nominally interested in exploring (although he really doesn't).

There at least 2 distinctions going on:

1. whether wealth is acquired with or without exploitation; Nozick uses consent as a proxy for exploitation, which is dubious but predictable given that he's a libertarian

2. whether there are ill-effects to (excessive) wealth regardless of how it was acquired

It's about how a utopian society could and/or should respond to changes in resource distribution, and how entirely consensual behavior and exchanges between people can still lead to situations that are problematic.

Obviously when viewed from other perspectives, they differ significantly.

> The work is done by the seed/sun/soil/water.

and the farmer collects. It's not that the farmer does nothing or deserves nothing. But it is precisely the same as the capitalist model: the capitalist sets the stage for labor to do the work, and then collects.

As others have noted, the central question is who gets to benefit from what is created and why.

And that utility library (there are dozens of them) is just as subject to debate and issues as libstdc++

I am not going to implement my own C versions of 90% of the stuff std:: provides, sorry.

I wasn't seeking to establish my own authority in any way: "X is brilliant, we should listen to them" being countered by "there are lots of people with similar levels of experience with this thing who have many different opinions (I happen to be one of them)" isn't an appeal to authority. But sure, I could have left out the ("I happen to be one of them") part without changing my point much.

TFA is not about someone sharing their preferences. It's a direct call to not use many features, and claiming that to do otherwise is a mistake. Here's an example of sharing preferences:

"I've often tried to use C++'s variadic function templates, but I've found that just using initializer lists tends to be simpler and more readable".

Here's an example of how TFA would put that:

"do NOT use variadic function templates"

Moreover, what's even more beautiful? You can change the type of things in the container "esses", and the code doesn't need to change.

If you have the experience, this construct tells you everything you need to know: it's an iteration over a container, visiting every element in order, without copying it, and without modifying it.

You don't need to know any more.

It's a bit like concrete - there's two kinds (of programmers): the ones who have experienced namespace issues (i.e. name collisions) and the ones who haven't, yet.

But even "avoiding iostream" is stupid. The author presumably really means "avoid operator>> and operator<< for I/O". Even using type-safe printf-like stuff ultimately still sits on top of iostream.

I can see no rationale for this whatsoever. It is nothing but syntactic sugar.

> Branmir (of BGFX fame

Appeals to authority don't really work for me.

I've been writing a cross-platform DAW (0) for 25+ years, in C++, and what a game dev has to say about the language in their own work might be of passing interest but not much more.

Being aware of the pitfalls of particular features of a language is an important task for anyone programming in that language. But that doesn't mean that the language is fundamentally broken or that programmers cannot make their own choices about which features to use.

(0) on at least the same level of complexity as a modern game

   for (auto const & ess : esses) {
         ...
   }

Also, you can fight me if you want to take

      dynamic_cast (base_ptr)

Basically, stick with C and leave C++ programmers alone. I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.

Comments URL: https://news.ycombinator.com/item?id=48482424

Points: 3

# Comments: 1

This obviously changed as pthreads came into being, and at this point, I suspect that the typical use for threads-sharing-memory and threads-not-sharing-memory is the same on most platforms.

A reminder that the task_t data structure describes threads and processes not just in Linux, but earlier Unixen also.