cmontella

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.

> this sounds more like an artsclass to me.

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:

https://medium.com/bits-and-behavior/my-splash-2016-keynote-...

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 know about this one as well: https://www.reddit.com/r/ProgrammingLanguages/comments/1ioij... but the author seems to have taken it private for now. I think he's the Gren author, which is a fork of Elm.

As for me, I brought some eve-y ideas to my language project: https://github.com/mech-lang/mech

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.

Here's a postmortem Chris gave about all that: https://www.youtube.com/watch?v=WT2CMS0MxJ0 / https://www.youtube.com/watch?v=ThjFFDwOXok

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

Super cool! I just happened to write one of these last week, I posted it here if anyone wants to take a look at another implementation: https://github.com/mech-lang/mech/releases/tag/v0.2.58-beta

The code is here: https://github.com/mech-lang/mech/tree/main/src/core/src/pro...

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.

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.

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.

Congrats on Dark for making it this far!

Relevent timeline:

https://blog.darklang.com/dark-announces-3-5m-in-seed-financ... (2019)

https://blog.darklang.com/dark-and-the-long-term/ (2020 - in which the team is fired to extend runway I guess to today)

  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:

Start of a new rewrite: https://blog.darklang.com/dark-v2-roadmap/ (2020)

Two years later: https://blog.darklang.com/backend-rewrite-complete/ (2022)

seemingly a new pivot to "all in" on AI?: https://blog.darklang.com/gpt/ (2023)

No news, one year later https://blog.darklang.com/an-overdue-status-update/ (2024)

Would be interesting to the Dark team to revisit this post, which is a look at PL funding models:

https://blog.darklang.com/how-to-fund-caramel/

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.

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.

Lol this was my favorite thing to do at CMU. Except it wasn't luxury goods, it was all the textbooks and computer equipment they would leave behind.

I'm working on a programming language called Mech: https://github.com/mech-lang

It's for building robots, scientific computations, user interfaces, reactive systems, and so forth. Currently working on docs for this new version that I'm about to release. I'll post a Show HN when I do. Here's the spec so far it's a very WIP, maybe 20% done: https://docs.mech-lang.org/v0.2/II.reference/specification.h...

The cool part about the spec is it's a valid Mech program which is formatted into html by the formatter! https://gitlab.com/mech-lang/docs/-/raw/main/II.reference/sp...

Science absolutely depends on people meeting and exchanging ideas. Whether that happens at a conference as they exist today is one thing, but if you don't spend money on getting people from around the world to meet and exchange ideas, you're going to lose a key aspect of the scientific process.

> for all intents and purposes

What you mean is for your intents and purposes. Others in the thread have pointed out specific intents and purposes for which Tesla's approach fails -- driving when you don't have to pay attention. Which is the core function of self-driving, so not being able to do it is kind of whole thing.

> If that's not full self driving, but waymo's geofenced, $45 for a ride down the street is, we just disagree.

Geofenced or not, self driving is about not having to pay attention while the vehicle is in motion. If you have to supervise it, that's a very different thing from a system that will all you to looking at your phone or sleep.

Tesla's approach of trying to drive everywhere instead of a geofenced area is part of why their system is failing to deliver self driving.

Trying to do one thing well before expanding the performance envelope is good systems engineering practice. But Tesla has been widely testing their systems on the greater public, which has tragically resulted in deaths. This is why at the end of the day Tesla requires you to supervise their system while you operate it.

That's an interesting counterfactual but it doesn't really mean much to reality. Fact is, what happened is that public research got the results where private industry did not, and everyone is better for it, including private industry. Progress doesn't wait for private industry to be certain of its profits; if it doesn't happen here, it'll happen elsewhere.

> If the OP's specific research was into The Changing Mating Habits of the Delta Smelt Due to Habit Destruction, then probably it was money that could far better spent paying tuition for, say, medical students or even just letting tax payers keep their money and spend it in a way that directly benefits their family, their community, and themselves.

The problem is it's very hard to know ahead of time which research directions will yield fruit. If we knew how to only fund good research, then science funding would be very easy. Unfortunately, that's not the case -- oftentimes things that are sure bets fail, and things that are rejected as "not promising" result in a breakthrough. So we have to fund a lot of stuff, some of which is not obviously going to yield a great ROI.

On the one hand, yes, funding science the way we do results in a lot of "wasted" funding. There are tons of inefficiencies. On the other hand, the way we fund science has been wildly successful in terms of the benefits we have reaped. Look around you, you can see them everywhere in every sector.

The danger is we pull back funding to things that are "sure bets" and they turn out to be duds while we miss out on other less sure opportunities. That would be a loss for everyone involved.

The charge is that Tesla can't do self-driving successfully. If they could, you wouldn't need to supervise, as is the case with e.g. a Waymo taxi. That they require you to supervise is an admission that their system is not sufficient for self driving, i.e. they're not doing it successfully.

If that's how you're using it, then you're doing it wrong, because you're supposed to be supervising the drive the entire time. It's not self-driving if you're supervising. And you're required to supervise because... they're not confident it can actually self-drive.

Please read my sibling reply about DARPA grand challenges. This knowledge was built using public dollars by people who publish papers, which are being read today by people building products. That's the great cycle of progress.

Notably DARPA felt the need to do this because they didn't trust private industry to do it on their own; with no money in driverless cars, the government figured industry would get there only if there was some catalyst, which they provided (successfully).

If you only ever go where the work is, then you're going to be left behind by societies that have a vision and leadership that will work to make it real.

Yes, the entire DARPA "challenge" series has been about jumpstarting the US robotics industry. People who were involved in those went on to found driverless car companies, which then went on to create a market for driverless cars, and now America is a leader in the industry.

And it needed to happened because the state of American robotics was sad in 2004; the very first challenge was a disaster when all the cars ran off the road, with zero finishing the race. Top minds from MIT and Stanford got us that result. But they held the challenge again and again, and 20 years later we have consumers making trips in robo taxis.

e.g. Kyle Vogt, participated in the 2004 Grand Challenge while he was at MIT, went on to found Cruise using exactly the techniques that were developed at the competition.

So while Elon Musk is busy slashing whatever federal spending he can through DOGE, it's only because of federal spending that he can even fantasize about launching a robot taxi service.

Thank will follow along with great interest!

Bill Wadge ruined my life! I stumbled upon his book on his language Lucid in the library when I was in grad school, and it opened up my eyes about different programming models. It inspired me to try making my own programming language and I’ve been doing it ever since!

Going on 10 years now, no sign of losing interest. Don’t read his book if you have an interest in the thing you’re doing; it’ll turn you into a compiler dev and you’ll never do your interest again.

This is really cool! What do you mean by "the" compiler for our chip? Is this a compiler backed like LLVM which generates efficient machine code, that other languages can target? I'm an author of a dataflow programming language, what kind of resources do you have that I could read about targeting your hardware? I've been waiting for hardware to catch up with the language I'm building, so that's why I'm interested!

I’m working on a programming language for robots called Mech!

https://github.com/mech-lang/mech

Mostly a research project until I find some more people interested in pushing it further.

A recent blog for anyone who wants to check it out: https://mech-lang.org/post/2025-01-09-programming-chatgpt/

And a 10 minute video: https://www.hytradboi.com/2022/i-tried-rubbing-a-database-on...

Looks like a great lineup, can't wait!

It's bimodal. Most of the world uses one paradigm of programming (declarative programming via Excel and SQL), while developers use another paradigm (imperative programming via Python/C/C++/Javascript et al.).

Thanks for the kind words, and I agree it is a shame, but we a ran out of money! Chris raised $2m from investors, and we spent that over 3 years with a pretty minimal burn rate as far as SF startups go. We couldn't really show a path to making money at that time (although I still think we were on to some things), so we couldn't raise anymore. We tried for an acquihire but nah.

As for continuing the ideas, I'm putting a lot of what we learned into Mech. I know that Chris and Josh went to work at Relational AI, but I'm not sure exactly what work they got up to there. But Chris recently posted about generative AI and how it goes back to things we were thinking about in 2015 with respect to Eve: https://x.com/ibdknox/status/1630548754238435330

So in that sense generative AI can be a vector for some of the ideas in Eve coming to the mainstream.

How do you deal with writing code with multicursors when you have to type the same thing multiple times? With monospace I just ctrl+alt+down a couple times on aligned text and then type. With proportional fonts I don't suppose it's easy to align text exactly, so do you just not use multicursors or is there a solution you came up with that works?

> A Truly Relational Language... Value Database

I helped on a language called Eve about 10 years ago. A truly relational language was exactly what that language was supposed to be, or at least that's what we were aiming at as a solution for a user-centric programming language.

https://witheve.com

The language we came up with was sort of like Smalltalk + Prolog + SQL. Your program was a series of horn clauses that was backed by a Entity-Attribute-Value relational database. So you could write queries like "Search for all the clicks and get those whose target is a specific id, then as a result create a new fact that indicates a a button was pressed. Upon the creation of that fact, change the screen to a new page". We even played around with writing programs like this in natural language before LLMs were a thing (you can see some of that here https://incidentalcomplexity.com/2016/06/10/jan-feb/)

Here's a flappy bird game written in that style: https://play.witheve.com/#/examples/flappy.eve

It's very declarative, and you have to wrap you brain around the reactivity and working with collections of entities rather than individual objects, so programming this way can be very disorienting for people used to imperative OOP langauges.

But the results are that programs are much shorter, and you get the opportunity for really neat tooling like time travel debugging, where you roll the database back to a previous point; "what-if" scenarios, where you ask the system "what would happen if x were y" and you can potentially do that for many values of y; "why not" scenarios, where you ask the system why a value was not generated; value providence, where you trace back how a value was generated... this kind tooling that just doesn't exist with most languages due to how they languages are built to throw away as much information away as possible on each stage of compilation. The kind of tooling I'm describing requires keeping and logging information about your program, and then leveraging it at runtime.

Most compilers and runtimes throw away that information as the program goes through the compilation process and as its running. There is a cost to pay in terms of memory and speed, but I think Python shows that interpretation speed is not that much of a barrier to language adoptions.

But like I said, that was many years ago and that team has disbanded. I think a lot of what we had in Eve still hasn't reached mainstream programming, although some of what we were researching found its way into Excel eventually.

> Loosen Up The Functions... Capabilities... Production-Level Releases... Semi-Dynamic Language... Modular Monoliths

I really like where the author's head at, I think we have similar ideas about programming because I've been developing a language called Mech that fits these descriptors to some degree since Eve development was shut down.

https://github.com/mech-lang/mech

So this language is not supposed to be relational like Eve, but it's more like Matlab + Python + ROS (or Erlang if you want to keep it in the languages domain).

I have a short 10 min video about it here: https://www.hytradboi.com/2022/i-tried-rubbing-a-database-on... (brief plug for HYTRADBOI 2025, Jamie also worked on Eve, and if you're interested in the kinds of thing the author is, I'm sure you'll find interesting videos at HYTRADBOI '22 archives and similarly interested people at HYTRADBOI '25), but this video is out of date because the language has changed a lot since then.

Mech is really more of a hobby than anything since I'm the only one working on it aside from my students, who I conscript, but if anyone wants to tackle some of these issues with me I'm always looking for collaborators. If you're generally interested in this kind of stuff drop by HYTRADBOI, and there's also the Future Of Coding slack, where likeminded individuals dwell: https://futureofcoding.org. You can also find this community at the LIVE programming workshop which often coincides with SPLASH: https://liveprog.org