Homoiconicity is overrated. Python is an acceptable lisp: higher order functions, dynamic types, generators, decorators.
If you really need syntactic transformation you can use the ast module.
The programmers who live in Flatland
41–50 of 153 posts
Re: The programmers who live in Flatland
#42Lisp has been around for 65 years (not 50 as in the author believes), and is one of the very first high-level programming languages. If it was as great as its advocates say, surely it would have taken over the world by now. But it hasn't, and advocates like PG and this article author don't understand why or take any lessons from that.
> If it was as great as its advocates say, surely it would have taken over the world by now. That is a big assumption about the way popularity contests work.
free market brain.
Re: The programmers who live in Flatland
#43it'd be nice if there was an attempt to give an example of what kind of powers moving into 3d-lispland allows instead of just saying that it's beyond the comprehension of the 2d-planar programmers. because, i guarantee that it's not beyond our comprehension. at some point the author was a 2d-er that read/did something and had their understanding expanded. so... do that for us
I agree. Especially as someone that likes LISP-like languages and uses Janet and Fennel quite a bit (and some elisp, in the past also Clojure) but never used a macro for anything. Would love to hear more about that third dimension I am missing out on.
Marcos are only very appealing to tyros. Most old salt Lispers avoid them. I would argue that a macro is only appropriate if you are adding a genuine syntactic feature to a language (one hint that this is the case is if your macro involves binding variables).
Re: The programmers who live in Flatland
#44A sadly typical flavor of essay: a lisp enthusiast who believes that learning lisp has made them into a uniquely Very Smart Boy who can think thoughts denied from programmers who use other languages. The "blub" paper asserts that there exists a linear hierarchy of goodness and expressiveness in languages, where lisp, by virtue of its shapelessness, exemplifies the pinnacle of expressiveness. This is a profound misapp…
> The idea of a linear hierarchy in languages is the true flatlander mindset.
100% this. I think you can replace "languages" in that sentence with many things (employee levels is another big one that is relevant to this forum - employee value comes in many, many shapes). Reducing complicated things to one dimension can be a useful shortcut in a pinch, but it's rarely the best way to make complicated choices among things.
Re: The programmers who live in Flatland
#45Earlier quoted context omitted.
Clojure is built on dynamic typing. This is pain. I wrote enough Python (pre-mypy), Javascript, and elisp to say this. Past certain size a dynamically typed codebase becomes needlessly hard to wrangle because of that. Hence the success of Python type annotations and Typescript. Instead, the world should have seen the light of Hindley-Milner type systems, ML-inspired languages, immutability, or at least not sharing mu…
On the other hand, it would be easier to add type checking to a Lisp than it was to Python or JavaScript, and I don’t know any technical reason you couldn’t. A little Googling shows it’s been experimented with several times.
That means little to a programmer unless they really want to spend thousands of hours building a type checker before starting a project.
Re: The programmers who live in Flatland
#46Or perhaps, just perhaps, the true higher-dimensional move is realizing that choice of programming language isn’t usually the critical factor in whether a project, system, or business succeeds or fails, and that obsessing over the One True Way is a trap. It might surprise the author to learn that there are many people who: 1) Have tried lisp and clojure 2) Liked their elegance and expressiveness 3) Have read through…
Clojure is built on dynamic typing. This is pain. I wrote enough Python (pre-mypy), Javascript, and elisp to say this. Past certain size a dynamically typed codebase becomes needlessly hard to wrangle because of that. Hence the success of Python type annotations and Typescript. Instead, the world should have seen the light of Hindley-Milner type systems, ML-inspired languages, immutability, or at least not sharing mu…
The big difference is Clojure is immutable by default.
Re: The programmers who live in Flatland
#47A sadly typical flavor of essay: a lisp enthusiast who believes that learning lisp has made them into a uniquely Very Smart Boy who can think thoughts denied from programmers who use other languages. The "blub" paper asserts that there exists a linear hierarchy of goodness and expressiveness in languages, where lisp, by virtue of its shapelessness, exemplifies the pinnacle of expressiveness. This is a profound misapp…
It would also be a lot more persuasive if the article provided even a single example of how Lisp enables superior solutions. Instead, it's just an ad-hominem attack based on the idea that non-Lisp programmers are too limited in their thinking to appreciate Lisp. Show me a convincing example of something that's simple/clear/elegant/superior in Lisp, and how difficult/complicated/ugly/impossible it would be to do the s…
The example that comes to mind immediately is that inline assembly is a Lisp macro.
You can also read anybody ranting about how great Zig comptime is if you want more contemporary examples.
Re: The programmers who live in Flatland
#48As others have said, the lack of any examples makes this post fall flat.
Also, consider that good work - particularly in art but also in engineering - requires constraints. Knowing what you cannot do adds guard rails and a base set of axioms around which you can build. Perhaps the power of LISP macros and AST manipulation is not “powerful and thus good”, but rather “too powerful and thus complicated”. Needing to write out a boring old function/class/module instead might leave you with code that is simpler to read and design around.
Re: The programmers who live in Flatland
#49Robust macros allow you to create domain-specific abstractions. That's cool, but there are plenty of other ways. Even functions are a way to create abstractions. And with anonymous functions, you can easily create higher-order abstractions. The only thing AST-level macros help with is creating custom syntax to cut down on boilerplate. That's very cool, but it comes with a cost: now you have to learn new syntax. I lov…
I’m writing a lot of Rust lately, which is rapidly becoming regarded as a conventional language, and I sure do appreciate all those things I use every day that end in exclamation points.
I'm curious here, because I don't know Rust. What's the difference between a macro and a function call from the caller's perspective? Do I (as the caller) need to know I'm calling a macro? Why?
Why is println! a macro when it's a function in almost all other languages?
Re: The programmers who live in Flatland
#50Earlier quoted context omitted.
I’m writing a lot of Rust lately, which is rapidly becoming regarded as a conventional language, and I sure do appreciate all those things I use every day that end in exclamation points.
I'm curious here, because I don't know Rust. What's the difference between a macro and a function call from the caller's perspective? Do I (as the caller) need to know I'm calling a macro? Why? Why is println! a macro when it's a function in almost all other languages?
GCC can type-check printf (matching format string to arguments) because the compiler doesn’t just treat it like a function. But that requires special-case code in the C compiler itself that is basically opaque magic.
Rust doesn’t need that, it’s mostly Rust code in the standard library, with only a small bit of compiler magic triggered by the macro. (Println! isn’t the best example because it does have that small bit of magic; most macros are just plain Rust code.)
Here’s a very impressive set of macros that I use daily. [0] This lets you do “printf logging” on an embedded device, with the human readable strings automatically pulled out into a separate section of the ELF file so the actual log stream data is tiny.
I did a similar thing for C a while ago, as a pre- and post- build step. It worked, but much less well, and was a maintenance nightmare.
Edit: and yeah, I think you do need to know you’re calling a macro, because macros aren’t limited to “normal” syntax or semantics. The ! is a signal that you’re escaping the usual bounds of the language. Like this. [1]
[0] https://defmt.ferrous-systems.com/macros
[1] https://docs.embassy.dev/embassy-stm32/git/stm32f301k6/macro...