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).
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.
It's starting with the exception before you even had a chance to understand the rule.
> 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.
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.
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.
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.
Doing a fix, like playing music well at all, takes copious practice.
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.
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.
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.
Insert mandatory observation here that LISP was there decades ago. I don't know about SLIME in Emacs, but if you use SLIMV in Vim, you have a keyboard shortcut for MACROEXPAND already there.
- 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).
I want it because LLMs make it easy to do without having to think.
It's certainly the weakest argument I have seen today
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.
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 :)
[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
[7]: http://goshdarnblocksyntax.com (https didn't work for me)
I guess this will become the frontline of the upcoming civil war in programming-land...