Great catch. I was getting ready to mention the theoretical risk of asking an LLM be your arbiter of truth; it didn't even occur to me to check the chosen example for correctness. In a way, this blog post is a useful illustration not just of the hazards of LLMs, but also of our collective tendency to eschew verity for novelty.
> Maybe there is a way to build a new web, a new kind of social media using a
> hash graph to implement a decentralized web of trust, something that can
> allow content verification without forcing everyone to sacrifice their right
> to remain anonymous online.
Comparisons to OpenGPG are likely to make anyone cringe, but if you're willing
to suspend disbelief about the usability issues, it seems like such an apt
metaphor. Where signing a key is vouching for the owner's humanity, not their
identity. I can imagine websites integrating my browser to attach a "humanity
key" to the content I post, and my browser maintaining my collection of keys
and my preferences for divulging them.
Granted, pseudonymity is not the same as anonymity. Maybe if the meaning (and
lifespan?) behind these keys was constrained, then they could be sufficiently
disposable to approximate anonymity.
This system is either fundamentally flawed or already implemented, but I don't
know how determine which. Can anyone here share writing along these lines?
> Unlike reading books and long magazine articles (which
> require thinking), we can swallow limitless quantities
> of news flashes, which are bright-coloured candies for
> the mind.
...and the manner of publication:
> This is an edited extract from an essay first published
> at dobelli.com. The Art of Thinking Clearly: Better
> Thinking, Better Decisions by Rolf Dobelli is published
> by Sceptre, £9.99. Buy it for £7.99 at
> guardianbookshop.co.uk
But there's a good case to be made for knowing your
audience. In that sense, this version is actually much
more likely to reach those who might be influenced by it.
Based on the full quote (below), it seems that he was referring to Valve's offering only:
"Well certainly our hardware will be a very controlled environment," he said. "If you want more flexibility, you can always buy a more general purpose PC. [...]"
Yeah, that's a good point. This introduces a new inventory consideration, namely CPU model demands (they'll have to determine the best distribution of proc models across each product). Probably not too big a deal
1. Waste. If some component on your motherboard goes, you're on the hook for a new CPU (and vice versa). This seems tremendously wasteful. Maybe bigger repair shops will support mail-in refurbishing? Will people take advantage of that? Or just buy new for convenience?
2. Competition. Smaller motherboard vendors won't be able to sell direct anymore. I'm wondering if anyone can comment on how bad of a thing this is.
The OP doesn't mention expected client count, but the number of concurrent connections is a crucial factor that these tests overlook.
I'm currently doing some Socket.io stress testing, and it's clear that XHR-polling is significantly harder on the CPU for the reasons you've mentioned. This detail is lost in the noise for single-client tests, but it will become increasingly relevant as more clients connect.
"Showing up every day is very interesting because it’s the least visible indicator of success. No successful person tallies how much they show up every day. Well except maybe this guy."
I really expected this link to point to Jerry Seinfeld's productivity secret. The story has made the rounds at this point, but in case anyone missed it:
> CoffeeScript was a godsend here, simply as an explicit compile and validation step.
> Automatic local scoping (no var necessary) is a sane choice, and safe loop scoping with for x in y do (x) -> erases a whole category of errors.
> indentation
Thought it might be useful to others seeking these advantages that passing your JS through JSHint in the build process could provide these benefits. It's not a cure-all, of course--the author cites other benefits that linting can't achieve. But if you're a like-minded developer looking for assurances along these lines in JavaScript, check out http://jshint.com and https://github.com/jshint/jshint/
Basically, publicly-funded elections could remove the corrupting influence of corporate money. Still not clear on how we get there, but I may pick up his latest book to learn more
I think the author mis-understands memory management. The following line argues that, without a reference to the prototype, the object is smaller:
"The other way it differs from the constructor pattern is that the prototype class is not instantiated. Which reduces the memory consumption of the object (among other things)."
Admittedly, there is some ambiguity because the second statement is a fragment. The way Crockford is quoted seems to support this fallacy, though.
Echoing what jashkenas said: anything you may save on a reference to the function's prototype (minimal), you lose when creating copies of each member function.
What Crockford was speaking about in his post was using "new" directly on a function definition. In that specific case, the reference to the prototype is useless, since it is blank. In the OP's "Mammal" example, the prototype reference provides key functionality that is well worth the cost.
When I was putting this together, I kind of felt like I was writing a general article on one method of exploiting polymorphism--not necessarily the Strategy pattern specifically. Honestly, I'm still not sure.
What I do know is that JavaScript has a number of features that make OOP significantly more informal--namely dynamic typing, object literals, and first-class functions. I'm thinking of implementing more patterns in JS in the future to try and get a better grasp on this...
I think jbwyme is getting at this with his comment http://news.ycombinator.com/item?id=2680408 (specifically "Then, if needed, use a prototype to set defaults"). Using the prototype is not really necessary at all, but it adds some amount of formality to what is otherwise a ragtag collection of objects.