mmorearty

About the risk that vibe coding may go astray. Some irresistible quotes:

[…] Claude is a fuckin' slot machine, not a human. Every query is a pull of the lever, with potentially infinite upside or downside. It's addictive, sure. Lots of dopamine and adrenaline, and what's more, over time, your outcomes are even improving. But your slot machine doesn't "get" you. You don't have a beautiful rapport with it. You're just getting better at prompting, and getting consequently luckier with your pulls. Any bond you might perceive there is illusory.

and

Paraphrasing astronaut Frank Borman, you should be using your superior judgment (only vibe code when there's an instant Undo) to avoid having to use your superior skill (vibe coding your way out of the mess you made.)

I've had good results recently by deleting all my social media apps from my phone, BUT allowing myself to use them through Mobile Safari. And I did not bookmark them; e.g. for Instagram I type "in" and then Enter.

This gives me some friction, without having to go cold turkey. All the popular social media sites have mobile websites that are "good enough", but slightly clunkier than the apps, and also they can't send me notifications.

My phone screentime per day has dropped by about 1/3rd.

Me too; but recently I used ChatGPT to just quickly me the jq syntax I needed: https://chat.openai.com/share/40b68d73-d2dd-412d-867f-9f375e...

Shoot, you’re right. I’ll try to delete this HN submission

A joke I heard around 1988:

A young man went back to visit his old economics professor, under whom he had studied many years earlier. He took a look at the final exam the professor was preparing to give the students. He said, "Professor, this exam is identical to the one you gave us year ago!"

The professor replied, "That's okay, all the answers have changed."

From https://twitter.com/brainwane/status/1319692088758489089 :

For most of this year, @elwoz and I have been working on a pretty ambitious project:

* to make a fresh release of GNU Autoconf, a crucial #FLOSS build tool that hadn't had a new release since 2012

* to get paid for that

* to help put Autoconf on a more sustainable footing, so it doesn't have to get rescued again a little while down the road

Scons is definitely slow in some scenarios. It has O(m * n) performance if a rule has m inputs and n outputs. I tdiscovered this when working with a code base that had a single rule with all .ts files as inputs, and all .js files as outputs. As the number of files we had got bigger, SCons got painfully slow. Of course we can rewrite our rules, but that shouldn’t be necessary, especially since it was quite hard to figure out why our builds got so slow.

embrace, extend, exFAT

I stumbled across this, and it's nice. It's a very straightforward walkthrough of what happens when a small program calls open() and then read().

If you look up today's Linux source code, the code has of course evolved and is a bit more complex, but not a lot more. The nice thing about the 2001 code is that it's still dead-simple.

This American Life had a nice segment about this phone. It's one of the stories on this episode: https://www.thisamericanlife.org/597/one-last-thing-before-i...

Very interesting, thanks for posting that!

What caught my attention about this post, and the reason I'm sharing it on HN, is that even though Rust's original selling point was its "ownership" feature, I'm starting to get the feeling that there are other things about the language and its that are driving its success.

In this case, it sounds like the killer feature is easy, powerful reflection. People also seem to really like Cargo. The standard library seems to be very nice. And the language's speed is excellent (ripgrep is written in Rust).

Original source: https://twitter.com/dangerdave/status/921790333905641472

I really like your idea, lph. Reminds me of "Why Japan's Rail Workers Point at Things" https://news.ycombinator.com/item?id=14011793

My children are teens now, but I agree 100% that having children changed me in the same way that it changed you.

That is awesome. He has a lot more guts than I do. It's one thing to play a clever prank on a friend. It's quite another to play a clever prank on a casino security manager. And the secret service? Wow.

I wish Groklaw was still around to give a good analysis of this :(

I think this is extremely cool, but I'm struggling to understand the disadvantage of actors compared to channels.

I think I understand the argument; just not sure I'm convinced by it. As I see it, the argument goes like this: Suppose you want to set things up so that block "A" is sending messages to block "B". With channels, block "A" just sends a message to a channel that it was handed; it doesn't know or care what is at the other end of the channel. The higher-level code that set things up created a channel, and then passed that channel to both "A" and "B". So, everything is loosely coupled, which is great.

With actors, on the other hand (so the argument goes), you would have to create actors "A" and "B", and then send "A" a reference to "B", saying, "Hey 'A', here is the actor to which I want you to send your output." So now "A" and "B" are wired up, but there is no explicit "channel" object connecting them. I think the argument is that this is worse than channel, because there is a tightly-coupled connection between "A" and "B".

But I don't think there is. In my scenario, some higher-level object still had to create "A" and "B" and wire them up; so, they are loosely coupled.

I think it may, perhaps, be true that an actor system lends itself more readily to tight coupling than a channel system does -- in other words, an actor system might lead the casual programmer down the wrong path. Is that what Rich meant when he said of actors, "Yes, one can emulate or implement certain kinds of queues with actors (and, notably, people often do), but..." ?

If I'm missing something, I'd love to be enlightened!

Yes, sort of -- although actually the New York Times correctly labeled it an "opinion" piece rather than a book review.

I don't know much about RethinkDB yet, but I will say that I have been a big fan (online) of one of its founders, Slava Akhmechet, for years. I've never met him, but he wrote some terrific articles on his website, http://www.defmacro.org/ , a few years ago. Start at the bottom of the list of articles, with "The Nature of Lisp."

Slava is a deep thinker, which makes me very excited to take a look at RethinkDB.