it's part of the Material Design 3 branding, for some reason. The original thread for the launch of the design system [1] is full of people baffled by Google making a cursor that lags

[1]: https://news.ycombinator.com/item?id=43975352

Look at all the rubes who can't understand that a lagging mouse cursor is an integral part of Google's Molasses-Forward Design Language Initiative.

I just checked Material Design 3, as I use a lot of it in projects, and it still uses Roboto font for everything, so they're not even dogfooding the Sans font there yet, but they'll make us suffer their cursor :)

there was definitely a time when iOS App Store did not have ads

you know, there are two hard problems in computer science...

For today's lucky ten thousand, the joke is that

> There are only two hard things in Computer Science: cache invalidation, naming things, off-by-one errors.

I thought there were 3 difficult problems: naming things, cache invalidation, , and off by one errors. concurrency

the concurrency twist got a laugh out of me, I've seen this joke a zillion times but never the concurrency bit

Why do people say that, when the number one hardest problem is making good abstractions?

Because it’s a “famous” (in our circles) quote. You might prefer this one:

> There’s two hard problems in computer science: We only have one joke and it's not funny.

There are at least one more joke:

"There is 10 kinds of people, those who can read binary and those who can't."

Personally I prefer the cache invalidation one.

> "There is 10 kinds of people, those who can read binary and those who can't."

I like the continuation (which requires knowledge of the original): “And those who didn’t expect this joke to be in base 3”.

Names abstract things.

You explained one thing but introduced another needing explanation.

https://xkcd.com/1053/

can you blame him? guy has a Bobcat!

in my daily experience Claude Code writes better Elixir code than JS (React). Surely this has to do with the quality of the training material

Can’t confirm or deny comparison with JS but I can second that it write decent elixir

The only problem I’ve ever had was on maybe 3 total occasions it’s added a return statement, I assume because of the syntax similarity with ruby

I’ve found Claude (at least until Opus 4) would routinely fail at writing a bash script. For example it would end an if block with }. Or get completely lost with environment variables and subshells.

But those are exactly the same mistakes most humans make when writing bash scripts, which makes them inherently flaky.

Ask it to write code in a language with types, a “logical” syntax where there are no tricky gotchas, with strict types, and a compiler which enforces those rules, and while LLMs struggle to begin with, they eventually produce code which is nearly clean and bug free. Works much better if there is an existing codebase where they can observe and learn from existing patterns.

On the other hand asking them to write JavaScript and Python, sure they fly, but they confidently implement code full of hidden bugs.

The whole “amount of training data” is completely overblown. I’ve seen code do well even with my own made up DSL. If the rules are logical and you explain the rules to it and show it existing patterns, the can mostly do alright. Conversely there is so much bad JavaScript and Python code in their training data that I struggle to get them to produce code in my style in these languages.

the Erlang vm is called BEAM, not OTP. sadly, Gleam's implementation of OTP is not at the same level as Elixir's or Erlang.

Gleam uses regular OTP, it doesn’t have a distinct OTP inspired framework. Source: I’m the author of Gleam.

I wonder why so many have got this wrong across this thread? Was it true once upon a time or something, or have people just misunderstood your docs or similar?

OTP is a very complex subject and quite unusual in its scope, and it’s not even overly clear what it even is. Even in Erlang and Elixir it’s commonly confused, so I think it’s understandable that Gleam has the same problem further still with its more distinct programming style.

hey, thanks for the clarification. I was under the impression that Gleam had a few shortcomings re: OTP, like missing APIs or the need to fall back to Erlang. Many people I know who work regularly with Elixir hold similar opinions - do you have any idea what happened there? Is there a lack of publicity for this support? Is it a documentation problem?

I presume they checked out Gleam years ago, or their investigation was more shallow.

That aside, it is normal in Elixir to use Erlang OTP directly. Neither Elixir nor Gleam provides an entirely alternative API for OTP. It is a strength that BEAM languages call each other, not a weakness.

"Big Elixir" must be paying people to misunderstand Gleam today eh ;-)

Free software was started as a political movement by Stallman et al. Why would we stop now?

> who cares, just dont shove political opinions into a software project that developers. we are devs not jobless sjw's running around the road with some useless sign board

Here we are, having a technical discussion and here you are, shoving politics into it.

They made sure it wouldn’t happen again though

in Italy we have a saying for this - "innkeeper, how is the wine?"

but that crisp shadow is exactly what we call perception

it's coming from an extremely biased source, that's why nobody else would make that claim