Hacker News Reader

Comment by kubb | Hacker News Reader

I wonder if „hard“ languages like Haskell will make a comeback with LLMs, because the short term cost of learning the language isn’t that significant anymore contrasted with the long term benefits of the type system and better structure.

View on HN

What makes languages like Haskell good is exactly benefits you acquire due to learning various abstractions which allow you to write better code. For example I like for an LLM to write code in Haskell using higher order algebraic effects, it's really great for readability but you still need to have some notion of what they are to use them. LLM won't program using them just by itself it needs to be deliberate instruction.

This is true!

My new favourite thing is to use records to type interfaces for more C style libraries with lots of IO. The trick is to use Generic and a type class to gather the interface into a list or similar and running that in IO using the library. Say, using a record to type audio and midi inputs and outputs in an audio plugin.

Opus can do this correctly first try, you just need to give it the idea!

I sometimes ask an llm to plan out an algorithm or concept in Haskell. Then I ask it to implement it in rust. I think I get a better implementation that way - though I might just be fooling myself. They seem to find simpler abstractions if you start there.

In my limited experience with OCaml, Opus has problems using the paradigm correctly. For instance it sometimes avoids recursion when it obviously fits.

It gets it right after a few attempts.

I have used LLMs a ton with Haskell! Opus knows Haskell really well, and it can do things very quickly in it. And in my experience the code it produces has very few bugs.

I think everyone is focused on the wrong future, it is like watching folks arguing about which Assembly ISA variant is more relevant in the presence of optimising compilers.

The hard reality is none of them.

We will have some kind of type system/profs to help drive LLMs output, and those that still will have a job as system architects or whatever, will generate applications directly.

And just it happens with optimising compilers, there will be a way to generate some kind of intermediate representation, like the -S switch, but that is it.

Generating source code for 3 GL languages is an intermediate step.

Who thinks otherwise should spend sometime looking into papers of AI role in compiler development.

For example,

"CGO 2022 Keynote: Compiler 2.0"

https://www.youtube.com/watch?v=w_sX9aZoZxg

"Machine-Generated, Machine-Checked Proofs for a Verified Compiler"

https://www.youtube.com/watch?v=Dmt0h99iOmM

> We will have some kind of type system/profs

Yes, and there's a good chance that will be Rust, at least in the short term.

You can't realistically write a whole program in Lean. So you want a good type system that combines well with a prover. Rust has a good type system, and annotating unsafe sections with proofs is becoming common practice in Rust. Right now you have to choose the proof syntax among several alternatives, but there are efforts to unify.

That's the future of Rust in many companies, agents or no: unsafe code must be annotated with proofs to eliminate undefined behavior.

Now certainly a purpose built system may be better than adding annotations to an existing language, but it'll probably work better if that happens after people & agents get experience writing the awkward combination.

Rust advocates forget that there are other more convenient ways to use Standard ML linage of type systems, and Lean isn't the only alternative around.

I think we are on the Rewrite in Rust hype cycle now, eventually the dust will settle, when folks realise agents are an evolution of garbage collected systems.

I explicitly stated that Rust had annotation support for several different provers. Not just Lean.

I also explicitly stated that this was not likely the best way to do this.

Yes, my point is that this is only interesting for those pushing for Rust.

Many folks not into Rust land will favour other tooling approaches for their LLMs, who knows might even be something based in Markdown or YAML, as these kind of things usually turn out.

The rust implementations cooperate and help advance the state of the art for other approaches, and vice versa. For example, in adding pointer provenance to LLVM.

Ok, but that doesn't get rid of type systems or function signatures. It just means you don't care about having syntax for an executable implementation, if there is an executable syntax it would only be used for testing.

Also, this doesn't necessarily mean there won't be any compilers either. It might just mean that the AI builds a dedicated compiler for each individual function.

Indeed, however that means there are plenty of ways to choose, linear types, affine types, effects, formal proof, dependent types.

Why a dedicated compiler for function? The whole infrastructure generates the code.

I suggest some sceptics to try to do a ecommerce like application only with low code agentic tools, that already gives a glimpse where we are going.

Get an headless ecommerce or CMS SaaS product like Alokai (https://alokai.com), an iPaaS agentic platform like Workato (https://www.workato.com), and the whole application logic will be diagrams with English prompts, naturally with guardrails to the IA infrastructure more or else inline with the desired behaviour.

That is all, that is the application, these lego pieces connected via prompts.

The size of the training data also matters. Turns out the Rust Evangelist Task Force was right to push it on HN all along

I also wonder if some deprecated practises and packages will linger in the training data for a long time. I remember the Python 2 to 3 transition. A lot of people parroted all kinds of outdated information on Python 3 and that made people hesitant to switch to Python 3.

I found it amusing I used to push Rust so many years ago not knowing that I’d eventually get everything I asked for. And especially not how it would happen.

Just like many open source maintainers lectured their unhappy users that their broken and featureless software was given for free and they should make PRs instead of complaining.

Be careful what you wish for, etc

This is wrong. Training data is almost irrelevant because LLMs can apply cross-language semantic understanding. JS training data applies equally to JS, TS, C or Haskell.

Tooling and libraries matter much more than semantics for language use, and training data is crucial for that

While this is a good theory. In reality everything will shift to JS because llms are over trained on JS

Case in point: claude code is in the bun runtime of JS. Not in any fancy optimized binary

I'm working on a fully memory-safe (LLVM) compiled Lisp dialect with a system Fω type system. Borrow checking is actually far more extensive than Rust and in fact all memory operations are required to be proven safe at compile time (either by the compiler, and if not possible, by the source code via appended proofs). Fairly stable at this point, in benchmark performance is tied with C/C++ even exceeding it because of more aggressive autovectorization and native vector types

For instance

   ; Sysv native vectors. Initializer values require matching [].
   (mut x (the v64 [10 20]))
   (set x (+ x 5))
   (at x 0 17)
   (print (at x 1))
   (print (all (= x (the v64 [17 25]))))

   ; Parameter and result types can be written inline
   (fn add4 ((a w64) (b w64)) -> w64 (+ a b))
   (let ((result (add4 (the w64 [1 2 3 4]) (the w64 [10 20 30 40]))))
      (print (at result 3)))

You also get full fp primitives

   ; helpers reused below
   (fn inc (x) (+ x 1))
   (fn dbl (x) (* x 2))
   (fn sq  (x) (* x x))
   (fn pair (a b) (+ a b))
   (fn add3 (a b c) (+ a b c))
   (fn dv (a b) (/ a b))
   (fn id (x) x)
   (fn zero (x) 0)

   ; |> : pipe a value left-to-right through functions.
   (print (|> 5 inc dbl sq))                ; => 144   (sq(dbl(inc 5)))

   ; >> : left-to-right compose; << : right-to-left compose.
   (print ((>> inc dbl) 5))                 ; => 12    (dbl(inc 5))
   (print ((<< dbl inc) 5))                 ; => 12    (dbl(inc 5))

   ; fmap / <$> : apply f, then g  (same as >>).
   (print ((fmap inc dbl) 5))               ; => 12
   (print ((<$> inc dbl) 5))                ; => 12    (11 on sysv: (inc (dbl 5)), function-first)

   ; <*> (and its alias <>) : the S combinator, (f x (g x)).
   (print ((<*> + (lambda (x) (+ x 2))) 5)) ; => 12    (5 + (5+2))

   ; <&> : flipped fmap, a(b x).      <**> : flipped S, (g x (f x)).
   (print ((<&> inc dbl) 5))                ; => 11    (inc(dbl 5))
   (print ((<**> (lambda (x) (+ x 2)) +) 5))   ; => 12 (5 + (5+2))

Reply on news.ycombinator.com