51–60 of 105 posts
Earlier quoted context omitted.
> But writing Haskell, it's pretty bad, I’m surprised by this. Most likely significant white space is a big part of the problem (LLMs seem horrible at white space). Functional with types has been a win for me with Gleam.
But LLMs do Python quite well, so white space isn’t necessarily a problem.
Earlier quoted context omitted.
> Of course there's no way to tell at compile time that a value will definitely be zero. Yes there is. Dependently typed languages like Idris can inspect terms at the value-level during compile time. Rather, instead of proving that the divisor will be zero, you must instead statically prove that the divisor cannot be zero; otherwise the code will not typecheck.
Okay, int integer_division(int a, int b) { if (b!=0) return a/b; raise(SIGFPE); } Great.
Earlier quoted context omitted.
I'm curious what issues you had with haskell? I have had the opposite experience and find them dreadful at Java et al. Surely, denser languages should be better for LLMs?
The context window also limits how deeply the model can "think", and it does this in natural language. So a language suited to LLMs would have balanced density, if it's too dense, the model spends many tokens working through the logic, if it's too sparse, it spends many tokens to read/write the code. I think in the context of already trained LLMs, the languages most suited to LLMs are also the ones most suited to hum…
Earlier quoted context omitted.
Okay, int integer_division(int a, int b) { if (b!=0) return a/b; raise(SIGFPE); } Great.
You don't appear to understand the difference between runtime and static analysis/compile time, or term-level and type-level.
The right granularity for agents isn't files or lines, it's entities: functions, classes, methods. That's how both humans and agents actually think about code.
We built sem(Ataraxy-Labs/sem) which extracts entities from 30+ languages via tree-sitter and builds a cross-file dependency graph, so building semantic version control and semantic diff. weave (same org) takes it further and does git merges at entity level. Matches functions by name, merges their bodies independently.
The dependency graph also answers questions LLMs can't. I love the analysis based on ASTs.
Yes, you’re adding this layer of verification, but LLMs don’t think in ASTs or use formal logic.
They are statistical predictors, just predicting what the next token will be.
There is a reason they perform best with TS/PY and not Haskell. The difference in size of the code corpus for each language.
The premise behind this seems to ignore all of that.
Earlier quoted context omitted.
You don't appear to understand the difference between runtime and static analysis/compile time, or term-level and type-level.
Great! Explain it to us while I read to my kid!
Seemingly opposing forces.
Earlier quoted context omitted.
You don't appear to understand the difference between runtime and static analysis/compile time, or term-level and type-level.
Great! Explain it to us while I read to my kid!
Or maybe it's over your head and you should just stick to reading children's fiction after all. Want some colouring books too?