[HN Gopher] The programmers who live in Flatland
___________________________________________________________________
The programmers who live in Flatland
Author : winkywooster
Score : 67 points
Date : 2025-11-27 15:44 UTC (10 days ago)
(HTM) web link (blog.redplanetlabs.com)
(TXT) w3m dump (blog.redplanetlabs.com)
| parpfish wrote:
| it'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
| 1313ed01 wrote:
| 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.
| joeevans1000 wrote:
| Ditto.
| nathan_compton wrote:
| 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).
| Sophira wrote:
| This, exactly.
|
| I had heard before that Lisp had something called "macros", but
| I didn't know exactly what they were or how they differed from
| C macros. This blog post _kind of_ explains that, but not in a
| way that couldn 't also apply to C macros if you tried hard
| enough.
|
| I want to know more, but I didn't have any examples here to
| look at. I may look them up now that I have an idea.
| joeevans1000 wrote:
| This is too high level, but I found this:
|
| https://blog.redplanetlabs.com/2025/04/22/how-gd-netcetera-u...
| joeevans1000 wrote:
| Hmmm... this might be a way:
|
| "You can get in touch with us at consult@redplanetlabs.com to
| schedule a free consultation to talk about your application
| and/or pair program on it. Rama is free for production
| clusters for up to two nodes and can be downloaded at this
| page."
| somethingsome wrote:
| Let say.. I remember quite well when I learned Lisp, and
| differently to any other language I learned, it gave me
| profound insights and even more profound frustration trying to
| understand some concepts.
|
| I remember playing with call with cc, or creating a flow
| programming language, thinking in higher order, etc..
|
| I clearly do not want to work with lisp, and many of those
| concepts can be used in other languages without too much effort
| now (lambdas, map, filter, reduce,... Among the most common and
| useful).
|
| I think learning lisp is nice as it helps explore interesting
| areas of programming on a mental level. I can't stress enough
| how it can wrap your mind sometimes.
|
| Will it help you program faster and bug free? Probably not,
| will it improve your mental model of programming languages,
| probably. Will you enjoy learning abstract things, if you like
| solving math puzzles, probably, otherwise probably not.
|
| It's hard to express the 'powers' it gives you, it's like
| spending much time thinking about simple things that usually
| you just use without thinking about.
|
| As a crude example, the scope of a variable shared between two
| lambda function that is not shared with the global space.
|
| Sorry that I don't have a specific example in mind, I feel like
| the 'power' is just spending enough time thinking on complex
| things.
| ModernMech wrote:
| Alan Kay said something similar back in the 90s, framing it as
| ants living on the "pink plane" and the "blue plane". What he
| said at the time was an ant crawling on the pink plane can do a
| lot of pink plane things, but he won't think about the kinds of
| things he can do on the orthogonal blue plane, because he's never
| been there so he doesn't have those thoughts. Innovation in PLs
| comes when someone from the pink plane travels to the blue plane
| and brings back all they have seen, which causes people in the
| pink plane to start thinking new (bluer) thoughts.
| I'm going to use a metaphor for this talk which is drawn from a
| wonderful book called The Act of Creation by Arthur Koestler.
| Koestler was a novelist who became a cognitive scientist in his
| later years. One of the great books he wrote was about what might
| creativity be.--Learning.--He realized that learning, of course,
| is an act of creation itself, because something happens in you
| that wasn't there before. He used a metaphor of thoughts as ants
| crawling on a plane. In this case it's a pink plane, and there's
| a lot of things you can do on a pink plane. You can have goals.
| You can choose directions. You can move along. But you're
| basically in the pink context. It means that progress, in a fixed
| context, is almost always a form of optimization, because if
| you're actually coming up with something new, it wouldn't have
| been part of the rules or the context for what the pink plane is
| all about. Creative acts, generally, are ones that don't stay in
| the same context that they're in. He says, every once in a while,
| even though you have been taught carefully by parents and by
| school for many years, you have a blue idea. Maybe when you're
| taking a shower. Maybe when you're out jogging. Maybe when you're
| resting in an unguarded moment, suddenly, that thing that you
| were puzzling about, wondering about, looking at, appears to you
| in a completely different light, as though it were something
| else.
|
| https://tinlizzie.org/IA/index.php/Alan_Kay_at_OOPSLA_1997:_...
| libraryofbabel wrote:
| 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.
| wrs wrote:
| 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.
| AlotOfReading wrote:
| The reality of modern software development is that most people
| focus on languages they use for work, and developers are
| statistically likely to be employed at companies with large
| numbers of other developers.
|
| The technical merits of languages just aren't relevant to
| choosing them for most developers, unless they're helping solve
| a people problem.
|
| "Artisanal" languages like Lisp, and Forth can be fantastic at
| solving problems elegantly, but that's not the most important
| thing to optimize for in big organizations where a large
| portion of your time is spent reading code written by people
| you've never met who may not have known what they were doing.
|
| Many of the tools that come from big tech are designed to ease
| the challenges of organizational scale. Golang enforces uniform
| styles so that you don't have idiosyncratic teams doing their
| own things. Bazel is a largely language agnostic build system,
| with amazing build farm support. Apple and Google have both
| contributed heavily to sanitizers and standard library
| hardening in order to detect/eliminate issues without reading
| the code. Facebook has poured vast resources into automatic
| static analysis. AWS built an entire organization around
| treating all their internal interfaces the same as external
| ones.
| ModernMech wrote:
| > "Artisanal" languages like Lisp, and Forth can be fantastic
| at solving problems elegantly, but that's not the most
| important thing to optimize for in big organizations ... Many
| of the tools that come from big tech are designed to ease the
| challenges of organizational scale.
|
| I think the field of programming languages has grown enough
| that we have to start acknowledging the future of programming
| largely won't be in the context of what it means for devs
| working at large corporations. One of my favorite talks is
| from Amy J. Ko called A Human View of Programming [1], which
| argues there are many other ways to look at programming than
| "tool for generating business activity" and "mathematical
| construct", which heretofore have been the dominant views of
| programming languages.
|
| Because there are so many other forms and purposes
| programming languages can and will take (she goes through
| them in the talk), so evaluating them and creating them
| solely on how well they are able to fit into a corporate R&D
| pipeline is a very narrow and short-term view of the field.
|
| Indeed, it's been the case for a long time now that most
| people who write programs are not in fact professional
| software developers. The most used language in the world is
| Excel, by several orders of magnitude, and it's the opposite
| of everything devs say a "proper" language must be. There's
| something we as a field still need to learn from that.
|
| [1]: https://www.youtube.com/watch?v=TjkzAls5fsI
| AlotOfReading wrote:
| As a member of the handmade community, I certainly hope
| that corporate constraints aren't the main future of the
| field. I just think it's a major part of the answer as it
| stands today.
| saltcured wrote:
| I have very mixed feelings on this topic, starting with how
| you quantify and weigh something like "most used" for a
| programming language. To me, the claim feels almost as much
| a non sequitur as saying the most used building material in
| the western world is Legos blocks or Play-Doh...
|
| Is the most used bridge-building technique a plank over a
| small culvert, or the properly engineered bridge that
| carries constant, multi-lane highway traffic for a century?
| How do we weigh the usage of resulting products into the
| usage of a design and production method? Should we consider
| the number of program users? The users X hours of usage?
|
| Fundamentally, the software field is still just so young
| and we haven't teased apart the "obvious" different domains
| and domain rules that we have for production of different
| material goods. In some sense, the domains and domain rules
| for material goods emerge out of the connection to culture,
| economic roles, health, and safety aspects. Whether it
| falls into civil engineering, building codes, transporation
| rules, consumer product safety, food and drug, ...
|
| The self-similar way that software can be composed into
| systems also makes it confusing to categorize. Imagine if
| we talked about other crafts the same way, and conflated
| textile manufacturing, clothing design, tailoring, costume
| making, wardrobe management, scripting, choreography,
| acting, and dancing as a single field that coordinates the
| visual movement of fabric on a stage.
| nine_k wrote:
| 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.
| wrs wrote:
| 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.
| teaearlgraycold wrote:
| That means little to a programmer unless they really want
| to spend thousands of hours building a type checker before
| starting a project.
| wrs wrote:
| Talk about moving the goalposts! Did you implement
| TypeScript yourself before using it?
| teaearlgraycold wrote:
| The parent comment implies that the tool does not exist
| yet.
| nine_k wrote:
| 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.
| wrs wrote:
| 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).
| nine_k wrote:
| 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.
| andersmurphy wrote:
| Right the same way the type checker should check the type
| checker.
| andersmurphy wrote:
| The big difference is Clojure is immutable by default.
| slifin wrote:
| Plenty of ways to define complex data shapes in Clojure
|
| Spec is definitely underrated here considering it's built
| into the language and has a wider scope but for most people
| they want the intellisense experience which you can get with
| clj-kondo + mailli but is not built in so most teams don't
| use it, fair enough
|
| I'd like to move the goal posts though and say I want
| flowstorm in every (any other?!) language
|
| I can just run the program and scrub backwards and forwards
| through the execution and look at all the immutable values
| frame by frame with a high level UI with plenty of
| search/autocomplete options
|
| For program understanding there's nothing better
|
| The fact I can program against the timeline of values of my
| program and create custom UI on top is crazy
|
| One of the most mind blowing demos to me was Bret Victor's
| inventing on principle and having a programmable reverse
| debugger for your language makes those demos viable
|
| I built an emulator recently for work that replays what
| happens on live locally, combined with flowstorm I can go
| line by line and tell you exactly what happened and why, no
| print statements no reruns with my own custom UI customised
| to our apps interesting parts
|
| This is my appeal to anyone outside of Clojure please build
| flowstorm for JavaScript and or Python
|
| The design of flowstorm is definitely helped by the fact that
| 95% of Clojure programs are immutable but I don't think it's
| impossible to replicate just very difficult
| ModernMech wrote:
| > 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.
|
| The talk I posted from Alan Kay is the steel man. I think
| you've missed the essence of TFA because it's not really about
| Clojure or lisp.
| libraryofbabel wrote:
| You may need to explain more? I don't think I missed the big
| idea - the metaphor of a separate plane or higher dimension
| that contains ideas not expressible in the ordinary one is a
| nice metaphor, and does apply well to some things (Kuhn's
| paradigms in history of science come to mind, e.g. Newtonian
| Mechanics versus Relativity). I just don't think it really
| applies well here. What business concepts or thoughts can you
| express in Clojure that you can't express in Python or Rust?
| xigoi wrote:
| > What business concepts or thoughts can you express in
| Clojure that you can't express in Python or Rust?
|
| If you only think about programming languages as a way to
| make money, the analogy of being stuck in Flatland is
| perfect.
| scragz wrote:
| some people only think about _life_ as a way to make
| money. unfortunately coding was best-in-slot career for
| too long and these kinds of people hijacked the culture.
| libraryofbabel wrote:
| That's a bit of an _ad feminam_ attack, isn 't it? Just
| because I used the phrase "business concepts", somehow
| money is the only thing I care about when it comes to
| language choice? And yet, in my top-level post I said I
| went and learned lisp and clojure and read SCIP, and I
| will add that I did both of those things _for fun_. So
| no, I don 't only think of programming languages as a way
| to make money. Elegance and expressiveness are
| interesting for their own sake. I trained as a
| mathematician; _of course_ I think that.
|
| But TFA was riffing on Paul Graham's old essay _Beating
| the Averages_ , which argued precisely that the
| expressiveness of Lisp gave his startup a business edge.
| That was the context of my comment. I'd add that most of
| what most of us do in our day jobs _is_ to use
| programming languages to make money, and there 's no
| shame in that at all. And if you want to talk about why
| certain languages get widespread adoption and others not,
| you have to talk about the corporate context: there is no
| way around it.
|
| But I'll rephrase my question, just for you: "what
| abstract problems can you solve or thoughts can you
| express in Clojure that you can't express in Python or
| Rust?"
| dap wrote:
| I'm sympathetic to looking down on the obsession with
| money. But there's something deep and important about the
| monetary element. Engineering is about solving real-
| world, practical problems. The cost is a real factor in
| whether a potential solution is a useful one.
|
| I think the money question is a red herring here. I'd
| phrase it more like: what problem in a _user's_ problem
| space is expressible only like this? And if the only user
| is the programmer, that's alright, but feels more aligned
| with pure academia. That's important, too! But has a much
| smaller audience than engineering at large.
| Chinjut wrote:
| Why are we limiting ourselves to business concepts?
| miohtama wrote:
| I have several decades of programming experience and would
| never choose Lisp, unless for funny one pagers.
|
| Programming language ergonomics matter and there is a reason
| why Lisp has so little adoption even after a half a century.
| logicprog wrote:
| "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."
|
| This is me to a T -- even when I'm building hobby projects. The
| point of writing any code, for me, is most of all to _see a
| certain idea to fruition_ , so I choose what will make me most
| productive getting where I want to go. And while I still
| worship at the altar of Common Lisp as an incredibly good
| language, the language matters much less than the libraries,
| ecosystem, and documentation for productivity (or even
| effective DSL style abstraction level!), so eventually I have
| had to make my peace with Python, TypeScript, and Rust.
| Terr_ wrote:
| Tacking on, part of seeing it to fruition, and continued
| lifetime, is to ensure you can communicate the intent and
| operation to a large group of potential successors and co-
| workers.
|
| An incredible epiphany that you _can 't transmit_ may not be
| as useful as a a moderately clever idea you can.
| logicprog wrote:
| Yeah that's another good point. I always hope anything I
| make can be improved or understood by others. Now, does
| that happen? No. But it'd be nice
| attila-lendvai wrote:
| yes. and as a long time lisper, i don't think that it's the
| macros.
|
| i think lisp's magic is a lot more cultural than most people
| think. i.e. how lispnicks implement lisps and the ecosystem
| around it. how easy it is to walk the entire ladder of
| abstractions from machine code to project specific DSL's. how
| pluggable its parsing pipeline is -- something that is not even
| exposed in most languages, let alone customizable.
|
| the language, the foundation, of course matters. but i think to
| a lesser extent than what people think. (hence the trend of
| trying to hire lispnicks to hard, but non-lisp positions?)
|
| and it's not even an obviously good culture... (just how
| abrasive common lispers are? need to have a thick skin if you
| ask a stupid question... or that grumpy, pervasive spirit of
| the lone wolf...?)
|
| maybe it's just a peculiar filter that gets together peculiar
| people who think and write code in peculiar ways.
|
| maybe it's not the macros, but the patterns in personality
| traits of the people who end up at lisp?
| zarzavat wrote:
| There are several languages that I could use and be
| economically successful with, but I refuse to use because I
| consider them to be poorly designed.
|
| Using a bad language for 8 hours a day makes me irritable and
| it's impossible to prevent that irritability from overflowing
| into my interactions with other people. I'd rather that my
| conversations with the computer be joyful ones.
| anthk wrote:
| Me with TCL instead of Python. TCL is the weird Unixy cousing.
| Instead of cons cells and lists, you get lists and strings.
| willrshansen wrote:
| Thought this was going to be about the new discovery of a 1d
| spaceship in conway's game of life. Stuff is nuts.
| https://conwaylife.com/book/conway_life_book.pdf
| NooneAtAll3 wrote:
| and I thought it would be about influence of spherical geometry
| for maps and stuff, and how that differs from standard
| arr[x][y]
| hashmap wrote:
| > The ability to manipulate compile-time so effortlessly is a new
| dimension of programming. This new dimension enables you to write
| fundamentally better code that you'll never be able to achieve in
| a lower dimension.
|
| Show me. Specifically, material outcomes that I will care about.
| geocar wrote:
| What do you care about?
|
| There are quite a few programmers who say lisp led to early
| retirement. That was a pretty interesting idea to me. I like
| going to the beach a lot.
|
| I am not so sure about people who don't want to get done: if
| you like doing what the ticket says instead of the other way
| around lisp probably isn't going to be something you're
| interested in.
| bccdee wrote:
| Serialization & deserialization, for instance. Macros are great
| for generating ser/de hooks automatically.
|
| Thing is, other languages do this with metaprogramming or
| explicit codegen. Everyone needs metaprogramming sometimes--
| that's why everything supports it, actually.
| johnfn wrote:
| > Many point to "ecosystems" as the barrier, an argument that's
| valid for Common Lisp but not for Clojure, which interops easily
| with one of the largest ecosystems in existence. So many
| misperceptions dominate, especially the reflexive reaction that
| the parentheses are "weird". Most importantly, you almost never
| see these perceived costs weighed against Clojure's huge
| benefits. Macros are the focus of this post, but Clojure's
| approach to state and identity is also transformative. The scale
| of the advantages of Clojure dwarfs the scale of adoption.
|
| > In that essay Paul Graham introduced the "blub paradox" as an
| explanation for this disconnect. It's a great metaphor I've
| referenced many times over the years. This post is my take on
| explaining this disconnect from another angle that complements
| the blub paradox.
|
| The blub paradox, and the author's "flatland" methaphors,
| function as thought-terminating cliches. They provide the author
| (and Lisp proponents) with a simple explanation ("Everyone else
| is stupid") that doesn't force them to reconcile with more
| difficult questions ("Is it possible that other intelligent
| people have considered Lisp and rejected it for good reasons?")
|
| And, honestly, it's just an annoying line of reasoning to hear
| that the only reason <you> don't use <favorite technology> is
| because you're just not perceptive enough.
|
| For instance, the suggestion that "ecosystem" problems are
| "misconceptions" that critics fail to reconcile seems inaccurate
| to me. Does Clojure have a package manager as simple and
| straightforward as npm/cargo? Does it have a type system as well-
| maintained as TypeScript? Does it have a UI library as good as
| (choose your favorite web UI library)? These are all ecosystem
| problems. Do you think these problems meant nothing to everyone
| who decided against Clojure? Or do they all live in Flatland?
|
| > The ability to manipulate compile-time so effortlessly is a new
| dimension of programming. This new dimension enables you to write
| fundamentally better code that you'll never be able to achieve in
| a lower dimension.
|
| There are many such "new dimensions of programming". Macros _are_
| cool, don 't get me wrong. But given the choice between a proper
| macro system or a proper type system, I know which one I'm
| choosing every time.
| wrs wrote:
| 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.
| johnfn wrote:
| 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.
| wrs wrote:
| 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?
| johnfn wrote:
| 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.
| andersmurphy wrote:
| >Does Clojure have a package manager as simple and
| straightforward as npm/cargo? Does it have a type system as
| well-maintained as TypeScript? Does it have a UI library as
| good as (choose your favorite web UI library)? These are all
| ecosystem problems.
|
| The irony is Clojure(script) has all those things. By virtue of
| being hosted on the JVM and Javacript and having first class
| interop with both. ClojureCLR even gives you access to all of
| C# etc.
|
| Being hosted was a great play in terms of ecosystem.
|
| What it doesn't have is ALGOL style syntax.
| chromaton wrote:
| Lisp 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.
| tikhonj wrote:
| > 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.
| scragz wrote:
| free market brain.
| samdoesnothing wrote:
| If something is marginally better, it's not guaranteed to win
| out because markets aren't perfectly rational. However if
| something is 10x better than its competitors it will almost
| always win.
| ruricolist wrote:
| The sketch here would be that Lisps used to be exceptionally
| resource-intensive, allowing closer-to-metal languages to
| proliferate and become the default. But nowadays even Common
| Lisp is a simple and lightweight language next to say Python or
| C++. Still it's hard to overcome the inertia of the past's
| massive investments in education in less abstraction-friendly
| languages.
| xigoi wrote:
| You're assuming that people choose languages based on merit and
| not based on how much money someone will give them for using
| them.
| philipwhiuk wrote:
| _You 're_ assuming something better on merit wouldn't make
| more money as a result, and I'm questioning the actual merits
| as a result
| attila-lendvai wrote:
| the silent assumption in both of your perspectives is that
| the current monetary system is an even playing field when
| it comes to this context (corporations and their
| programmers)
| didibus wrote:
| I take Lisp more like artisanal work. It actually requires more
| skill and attention to use, but in good hands it can let
| someone really deliver a lot quickly.
|
| That said, like in anything else, this kind of craftsmanship
| doesn't translate to monetization and scale the markets
| demands. What markets want is to lower barrier for entry,
| templatize, cheapen things, and so on.
|
| It's normal then that languages optimized for the lowest common
| denominator, with less expressive power and more hand holding
| have won in popularity in enterprise and such, where making
| money is the goal, but that Lisp remains a strong and popular
| language for the enthousiasts looking to level up their craft
| or just geek out.
| attila-lendvai wrote:
| this assumes that greatness is a single dimension, and namely,
| popularity.
| RodgerTheGreat wrote:
| A 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 misapprehension of the nature of language
| design. Languages exist within contexts, and embody tradeoffs. It
| is possible- common, even- to fully grasp the capabilities of a
| language like lisp and still find it inappropriate or undesirable
| for a given task. Pick any given context- safety-critical medical
| applications, constrained programming for microcontrollers or
| GPUs, livecoding environments where saving keystrokes is king-
| and you can find specialized languages with novel tools,
| execution models, and affordances. Perhaps it never crossed Paul
| Graham's mind that lisp itself might be a "blub" to others, in
| other situations.
|
| The idea of a linear hierarchy in languages is the true
| flatlander mindset.
| wrs wrote:
| "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?
| chihuahua wrote:
| 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
| same thing in Java/C++/Ruby/Python.
|
| In the absence of that, the entire article can be refuted by
| quoting The Big Lebowski: "Yeah, well, you know, that's just,
| like, your opinion, man."
| wrs wrote:
| 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.
| wrs wrote:
| 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.
| evdubs wrote:
| > 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
| same thing in Java/C++/Ruby/Python.
|
| Serialize and deserialize data. You're currently using
| something like XML or JSON for a human readable data
| serialization format in those languages. JSON and XML are not
| first class components of those languages. S-expressions are
| a better version of JSON and are first class components of
| Lisp.
| bccdee wrote:
| That's a bad thing, though. You should not be `eval`-ing
| your config file, much less untrusted messages.
| evdubs wrote:
| I am not so sure how it works, but you can define your
| own evaluation handler for `eval` which, I assume, can be
| as restrictive as you need if you're dealing with
| untrusted data.
| bccdee wrote:
| Seems simpler just to use `json.load`.
| didibus wrote:
| I don't think the article argues for superior solutions, but
| I understand how it can feel as such.
|
| I think it's just trying to say there's another dimension,
| the meta-level enabled by macros and Lisp's syntax that opens
| up the possibility of new solutions, which may or may not be
| better, as that's so context dependent.
|
| But what I feel it's saying is you can't even begin to
| imagine solutions that leverage this new dimension without
| learning about it and getting to grip with it mentally.
|
| In that sense, it's saying when you don't know, you can't
| even explore the space of solutions at that higher dimension,
| not necessarily that they're better for all problems.
| rented_mule wrote:
| > 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.
| tra3 wrote:
| I've been using emacs and have written a a few thousand lines of
| elisp. I like elisp. I generally like any language that I become
| proficient in. But lisp isn't some sort of magical hammer that
| turns everyone into 10x programmers.
|
| Maybe I still haven't had my epiphany, but I'm not a huge fan of
| macros in lisps and DSLs (like what ruby is known for). It makes
| code harder to understand.
|
| > Everyone knows that debugging is twice as hard as writing a
| program in the first place. So if you're as clever as you can be
| when you write it, how will you ever debug it?
| didibus wrote:
| I don't think you should use eLisp as your point of reference.
| It's the worst Lisp by far.
|
| Lisps are a continuum, and I still think there's room for new
| ones that are even better.
| GMoromisato wrote:
| Robust 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 love Lisp. I've written tiny Lisp interpreters for most of my
| games (Chron X, Transcendence) and even GridWhale started out
| with a Lisp-like language.
|
| In my experience, Lisp is great when you have a single programmer
| who understands and controls the whole source tree. Once a
| program exceeds the capacity of a single programmer, more
| conventional languages work better.
| wrs wrote:
| 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.
| GMoromisato wrote:
| 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?
| wrs wrote:
| 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...
| nathan_compton wrote:
| Big lisp guy here. Have written tens of thousands of lines of
| scheme, at least, and common lisp.
|
| But I don't get this "Lisp is so much better than everything
| else," thing. It feels very jejune to me.
|
| Most lisp programmers barely use macros and most programming
| languages these days have most of the features of Lisp that
| originally made it useful (automatic memory management, repls,
| dynamic typing*, and even meta-programming if you really want
| it).
|
| I do think that most common languages are mediocre but mediocrity
| is just how humans are.
|
| --
|
| If I had one thing I want fixed about Scheme it would be the
| dynamic typing, especially since many Schemes compile
| aggressively. Finding bugs is much harder when your apparently
| dynamic language has compiled out everything useful for
| understanding an error condition. Most of those mistakes could be
| caught at compile time.
| drivebyhooting wrote:
| 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.
| teaearlgraycold wrote:
| As 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.
| shrubble wrote:
| From the article:
|
| "Lisp/Clojure macros derive from the uniformity of the language
| to enable composing the language back on itself. Logic can be run
| at compile-time no differently than at runtime using all the same
| functions and techniques. The syntax tree of the language can be
| manipulated and transformed at will, enabling control over the
| semantics of code itself. "
|
| If you are a smaller consultancy solving hard problems, then you
| might need this.
|
| The problem sometimes is: "I don't want this level of
| complication, especially when I am going to hand it off to other
| people to maintain it."
|
| In the business world, you are not gated by your intelligence,
| but by the average IQ of the people who are going to maintain it
| over the years.
| moffkalast wrote:
| > A big chunk of our code was doing things that are very hard to
| do in other languages. The resulting software did things our
| competitors' software couldn't do.
|
| I've never seen a general purpose programming language that
| couldn't do everything the underlying hardware is capable of. It
| could only be unperformant enough that you could call it
| unfeasible at worst. What's so hard to do in languages other than
| Lisp? Spam parentheses?
| philipwhiuk wrote:
| Honestly, if you read the idiomatic factorial function and can't
| understand why no-one writes LISP I think you need a reality
| check.
|
| Nobody thinks natively in nested prefix notation.
___________________________________________________________________
(page generated 2025-12-07 23:01 UTC)