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?

pdf: https://www.math.upenn.edu/~wilf/website/recounting.pdf

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.

I guess all it takes to push a draft is hubris. The clear fact it hasn't received editorial feedback from a single native speaker is an indication how popular this is. (not to shame non-native speakers!)

> I find it hard to believe if you're a programmer

Some people work better with reference documentation, books and their brain than SO "answers".

Google for "complex programming questions" is laughable and honestly a bit insulting to the profession.

by serendipity I clicked through on this link and sgentle's link to Kay on McLuhan and the following sentence comes remarkably close to my experience of the two presentations of the Selection task:

> .. the most important thing about any communications medium is that message receipt is really message recovery: anyone who wishes to receive a message embedded in a medium must first have internalized the medium so it can be “subtracted” out to leave the message behind.

(a tangent, but perhaps interesting)

This should be titled more honestly: perhaps something like "Case studies in rapidly replacing dangerous C parser code with Rust using nom".

The examples are interesting and well presented. But the first sections trying to put a veneer of respectability on rust-all-the-things were a bit rough and got my cynic sense tingling.

Yes, you believe Rust will produce better results: don't try to justify that with facts you don't have ("Several languages were tested .." bullshit, unless you show some data. Likewise the assertions about type-safety and no-GC being essential properties). The data you do have (implementations produced and integrated and tested in a paper-like time frame) are valuable, unfortunately they're cheapened/buried under this false veneer.

> note how the second expression has no "z" variable in it.

A better comparison would be to

    func2(1 + 2 + 3, func1(x, y));

> imagine Lisp without macros.

Early on in my Scheme career, I found the tools to create macros a bit confusing and arcane .. but I still knew I wanted macros.

I ended up writing code transformers - a poor man's macro system if you will, taking my "high level" foo.scm through a couple of translation layers that turned the abstractions I wanted into running code. It was literally:

  $ scheme expand-foo.scm < myprog.scm > myprog1.scm
  $ scheme expand-bar.scm < myprog1.scm > myprog2.scm
  $ scheme myprog2.scm

What made this possible - trivial - was the homoiconicity: simply by (read)ing a program from stdin I had a list of lists that I could pattern match over and make the transformations I wanted. Exactly as my final program did with ordinary data.

In some ways, this was a more satisfying approach than using define-syntax / syntax-case, which differ from the rest of Scheme in somewhat uncomfortable ways. That macros could never be first class eventually put me off, but that's another story :).

The thing about both Lisp and Smalltalk that keeps making me feel alienated is that their power seems much weaker beyond their kingdom. The outside world does not have an object browser, nor is it made of s-expressions.

Tcl occupies a very nice place in this regard: its homoiconicity and symmetry (and late binding) come from text. The outside world, to a very close approximation, is also made of text. Subprocesses, sockets, FFI, files and user interaction just feel more native - in the image-oriented languages, I always find myself fighting the ambassador who imperfectly represents these things in forms the kingdom understands.

Just a feeling. They're all wonderful languages, and this article speaks well to some of the "why".

imho the headline should be the other way around:

> Most scientific studies cannot be replicated by peers

.. which is more to the point.

Thanks! That's excellent. Different measurements from populations with varying exposure to snakes certainly seems to weigh in favour of an evolutionary explanation.

> That's a general argument against any complex adaptation.

I know my comment looks remarkably close to typical poorly-informed arguments for ID (eyeballs, even bananas lol), which probably explains the poor reaction to it. There's a lot of fuzzy thinking about evolution all round, and I'm just as guilty of it as the next person.

Thanks for taking the time to give me a good read :).

I take it you do. Thanks for enlightening me!

> This makes sense, as humans have co-evolved along venomous snakes for presumably a very long time.

I always find appeals to evolution for phenomena like this a bit weak. In the Darwinian sense, this response would have to be a random mutation that is environmentally selected for. Not a biologist, but that seems a very high-order function to be subject to random mutations.

no source repository? Looks like a great opportunity for someone to grab all the release tarballs and build one to chuck on github. Bonus points for putting changelog contents in the commit logs!

The relevance of Android here is that Go has a reason to target it. Not that it's a Java/C hybrid.

OP: go has an interest in suiting embedded because Android.

Me: Android doesn't need to meet constraints anywhere near a home router (which needs to run ntpd)

You: there's a proprietary Java-based OS for Cortex-M3

.. still don't get it. Are you trying to sell me something?

I don't understand the relevance?

Badly needs static analysis. coverity is free for open source projects, will find many of the same issues, and produces reports that directly identify the buggy code, rather than the crash which might come thousands of instructions later in a completely different layer, requiring extensive reverse engineering to identify the source. And then when you've fixed one, the other test cases all need to be re-tested because they might have come from the same root cause, despite crashing in different locations.

Particularly when the hit rate is very high, fuzzing is a stupidly inefficient way to find bugs.