I'm building something like Lua for robots, you might want to check it out if you're looking to collaborate. I didn't know about Lua when I started it, but I did end up at an "everything is a table" metaphor because it seemed good for robotics. This does allow for cool things like hot reloading and such.
Although, we've since moved to having several distinct data structures which conceptually map to tables, but implementation and syntax-wise have differences (mostly for performance).
BTW Basis was a good idea, I remember reading about Nondeterministic replay is a big problem on platforms like ROS.
I think I could actually build what I was thinking of on top of basis, but need to think about some things. Serialization of internal state was kicked around as a design idea at the start, but didn’t see enough benefit back then. In any case basis isn’t quite dead, I still use the thing as a test bed for ideas.
Thanks for the kind words and keeping the joke going, I laughed at many of these responses. I think they'll make it in to v2.0 which should be out by 4/1
It makes sense that the first thing I'd get to the front page of HN is what amounts to a bad joke :P
I think it's the exact opposite -- LLMs have revealed the precise utility of programming languages. For decades the "English as programming language" has been the holy grail of language designers. From COBOL to SQL to AppleScript, it was the hope that one day we'll be able to program a computer just as easily as we can instruct a person.
Well LLMs finally offer that, and what they are proving is what programmers have known for decades -- natural language is a terrible way to specify a program to a computer. So what is happening in the LLM world is they are reinventing programming languages and software engineering. They're just calling it "prompt engineering" and "context engineering".
What this tell us is that natural languages are not only not sufficient for the task of programming, to make them sufficient you need to bring back all the properties you lost by ditching the programming language. Things like reliability, reproducibility, determinism, unambiguity are thrown away when you use an LLM, and context engineering / prompt engineering are ways of trying to get that back. They won't work well. What you really want is a programming language.
> natural languages are not only not sufficient for the task of programming,
Downthread there is an example of an ICPC problem statement, [0] given as natural language, (modulo some inequalities and example program inputs/outputs) which was sufficient for Gemini to program & implement the correct solution where no other human could.
> problem statement, [0] given as natural language, (modulo some inequalities and example program inputs/outputs)
I also see two graphics, and several formal mathematical expressions. You can't modulo away all the not-natural language and then claim natural language alone was sufficient. I presume these things were added by the authors to increase clarity of the problem statement, and I agree with them. They used formal languages to specify all the important parameters in an unambiguous way, which was the right call! Otherwise we would all be left wondering at the semantics.
Anyway, I don't think this really responds to my point, because competition prompts are designed to be self-contained problem statements that are as clear and unambiguous as possible for competition purposes. And in this case, they switched to speaking in a formal language when being precise and unambiguous was most important.
On the other hand, my statement was about the task of programming, which typically involves solving ill-defined problems with specifications and requirements that shift over time. I've been in programming competitions, I've also been a programmer, and I don't find one to be really related to the other.
Indeed, it is, and that's the point! Being interfaces to computers for humans, programming languages sit at the intersection of computer science and humanities. Lots of people like to treat programming languages like they're math class, but that's only half the picture. The other half is usability, ergonomics, learnability, and especially community. Not to mention the form of the language is all about aesthetics. How many times has someone on Hacker News called a language "beautiful" or "ugly" referring to the way it looks? When people praise Python they talk about how easy it is to read and how pleasant it is to look at compared to C++. Or look at what people say about Elm error messages versus C++ template errors. Actually a lot of what's wrong with C++ could have been averted if the designers had paid more attention in art class.
> But these days we would need greater insights into higher-level language semantics and inherent tradeoffs to guide language-design and language evolution.
Here's a talk that argues there's much more fertile languages ground for ideas outside of the "programming languages are math" area, which has been thoroughly strip-mined for decades:
This author takes the perspective that programming languages are much greater than the sum of the syntax + semantics + toolchain + libraries, and treating them as such is limiting their potential.
I worked on this project so I can give some insight. The main reason we didn't keep working on it was it was VC funded and we didn't have a model for making money in the short term. At the end we were pursuing research related to natural language programming and reinforcement learning in that area (I recently blogged about it here: https://mech-lang.org/post/2025-01-09-programming-chatgpt), and were considering folding our small team into OpenAI or Microsoft or something. But we wanted to work as a team and no one wanted to take us as a team, so we called it.
It didn't get far enough to be "used" in a production sense. There was enough interest and people were playing around with it, but no real traction to speak of. Frankly, language projects are difficult because these days they have to be bootstrapped to a certain size before there's any appreciable use, and VCs are not patient enough for that kind of timetable.
This article is yet another reminder I need to learn Haskell (I've been meaning to for a decade), although the code from this article is approachable considering the topic. However, I've just started using Rust for professional projects, so the code you've posted is a bit easier to read, if more verbose, though the concepts are still unfamiliar to me.
I'm assuming this isn't your first go at writing a compiler?
Glad someone found it useful! It's at least represents a more fleshed out working example, and it's in a little module so it's pretty self-contained and easy to read through.
> I'm assuming this isn't your first go at writing a compiler?
Not quite, the first real language I worked on was called Eve: https://witheve.com
TL;DR: We’re taking a longer term approach to building Dark. As part of this, we’ve made the difficult decision to shrink Dark’s team, and to change how we build both the product and the company."
So where do we go from here? Right now, the team is just me. I am committed to realizing the full vision of what Dark should be. Dark is financially healthy for many years, and there is time to think and to plan. I plan to involve the community much more in Dark’s growth, and slowly rebuild the team at a pace appropriate to the product’s maturity, focusing on a small, tight team that can wear many hats.
Then there was a pivot to a rewrite of the whole thing, which I think was just Paul at the time:
Building programming languages is hard especially when you're not backed by a company. I think Eve (I worked on that one) and Dark were the two major VC funded languages, and at this point I don't think that's a good model for funding this kind of thing. You need waaaaay more that 2-3 million; most of that is funneled directly in to SF landords pockets. Something more like the Mojo people have gotten is what it takes (they've raised upwards of 100 million).
Anyway I can't wait to see where Dark goes in the future, and what their funding model will be going forward.
> You need waaaaay more that 2-3 million; most of that is funneled directly in to SF landords pockets
Which is why you should build your team in Denver, Minneapolis, Chicago, Detroit, etc. There's a competitive advantage to hiring outside the SF tech bubble today. Over the last 5 years the network effects in SF have begun to evaporate.
Agreed in hindsight, but at the same time there was no place else where a couple of 20-somethings could grab a cup of coffee with a VC and walk away with a handshake deal for $2 million dollars. That just didn't happen in Denver et al in 2014.
Does that still happen today? Anecdotally there has appeared to have been a massive funding crunch for pretty much anything that isn't virtual healthcare or AI since COVID passed, though I'll be the first to admit I'm not in the know on a lot of these things.
This is a pretty weird take. Talent in Denver, Minneapolis, Chicago etc. is not a whole lot cheaper than in the Bay Area. Employees are getting a large (majority) of their comp as options or RSUs, so that makes the delta even smaller, you're just talking base salary.
If that's "make or break" for you, then something is wrong. There are plenty of reasons to want to have a distributed workforce (larger talent pool in general, passionate employees) but saving money is the least important one here.
My point was that José and Chris being continuously employed working on the language and Phoenix respectively (by the companies I named) are probably considered a form of commercial backing by most people. If you want to split hairs about specific timing or magnitude of investment, that's kind of nitpicking IMO. It's not grassroots at basically any point.
José founded Dashbit after Plataformatec got acquired but up until ~2020 Plat directly funded the creation and iteration of the language, with it originating as an internal research project.
I don't think open sourcing is going to fix their adoption issue. Like the other comments mention, you need to be worth the time investment to gain traction. If Dark was truly as revolutionary as it was marketed as, it wouldn't have had problems staying source available, IMO. Folks will pay or put up with whatever it takes to be in the ecosystem (such as CUDA).
I agree it won't fit it, but IMO it will remove one of the barriers to adoption. The problem with doing something revolutionary, is that it's only going to be revolutionary in some ways, and it has to compete with things that are mature in ways you are not. And the original version (now called Darklang-Classic) was quite immature in an awful lot of ways that made it difficult to build on.
That's being addressed with the new version of course!
Mojo was also less ambitious in a lot of ways. It blows my mind the Eve and Darklang guys raised so much money without a lot of momentum. I'd think you'd go the other way, start an Open Source project, spend 10+ years gaining a community and refining it, then raise money.
In both of the above cases, the founders just got bored of their project before they found PMF.
You just have to look at the landscape at the time. There was a lot of money to be had if you promised the sun and moon, because $2 million wasn't a lot compared to the potential upside. The problem was, and this is what Paul found out too, they wanted to see typical startup metrics before they'd put more money in, and it was always going to take more than $2-3 mil. You just can't demonstrate those with a concept of a language.
No, I mean these low bus factor languages don't really die as long as the BDFL keeps working on it. Biggar keeps Dark going through thick and thin. Chiusano likewise with Unison. Even if their Unison public benefit corp runs out of money, Chiusano could probably do what Dark did and buy the IP. With my programming language I'm making sure that there is no IP and therefore nothing to own. It would probably be easy for Biggar to just wash his hand of Dark as well but it takes guts to keep going in a direction you know it right, and so I'm happy to see the project continue.
I'm glad to hear it as I'm very interested in Unison. (I've been watching them from the sidelines for ages.) For those not in the loop, it's a language where your code is stored on disk in AST form, not textually. The AST representation is smart in many ways - for example, renaming a function is an O(1) operation, regardless of how often the function is used. They also have a way to serialize Unison functions and send them over the wire to other Unison programs, which is pretty sick. Their site is here: https://www.unison-lang.org/
(I'm mostly interested in it because I think it would be an ideal language for videogame scripting & modding)
FWIW we also store ASTs, not text. We offer many of the same benefits. Some day (soon?) I'll write up a full comparison between the two, because it seems a common ask.
I'd love to see where BABLR falls in that comparison. We're trying to take the same kinds of tricks and bring them to every programming language at the same time
I can’t see teams adopting Unison (or similar languages) without a way to store code in Git.
Maybe the editor can load text and do structured editing. Maybe the runtime can send functions across the network. Great. But not using Git for storage and review is just too alien for most teams to even consider.
They were planning some language extensions but it's more like a compiler project than a programming language project.
The truth is, most developers don't want to learn a new language.
They will jump through extra hoops just to use their favorite one (e.g. Airflow).
Successful languages appear when there is an extreme market demand (C++ providing OOP over C) or, more commonly, a hot new platform that people want to get in on (JavaScript, Swift, Kotlin, C#, ...)
For most people, new syntax / semantics is considered a negative and there needs to be some massive upside to overcome that.
Feels like two types of companies raised money: - Companies trying to couple the cloud with a programming language. - More recently, companies trying to couple GPUs with a programming language/alternative to CUDA.
Haha yeah! When I was a kid before we could afford a computer, I would type magazine programs out on a type writer. I remember that I had to keep starting over because I would make a mistake, but that was okay because the program was short enough I was confident I could get through without any mistakes eventually.
Although, we've since moved to having several distinct data structures which conceptually map to tables, but implementation and syntax-wise have differences (mostly for performance).
BTW Basis was a good idea, I remember reading about Nondeterministic replay is a big problem on platforms like ROS.