←back to thread

The programmers who live in Flatland

(blog.redplanetlabs.com)
107 points winkywooster | 3 comments | | HN request time: 0s | source
Show context
libraryofbabel ◴[] No.46182942[source]
Or 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 SICP and done most of the exercises

4) Would still choose plain old boring easy-to-read always-second-best Python for 90% of use-cases (and probably Rust for the last 10%) when building a real business in the real world.

The article could really benefit from some steel-manning. Remove the cute Flatland metaphor and it is effectively arguing that lisp/clojure haven’t been universally adopted because most programmers haven’t Seen The Light in some sort of epiphany of parentheses and macros. The truth is more nuanced.

replies(15): >>46183197 #>>46183263 #>>46183285 #>>46183303 #>>46184008 #>>46185053 #>>46185956 #>>46185986 #>>46186097 #>>46186471 #>>46186553 #>>46187246 #>>46188232 #>>46191126 #>>46192256 #
nine_k ◴[] No.46183285[source]
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 mutable state. Did Haskell fail? Hmm, let's look at Typescript and Rust.

Don't get me wrong, a Lisp is always a great and fun language, and you can write whatever DSL you might like on top of it. But the old joke that "a Lisp programmer knows the value of everything, and the cost of nothing" still has quite a bit of truth to it.

replies(6): >>46183848 #>>46184089 #>>46185450 #>>46190920 #>>46191441 #>>46192905 #
wrs ◴[] No.46183848[source]
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.
replies(2): >>46184043 #>>46184471 #
nine_k ◴[] No.46184471[source]
Well, Typed Clojure is a thing!

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.

replies(2): >>46184582 #>>46192976 #
wrs ◴[] No.46184582[source]
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).
replies(1): >>46184940 #
1. nine_k ◴[] No.46184940[source]
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.
replies(2): >>46185078 #>>46192432 #
2. andersmurphy ◴[] No.46185078[source]
Right the same way the type checker should check the type checker.
3. Xmd5a ◴[] No.46192432[source]
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.

https://cybercat.institute/2024/09/12/bidirectional-programm...