saywatnow

I find these modern artifacts fascinating, and a great example of how poorly we communicate {in,about} code. Not that either Wikipedia or RC is a reliable source of quality, but there's plenty a critical eye could object to in both pages :-).

Also a great example of how pseudocode can muddy the waters: that given by WP (and quoted by RC) strongly suggests that the list must be reversed as a distinct step, which seems to have coloured some of the RC examples. Of course, in some languages doing so would be idiomatic .. while in others traversing the list in reverse would be, and in others constructing it tail-first. Same with mapping the function and then filtering for overflow, which seems at odds with the pseudocode.

Also, specifics of the output are entirely lost along the way.

Does Site Reliability include using assets from no less than 7 domains and requiring Javascript to present a few paragraphs of text?

Nice to see a fairly thorough set of examples, but my only conclusion is that C++ really has become a parody of itself.

The language describing each policy is awful, but okay.

"so concise code" for 10 lines consisting mostly of ceremony to get the results of one std function into a vector?

Does the first example with std::transform::reduce really need `std::uintmax_t{ 0 }` twice instead of `0`?

2x-3x speed up for specifying a parallel execution policy on reasonably large examples seems deeply disappointing. Author didn't specify how many cores the examples were run on, but ouch.

Best of all is the volume of comments here predicting that these annotations will eventually be deprecated ..

I really want to like C++.

This is nice .. but it could be nicer with (pun intended) use of the context manager protocols, a few less empty lines and a bit of minor refactoring for readability.

Is execution_loop really meant to start and end holding the GIL?

My opinion is almost the opposite: I find Granger's ambitious ideas and presentations stimulating, and I like that they're out there to inspire people to imagine more and experiment more agressively.

I wish his audiences were a bit less credulous though. Experiments like Light Table and Eve are just that: interesting and potentially useful explorations of design space, but as unlikely as anything else to radically change the discipline of programming overnight.

> Sounds like an ideal job for a 3d printer.

Or, you know, a piece of timber and some sand paper.

The consumer-grade 3d printers I have exposure to would have trouble with some combination of piece length, tensile consistency, strength and durability you'd want in a book press. Printing alone would take longer than sanding and drilling. And I suspect a printed part wouldn't be so forgiving of adjustments made after manufacture.

Using the 3d printer because it's fun and a learning experience is fine, but calling it "ideal" when it doesn't offer any real improvements over the cheaply and easily made "traditional" material is going a little bit too far :-).

> developers often write software that trusts the local network

Yes, this is still a source of problems - DNS rebinding allowing websites to attack random sockets on LAN and localhost makes my skin crawl. That the protections are being implemented in the browser makes me sad.

> I'd like to see servers that utilize encryption and authentication

Me, I'd prefer architectural solutions further down the stack than /every single service/ that happens to benefit from a TCP control socket having to duplicate the work of encryption + authentication, with the attendant myriad opportunities for it to go horribly wrong. I already mentioned IoT and we know exactly what that's like when it comes to protecting itself.

Yes, I know, pipe dream .. and going off topic .. but I can wish.

> This is without considering the false sense of security that address masquerading provides; I cannot recall how many times I’ve heard people say that (gasp!) NAT was fundamental piece in the security of their internal networks (it’s not).

It bugs me when this dogma gets repeated without further explanation, /particularly in the case of IPv6/. No, NAT probably doesn't provide as much security as you think it does, but it does provide benefits. A NAT network is a default-deny-incoming network that cannot fail open, protecting against common boundary firewall configuration errors. A small (but once very pervasive) class of firewall bypass attacks (fragmentation) is eliminated. Obscuring information about the number of devices, and especially (IPv6) their vendors is beneficial. When (inevitably) a bug in your firewall is discovered by bad guys, the presence of NAT limits the kinds of attacks they can make. In the world of IoT, These Things Matter.

It's commonly phrased "NAT is not a security feature, firewalls are", which is midly nonsensical as NAT is a firewall feature .. one which often improves the security posture of the network. Of course there are places you absolutely don't want NAT, but I think it still belongs between the internet and most networks made entirely of desktop, IoT & personal devices.

Thanks, that's clear enough :-). In hindsight I can't imagine what alternative I was thinking of .. I had some idea you might have put the additional cost in the iterator by maintaining only an epoch counter in the vector, but that's obviously not enough to do the right thing in the presence of insert and erase.

Your library looks like a good toolset. While I still find the code pretty impenetrable, the number of tests I can see give me confidence. Bookmarked for reference when I'm using C++ again.

Can you briefly describe how the msevector + ipointer works? I tried to look at the code but dense C++ is not my forte.

It's not cmake's job to limit the behaviour of programs written with it.

> The third social space (restaurants, cafe's, etc) becomes more and more irrelevant due to delivery services.

Did you really mean to write that? :-)

To be fair, delivery services aren't really responsible for undermining the "third space" nature of these places: we've been treating them increasingly as retail conveniences for a very long time, failing to acknowledge their social and psychological role. But it is true that the rise in delivery makes the resulting isolation even more stark.