Thanks for the ragebait. Reminding myself that the flaw here is obvious, there’s no need to respond, arbitrary „tests” aren’t binding to anyone, protecting the future is perfectly defensible as a moral stance even at cost of present convenience.
Yes!!
And with today's translation programs, the user does not even need to understand the local language.
Better — for me — would even be a mix of languages. Give me the most and longest articles of all languages for the places around.
This unfortunately doesn’t help if it isn’t paired with withholding judgement in the face of insufficient evidence, but rationalists don’t do that. They just pick a model they like and continue, and the burden of scrutinizing that model is on others.
Making rational decisions means picking the most responsible option given imperfect information. It doesn't mean delaying decisions until you have perfect information because that point never comes.
What's sufficient information is also a huge part of the debate. See: should we start worrying about AI safety or not yet?
Opinions based on insufficient information help immensely in determining whether we have sufficient information, and also raise awareness of important topics that we need more information on. These blog posts serve a very important role in the information exchange ecosystem and the whole world would be worse off if all these people held off until they're 99% certain. Nobody would be talking about climate change, about economy, about quantum gravity, about ancient civilizations, about prehistoric animal species, etc. etc. and so on.
Using the easy to defend claim (acting without perfect information is necessary) to defend a much broader one (my judgement is rational and justified based on the information I have) is a classical motte and bailey fallacy.
People in the rationalist community don’t see it, because ironically they’re not rational enough. But they use the language and essay format to make it seem like they are.
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.
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.
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.
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.
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.
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.
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))
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.
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.
What’s amazing is that nobody would have even noticed if it weren’t for Anthropocene being all “LOOOK WHAT WE DIIIIID WE SENT AN EEEEEEEEEMMMMMAAAILL. SOOORRRY”.
Crying for attention in the attention economy has never been more pathetic, but I think it will get worse.
Along with "lose" and "loose", "rogue" has to be one of the toughest words for the internet. With all of the posts available publicly, it would be interesting to do an analysis of words the internet misspells the most often.
reply