[HN Gopher] The Programming Languages Zoo
___________________________________________________________________
The Programming Languages Zoo
Author : alabhyajindal
Score : 112 points
Date : 2025-10-23 06:01 UTC (5 days ago)
(HTM) web link (plzoo.andrej.com)
(TXT) w3m dump (plzoo.andrej.com)
| bckr wrote:
| This brings up a question I've had for a while:
|
| Is it possible to create a programming language that has every
| possible feature all at once?
|
| I realize there are many features that are opposed to each other.
| Is it possible to "simply" set a flag at compile / runtime and
| otherwise support everything? How big would the language's source
| code be?
| tarwich wrote:
| I would assume not. Consider ARC vs GC. With ARC the programmer
| manages memory and with GC the compiler manages it. People
| choose one or the other because of the style they're going
| after. Could you set a flag for it. Maybe if all libraries you
| download were pre-compiled perhaps.
|
| Personally, I just prefer to know that the team that supports
| the tool I'm using is dedicated to "that one thing" I'm after.
| mpweiher wrote:
| Huh?
|
| ARC stands for _Automatic_ Reference Counting. The compiler
| manages the reference counts.
| Verdex wrote:
| They may have been thinking rust where it means atomic
| reference counting.
|
| (Although the compiler inserts ref count inc and dec calls
| automatically, so ...)
| AnimalMuppet wrote:
| You could do it. You could allocate something as garbage-
| collectible or not at allocation time. You probably would
| want them to be different types, though, so that the type
| system keeps track of whether you need to manually deallocate
| this particular thing, or whether the garbage collector will
| do so.
|
| It could be done... but I'm not sure what it would gain you.
| It seems to me that knowing that it will do one or the other
| is better than having to think about which it will do in each
| instance.
| Imustaskforhelp wrote:
| Nim language iirc can have either of arc or gc and even
| manual etc. via their Multi-paradigm Memory Management
| Strategies Source: https://nim-lang.org/1.4.0/gc.html
| muxl wrote:
| It seems that in practice no it's not possible based on what
| I've read from people much closer to programming language
| design and compiler work.
|
| "In practice, the challenge of programming language design is
| not one of expanding a well-defined frontier, it is grappling
| with a neverending list of fundamental tradeoffs between
| mutually incompatible features.
|
| Subtyping is tantalizingly useful but makes complete type
| inference incredibly difficult (and in general, provably
| impossible). Structural typing drastically reduces the burden
| of assigning a name to every uninteresting intermediate form
| but more or less precludes taking advantage of Haskell-style
| typeclasses or Rust-style traits. Dynamic dispatch
| substantially assists decoupling of software components but can
| come with a significant performance cost without a JIT. Just-
| in-time compilation can use runtime information to optimize
| code in ways that permit more flexible coding patterns, but JIT
| performance can be unpredictable, and the overhead of an
| optimizing JIT is substantial. Sophisticated metaprogramming
| systems can radically cut down on boilerplate and improve
| program concision and even readability, but they can have
| substantial runtime or compile-time overhead and tend to thwart
| automated tooling. The list goes on and on."
|
| From https://lexi-lambda.github.io/blog/2025/05/29/a-break-
| from-p...
| JoelMcCracken wrote:
| I do agree with this, but also, I don't really understand a
| lot of the tradeoffs, or at least to me they are false
| tradeoffs.
|
| Her first example is excellent. In Haskell, we have global
| type inference, but we've found it to be impractical. So, by
| far the best practice is not to use it; at the very least,
| all top-level items should have type annotations.
|
| the second one, structural typing: have your language support
| both structural types and nominal types, then? This is
| basically analogous to how haskell solved this problem: add
| type roles. Nominal types can't convert to one another,
| whereas structural types can. Not that Haskell is the paragon
| of language-well-designed-ness, but... There might be some
| other part of this I'm missing, but given the obviousness of
| this solution, and the fact that I haven't seen it mentioned,
| it is just striking.
|
| on dynamic dispatch: allow it to be customized by the user -
| this is done today in many cases! Problem solved. Plus with a
| global optimizing compiler, if you can deal with big
| executable size, you have cake and eat cake.
|
| on JIT: Yes, JIT can take some time, it is not free. JIT can
| make sense even in languages that are AOT compiled, in
| general it optimizes code based upon use patterns. If AOT
| loop unrolling makes sense in C, then I certainly think
| runtime optimization of fully AOT compiled code must be
| advantageous too. But, today, you can just about always
| figure that you can get yourself a core to do this kind of
| thing on, we just have so many of them available and don't
| have the tools to easily saturate them. Or, even if you do
| today with N cores, you probably won't be able to on the next
| gen, when you have N+M cores. Sure, there's gonna have to be
| some overhead when switching out the code, but I really don't
| think that's where the mentioned overhead comes from.
|
| Metaprogramming systems are another great example: Yes, if we
| keep them the way they are today, at the _very least_ we're
| saying that we need some kind of LSP availability to make
| them reasonable for tooling to interact with. Except, guess
| what, all languages nowadays of any reasonable community size
| will need LSP. Beyond that, there are lots of other ways to
| think about metaprogramming other than just the macros we
| commonly have today.
|
| I get her feeling, balancing all of this is hard. One think
| you can't really get away from here is that all of this
| increases language, compiler, and runtime complexity, which
| makes things much harder to do.
|
| But I think that's the real tradeoff here: implementation
| complexity. The more you address these tradeoffs, the more
| complexity you add to your system, and the harder the whole
| thing is to think about and work on. The more constructs you
| add to the semantics of your language, the more difficult it
| is to prove the things you want about its semantics.
|
| But, that's the whole job, I guess? I think we're way beyond
| the point where a tiny compiler can pick a new set of these
| tradeoffs and make a splash in the ecosystem.
|
| Would love to have someone tell me how I'm wrong here.
| Mylloon wrote:
| Oz is maybe what you looking for
| https://en.wikipedia.org/wiki/Oz_(programming_language)
| mpweiher wrote:
| Yes, Oz is pretty cool, though I personally find the use of
| FP as the base limiting.
|
| I also highly recommend the book: https://en.wikipedia.org/wi
| ki/Concepts,_Techniques,_and_Mode...
| Razengan wrote:
| Since all languages compile to the same representation on
| silicon (give or take a few opcodes) it would have to be a
| language with customizable grammar and runtime.
|
| I for one would LOVE to make semicolons; optional and choose
| between {} braces/indentation per project/file, just like we
| can with tabs/spaces now (tabs are superior)
| BigTTYGothGF wrote:
| > Since all languages compile to the same representation on
| silicon (give or take a few opcodes)
|
| I'm not sure that this is the case.
| hansvm wrote:
| It depends how we're defining "representation", but I'd
| argue that languages are definitely more dissimilar here
| than they are they same. If you want to mix and match two
| compilation units with the semantics of different
| languages, even something as simple as a cross-language if-
| statement is going to be a hard bridge to cross, and even
| when targeting a single runtime it's easy to have a
| syntactic layer which doesn't efficiently map to that
| runtime.
|
| That said, for the first thing they asked for (different
| syntactical views on the same "substrate," where I'm
| assuming the language has one model of how its runtime
| works), that's very doable.
| BigTTYGothGF wrote:
| > compilation units
|
| Is this a universal concept?
| hansvm wrote:
| No. It's a common enough term, but the handwavy concept I
| wanted to get across is that if you have code mixing and
| matching different syntaxes then there will necessarily
| be boundaries between those. Code with one syntax (if you
| can actually mix and match runtimes as the comment author
| said they want) will behave differently from "adjacent"
| (commonly a different file or directory, but I could
| imagine multiple syntaxes within a file too) code with a
| different syntax.
|
| In common languages, you're usually still targeting the
| same runtime in different compilation units, but it's a
| rough description of optimization boundaries (you compile
| one unit at a time and stitch them together during
| linking). Some techniques bridge the gap and thus the
| language crispness (e.g., post-hoc transformations on
| compiled units, leading to one larger "effective"
| compilation unit), but you can roughly think of it as
| equivalent to a whole shared library.
| the_af wrote:
| > _Is it possible to create a programming language that has
| every possible feature all at once?_
|
| Some random thoughts about this:
|
| If languages are a tool of communication between programmers
| (there's that adage "primarily for humans to read, and only
| secondarily for computers to run") would this be a good idea?
|
| Wouldn't each set of flags effectively define a _different_
| language? With a combinatorial explosion of flags.
|
| An act of design is not only about what to include, but what to
| leave out. Some features do not interact well with others,
| which is why tradeoffs exist. You'd have to enforce
| restrictions on which flags can be used together.
|
| You'd be designing a family of programming languages rather
| than a single language. Finding code in this language would
| tell you little, until you understood the specific flags.
| mpweiher wrote:
| All at once? Unlikely.
|
| However, can a lot more "features", or better, "programming
| paradigms" or as I would call them "architectural styles" be
| accommodated together, usefully?
|
| Absolutely yes!
|
| Objective-S does this using a combination of two basic
| techniques:
|
| 1. A language defined by a metaobject protocol
|
| 2. This metaobject protocol being organized on software
| architectural principles
|
| (1) makes it possible to create a variable programming
| language. (2) widens the scope of that variability to encompass
| pretty much all of programming.
|
| What was surprising is how little actual language mechanism was
| required to make this happen, and how far that little bit of
| mechanism goes. Eye-opening!
|
| Site for the language:
|
| https://objective.st
|
| However, the site doesn't really have the explanation of how
| 1+2 work and work together. That is explained as best I could
| manage within the space limitation of an academic paper in
| _Beyond Procedure Calls as Component Glue: Connectors Deserve
| Metaclass Status_.
|
| https://2024.splashcon.org/details/splash-2024-Onward-papers...
|
| ACM Digital Library (open access):
|
| https://dl.acm.org/doi/10.1145/3689492.3690052
|
| Alas, the PhD thesis that goes into more detail is still in the
| works (getting close, though!). That still being in the works
| also means that the site will not be updated with that
| information for a bit. Priorities...
| ModernMech wrote:
| Yes, it's called C++.
|
| Seriously tho, not really because programming languages are
| _designed_ , and design is all about carefully balancing
| tradeoffs. It starts with the purpose of the language -- what's
| it for and who will be using it? From there, features follow
| function. Having all the features is counterproductive because
| some features are only good in the absence of others, others
| are mutually exclusive. For example, being 1-indexed or
| 0-indexed. You can't be both, unless it's configurable (and
| that just causes bugs as Julia found out).
|
| If you want your language to be infinitely configurable to meet
| the needs of everyone, then you would want it to be as _small_
| as possible, not big. Something like Lisp.
| jpfromlondon wrote:
| Academically the answer is obviously yes since they are all
| abstractions on the same instruction set.
| humanfromearth9 wrote:
| Can't you program everything with C? If yes, doesn't C have all
| features all at once?
| alabhyajindal wrote:
| Posted this because I love how concise the implementations are.
| Might be a combination of using OCaml plus lexical and parser
| generators.
| ontouchstart wrote:
| Programming languages are more a UI problem than a mathematical
| problem. Not sure how it will evolve if coding agents are
| becoming the "middlemen".
| satiated_grue wrote:
| What might a programming language designed specifically as a UI
| for coding agents look like?
|
| Serious (germ of a) question.
| pona-a wrote:
| If true ASI ever materializes, JVM bytecode.
| KerrAvon wrote:
| This is the correct answer. Why wouldn't an actual AI just
| generate raw, fully optimized executables for production?
| Timwi wrote:
| You're contradicting yourself. Raw, fully optimized
| executables for production would mean machine code for
| the target platform, not an intermediate bytecode that
| still requires a VM.
| hagbard_c wrote:
| Not really, it would be one of the steps in the chain
| between design and implementation for a specific hardware
| platform. That is, unless that code is only ever to run
| on a single hardware platform, a rare occurrence outside
| of embedded applications.
| Maxatar wrote:
| The same reason an actual AI wouldn't play chess by brute
| forcing every possible position. Intelligent systems are
| about reasoning, not simply computing, and that requires
| operating at the level of abstraction where your
| intelligence is most effective.
| bigfishrunning wrote:
| > What might a programming language designed specifically as
| a UI for coding agents look like?
|
| A bad idea, probably. LLM output needs to be reviewed very
| carefully; optimizing the language away from human review
| would probably make the process more expensive. Also, where
| would the training data in such a language come from?
| embedding-shape wrote:
| So then a programming language designed explicitly for
| coding languages would need to take human reviews into
| account, what is the most efficient and concise ways to
| express programming concepts then?
|
| In the end, we circle back to lisps, once you're used to
| it, it's as easy for humans to parse as it is for machines
| to parse it. Shame LLMs struggle with special characters.
| hansvm wrote:
| > once you're used to it
|
| > shame LLMs struggle
|
| That sounds like Stockholm syndrome more than an easy-to-
| use language.
| KerrAvon wrote:
| I don't think that would be a real issue in practice.
| Coding LLMs need to be able to cope with complicated
| expressions in many languages. If they can produce
| legitimate code for other languages, they can be taught
| to cope with s-expressions.
|
| edit: Lisp -> s-expressions
| embedding-shape wrote:
| Yeah, makes sense it sounds like that. But the crux is
| probably that most of us learned programming via Algol-
| like languages, like C or PHP, and only after decades of
| programming did we start looking into lisps.
|
| But don't take my word for it, ask the programmers around
| you for the ones who've been looking into lisps and ask
| them how they feel about it.
| swiftcoder wrote:
| Surely lisps don't have drastically more special
| characters as other languages? A few more parens, sure,
| but less curly braces, commas, semicolons, etc
|
| Also feels like making sure the tokeniser has distinct
| tokens for left/right parens would be all that is
| required to make LLMs work with them
| embedding-shape wrote:
| Don't get me wrong, they do work with lisps already, had
| plenty of success having various LLMs creating and
| managing Clojure code, so we aren't that far off.
|
| But I'm having way more "unbalanced parenthesis" errors
| than with Algol-like languages. Not sure if it's because
| of lack of training data, post-training or just needing
| special tokens in the tokenizer, but there is a notable
| difference today.
| ojkelly wrote:
| Until such a point where have agents not trained on human
| language or programming languages, I think something that's
| also really good for people as well. - one obvious way to do
| things
|
| - memory safe, thread safe, concurrency safe, cancellation
| safe
|
| - locality of reasoning, no spooky action at a distance
|
| - tests as a first class feature of the language
|
| - a quality standard library / reliable dependency ecosystem
|
| - can compile, type check, lint, run tests, in a single
| command
|
| - can reliably mock everything, either with effects or
| something else, such that again we maintain locality of
| reasoning
|
| The old saying that a complex system that works is made up of
| simple systems that work applies. A language where you can
| get the small systems working, tested, and then built upon.
| Because all of these things with towards minimising the
| context needed to iterate, and reducing the feedback loop of
| iteration.
| JoelMcCracken wrote:
| You can certainly think of them that way if you want. And,
| you'll be wrong, at least IMO, and in what seems to be the
| consensus of people who study and work on PLs.
|
| "UI" issues, while not at all unimportant, are surface level.
| Semantics are fundamental. Get the semantics of your language
| wrong, and you are stuck. Indeed, this is what happens with
| most popular languages that aren't well-considered:
|
| - lang author creates some random new lang, throws whatever
| feels like a good idea to them into the lang
|
| - lang community discover that these features interact in
| rather surprising ways, ways that keep tripping up newcomers to
| the language, and would like to change it.
|
| - lang author, having had X more years of experience now,
| identifies that changing the behavior could break user programs
| who rely on that behavior (wittingly or un-)
|
| - lang author decides to write a new, backwards-incompatible
| version, community has 20 years of turmoil before recovering
| (python3), if it ever does (perl6).
| sestep wrote:
| Speaking as an academic PL researcher: you are right that
| this math-centered view is common in the PL research
| community, but that doesn't make the opposing view "wrong".
| There is also plenty of work in the intersection of PL and
| HCI. Both perspectives are crucial, and neither field is
| intrinsically superior to the other, despite what some
| individual researchers feel.
| andai wrote:
| Well it's like asking, are the wheels more important on a
| car, or the engine?
| ModernMech wrote:
| If you haven't seen this talk, it touches on exactly this
| topic: https://medium.com/bits-and-behavior/my-
| splash-2016-keynote-... A human view of
| programming languages - Amy J. Ko In computer
| science, we usually take a technical view of programming
| languages, defining them as precise, formal ways of
| specifying a computer behavior. This view shapes much of
| the research and development that we do on programming
| languages, determining the questions we ask about them, the
| improvements we make to them, and how we teach people to
| use them. But to many people (even software engineers)
| programming languages are not purely technical things, but
| socio-technical things. In this talk, I discuss several
| alternative views of programming languages, and how these
| views can reshape how we design, evolve, and use
| programming languages in research and practice.
|
| The upshot is while the "PL as math" and "PL as tool" views
| have been well researched, if you're a researcher getting
| started in this area there is plenty of fertile ground out
| there. We might just have this view that "PL is math"
| because we've done the most work there, but there are many
| more applications of programming languages we have not
| thoroughly explored enough to say they are not just as
| important.
| sestep wrote:
| Amy is great, thank you for the link!
| ontouchstart wrote:
| We can say that the same thing about math itself. For
| example, to pure mathematicians, math is math, to
| physicists, math is a tool.
| JoelMcCracken wrote:
| Yes, "wrong" was a bit of a strong word, but do note that I
| intentionally framed it as an opinion and not as, like,
| objectively wrong.
|
| UI is still important, but I do not think it really defines
| a language.
|
| Let's say I created a new Haskell compiler, and it had the
| best error messages in the world, a hiccup-free LSP
| experience, maybe an alternative syntax format that's more
| familiar to mainstream devs. But it still has all the same
| semantics. Is that still Haskell? Why or why not?
|
| Now let's say I took whatever has the best tooling
| currently, idk what it would be, maybe TypeScript, but gave
| it say non-strict semantics. Is that still typescript?
| seanmcdirmid wrote:
| If you consider the programming experience/UI to be the
| language along with the tools that support that language,
| then you don't need to concern yourself if using Haskell
| in vim is the same thing as using Haskell in an IDE that
| supports it really well, they aren't the same thing.
|
| If you take it to an extreme, like with Smalltalk, you
| wind up with languages whose environment is considered
| essential, they are basically part of the language at
| that point.
| ontouchstart wrote:
| UI can mean many things.
|
| To most people it is about IDE and development tool chains.
|
| Or we can think of it from the perspective of mapping
| programmer's mental model to the problems they want to solve.
| Interface to the Mind, so to speak.
| JoelMcCracken wrote:
| I don't disagree, but if you set it up as "ui vs math", you
| signify certain things. And based upon your comment it did
| not say "they mean how the programmers mental model maps to
| the problem". In fact I'd say that's more math like than
| not
| ontouchstart wrote:
| Interesting perspective.
|
| I have been intentionally coding with Claude in the past
| few months and I started to think about programming from
| problem solving standpoint other than generating
| artifacts that conform to whatever languages, libraries
| and frameworks I happen to use to solve the problem at
| the time.
|
| We can call this mental model or not. But it seems to be
| a different abstraction than we are talking about at PL
| level.
|
| To me, LLM is part of the interface between me and the
| solution, that is what I mean by UI.
|
| The real work is still in my head. PL language is just a
| medium.
| armchairhacker wrote:
| This is an interesting take, but I disagree.
|
| Syntax is a UI problem, but programming languages are more than
| syntax sugar for assembly. Features like Rust's borrow-checker,
| type systems, even small things like name resolution and
| async/await provide "semi-formal"* guarantees. And LLMs are no
| substitute for even semi-formal guarantees; people have spent
| lots of money and effort trying to integrate (non-NN, rule-
| based) algorithms and formal methods into LLMs, some even
| writing LLM programming languages, because they may be the key
| to fixing LLMs' accuracy problem.
|
| * Not formally defined or verified, but thoroughly defined and
| implemented via reliable algorithms. A true formal
| specification is completely unambiguous, and a true formally-
| proven implementation is completely accurate to its
| specification. A thorough language specification or reference
| (like https://tc39.es/ecma262/ or https://doc.rust-
| lang.org/nightly/reference/) is almost unambiguous, and a well-
| tested compiler or interpreter is almost always accurate,
| especially compared to LLMs.
|
| Cases where true formal guarantees matter exist but are rare.
| There are many, many cases where LLMs are too inaccurate but
| well-tested algorithms are good enough.
| sheepscreek wrote:
| Should be called: "The Exotic Programming Languages Zoo"
| pona-a wrote:
| To be fair, zoos don't usually feature the boring species, like
| insects, worms, and other tiny invertebrates.
| IAmBroom wrote:
| Good ones include an arthropod (insect+) house.
|
| Tiny invertebrates are anything but boring (although many
| bore), but too small to make good showcases.
|
| Worms aren't attractive to anyone who isn't on several
| government lists.
| kibwen wrote:
| A shame there's no little language here that demonstrates linear
| types.
| azhenley wrote:
| Brief discussions 4 years ago
| (https://news.ycombinator.com/item?id=27024804) and 7 years ago
| (https://news.ycombinator.com/item?id=18638290).
| tnlogy wrote:
| Made me think about this book
| https://webperso.info.ucl.ac.be/~pvr/book.html where the author
| creates a mini language and extends it in many different
| paradigms.
___________________________________________________________________
(page generated 2025-10-28 23:01 UTC)