Your overall point is certainly valid, but there's no "dichotomy" there. I'd say "sidewalks are for people, not X" where X is pretty much anything that's not people (including scooters and bikes, even though there are people on them).
If those delivery drivers were parked on the sidewalk, it would be a different discussion. Or if the robots were in the bike lane, we'd be saying "bike lanes are for bikes, not robots".
My point is that you aren't simply pushing robots off the sidewalk and getting a better city. You have externalized the problem somewhere else. "Look, our streets are free of garbage", he says, dumping it all into the ocean...
It’s not clear to me there even is a “problem”. We did just fine before there were either robots or DoorDash drivers clogging up the road/sidewalk. (Admittedly DoorDash was very handy in 2020.) The problem is in allowing commercial interests to unilaterally clog public infrastructure.
But isn't this whole concept externalizing the commercial micro-transit problem onto pedestrian-only right of way? The sidewalk is the ocean in this metaphor.
It’s amazing how people are reading this to say the opposite of what it says. The end of the essay literally tells the reader they can appreciate Lisp if they just take the time to understand it, and they should make the effort. Not “if you don’t already know this, you must be stupid.”
If someone writes code based on an algorithm out of a 1985 textbook, and I tell them that they could make it go 20X faster if they learned more about processor architecture (out-of-order execution, cache coherency, NUMA, etc.) — a new dimension of programming to them — am I making an ad hominem attack?
Once I made somebody’s SQL query 100X faster by explaining what an index was. Fortunately they didn’t think I was attacking their intelligence.
I honestly don’t understand how that’s offensive. It’s just a metaphor, and a pretty good one. Why are you taking it as some kind of value judgement? Do you feel like people who don’t know something are lesser beings?
The book was originally written as a metaphor for understanding a fourth spatial dimension, and as far as I know the metaphor is generally taken as helpful, not demeaning. The flatlanders are never described in an unflattering way.
“Common, even”? Citation needed. I’ve worked closely with hundreds of developers over the years and maybe two of them made a conscious, knowledgeable choice whether to use Lisp for something.
You’re even sort of making the same point. Specialized problems need specialized tools. How do you write those specialized tools? Start from scratch, or just make a Lisp package?
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]
I think another macro, `json!()` works better as an example for that: inside the `json!()` you write something very similar to actual JSON. So when you see a `!` you know that there might be something out-of-the-ordinary following: https://docs.rs/serde_json/latest/serde_json/macro.json.html
Incidentally it also means that formatters like `rustfmt` won't apply the usual rules. For the macros that don't really deviate from ordinary Rust syntax, that can be a bit annoying.
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.
But the real strength of Lisp is in the macros, the metaprogramming system. And I suspect that typing most macros properly would be a bit less trivial than even typing of complex generic types, like lenses. Not typing a macro, and only typechecking the macroexpansion would formally work, but, usability-wise, could be on par with C++ template error reporting.
I think we (the Clojure community) quickly figured out we don't really want static typing, which is a bit evident by the low uptake of Typed Clojure.
Personally I found it to A) make it a hassle for downstream consumers since your design is suddenly impacting others, because you can "lock things down" and B) have that very same effect on your own codebase, where it becomes a lot less flexible where it needs to be flexible.
Nowadays, I just use another language if I want static types, which happens sometimes but not nearly as often to say that dynamically typed languages are "dead" or whatever.
My point was that you could implement type checking with macros, not that you could type check macros. (Though that would be cool!) As opposed to having to change the language definition first (Python) or implement an entirely new compiler (TypeScript).
Certainly you can implement the typechecker with macros, but it should also work on macros, before expansion. That is, you likely want (-> ...) typechecked as written, not (only) as expanded, and typing errors reported on the non-expanded form.
Word. This is a problem of lisps in general, they loose information as the same "thing" traverse the various meta-layers that constitute the system. A parsed expression is not tied to its string, and the expansion of the expression, provided it is a macro, is not tied to the original expression. In the same vein: you can't easily find the source code of a lambda that was compiled/interpreted.
Of course you can do all of this, but you need to build it yourself: see rewrite-clj. If you want to build a clojure debugger that is able to display or refer to code with the same indentation the programmer is dealing with in his text editor, you need to bridge the gap between clojure expressiosn and their string representation.
Anyway I concur that reversible macros would be great. Tag the output, have those tags propagate to the input by playing the macro backwards. Complex stuff really. That's a job for category theory I guess.
In reality, most people, intelligent though they may be, don’t consider and reject Lisp, so that argument doesn’t really work. I know it irritates people who actually do consider and reject Lisp, but those people don’t realize that they’re a tiny elite who are not the target of these essays.
There are plenty of reasons it might be better not to use Lisp, but very few people actually get as far as considering them.
Quite a lot of people have given Lisp a shot and determined, for one reason or another, that it doesn't work for them. Why wouldn't that be the case? There are no special forces that prevent people from giving Lisp a shot when every other popular language in the world was at one point in time was at Lisp's level of popularity, and overcome the barriers that Lisp could not.
The essay’s thesis is “most people don’t consider Lisp because they don’t know what’s different and special about it”. I think that’s unarguably the case. You equated that with “everyone else is stupid”, which is uncharitable and not at all what the essay says. Why would you even bother to write an essay if your audience is too stupid to understand what you’re saying?
Is it really that uncharitable? Yes, it's slightly hyperbolic, but I argue only slightly. Whether intended or not, the tone of the article is patronizing. Here are some examples.
> The programmers who live in Flatland
> Likewise, you cannot comprehend a new programming dimension because you don’t know how to think in that dimension
> the sphere is unable to get the square to comprehend what “up” and “down” mean.
All of this is patronizing. It implies that I am incapable of understanding the benefits of Lisp. If only I were able to lift myself out of the dull swamp I find myself in! But I am capable, and I do understand them, and I still don't like it! And I think most Lisp detractors do as well! I would argue that it is the Lisp proponents that live in Flatland - they need to understand that there's another dimension to criticisms of Lisp that aren't just "I don't like parentheses" and that there is substantive feedback to be gleaned.
> they need to understand that there's another dimension to criticisms of Lisp that aren't just "I don't like parentheses" and that there is substantive feedback to be gleaned.
I'm also somewhat reminded of the decline of Perl and how some people who love and still frequently use Perl don't really seem to even acknowledge the complaints people have about it, which seems to prove the claim about the decline being cultural. According to that kind of attitude, the lack of popularity is inexplicable, and we might actually be lucky that they're not resorting to conspiracy theories to "explain" the mismatch between their preferences and observable reality.
The Haskell motto of "avoid success at all costs" seems a lot healthier, as in, they know they might need to choose between going mainstream and getting to keep a language that suits them personally.
Lots of the Lisp advocacy also comes off as either entirely too vague, like this blog post, or stuck in the age of the `worse-is-better` talk (1989, so predates WWW and nearly all the programming languages in widespread general use). I don't care about comparisons to C, because the only places C is seriously considered for new projects these days are in places where a GC is unacceptable (and purposes Rust isn't certified for or whatever).
While what you say is true (I’ve used Lisps for 40 years and here I am writing Rust), the people who consciously make that choice are a tiny niche. There are vastly more people who don’t and can’t make that choice because they don’t have 1-3. So the empirical evidence for what’s actually critical is pretty slim.
reply