💾 Archived View for idiomdrottning.org › judging-a-programming-language captured on 2024-03-21 at 15:28:24. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-12-28)

-=-=-=-=-=-=-

Judging a programming language

Here is something where I have a li’l bit of hypocrisy in my own bitter heart.

I’ve got a close friend who, whenever we’re talking about programming languages, I get the impression that he only judges them by the surfacest of surface syntax features. Does the code look like the languages of old that he’s used to? Then good. Otherwise bad.

Never a look at things like type systems, generics, comptime, metaprogramming, container heterogenity, polymorphism, inference, verbosity (well—he does favor explicitness whereas I favor implicitness & good defaults), first-class functions or the first-class–ness of any other codemes, performance, code reuse, ease of factoring and refactoring, flexibility etc.

No. It’s only “I think square brackets look good”, that’s the extent of it with him.

Now to the hypcrisy part. It’s not as if I don’t have a passion for surface syntax: I love sexps and I cannot lie. If I can’t paredit it’s not my revolution. And I generally hate grawlixes and redundancy. It’s just… that’s not the only thing I look at.

A paredit pro tip

Naming philosophy (for Lisp stuff)