> 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...

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).

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.

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.

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.

Please don’t.

Either make a full DSL, like GDScript, a general purpose language, or use one of the existing languages.

For me Unity using C# has been a very essential part of my career. I can learn tricks once and reuse them.

With Godot I understand why GDScript exists and we now have a fantastic community around it. C# Godot is still iffy.

I can’t imagine anything worse than joining a company and having to catch up on their specific frankien language with all types of macros and magic.

It sucks enough when they use non standard tooling or CI/CD systems. This company shall remain nameless, but once I had to work with a shitty CI/CD that took 4 or 5 hours for deployments.

Like most comments here, I kinda throw up in my mouth thinking about all the weird DSLs that would come from unrestrained abstraction.

What about a slightly different angle: a custom language runtime? The language itself stays true to the original but you build your own custom compiler and dev tooling: an expanded stdlib, LSP, linting, formatting rules, build systems, test runners, package manger, host extension system, etc.

This is becoming somewhat of a reality in the Clojure world. https://clojure.cc/dialects/ lists ~30 languages which are recognized as "Clojure" but have radically different host environments. Of course Clojure has macros too so nothings stopping you from going overboard on the DSL weirdness.

I could see the following scenario: Your company picks Typescript. You evaluate Bun and Deno and others but nothing really works. You take the most promising one, build a little test suite to make sure it stays consistent with the language spec, fork it, and add the runtime features you need. Your dev team still writes Typescript but you have full control over the tooling and how that code works at runtime.

I think being able to define additional rules in a language is a reasonable feature and sometimes would make life a whole lot easier, but I think when implemented through text macros rather than rewriting the underlying program graph along with accounting for all the constraints, that causes most issues.

Program graph rewriting is of course more complex, but can be better defined with regards to acceptable inputs and more defensive as opposed to letting the next step of compiler or interpreter handle it.

The other problem is that most IDEs don't offer an expand macro (or similar) option for the rewritten parts (or I haven't seen them doing that), so observing what the final code looks like requires additional steps. In some ways its similar to functions, but most languages have functions that have a well defined input/output structure whereas macros can do some unexpected things depending on the inputs.

Not sure what this guy is on about. Languages with extensible syntax (through macros, through term rewriting, through intrusive function like decorators) have always been available, though notably less popular. Languages also can support extensible features through reflection: runtime inspection of structure of user-defined types.

- Any language with bicameral syntax (the lisps, etc)

- Rebol and Red

- Smalltalk, Self, etc.

People tend to not like these for most programming problems due to the eventual maintenance burden and the steep up front cost of becoming competent with them. But the title and thesis of this post is a bit of a head scratcher: we've always been able to change languages designed to be changed, and mainstream high level language no. 2, Lisp, was one such language. As always, whether or not a language supports macros or some general metaprogramming facility is a design tradeoff both for the complexity of the compiler and the implicit complexity of the codebase (knowing that the language doesn't prevent you from defining new operators with semantics that may go counter to the intuition employed in the base language).

Basic argument:

I want it because LLMs make it easy to do without having to think.

Forth is essentially built around that idea and while not a flop it also didn't exactly take the world by storm. The problem is that every Forth codebase is so extremely personalized that it only makes sense to its author.

It sounds like they are ready to give up human readability of code for a mostly untested idea macros _might_ help LLMs?

It's certainly the weakest argument I have seen today

Someone just asked for Common Lisp and Smalltalk.

My last project needed Rust for one module, but the rest was Go. Felt silly rewriting core logic just to stay unified.

Thats a hard no from me Jimmy. There was a fashion for domain specific languages about a decade ago.

It was a nightmare.

Now hand wave about LLMs means we should just go right into machine code and not bother with intermediate. That statement is also as mad as the statement about just changing the language on the fly.

The need for langauge changes arguably has disappeared, as there isn't really a need to save keystrokes. the key thing is common understanding. If you let the LLM change the fundamentals, you're ending up with a logic puzzle on top of your problem.

Moving from Java to Kotlin was a breath of fresh air; sometimes a language change genuinely unlocks productivity.

I like Objective C. I worked at Apple for a couple of decades and I still think it hits the sweet-spot between expressiveness and complexity. Just a dozen or so more keywords over C and it became so much more. It certainly helped that it came with a really good class library. However, the writing is on the wall for ObjC, it has been for a decade, and I’m not a fan of Swift. So, being retired I thought I’d look at what I could do to create something in the ObjC vein, and maybe file off some warts along the way.

Enter ‘xc’ [1]. It’s cross-platform (Windows, Mac, Linux), and can compile for (amongst others) Windows, Mac, Linux, iOS, Android and WASM. I’m slowly building out an AppKit-like UI library [2] that supports all the platforms with the same View / delegate / datasource paradigm as AppKit, and an Interface-Builder like app that lets you associate the same code core with a variety of platforms layouts {desktop, tablet, phone,}

If you know ObjC, xc will be very familiar though there’s a lot less [] - the function/method calling style is C not ObjC. It has ARC and blocks (without the god-awful block syntax [7], I use 'block' as a type), threads, a Foundation like class library (no NS prefix). It doesn’t have header files, preferring to bind C libraries by reading the DWARF data in library for types/structs/classes/methods/functions. So a ‘#use <psql>’ statement will parse libpsql.so, read out all the types and let you use them. I adopted C-style structure ordering on the target platform to make this seamless.

As far as performance, it’s pretty much on-a-par with clang, on all 64-bit targets [3]. Sometimes a bit faster (notably method/function calls), sometimes a bit slower. That’s good because it gives me a target to still optimise. It’s basically float vectorisation that is the long tail, clang vectorises in places you might not initially expect, for good reason.

In some ways, this is going from a somewhat-still-popular language to a language used by precisely 1 person (me), but the advantage of owning the compiler is the ability to effect change in an afternoon, not 6 months. It’s also rather cool to have the same classes for the web-app that talks to your back-end server, and if you implement the ‘Codable’ protocol, to be able to serialise those classes seamlessly between WASM client and native server. Using xc let me write blewit.net [4] really easily, and one of the games within blewit (Monokracy [5], a web-client rewrite of Wolfpack Empire [6]) is in-process so I'd say its undergone at least some "in anger" testing, not just the 900 or so unit-tests.

So I agree that you should be able to change our languages, though perhaps my path and the author's differs somewhat :)

[1]: https://compile-xc.org

[2]: https://compile-xc.org/compiler/api/uxkit/guide-first-window...

[3]: https://compile-xc.org/compiler/performance/

[4]: https://blewit.net/sandbox/

[5]: https://0x0000ff.co.uk/img/blewit/monokracy.png

[6]: https://www.empire.cx

[7]: http://goshdarnblocksyntax.com (https didn't work for me)

Not a single mention of Chesterton's Fence. Was this really written for HN, then?

[dead]

[dead]