I would like to see Raku (https://raku.org) at least mentioned in the list of languages to be aware of. Why?
- Raku has built in Grammars so it is a great place to do early iteration of your parser
- Raku is objects and type classes all the way down (as explained here https://gist.github.com/raiph/849a4a9d8875542fb86df2b2eda89296 )
- RakuAST development is well advanced (use v6.e.PREVIEW) with the Slangify module to accelerate development of sub languages (Slangs)
The main idea of renaming from Perl6 to Raku was to allow this beautiful and seductive new language to escape the black hole gravity well formed by the collapse of the Perl star. Seems like Raku is stuck inside the Perl event horizon for ever, with no hope of reputational escape.
I think it was based on the misconception that the mainstream turned away from Perl because of a handful of warts and mistakes, not because Perl's unconstrained flexibility made it impractical, and that Perl "done right" could recapture the excitement and mainstream attention that Perl once enjoyed. I think they should have accepted that the existing community was already the largest subset of programmers that could embrace Perl's trade-offs, with or without the historical warts.
fwiw I think Perl was so popular in the late 90s that a transition like Python2.0 to 3.0 that traded some backward compatibility for some structure COULD have been successful. However, the Perl community also got tired of waiting such a long time for what is now Raku, and it was so different with no incremental migration path, that the lifeboat never materialized. Its not like Larry and the community didn't know that a transition was needed, but the execution was not there.
I've been playing around with interpreted variants of brainfuck for genetic programming experiments. The intended audience of the language is the evolutionary algorithm, not a human. The central goals are to minimize the size of the search space while still providing enough expressivity to avoid the Turing tarpit scenario (i.e., where we need an infeasible # of cycles to calculate a result).
I've recently found that moving from a linear memory model to a stack-based model creates a dramatic improvement in performance. The program tape is still linear, but the memory is a stack interface. It seems the search space is made prohibitively large by using pointer-based memory access. Stack based makes it a lot easier to stick arbitrary segments of programs together and have meaningful outcomes. Crossover of linear program tapes does not seem practical without constraining the memories in some way like this.
I'm curious if there if any book or blogs that detail the design decisions, or the lack of, for some popular languages, from the perspective of language design and industry usage.
I could and have written a few toy interpreters, but I have no academic or industrial background (on the matter of language design), so it is useful to know why they put some features into a language, and why they don't. It is actually one of the most confusing parts of writing an interpreter for a toy language -- in all of my projects I simply pick a subset of an existing language I know about, e.g. Python or C.
The Ada programming language has documentation about its design rationale that discusses the tradeoffs/options considered and why they made certain decisions. Really interesting even if you don’t use Ada since a lot of these decisions are made by every language’s designers.
For Python, you can read the PEP documents - Python Enhancement Proposals - and see the discussion of what was suggested, pros and cons, work done to determine the preferred implementation, and the final decision.
To get the best historical sense, pick a language feature that has evolved in several steps over a number of years, e.g. async/await, type annotations, the GIL, etc.
For ordered dicts, for instance, which is topical because of [1] posted two weeks ago, the relevant PEPs are:
- PEP372: The original collections.ordereddict proposal in Python 3.1 [2]
- PEP468: Making kwargs ordered in Python 3.6 [3], which also made standard dicts ordered.
It's pretty far back on my blog to-do list, but the key order guarantee that was solidified in 3.7 lost the opportunity for a further space optimization (for dicts where keys are frequently removed).
The Design and Evolution of C++ by Stroustrup is a fascinating book. It only covers the early years of C++, but that's perhaps what you're most interested in.
In a similar vein is this 2003 post in an MIT discussion forum by Scott McKay [1].
I'd also highly recommend that anyone interested in this kind of thing listen to all three of the Dynamic Languages Wizards Series panels from 2001: runtime [2], language design [3], and compilation [4]
Note that though these are videos, there isn't that much compelling in the visual portion, you could easily rip them to audio files and lose little.
I think you should probably start by asking yourself if you should design a new language. Most new languages fall in the bucket of low value innovation that is instant tech debt for anyone who tries to use it for real
Even the successful ones are often pointless variations on a theme. Ruby, perl & python don't all need to exist for example, as they essentially do the same thing, about as poorly. Now python has won we should just drop the others
You've assumed there's only one reason for designing a language and based your opinion around that, which makes it shallow and not terribly convincing.
Different languages excel at different things. There shouldn’t be a “one size fits all” otherwise we’d be writing software in FORTRAN and assembly.
And designing a language is a good exercise if purely from an academic perspective. Eg you learn how to write parsers, and a bunch of PL theory that we take for granted when just being a consumer of a programming language.
Not everything needs to be done with global domination in mind.
I started programming assembly in 2025 for 6592 and Z80 cpus and believe me: it is fun and IMO actually easier then lets say learning Haskell or JS from scratch.
You’re missing my point. I’m not criticising FORTRAN nor assembly. I’m saying that people wouldn’t have created C, Java, Python, Pascal, BASIC, and so on and so forth if everyone said “why bother creating a new language when we already have something perfectly good here”
The bad thing is the uncanny valley. Popular enough to fragment the niche and add tech debt, not big enough to win and defragment the niche, not innovative enough to make any real positive difference beyond personal tastes.
You know, there was an idea of a planned economy, which promised the best allocation of resources. But it didn't work in practice. What works is a chaos, when everyone does what they deem worthy to do. We can see, that the overall result is a progress, ideas are tried, rejected or accepted. But we can also see that efficiency of the process is not ideal. You talk about this non-ideals in terms of "fragmentation" and "tech debt". My point is: we can claim that costs of fragmentation and tech debt are avoidable, if we cannot propose a way to avoid them, while keeping benefits.
You think that it will be better for people to stop developing programming languages, but how do you think new programming languages will appear? Will they be better? To be better you need to try new ideas and to look how they work in practice. And very probably your ideas will fail when tested by reality. How to organize the activity to test new ideas without risks of fragmentation? We can't keep our results of developing an experimental language in secret, because then everyone will do the same, and we would need to test all ideas without any hope to learn from other's experience. U'see, the very activity of testing new ideas is almost a synonym for fragmentation.
I don't think you have any viable alternative to "every programmer should create its own programming language".
That seems like a silly reason not to do something educational.
Build something for fun. Build it for yourself. If people want to use it then they’ll use it. But more likely they won’t.
The only thing I would advise against is building something expecting other people to use it.
As I said elsewhere, not enough people these days build things for their own pleasure without any expectation nor desire for it to be used by anyone else. Sometimes just doing something for yourself is its own reward.
And it’s far more likely that DIY projects will teach skills that you can then directly contribute to established projects with, rather than DIY projects fragmenting those established communities.
This sentiment seems short-sighted and to express an unqualified value judgement. Furthermore, this seems like a presupposition that once a popular language is implemented, new idioms and features are not implemented from elsewhere as ecosystems elsewhere proliferate and prosper.
That said, I think it's okay, really, to allow people to think they are working on the next definitive thing; not because they are actually solving the "problem" of fragmentation once and for all, but rather bringing to bear the passion to see an idea to fruition. New concepts and approaches should not be considered to be inherently counterproductive or dangerous.
The only reason any programming language ever "won" in any niche is because of people who were taking a risk that their language wouldn't.
In broad terms, the spectrum of "what programming languages could look like" seems pretty well covered, yet I still have ideas that aren't represented. And then, that spectrum would still have looked pretty well covered, say for example, shortly before the dawn of Rust.
You missed his point. He's not saying "why bother why a new language if this one is fine", he's saying "why bother with a very similar language if this one is fine".
I think that's fair. Even if you are just doing a hobby language there are plenty of unexplored niches, e.g. that compile-to-shell language I've forgotten the name of.
I didn’t miss his point. Back in the 70s, many of the new languages were just a subtle variation on the previous one. It’s only later they evolved into something distinctive.
Which is why I said we’d still be using FORTRAN.
Languages that start out radically different don’t tend to gain momentum. Whereas languages that are familiar tend to grow and introduce new ideas.
Nothing is invented in a vacuum.
Also I completely disagree that one shouldn’t create a hobby project need to be innovative. Sometimes people do create things just because they can. And it’s a good thing too because otherwise we wouldn’t have half the open source software available to us today. Many of which was originally intended for personal use, including Linux.
The problem these days is we’re so brainwashed by stories of unicorn start ups pumped with VC money that now everyone thinks every hobby needs to has a viable business plan underneath. It’s like people have forgotten how to play for fun.
So people should go out and create new programming languages. The worst that would happen is they learn to be a better programmer in their day to day language.
That's nice summary of the space and how large it is. My recommendation is to just start with math expression parser and evaluator. You can start with Pratt but I would even recommend going with infix to reverse polish using stack.
Adding construct like IF or variables is naturally next step but you will have code in place and idea where to put it and how approach it.
I learned a lot about JVM runtime, how Zig is parsing itself, how Lua represents values... Too many good rabbit holes to fall in.
I believe there are far more interesting stuff to learn about these languages, like the whole category of runtimes could have been mentioned, which can directly affect the language design itself (e.g. having GC vs some language feature for managing memory, open vs closed world model, having an async feature in the language or let the runtime handle it, etc)
You're in good company. The original C++ compiler translated to C. Haskell translates to C--.
That sounds like a good approach, concentrate on the things you want to do/learn and let the C compiler pick up the rest. You can then be finished, add to your front end, or start replacing the backend.
My language compiles to Javascript. I wanted to concentrate on the frontend tasks like type checking and elaboration, and I wanted a web playground (the language is now self-hosted). Javascript got me a runtime with closures and garbage collection for free.
One day I aspire to be able to fully comprehend Cheney on the MTA. I kinda get it? But I've never learned C, and never had to slog through manual memory management, so it's a little lost on me
I’m waiting for a llm focused language. We’re already seeing AI is better with strongly typed languages. If we think about how an agent can ensure correctness as instructed by a human, as the priority, things could get interesting. Question is, will humans actually be able to make sense of it? Do we need to?
I'm pretty sure, ChatGPT could write a program in any language, which is similar enough to existing languages. So you could start by translating existing programs.
Yes. The learning comes from running tests on the program and ensuring they pass. So running as an agent. Tests and compiler give hard feedback- thats the data outside the model that it learns from.
I think modern RLHF schemes have models that train LLMs. LLMs teaching each other isn't new.
It’s basically called “reinforced learning” and it’s a common technique for machine learning.
You provide a goal as a big reward (eg test passing), and smaller rewards for any particular behaviours you want to encourage, and then leave the machine to figure out the best way to achieve those rewards through trial and error.
After a few million attempts, you generally either have a decent result, or more data around additional weights you need to apply before reiterating on the training.
Defining the goal is the easy part: as I said in my OP, the goal is unit tests passing.
It’s the other weights that are harder. You might want execution speed to be one metric. But how do you add weights to prevent cheating (eg hardcoding the results)? Or use of anti-patterns like global variables? (For example. Though one could argue that scoped variables aren’t something an AI-first language would need)
This is where the human feedback part comes into play.
It’s definitely not an easy problem. But it’s still more pragmatic than having a human curate the corpus. Particularly considering the end goal (no pun intended) is having an AI-first programming language.
I should close off by saying that I’m very skeptical that there’s any real value in an AI-first PL. so all of this is just a thought experiment rather than something I’d advocate.
With such learning your model needs to be able to provide some kind of solution or at least approximate it right off the bat. Otherwise it will keep producing random sequences of tokens and will not learn anything ever because there will be nothing in its output to reward, so no guidance.
I don’t agree it needs to provide a solution off the bat. But I do agree there is some initial weights you need to define.
With a AI-first language, I suspect the primitives to be more similar to assembly or WASM rather than something human readable like Rust or Python. So the amount of pre-training preparation would’ve a little easier since syntax errors due to parser constraints.
I’m not suggesting this would be easy though haha. I think it’s a solvable problem but that doesn’t mean it’s easy.
I've wondered about this too. What would a language look like if it were written with tokenization in mind, could you have a more dense and efficient form of encoding expressions? At the same time, the language could be more verbose and exacting because a human wouldn't bemoan reading or writing it.
Interesting page. The latest language I designed is an stack based intermediate language for a C compiler. Not realy intended for human usage, but readable in the sense that you can compare it with the original C code.
Ha! I just wrote stack based RISC cpu architecture with assembler and now thinking about implementing my own FORTH like lang (niche stack based programming language) compiler.
Nice summary, but in my experience with programming language design the macro usage issues loom large. What about base libraries, use of popular libraries, build tools, performance analysis, debugging, packaging and modularity, and so on. The core design matters and then cascades into all manner of differences.
My understanding after reading many of such posts is the following:
1) You are NOT serious (in effort to be invested, resources, knowledge), then don't do it.
2) You are MEH serious, then probably design some DLC in Lua or similar, will serve your case 99%.
3) You ARE serious, then go for it. Chances are that you might even post it here one day, but also almost no one will ever use it apart from some crazy fans.
> 1) You are NOT serious (in effort to be invested, resources, knowledge), then don't do it.
I did it while being non-serious. I got like a half of a language working. And I don't regret it. It was fun. I've got a little bored and distracted by other things, and so I've stopped working on it.
Such posts are great, because they let you pick some new ideas that will be fun to code.
> You ARE serious, then go for it.
I don't think it works this way. To become serious you need some really good idea. But to get a really good idea you need to do at least a couple of full loops through the four phases the article begins with. Before you invested a lot of time into writing languages, you are highly unlikely can get a really good idea for a new language.
What you mean with runtime context? In any case language design and implementation are distinct concepts, although they're usually running in parallel so you don't end up with a design that is unimplementable (e.g. BitC).
- this new language looks and behaves exactly like javascript, except it doesnt have "eval" and "new Function", so it is CSP safe. That's the only difference. I wanted to execute dynamically generated code in chrome extension
- llm did most of the work of creating a nearley grammar and associated interpreter (whole thing is bundled, nearley is not a final dependency), elaborate tests make this quite sane to handle
- took me about total of 1 weeks for the initial mvp to try out, and then have been fixing bugs and inconsistencies with javascript behavior, about 1 day a month of effort
- mostly 0
The only reason to create was I couldnt find something similar and it was low effort thanks to llm
I also created another even smaller DSL you can say
I once made a hacked version of javascript for work, starting with rhino. I adjusted it to make `.` and `[]` on null/undefined return undefined. Kind of like the `?.` in modern javascript, but it didn't exist back then. I was inspired by ObjectiveC's message send behavior.
The language was for some configuration in a reporting system. The scripts were written by non-engineers, and the changes made the language more user friendly for them. I started from javascript because I expected it would be easier for them to find documentation.
Nice. I built something basically just like this for work for the same reason last year. It only look a few hours though, cause I just used Acorn [0] to parse my JS, then directly evaluated the AST. It also had an iteration limit and other configurable limits so I can eval stuff in the browser without crashing the tab. I did not use an LLM.
csp safe has a particular meaning associated it with. its not a "safe" language whatever that is. chrome webstore team is okay with it and serves my purpose. if you have submitted extensions to google chrome then you would know that any sign of "eval" or new Function in the code will lead to rejection.
I want to execute dynamically generated javascript looking code in chrome extension without using eval or new function. basically eval without actually using eval.
linter would help me find and avoid usages of eval.
I think most popular languages were started as an experiment in some feature, or to solve a specific problem someone had. Those are good reasons to make a language. I see no reason to make a language just to take attention away from other existing languages. Instead, make a language so you can understand how to make languages. It is 100% doable by one person. It's fun and educational.
My idea of for fun is to release something people will use. I have more fun if I work on something useful. For me is less the journey than the end goal.
I love working on software, architecture, design but only if I see some use.
Of course, for other people, the journey is more interesting than the destination and they have fun hacking stuff just for the sake of it. They discover things and learn new stuff they wouldn't have learned otherwise. And this is a path at least as valid as the other.
1. Yes, as long as there are new machines that need programming, new programming languages will be needed. Today's top languages were built for the machines of the 1970, 80s, and 90s. Tomorrow's languages will be built for machines of today and tomorrow. As Alan Kay put it, if you want to invent a new language, first invent the machine of the future and then build a language for it.
2. No, you cannot. First of all, PL devs are cats, it's very difficult collecting them without financial compensation. So if your plan is to post a language and hope that people will come help you, you'll likely be disappointed. The problem is that everyone else interested in building PLs has their own itch to scratch, and they're not going to scratch yours without some compensation.
You might think "Well I can just raise money to do this", and you would be wrong. First, it's very hard to raise money for PLs. Usually you have to have come sort of cred to do it. I know of only 3 projects to have raised VC money for a PL project, and they each had some success before they had done so: Chris Granger (Light Table), Paul Biggar (CircleCI), and Chris Lattner (Swift/LLVM). Granger's project Eve raised $2M and ran out of money after 3 years; Biggar's project Dark also raised money, then fired all the devs when he realized he was burning cash too fast, then he slow-burned development for years, then he gave up and handed development over to someone else; and Lattner raised almost $100M for Mojo, which is probably going to end much the same way as Eve and Dark, but I wish them the best.
Anyway, the point is that you personally (no offense) don't have the profile to raise $100M like Lattner. $2M is not enough for a PL project. Lattner is keeping Mojo closed source for now because there's no good answer for how they're going to make enough money as an open source language to justify raising $100M.
And the reason it's so hard to raise money is because there's no money to be made. No one pays for PLs. No one pays for PL dev tools. They have to be open source or they're rejected by the dev community. The only ones these days who can reasonably pay for all of this with no potential revenue stream are giant corporations, who use the lang as a hook into their ecosystem.
3. Even though the answer is no, you yourself can still get an MVP off the ground in a pretty reasonable amount of time. It's never been easier to make a PL. The problem with PLs is building them is kind of like measuring the coastline; language projects are fractals -- there's an infinite amount of detail you can work on in any given direction. It's very easy for a language project to become a language + editor project, and it's easy for that to turn into language + editor + operating system if you're not disciplined. Plenty of PL devs have fallen into that trap.
4. Rounds to 0% chance. You'll be lucky if you build something that even you will use. Rather, most PL devs end up working on their language in some other language, because working on languages is what they want to do!
That said, it's still important to write languages that you understand no one will use. First it allows you to try new things that may good but unpopular. If PL devs only did what was popular with devs, PLs would go nowhere as a field.
Consider the so called "Hornet's nest" of programming languages [1], which is the tightly related cluster of imperative programming languages which have been the most researched and used over the last 50 years. There is a vaaaaaaaast design space outside that nest, begging for more language development. No one will use most of them, but it's important to understand what those languages might look like to maybe find some new ideas that work.
Also "didn't make it" is kind of an unfair judgement. Gaining popularity doesn't have to be a goal. In fact, it shouldn't be a goal if you want to have any fun at all. There's an infinite amount of work to be done, and if you're not doing it for you, you won't get far at all. That's really the only way to fail at this.
Bold plus, making PLs is a lifestyle, not a business. Most PLs clones each other and absorb features. The only difference is QOL and tooling. Users expect to have a full set of batteries, an IDE/LSP, jobs, OOP style, and minimal effort to learn. Being popular contradicts with the idea of pushing the boundaries and shifting paradigms.
> Bold plus, making PLs is a lifestyle, not a business.
Yeah, whenever I encounter a new language, to see how serious they are, I take a look at their github commit history. Usually they are all green every day, there's a sort of obsessive compulsion behind working on these projects.
It's pretty amazing how the boundary of what a PL actually is has expanded. It's really the story of "If you give a mouse a cookie"....
Used to be back in the day you didn't even have to implement the thing (ISWIM). But if you give the people a programming language they're going to expect a compiler to use it. Then devs started expecting a whole standard library sometime after the 70s. By the 80s and 90s IDEs were all the range -- you needed to provide at least syntax highlighting for sure. A breakpoint debugger was starting to become standard expectation.
In the 90s - 00s, open source rose to prominence and communities of open source developers works to create robust community-driven language ecosystems, which then became an expectation for new langs. Quite the paradox there -- how do you create a community around a new language if the new members expect a community??
But once you have a robust package ecosystem, devs start expecting ways to manage it. So now you not only need a package manager, but also a package repository and all the issues which come with that.
Now with all these packages you also need to provide a robust build system to download them all, build each one, link the binary, and it should be compatible with all major operating systems, all major architectures, and of course the web.
Today, LSPs were the most recent "must have", before "AI integration" took over and now you need to have AI assistants that know your language and all the libraries.
All that before you even start talking about the language specifics. To be popular, your language must a) be severely limited in its "weirdness budget" (the degree to which you break from tratitional languages must be a small delta or potential users complain) b) be imperative-first c) and most importantly, be open source and charge exactly $0 for all of this.
That's why the quickest way to build a new and different language is actually to create a cult around it. If you're gonna make any money at all, it'll be in selling plushies of your mascot. I wrote a whole novel about that route here a couple weeks ago. https://news.ycombinator.com/item?id=45806741
I would like to see Raku (https://raku.org) at least mentioned in the list of languages to be aware of. Why?
Here is a Raku implementation of Brainfuck to whet the appetite https://github.com/alabamenhu/PolyglotBrainfuck/blob/main/li...For some reason https://gist.github.com/raiph/849a4a9d8875542fb86df2b2eda892... wasn't a link in your comment but it was a great read
For those unaware, Raku is the evolution of Perl 6, basically. It's honestly a beautiful and seductive language. At the same time it terrifies me.
The main idea of renaming from Perl6 to Raku was to allow this beautiful and seductive new language to escape the black hole gravity well formed by the collapse of the Perl star. Seems like Raku is stuck inside the Perl event horizon for ever, with no hope of reputational escape.
I think it was based on the misconception that the mainstream turned away from Perl because of a handful of warts and mistakes, not because Perl's unconstrained flexibility made it impractical, and that Perl "done right" could recapture the excitement and mainstream attention that Perl once enjoyed. I think they should have accepted that the existing community was already the largest subset of programmers that could embrace Perl's trade-offs, with or without the historical warts.
fwiw I think Perl was so popular in the late 90s that a transition like Python2.0 to 3.0 that traded some backward compatibility for some structure COULD have been successful. However, the Perl community also got tired of waiting such a long time for what is now Raku, and it was so different with no incremental migration path, that the lifeboat never materialized. Its not like Larry and the community didn't know that a transition was needed, but the execution was not there.
Great analogy, and similar to how I saw things play out.
IIRC Perl 6 wanted to expand or morph into something better, spent a ton of time on it, and the community in general rejected it hard.
So now we have this dangling language that's shunned by its own community, regardless of its merits. Weird place to be in.
lol
Well Raku is not shunned by the very warm and welcoming Raku Community … https://raku.org/community
I've been playing around with interpreted variants of brainfuck for genetic programming experiments. The intended audience of the language is the evolutionary algorithm, not a human. The central goals are to minimize the size of the search space while still providing enough expressivity to avoid the Turing tarpit scenario (i.e., where we need an infeasible # of cycles to calculate a result).
I've recently found that moving from a linear memory model to a stack-based model creates a dramatic improvement in performance. The program tape is still linear, but the memory is a stack interface. It seems the search space is made prohibitively large by using pointer-based memory access. Stack based makes it a lot easier to stick arbitrary segments of programs together and have meaningful outcomes. Crossover of linear program tapes does not seem practical without constraining the memories in some way like this.
I'm curious if there if any book or blogs that detail the design decisions, or the lack of, for some popular languages, from the perspective of language design and industry usage.
I could and have written a few toy interpreters, but I have no academic or industrial background (on the matter of language design), so it is useful to know why they put some features into a language, and why they don't. It is actually one of the most confusing parts of writing an interpreter for a toy language -- in all of my projects I simply pick a subset of an existing language I know about, e.g. Python or C.
The Ada programming language has documentation about its design rationale that discusses the tradeoffs/options considered and why they made certain decisions. Really interesting even if you don’t use Ada since a lot of these decisions are made by every language’s designers.
[0] http://archive.adaic.com/standards/83rat/html/ratl-TOC.html
For Python, you can read the PEP documents - Python Enhancement Proposals - and see the discussion of what was suggested, pros and cons, work done to determine the preferred implementation, and the final decision.
https://peps.python.org/
To get the best historical sense, pick a language feature that has evolved in several steps over a number of years, e.g. async/await, type annotations, the GIL, etc.
For ordered dicts, for instance, which is topical because of [1] posted two weeks ago, the relevant PEPs are:
- PEP372: The original collections.ordereddict proposal in Python 3.1 [2]
- PEP468: Making kwargs ordered in Python 3.6 [3], which also made standard dicts ordered.
[1] https://news.ycombinator.com/item?id=45756058
[2] https://peps.python.org/pep-0372/
[3] https://peps.python.org/pep-0468/
It's pretty far back on my blog to-do list, but the key order guarantee that was solidified in 3.7 lost the opportunity for a further space optimization (for dicts where keys are frequently removed).
The Design and Evolution of C++ by Stroustrup is a fascinating book. It only covers the early years of C++, but that's perhaps what you're most interested in.
In a similar vein is this 2003 post in an MIT discussion forum by Scott McKay [1].
I'd also highly recommend that anyone interested in this kind of thing listen to all three of the Dynamic Languages Wizards Series panels from 2001: runtime [2], language design [3], and compilation [4]
Note that though these are videos, there isn't that much compelling in the visual portion, you could easily rip them to audio files and lose little.
[1] https://libarynth.org/fifty_questions_for_a_prospective_lang...
[2] https://www.youtube.com/watch?v=4LG-RtcSYUQ
[3] https://www.youtube.com/watch?v=agw-wlHGi0E
[4] https://www.youtube.com/watch?v=at7viw2KXak
I think you should probably start by asking yourself if you should design a new language. Most new languages fall in the bucket of low value innovation that is instant tech debt for anyone who tries to use it for real
Even the successful ones are often pointless variations on a theme. Ruby, perl & python don't all need to exist for example, as they essentially do the same thing, about as poorly. Now python has won we should just drop the others
You've assumed there's only one reason for designing a language and based your opinion around that, which makes it shallow and not terribly convincing.
Playing around and learning is great of course, as long as the language doesn't escape the lab
Terrible advice.
Different languages excel at different things. There shouldn’t be a “one size fits all” otherwise we’d be writing software in FORTRAN and assembly.
And designing a language is a good exercise if purely from an academic perspective. Eg you learn how to write parsers, and a bunch of PL theory that we take for granted when just being a consumer of a programming language.
Not everything needs to be done with global domination in mind.
FYI:
I started programming assembly in 2025 for 6592 and Z80 cpus and believe me: it is fun and IMO actually easier then lets say learning Haskell or JS from scratch.
Assemblers with macros are amazingly simple.
You’re missing my point. I’m not criticising FORTRAN nor assembly. I’m saying that people wouldn’t have created C, Java, Python, Pascal, BASIC, and so on and so forth if everyone said “why bother creating a new language when we already have something perfectly good here”
Building one for fun or to learn is great.
The bad thing is the uncanny valley. Popular enough to fragment the niche and add tech debt, not big enough to win and defragment the niche, not innovative enough to make any real positive difference beyond personal tastes.
You know, there was an idea of a planned economy, which promised the best allocation of resources. But it didn't work in practice. What works is a chaos, when everyone does what they deem worthy to do. We can see, that the overall result is a progress, ideas are tried, rejected or accepted. But we can also see that efficiency of the process is not ideal. You talk about this non-ideals in terms of "fragmentation" and "tech debt". My point is: we can claim that costs of fragmentation and tech debt are avoidable, if we cannot propose a way to avoid them, while keeping benefits.
You think that it will be better for people to stop developing programming languages, but how do you think new programming languages will appear? Will they be better? To be better you need to try new ideas and to look how they work in practice. And very probably your ideas will fail when tested by reality. How to organize the activity to test new ideas without risks of fragmentation? We can't keep our results of developing an experimental language in secret, because then everyone will do the same, and we would need to test all ideas without any hope to learn from other's experience. U'see, the very activity of testing new ideas is almost a synonym for fragmentation.
I don't think you have any viable alternative to "every programmer should create its own programming language".
That seems like a silly reason not to do something educational.
Build something for fun. Build it for yourself. If people want to use it then they’ll use it. But more likely they won’t.
The only thing I would advise against is building something expecting other people to use it.
As I said elsewhere, not enough people these days build things for their own pleasure without any expectation nor desire for it to be used by anyone else. Sometimes just doing something for yourself is its own reward.
And it’s far more likely that DIY projects will teach skills that you can then directly contribute to established projects with, rather than DIY projects fragmenting those established communities.
This sentiment seems short-sighted and to express an unqualified value judgement. Furthermore, this seems like a presupposition that once a popular language is implemented, new idioms and features are not implemented from elsewhere as ecosystems elsewhere proliferate and prosper.
That said, I think it's okay, really, to allow people to think they are working on the next definitive thing; not because they are actually solving the "problem" of fragmentation once and for all, but rather bringing to bear the passion to see an idea to fruition. New concepts and approaches should not be considered to be inherently counterproductive or dangerous.
The only reason any programming language ever "won" in any niche is because of people who were taking a risk that their language wouldn't.
In broad terms, the spectrum of "what programming languages could look like" seems pretty well covered, yet I still have ideas that aren't represented. And then, that spectrum would still have looked pretty well covered, say for example, shortly before the dawn of Rust.
What languages would you say fall into that uncanny valley?
You missed his point. He's not saying "why bother why a new language if this one is fine", he's saying "why bother with a very similar language if this one is fine".
I think that's fair. Even if you are just doing a hobby language there are plenty of unexplored niches, e.g. that compile-to-shell language I've forgotten the name of.
I didn’t miss his point. Back in the 70s, many of the new languages were just a subtle variation on the previous one. It’s only later they evolved into something distinctive.
Which is why I said we’d still be using FORTRAN.
Languages that start out radically different don’t tend to gain momentum. Whereas languages that are familiar tend to grow and introduce new ideas.
Nothing is invented in a vacuum.
Also I completely disagree that one shouldn’t create a hobby project need to be innovative. Sometimes people do create things just because they can. And it’s a good thing too because otherwise we wouldn’t have half the open source software available to us today. Many of which was originally intended for personal use, including Linux.
The problem these days is we’re so brainwashed by stories of unicorn start ups pumped with VC money that now everyone thinks every hobby needs to has a viable business plan underneath. It’s like people have forgotten how to play for fun.
So people should go out and create new programming languages. The worst that would happen is they learn to be a better programmer in their day to day language.
You should, just so you'll know how compilers and languages work. It doesn't have to be good.
Except for ruby on rails the industry pretty much has
Related. Others?
So you want to design a programming language (2017) - https://news.ycombinator.com/item?id=30481035 - Feb 2022 (58 comments)
Programming Language Design - https://news.ycombinator.com/item?id=27895124 - July 2021 (1 comment)
https://forum.rescript-lang.org/t/introducing-moonbit-and-a-... I happend to write a post sharing experience in building Rescript and MoonBit language
That's nice summary of the space and how large it is. My recommendation is to just start with math expression parser and evaluator. You can start with Pratt but I would even recommend going with infix to reverse polish using stack.
Adding construct like IF or variables is naturally next step but you will have code in place and idea where to put it and how approach it.
I learned a lot about JVM runtime, how Zig is parsing itself, how Lua represents values... Too many good rabbit holes to fall in.
I created this project with the aim of lowering the barrier to entry:
https://github.com/codr7/shi
> Java and C#, for being enterprisey
I believe there are far more interesting stuff to learn about these languages, like the whole category of runtimes could have been mentioned, which can directly affect the language design itself (e.g. having GC vs some language feature for managing memory, open vs closed world model, having an async feature in the language or let the runtime handle it, etc)
I’m pretty sure that most language designs skip the “formally” part of the cycle suggested in TFA
And that’s probably a good thing.
I started making a language, and I took many shortcuts.
I just parse my language, translate it to C, and use C compiler errors.
I don't add new semantics, I just add many things like strings, map, etc to make it usable and fast.
I don't know if it's a good idea and how difficult this will be.
You're in good company. The original C++ compiler translated to C. Haskell translates to C--.
That sounds like a good approach, concentrate on the things you want to do/learn and let the C compiler pick up the rest. You can then be finished, add to your front end, or start replacing the backend.
My language compiles to Javascript. I wanted to concentrate on the frontend tasks like type checking and elaboration, and I wanted a web playground (the language is now self-hosted). Javascript got me a runtime with closures and garbage collection for free.
I am also doing this. Like you i guess I want a nicer C. I produce my own errors though because it's better for the user.
Chicken Scheme compiles to C, using a method that ended up as a maths paper (Cheney on the MTA).
Its a valid approach.
One day I aspire to be able to fully comprehend Cheney on the MTA. I kinda get it? But I've never learned C, and never had to slog through manual memory management, so it's a little lost on me
"I don't know if it's a good idea and how difficult this will be."
It is a great idea, if you want to learn about languages!
(But if money is your goal, you may want to reconsider)
Nothing wrong with that - some others do it too. You can even use TCC to do quick test builds and only use Clang/GCC for release builds.
I’m waiting for a llm focused language. We’re already seeing AI is better with strongly typed languages. If we think about how an agent can ensure correctness as instructed by a human, as the priority, things could get interesting. Question is, will humans actually be able to make sense of it? Do we need to?
How could an LLM learn a programming language sufficiently well unless there is already a large corpus of human-written examples of that language?
I'm pretty sure, ChatGPT could write a program in any language, which is similar enough to existing languages. So you could start by translating existing programs.
LLM could generate such a corpus, right? With feedback mechanisms such as side by side tests.
So… llm learns from a corpus it has created?
Yes. The learning comes from running tests on the program and ensuring they pass. So running as an agent. Tests and compiler give hard feedback- thats the data outside the model that it learns from.
I think modern RLHF schemes have models that train LLMs. LLMs teaching each other isn't new.
My knowledge is limited, just based on a read of https://huyenchip.com/2023/05/02/rlhf.html though.
RLHF
It’s basically called “reinforced learning” and it’s a common technique for machine learning.
You provide a goal as a big reward (eg test passing), and smaller rewards for any particular behaviours you want to encourage, and then leave the machine to figure out the best way to achieve those rewards through trial and error.
After a few million attempts, you generally either have a decent result, or more data around additional weights you need to apply before reiterating on the training.
How do you define the goal? This kind of de novo neural program synthesis is a very hard problem.
Defining the goal is the easy part: as I said in my OP, the goal is unit tests passing.
It’s the other weights that are harder. You might want execution speed to be one metric. But how do you add weights to prevent cheating (eg hardcoding the results)? Or use of anti-patterns like global variables? (For example. Though one could argue that scoped variables aren’t something an AI-first language would need)
This is where the human feedback part comes into play.
It’s definitely not an easy problem. But it’s still more pragmatic than having a human curate the corpus. Particularly considering the end goal (no pun intended) is having an AI-first programming language.
I should close off by saying that I’m very skeptical that there’s any real value in an AI-first PL. so all of this is just a thought experiment rather than something I’d advocate.
With such learning your model needs to be able to provide some kind of solution or at least approximate it right off the bat. Otherwise it will keep producing random sequences of tokens and will not learn anything ever because there will be nothing in its output to reward, so no guidance.
I don’t agree it needs to provide a solution off the bat. But I do agree there is some initial weights you need to define.
With a AI-first language, I suspect the primitives to be more similar to assembly or WASM rather than something human readable like Rust or Python. So the amount of pre-training preparation would’ve a little easier since syntax errors due to parser constraints.
I’m not suggesting this would be easy though haha. I think it’s a solvable problem but that doesn’t mean it’s easy.
1. Choose set of code challenges (generate them, leetcode, AOC etc.)
2. LLM generates python solution and seperate python test (as in python test calls code as black box process so it can test non python code)
3. Agent using skills etc. tries to write new language let's call it Shark.
4. Run Shark code against test. If fails use agentic flows to correct until test passes.
5. Now have list of challenges, working code (maybe not beautiful) for training.
A bit of human spot checking may not go amiss!
I've wondered about this too. What would a language look like if it were written with tokenization in mind, could you have a more dense and efficient form of encoding expressions? At the same time, the language could be more verbose and exacting because a human wouldn't bemoan reading or writing it.
I don't know if you've seen this: https://github.com/toon-format/toon
Reading the headline my first thought was another kind of language : the linguistic language (English, Spanish, French, Esperanto etc.)
How does one create a new spoken/written language ?
Start a tribe and isolate yourself from the world for a millennium or so.
Conlangs are really cool!! You could always learned toki pona :)
Look up conlangs (constructed languages).
https://zompist.com/kit.html
https://conlang.org/resources/
Interesting page. The latest language I designed is an stack based intermediate language for a C compiler. Not realy intended for human usage, but readable in the sense that you can compare it with the original C code.
Ha! I just wrote stack based RISC cpu architecture with assembler and now thinking about implementing my own FORTH like lang (niche stack based programming language) compiler.
Fun
Great. Are you going to open source it? If so, let me know. You find my email address on my website mentioned in my profile.
Nice summary, but in my experience with programming language design the macro usage issues loom large. What about base libraries, use of popular libraries, build tools, performance analysis, debugging, packaging and modularity, and so on. The core design matters and then cascades into all manner of differences.
My understanding after reading many of such posts is the following:
1) You are NOT serious (in effort to be invested, resources, knowledge), then don't do it. 2) You are MEH serious, then probably design some DLC in Lua or similar, will serve your case 99%. 3) You ARE serious, then go for it. Chances are that you might even post it here one day, but also almost no one will ever use it apart from some crazy fans.
> 1) You are NOT serious (in effort to be invested, resources, knowledge), then don't do it.
I did it while being non-serious. I got like a half of a language working. And I don't regret it. It was fun. I've got a little bored and distracted by other things, and so I've stopped working on it.
Such posts are great, because they let you pick some new ideas that will be fun to code.
> You ARE serious, then go for it.
I don't think it works this way. To become serious you need some really good idea. But to get a really good idea you need to do at least a couple of full loops through the four phases the article begins with. Before you invested a lot of time into writing languages, you are highly unlikely can get a really good idea for a new language.
What do these languages compile to? What's the build pipeline and runtime context?
What you mean with runtime context? In any case language design and implementation are distinct concepts, although they're usually running in parallel so you don't end up with a design that is unimplementable (e.g. BitC).
No mention of INTERCAL!
PLEASE mention INTERCAL!
This talks about programming language.
Right question is to design own linguistic language common between computer and across human.
Marain
I had some thoughts about designing a new language. However it's a huge undertaking and I don't know the answers to some questions:
1. Is there a need for the programming language?
2.If the answer to the previous question is yes, can I find enough people to help and enough resources?
3. If the answer to the previous question is yes, can we release a MVPin a reasonable amount of time?
4. If the answer to the previous question is yes, what is the chance it will gather a reasonable amount of users?
There are literally tons of programming languages that didn't make it. I wouldn't want to waste my and other people resources.
I made a language for using in another project, so I'll answer your questions
https://www.npmjs.com/package/wang-lang
- this new language looks and behaves exactly like javascript, except it doesnt have "eval" and "new Function", so it is CSP safe. That's the only difference. I wanted to execute dynamically generated code in chrome extension
- llm did most of the work of creating a nearley grammar and associated interpreter (whole thing is bundled, nearley is not a final dependency), elaborate tests make this quite sane to handle
- took me about total of 1 weeks for the initial mvp to try out, and then have been fixing bugs and inconsistencies with javascript behavior, about 1 day a month of effort
- mostly 0
The only reason to create was I couldnt find something similar and it was low effort thanks to llm
I also created another even smaller DSL you can say
https://www.npmjs.com/package/free-text-json-parser
It parses json embedded in plain text
I once made a hacked version of javascript for work, starting with rhino. I adjusted it to make `.` and `[]` on null/undefined return undefined. Kind of like the `?.` in modern javascript, but it didn't exist back then. I was inspired by ObjectiveC's message send behavior.
The language was for some configuration in a reporting system. The scripts were written by non-engineers, and the changes made the language more user friendly for them. I started from javascript because I expected it would be easier for them to find documentation.
Nice. I built something basically just like this for work for the same reason last year. It only look a few hours though, cause I just used Acorn [0] to parse my JS, then directly evaluated the AST. It also had an iteration limit and other configurable limits so I can eval stuff in the browser without crashing the tab. I did not use an LLM.
[0]: https://github.com/acornjs/acorn
This is exactly what I wanted and couldn't find. Ended up creating along with an interpreter (so slightly easier then walk and execute)
> safe
> llm did most of the work
> it was low effort
I really wouldn’t trust its supposed safety.
csp safe has a particular meaning associated it with. its not a "safe" language whatever that is. chrome webstore team is okay with it and serves my purpose. if you have submitted extensions to google chrome then you would know that any sign of "eval" or new Function in the code will lead to rejection.
So what you want is a linter, not a language
I want to execute dynamically generated javascript looking code in chrome extension without using eval or new function. basically eval without actually using eval.
linter would help me find and avoid usages of eval.
"Just for fun" is always a valid default option. Though many authors don't stop there ;-)
I think most popular languages were started as an experiment in some feature, or to solve a specific problem someone had. Those are good reasons to make a language. I see no reason to make a language just to take attention away from other existing languages. Instead, make a language so you can understand how to make languages. It is 100% doable by one person. It's fun and educational.
Sometimes it might just be a fun project to push yourself. Maybe such a complex undertaking can't be fun indeed lol
My idea of for fun is to release something people will use. I have more fun if I work on something useful. For me is less the journey than the end goal.
I love working on software, architecture, design but only if I see some use.
Of course, for other people, the journey is more interesting than the destination and they have fun hacking stuff just for the sake of it. They discover things and learn new stuff they wouldn't have learned otherwise. And this is a path at least as valid as the other.
I'll try to answer your questions best I can.
1. Yes, as long as there are new machines that need programming, new programming languages will be needed. Today's top languages were built for the machines of the 1970, 80s, and 90s. Tomorrow's languages will be built for machines of today and tomorrow. As Alan Kay put it, if you want to invent a new language, first invent the machine of the future and then build a language for it.
2. No, you cannot. First of all, PL devs are cats, it's very difficult collecting them without financial compensation. So if your plan is to post a language and hope that people will come help you, you'll likely be disappointed. The problem is that everyone else interested in building PLs has their own itch to scratch, and they're not going to scratch yours without some compensation.
You might think "Well I can just raise money to do this", and you would be wrong. First, it's very hard to raise money for PLs. Usually you have to have come sort of cred to do it. I know of only 3 projects to have raised VC money for a PL project, and they each had some success before they had done so: Chris Granger (Light Table), Paul Biggar (CircleCI), and Chris Lattner (Swift/LLVM). Granger's project Eve raised $2M and ran out of money after 3 years; Biggar's project Dark also raised money, then fired all the devs when he realized he was burning cash too fast, then he slow-burned development for years, then he gave up and handed development over to someone else; and Lattner raised almost $100M for Mojo, which is probably going to end much the same way as Eve and Dark, but I wish them the best.
Anyway, the point is that you personally (no offense) don't have the profile to raise $100M like Lattner. $2M is not enough for a PL project. Lattner is keeping Mojo closed source for now because there's no good answer for how they're going to make enough money as an open source language to justify raising $100M.
And the reason it's so hard to raise money is because there's no money to be made. No one pays for PLs. No one pays for PL dev tools. They have to be open source or they're rejected by the dev community. The only ones these days who can reasonably pay for all of this with no potential revenue stream are giant corporations, who use the lang as a hook into their ecosystem.
3. Even though the answer is no, you yourself can still get an MVP off the ground in a pretty reasonable amount of time. It's never been easier to make a PL. The problem with PLs is building them is kind of like measuring the coastline; language projects are fractals -- there's an infinite amount of detail you can work on in any given direction. It's very easy for a language project to become a language + editor project, and it's easy for that to turn into language + editor + operating system if you're not disciplined. Plenty of PL devs have fallen into that trap.
4. Rounds to 0% chance. You'll be lucky if you build something that even you will use. Rather, most PL devs end up working on their language in some other language, because working on languages is what they want to do!
That said, it's still important to write languages that you understand no one will use. First it allows you to try new things that may good but unpopular. If PL devs only did what was popular with devs, PLs would go nowhere as a field.
Consider the so called "Hornet's nest" of programming languages [1], which is the tightly related cluster of imperative programming languages which have been the most researched and used over the last 50 years. There is a vaaaaaaaast design space outside that nest, begging for more language development. No one will use most of them, but it's important to understand what those languages might look like to maybe find some new ideas that work.
Also "didn't make it" is kind of an unfair judgement. Gaining popularity doesn't have to be a goal. In fact, it shouldn't be a goal if you want to have any fun at all. There's an infinite amount of work to be done, and if you're not doing it for you, you won't get far at all. That's really the only way to fail at this.
Good luck!
[1] https://tomasp.net/techdims/#footer=index,navigation;left=ca...
Bold plus, making PLs is a lifestyle, not a business. Most PLs clones each other and absorb features. The only difference is QOL and tooling. Users expect to have a full set of batteries, an IDE/LSP, jobs, OOP style, and minimal effort to learn. Being popular contradicts with the idea of pushing the boundaries and shifting paradigms.
> Bold plus, making PLs is a lifestyle, not a business.
Yeah, whenever I encounter a new language, to see how serious they are, I take a look at their github commit history. Usually they are all green every day, there's a sort of obsessive compulsion behind working on these projects.
It's pretty amazing how the boundary of what a PL actually is has expanded. It's really the story of "If you give a mouse a cookie"....
Used to be back in the day you didn't even have to implement the thing (ISWIM). But if you give the people a programming language they're going to expect a compiler to use it. Then devs started expecting a whole standard library sometime after the 70s. By the 80s and 90s IDEs were all the range -- you needed to provide at least syntax highlighting for sure. A breakpoint debugger was starting to become standard expectation.
In the 90s - 00s, open source rose to prominence and communities of open source developers works to create robust community-driven language ecosystems, which then became an expectation for new langs. Quite the paradox there -- how do you create a community around a new language if the new members expect a community??
But once you have a robust package ecosystem, devs start expecting ways to manage it. So now you not only need a package manager, but also a package repository and all the issues which come with that.
Now with all these packages you also need to provide a robust build system to download them all, build each one, link the binary, and it should be compatible with all major operating systems, all major architectures, and of course the web.
Today, LSPs were the most recent "must have", before "AI integration" took over and now you need to have AI assistants that know your language and all the libraries.
All that before you even start talking about the language specifics. To be popular, your language must a) be severely limited in its "weirdness budget" (the degree to which you break from tratitional languages must be a small delta or potential users complain) b) be imperative-first c) and most importantly, be open source and charge exactly $0 for all of this.
That's why the quickest way to build a new and different language is actually to create a cult around it. If you're gonna make any money at all, it'll be in selling plushies of your mascot. I wrote a whole novel about that route here a couple weeks ago. https://news.ycombinator.com/item?id=45806741