I have to this day never seen anything remotly resembling pattern matching to what we have on the BEAM, it’s a misnomer to call it pattern matching in Rust with the perspective of the BEAM.

I have to strongly disagree here. Of course readability increases with familiarity but that doesn’t mean there isn’t significant variation in baselines. The difference is quite clear between languages that value clean, communicative apis and those that don’t, just as there is between frameworks, and code bases.

And I have had the opposite experience, of developers shutting their ears to criticism around readability/clarity because in their view only “objective” metrics like performance, or LOC, etc, matter when assessing code quality.

edit Also should say I think the point that languages having their own domains makes direct comparisons problematic, is absolutely valid, but even, or rather especially those cases illustrate the power of readability. Like many newcomers to Elixir I started with little to no knowledge of parallel computing, and although of course this made the OTP stuff more opaque than, say, the Enum module, the care put into expressing the problem the clear consistent way made it a lot easier to gain that familiarity.

As much as I love it, in my experience aesthetics have been taken to extremes in Elixir in code I’ve had to work to the point where it makes me sad. The biggest (but not only) culprit would be the pipe operator, so I don’t really blame folks from other languages for being extremely skeptical.

Exactly. This is why I dislike code formatters; the practical value is clear (“avoid syntax bikeshedding on teams”), but the cultural cost is enormous. To format your code is to give in to the idea that writing code is a mindless, industrial activity with no affordance for artistic merit.

One thing I appreciate about LLMs is that they provide great clarity here: if you think about code this way, why are you writing code at all? Anyone with this mentality is about to be displaced.

The thing is, you have to factor out the skill issue.

Take the common dichotomy of “Clean Code” (that’s a proper noun) versus “Data-oriented Design”. This is often framed as a matter of aesthetics, where the former group prefers “beautiful” code and the latter is somehow sacrificing that for performance. But in reality the loudest voices on the DoD side are indie game developers, i.e. a group with more artistic integrity and merit than basically anyone else writing software. Naturally these are people who are going to care deeply about performance and beauty because that’s what it takes.

The difference between the “Clean Code” and DoD people is that, broadly speaking, the latter group understands how computers work and the former does not. This is not a matter of artistic merit but rather a pure skill difference. I mean, just look at the demoscene; who has more artistic merit or skill than that?

Someone who writes code that does not work well, regardless of how it looks, is simply not a good programmer.

Lol, I was not arguing for anything to be more readable than the other. Quite the opposite. It was a jab at the whole notion around readability in general.