Show HN: Jacquard, a programming language for AI-written, human-reviewed code

> a C-emitting native AOT backend that currently compiles the kernel .jqd carrier

This human reviewer gave up at line 4 of the Readme. What is the kernel? What does the carrier carry? Why does it need to be carried? Where does the .jqd come from?

Also, for whatever reason, from the submission here:

> I had AI analyze the ASTs of several mainstream languages plus a few of the conceptually groundbreaking but esoteric ones (listed in the README)

No, they are not listed in the Readme. Why lie to us right off the bat?

I like the general idea, but the human responsible for this seems to demonstrate no interest in actually reviewing their system's output. Which does not bode well.

> External/world effects are visible in function signatures

Brilliant. I think Jai has something like that? Each function declares what it's going to touch (both read/write) globally, and I think you can specify that per block even.

I haven't used Jai (I think it's not out yet) but I remember the author talking about this and it sounded like a great idea.

It's related to the idea of pure functions being easy to reason about. Right now most languages don't even have a concept of pure functions, but the ones that do, just have two categories. When a function is messing with global state you do actually want to know what it's doing.

I think that can be statically computed (and displayed as IDE annotations or whatever) but specifying it explicitly sounds like a good practice either way.

I like that you're including other side effects (e.g. network) there too though, that's pretty cool!

Another thing I'm really interested in is proofs. Not necessarily total proofs (though we seem to be moving in that direction, at least for subsets of the codebase), but just normalizing rudimentary pre and post conditions checks.

I was thinking of setting it up so code can't even compile in release mode if those are missing. (Not every function would need them, but you at least want to state their absence explicitly.)

I was also thinking of setting up strictness levels per function, using hashing or something, so if a function is modified, you'd have to go through a process of double checking it again. And then functions labeled e.g. level 7 strict couldn't call ones with a lower proven strictness level, and so on. I'm told that I've basically been reinventing Ada from first principles so I should probably go and take a look at that...

Wait, your thing is doing hashing too... Woah. (I think that comes from proofs land or something?)

Given how poorly LLMs do with writing prompts for LLMs, I'm not sure I'd trust their judgement in designing a language for LLMs.

> and the runtime requires explicit permission to touch the filesystem, network, etc

This feels like more of an OS problem (or library problem) than a language problem.

> Run one program against many worlds. The same code can run against the real network, a scripted fake, a recording of last week's traffic, or a probability model of how servers usually behave

How is the "world" model different from plain dependency injection?

This is an interesting direction. I like the premise that the language is designed around AI-written, human-reviewed code rather than treating AI as just another code generator.

I'm curious about one thing though: what kinds of bugs or review tasks does Jacquard make substantially easier than existing languages? In other words, what's the smallest example where reviewing Jacquard is noticeably easier than reviewing Python or Rust? Thank you.

Very cool, this is the first language I've seen that has effects/permissions annotated.

When reasoning about a bit of code, types and effects are two things that help me grok it. However, there are a lot more. Like: how much memory can this use, does it process any PII, how quickly should it respond, which users are allowed to run it. Our "type" system could then alert us when we call a function that takes 20 seconds straight from a button without a loading spinner.

I'm very curious to see whether a language with many annotations this could work. Probably a language stored in a database approach like Unison is needed.

Other than that, I'm also curious to know if Jacquard works well with LLMs in practice. How well does providing the language docs into the prompt actually work? The models are trained on mainstream languages so I've been doubtful whether new languages will be able to compete.

lol I had started a “plugin compiler” that Claude also wanted to name after the Jacquard loom https://github.com/jondwillis/jacq

Fricking training distribution/same-y ness coming for us all… cool project though.

Very cool!

I’ve been very fascinated by the concept of a programming language designed for LLMs, both to that advantage of their strengths and to try and minimize their weaknesses.

Here’s a take I experimented with last year (feel very free to steal anything useful): https://github.com/GoogleCloudPlatform/aether/tree/feature/v...

(Note: main has a version that was an ugly syntax, the branch in the link was for a prettier attempt)

I don't understand the code in the examples after simply reading it. That's a problem. You need to have comments to clarify or pick a better example of code.

You are in competition with Python and Javascript which has lots of code for training data. I wouldn't touch esoteric features unless it improves readability or is under the hood. The bigger problem with esoteric features is that its hard for humans in general to understand unless you cover it with enough syntactic sugar for people to write it down.

Why not use an existing language with proper algebraic effects? This language seems to be a language with something that looks like algebraic effects, but it doesn't look like it properly implemented those.

These effect systems seem nice enough when all your I/O is going through a narrow interface, but I'm wondering what happens when you have a very large API surface, like everything available to a web page running in a browser?

I love how people create so many new things with AI, but to think how much tokens, and in turn money we all have collectively burned for these side projects is crazy.

a feature that i thought would be good for llm-centric languages would be making something like python's doctest prominent where you put simple little unit tests in the docstring of the function rather than in some testing module someplace else.

it would make it easy for humans to easily stub out tests with a docstring description and the tests that would guarantee certain behaviors. for the machine, it'd make it easy to add in new tests because the function+tests are in the same context window

Very cool -- I often thought that Unisons caching approach should be adopted more widely. Look forward to poking at it later!

The obvious problem with any new AI-centric programming language (I think this is the third I’ve seen at this point) is that any LLM you try to use with it will be starting from zero - it has nothing to copy from and very little documentation available to find on its own, if it’s even capable of doing web searches. Java or C++ or whatever may be “worse” by some standards for LLMs (or humans) to work with, but all LLMs in common use have already been trained on decades of existing code which it can crib from.

An llm doesnt 'prefer' to use anything.

Whats different to the effects system just being a type system?

Isnt a function that opens a particular file still just a type? Perhaps dependent?

Reminds me of mercury which has determinism of the function like type signatures.

[dead]

[flagged]

"Esperanto for Clankers"