Hacker Newsnew | past | comments | ask | show | jobs | submit | dominicrose's commentslogin

reminds me of top age of empires II players making tons of clics per minute the game appears so smooth when watching it as a spectator (without seeing the player's mouse and clicks but only the units moving)

The article's definition: "A thick desire is one that changes you in the process of pursuing it."

This definition is compatible with watching some films and not others. I think Alan Watts said something like that his job was that you no longer needed him. This implies that consuming his work would be thick until it wouldn't.


As if we needed another reason not to buy junk food. By the way, in France we have a 5.5% VAT on food, instead of 20% for other products. Junk food is also 5.5% but cat food is 20%. I wonder if this is going to change some day for junk food or sodas.

I like repeating something someone else created until I master it. Playing just a little bit better after every attempt is motivating, playing well after training is also motivating.

Creating is not motivating because I compare myself to others. You have to feel that you could do something unique enough or good enough to be motivated.

Electric guitar can be really fun but I always end up playing the piano because it's easier. The keys are in order in front of you, not arranged in weird ways on strings.


Yes the expert brain anticipates and thus can be more relaxed. Music doesn't sound good until it's effortless, because trying hard is hearable.

> The types exist whether you write them down or not

That's easy to say when we're talking about primitive arguments in private functions, or primitive local variables, but let's not ignore the fact that it takes much more work to write a C# program than a Ruby program for instance.

We can see that by looking at a vanillajs library's typescript typings that were created after the js library when typescript didn't exist. The types are insanely complex and if you get one type wrong you can break compilation of some library user's program (its happened to me).

That being said I'm aware that dynamic programming languages are a "use at your own risk" type of language.


are dynamic languages really a "use at your own risk" ? or it's about changing frame of mind ?

my take is if you treat your program as a series of data flows - then use primitives such as maps | arrays - then you don't need as much typing or typing at all. a map doesn't need to take a shape or a Person | Manager - either the keys exist or they don't and almost every language has guards to ensure you can safely navigate existence of keys.

but then again my realm is mostly around - web | data systems - if I was dealing with OS level systems and needed to make sure i have i64 ints then yeah typing would be crucial.


Well we take risks in either direction. The risk of using Java is becoming bored to death and having delays. The risk of PHP is that you know bugs are going to happen in production, even if you have something like Sentry to monitor them, even if they're not critical bugs.

I've used Clojure/Script in the past and it's good to enforce working with immutable data.

Immutable.js has similar data structures but it's not the standard way of doing things and uglier to debug.

Using standard objects, immutability is not enforced in JS and throwing a few Object.freeze calls won't change that so we lose half the benefits that Clojure would bring: parallel/concurrent programming benefits, easier deep equality checks, performance...

If the code is not performance sensitive and can run in a single thread, simply "not mutating some of the mutable data" is a start for someone interested in immutability. That's what ramdajs does, it doesn't invent new data structures or freeze objects but simply returns new ones.

Only a few functions from ramdajs are actually useful in 2025 since JS has evolved with things like array/object destructuring and "..." but in any case it's an inspiring library.


I've used these things. IME, nowadays it's not worth the bundle size to bring in these libraries. map/filter seems quite optimized, {...obj} is fast since its only shallow. Yes it does come down to practices vs better libraries, but in practice, it's fine IME

One thing to note, i was very excited that we have a bunch of lazy methods on Iterator protocol, but they are slow as shit as of earlier this year.

I wrote a parser a year ago with extreme use of .map (every step of processing was cloning the tokens), and i thought, let's migrate it to lazy iterator - it got ~10x slower :(. The compile time was fine for my use cases, so i didn't give immutable-js a try, but it was a surprise

I did some benchmarks on map+filter vs mutable for of + push, and on firefox up to 200-300 elements map+filter is actually faster (unforunately not on chrome).

Of course, its not the best, but my experience is that modern js engines are fast enough for most use cases to not have to bring in any libraries anymore


I think the goal of lazy iterations is to make less iterations, not to make iterations themselves faster.

> Governments have typically expected efficiency gains to lower resource consumption, rather than anticipating possible increases due to the Jevons paradox

I think that it's true that governments want the efficiency gains but it's false that they don't anticipate the consumption increases. Nobody is spending trillions on datacenters without knowing that demand will increase, that doesn't mean we shouldn't make them efficient.


yes and the question is do horses have 20 years or less i.e. 5 years?

Full robotic servants are very costly, only AI servants are cheap enough. But I do think we're going to see more wars and robotic use in wars.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: