HN user

jugglinmike

88 karma
Posts14
Comments21
View on HN
ai;dr 5 months ago

It also contradicts the author's earlier argument:

I need to know there was intention behind it. [...] That someone needed to articulate the chaos in their head, and wrestle it into shape.

If forced to choose, I'd use coherence as evidence of care than use it as a refutation of humanity.

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?

The real irony comes from the author's claims:

> 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. [...]"

Two points that I haven't seen covered yet:

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.

Backbone patterns 14 years ago

It's great to see knowledge like this compiled into one place. Unfortunately, it looks like the resource is only superficially open source.

I was about to make a pull request to fix a typo, when I found someone had already done so: https://github.com/rstacruz/backbone-patterns/pull/3

If a objective correction like this takes 6 weeks (and counting!) to be merged, does the open nature of this page really matter?

Not that this detracts from the message, but take the claim "This is a massive work-in-progress." with a grain of salt.

> 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/

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.

I can't say I completely disagree.

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.

Good point! I don't have much experience with animation libraries, but maybe if I look at some source code I can get a stronger real-world use case for the article...