Y'all really over indexing on the "AI"-ness of intercom. Intercom is a chat box and help pages. Those are nice to have and nice to not have to build yourself (you can build your own help pages... great, now you're managing content and have to have an admin to update the docs etc!)

People here really forgetting the notion of "core competency".

> We replaced our helpdesk with Hermes

You didn't just put a computer somewhere and have a customer go up and type on the computer right? You have surrounding infrastructure on that right? That is the value add.

https://youtu.be/HyzD8pNlpwI?t=1759

I routinely get claude to do things pretty decently and finish up easily in the 4-5 digit range of tokens. It seems to be doing the right kind of thing to not waste its time looking at 1000 files.

Unfortunate policy, and generating weird incentives to get people to leave!

In Queensland (not exactly perfectly managing the rental crisis but...) their policies include not being able to raise rent more than once every 12 months (leases tend to be 12 months). Importantly it's linked to the property, not the tenants.

There's no actual cap in practice on how much you can raise it by ("reasonable" I believe is the nonfalsifiable term used) but it doesn't generate perverse incentives to kick people out

Tbh I don't feel great about people just writing up a bunch of scripts pulling things just on every run.

Other people have linked serious box cutters for "I need to use a box cutter on 100 boxes" cases, and OLFA's small box cutter will work well for a bunch of other stuff (OLFA also has like 20 other form factors all at reasonable prices).

Even in the age of the internet there's a huge business in people basically taking a "normal" thing from another market and then rebadging it to release as an elevated thing.

Studio neat has a $231 tiny box cutter[2]. OLFA (A "professional" box cutter maker) sells a 2 pack of tiny box cutters that probably are 5x more ergonomic on account of being made to be used instead of to look nice on a website, for $10. [3]

The best version of a thing is likely whatever people who do it all day use. But you can totally make a market for consumers who want "fashionable" things but who don't really get the space.

Studio Neat is a big offender on this honestly... basically all of their stuff have "better" things at least at half the cost just available in random stationary stores. I'm all for wasting money on pens, but at least waste them on good pens!

[0]: https://teenage.engineering/products/po-80

[1]: https://hon.gakken.jp/book/1575072200

[2]: https://www.studioneat.com/products/keen

[3]: https://www.amazon.co.jp/-/en/OLFA-Compact-Knife-Pieces-95B2...

My spouse bought one on a whim. The quality is ... quite bad. It's a tool for learning about how this works though! So it was a fun little activity. But it really is "just" what it is.

Maybe Teenage Engineering's toy that looks like is exactly the same tech is better. I have my doubts.

[0]: https://hon.gakken.jp/book/1575072200

You don't want to be super duper inefficient but "no waste that has to be dumped back out" feels really big to me

I don't get how people are so comfortable with dev tooling being as busted as it is.

Is this really a Python problem? `subprocess.run` for example defaults to `shell=False` so you have to set `shell=True`, and on top of that be building up argv?

The "default" API for `subprocess.run` has you doing `subprocess.run(["ping", ip])` which... I think just entirely avoids this problem?

There's def a general sort of "oh people will just copy/paste stuff into a shell" or the whole shell script arg escaping mess. Just feels like Python is not really doing anything bad here.

The median life expectancy means you're only in the top half! But well... simply being well off means you're going to be more likely to hit above average there.

We had those early "blessed by Apple" USB-C LG monitors. Garbage when it came to connectivity. Same with docks and the like.

We're now 9 years later so... I think it's all better now than before.

I understand the sort of philosophy and ergonomics of not having an early return, but it really does hurt certain kinds of code that otherwise would be more readable

Still plenty of ads in the articles!

I've always found Rust object buildup to be pretty annoying.

JS solves this problem in two ways in the ecosystem:

- basically saying "all functions must be async" in practice

- allowing you to await a non-awaitable ("await 3" is valid)

so library authors can "force" async/await, but users don't actually have to interact with it when they don't need to. But "everything" being async/await means it's all 'basically fine' anyways

There's also the fact that JS libraries tend to be "pass in a bunch of callbacks" vs, say, Python's "override this class". It makes it much easier for libraries to have everything be async and have it really not get in the way.

Python libs tend to have much larger API surfaces due to how OOP works. So async-y internals works are harder to isolate cleanly without breaking the public API. But if you make your API "async-first" then the debugging experience in Python is miserable (try pdb'ing your way through awaitables....)

Even here though there are problems. For example, I've tried in the past to replace some lib with a more performant WASM-y thing. But it couldn't be a drop in replacement because the original library was a sync-only API, and the replacement was async!

Something very silly: you write "function add(x, y) { return x+y }". A bunch of people do things like "add(add(x, y), z)" everywhere. You find out you could make "add" "better" with async/await. You now have to get all callers to rewrite.

So what everyone does is just throw _everything_ in to the async/await pile. Which... I guess is fine but I personally dislike writing "await add(await add(x,y)), z)".

(aside: Rust's postfix await at least makes this kinda refactor less annoying)