We Should Be Able to Change Our Languages

We Should Be Able to Change Our Languages jimmyhmiller.com

It's time we stopped treating languages as sacred fixed objects. We need now, more than ever, languages we can change.

58 points•surprisetalk•6 days ago•36 comments•

#able #fixed #ever #stopped #treating #sacred #objects #stopped treating

36 comments

The main problem with macros (and similar language features) is that they turn every codebase into its own DSL. When done tastefully it makes the code more readable, but there's still an overhead for newcomers to the codebase - they need to learn your DSL before they can be productive.

LLMs may make this overhead less visible to you, but surely it's still there? I'd rather more of my tokens went towards solving the actual task at hand, vs figuring out a custom syntax (and re-learning it on every fresh context window).

aeonik4 days ago

I've never understood this perspective.

The patterns that macros express are still there in the codebase, usually via uncompressed repetition.

You would need to learn the pattern regardless if you used a macro or not, and a macro at least formally codifies the repetition.

Indeed, one can make bad abstractions, or messy extensions to the macro, but that's true of functions or classes just as much.

Not supporting macros seems to me as an arbitrary limitation put in place as a stop gap for a symptom with a different root cause. (I.e. removing expressive power to solve poor engineering or immature macro tooling).

It's definitely easier to mess things up with macros, but it's also easier to mess more up the higher up you go in any abstraction ladder.

Now that I'm writing this comment, the very fact that we have to distinguish a macro vs regular code feels like a design smell to me.

Functions should operate on data or code, and controlling when it applies, comp time, run time, or some JIT, should be a separate lifecycle configuration detail, or decoupled in a different manner.

sverhagen4 days ago

I'm not stoked about macros, but the overhead for newcomers to the codebase, as an argument, I find weak. There's so many things that make understanding a new (to you) codebase hard, and I'm not hearing an argument that macros stand out, there.

AlotOfReading4 days ago

An example DSL I wrote implements a prolog subset inside an imperative language (C++). Can you imagine the confusion a poor junior would have the first time they look at a file and it's all logic programming? It's hilarious, but definitely not a sledgehammer to be used lightly.

xg154 days ago

> Things have been changing drastically. There was once a point where it made sense to create suboptimal code if it meant that your team understood it better. Why? Because changes to the code provided more business value than the code itself being optimal, and if your team didn't understand it, no one could change things. But this is becoming less and less the case. If you can make code faster, better, even at the cost of readability and understandability, by you, but the AI can work with it perfectly fine, why wouldn't you?

I guess this will become the frontline of the upcoming civil war in programming-land...

flohofwoe3 days ago

I think it will be more like the various religious schisms in history. When mapping it to Christianity, I'm just not sure yet whether the AI bros will be Catholic, Protestant, or American Evangelical weirdos (currently tending towards the latter).

pie_flavor4 days ago

Rust has been a practical experiment in macros for ten years now. I think it is safe to say the results are in: macros are great, and you just needed to have a better style of macros. Making and using something like `tokio::select!` in C-style macros is miserable, but `tokio::select!` is easy to use and understand in Rust.

xg154 days ago

Still learning Rust, but I found it unfortunate that basically the first command you're introduced to, println/print is a macro.

It's starting with the exception before you even had a chance to understand the rule.

kvemkon4 days ago

And one of the very first rules is:

> by default, variables are immutable

Well, since the name is a "variable", it must by default be mutable. Otherwise it is an exception being forced to become a standard case.

tombert4 days ago

At the risk of being a bit of a douchebag, it seems like nearly every tech opinion piece I read now boils down to "things used to be hard but they aren't anymore because LLMs can understand things faster than we can, so can ignore/change fundamentals!"

I didn't really find the argument convincing the first time and I don't really find it convincing now.

That said, with regards to macros, I actually do agree that the fear against them is broadly overblown. I have seen scary terrible horrifying macro soup in Clojure, but that has generally been outlier cases. Something like core.async abuses the hell out of macros, and despite that I think it very often increases readability and understanding of the language.

smitty1e4 days ago

As long as GPS stays bullet proof, Navies are in good shape.

It's going to be a hard come-to-Beevis moment if the magic signal goes away and people have to remember celestial navigation.

Not sure you can even find a sextant on most vessels.

So too these AI services.

fragmede4 days ago

GPS service is obviously going to go down whenever World War III goes hot, so the Navy is definitely training sailors on the alternatives.

QuesnayJr4 days ago

The Navy was phasing out celestial navigation, but after some public outrage from retired naval officers they brought it back.

rgoulter4 days ago

> it seems like nearly every tech opinion piece I read now boils down to "things used to be hard but they aren't anymore because LLMs can understand things faster than we can, so can ignore/change fundamentals!"

Sure, LLM coding agents being capable doesn't mean we can ignore fundamentals.

But LLM coding agents surely adjust the cost/benefit considerations for all kinds of programming efforts.

Arranging your code in such a way that it's so complicated you need an LLM to understand it is surely silly.

Using an LLM to write a macro because you weren't going to learn how to write macros and deal with all the subtle cases? I think that's arguable.

nvme0n1p14 days ago

And even if LLMs do our thinking for us, it's still not a reason to fork the programming language you're using, unless you expect me to believe an LLM can understand `foo |> bar` but it can't understand `bar(foo(x))`. If you're not looking at the code, it doesn't matter how pretty the code is anymore.

saint-evan4 days ago

Hate the fact that when someone dreams up an article such as this [nasty word] where the central premise is that, '[SW engineering constraint] is no longer an issue anymore'... it's always because the solution is to turn off your brain and ask the LLM. It's almost similar to, 'because computers have gotten faster and memory's cheaper, we can write [nasty word] software' but this time it's, 'proper code architecture don't matter anyway because ain't gonna read it'. Jesus! I am very certain, without evidence, that even LLMs have an upper bound for the shittiest, most warped code even they can understand and explain. How sad is it that we're going from 'this engineering constraint has been solved' to 'that's [LLM provider]'s problem'. There is a finite amount of context, a finite amount of signal that can be extracted from that context, and a finite amount of inferential reliability. Give the freaking chatbot a bizzare enough monstrosity and eventually the model's explanation becomes an increasingly plausible reconstruction rather than a reliable model of the program. This is the goddamned wall these damned idiots are about to run into... Taking on debt, pushing architecture in the OPPOSITE direction of human understanding AND banking on a neutral-at-best external entity to keep doing YOUR job for (essentially) free! And what's crazy is that I'm the absolute furthest thing from an Ai-hater AND I'm a 23yo JUNIOR PROGRAMMER but these sentiments are getting ridiculous asf on both ends of the AI preference spectrum.

dwrolvink3 days ago

Couldn't agree more. I think/hope the take of OP will be in the minority, but worried that a standardized language will arise that is optimized for AI (and thus not for humans). These AI proxy people are actively working on cutting humans out of the loop, to a point where we once we start to rely on AI there is no way back; mimicking the advent of the car in America: first it was a nice optional extra but now in many places in America you can't get around without one.

owebmaster3 days ago

The fact that a 23yo junior programmer thinks like you gives me some hope

Read the full thread on Hacker News →

36 comments

Related stories