3 ms·
exactly, i find the article a wierd take. i would have thougt that being able to catch errors at compile time is the assurance that the LLM generated code is ac
by em-bee 3mo ago
exactly, i find the article a wierd take. i would have thougt that being able to catch errors at compile time is the assurance that the LLM generated code is actually decent.
so does this mean that the LLM writes code that is so good that the compiler does not find any more errors?
or is it due to the nature of haskell that makes it hard to write bad code to begin with?
or just that because the haskell compiler catches more errors there is less broken haskell code for the AI to train on?
and what does that mean for the switch to python? if the python compiler/interpreter doesn't catch as many errors do we even know that the code is good?
or is this more like the belief if the LLM can generate good haskell code, surely it can also generate good python?
what's the solution here? speeding up the haskell compiler? if that were easy, would it not already have happened?
personally i still don't trust LLM code generation. i didn't learn haskell yet, but what i hear about it makes me more likely to trust that LLMs can generate good haskell code than python.
i believe the future in LLM code generation is code that can be proven to be correct. proving code correct has been a research topic at some point.
- tonyarkles 3mo ago> what's the solution here? speeding up the haskell compiler? if that were easy, would it not already have happened? I suspect you’ve nailed the answer: it’s probably not easy, although it’s also possible that it just hasn’t ever had a lot of attention paid to it because it’s been generally fast enough for their user base?
- antonvs 3mo agoPart of the issue is probably that Haskell build performance is perfectly fine for local development, even on rather large systems. But in commercial production environments, CI pipelines tend to want to build everything from scratch every time, and that slows everything down. Rust has the same issue. Both languages, by default, compile all their dependencies from source, rather than obtaining precompiled artifacts from a repo the way some languages (like Java) do. And their compilers are slower than e.g. Go's. As the article mentions, various kinds of caching can help with that, but that's extra stuff you have to manage and deal with. I'm not sure this is a bad thing, though. Haskell co-creator Simon Peyton-Jones coined the unofficial Haskell motto, "avoid success at all costs". I tend to agree with that. It would be difficult for Haskell to maintain its conceptual edge if it were a mainstream commercial language.
- cwillu 3mo agoThe thing I hate about rust is that compiling a small app immediately creates 100gb of junk, and that junk doesn't live in the responsible project's folder, and that junk doesn't get cleaned up by anything.
- pdimitar 3mo agoYou're exaggerating quite a lot. Biggest I've seen the cargo directory after 3 months of active Rust development was ~17GB. You can also limit it with an env var. I have capped mine at 10GB.
- kstrauser 3mo agoI’m at 227GB as I write this.
- valcron1000 3mo agoHad no nuke the `target` folder a couple of weeks ago, +400 GB ...
- capitainenemo 3mo agoMany rust nightly versions + no clean / sweep / clean-all?
- pdimitar 3mo agoSuper curious then, and I stand corrected. You can put the `cargo clean gc` command on a daily/weekly schedule then, or configure the `gc` option in your Cargo config. Or set `CARGO_UNSTABLE_GC=true` in your shell init. Or all of the above.
- hunterpayne 3mo ago"proving code correct has been a research topic at some point." It has been an area of active research for 40 years. But almost all the research returned the null result, meaning that the program proving didn't improve code quality (basically it didn't work). Yet somehow a group of programmers, usually fresh out of academia falls for program proving each generation. Strong types do really help but you need a good compiler which is sometimes lacking in the real work cough Scala cough. The problem with strong types and program proving is that the juice just isn't worth the squeeze meaning the extra time taken doesn't result in reduced debugging time or improved code quality. I don't think that changes with LLMs. It just exposes the flaws more quickly.
- em-bee 3mo agowhat i expect to change with LLMs is the benefit you get from automated testing. which is really what LLMs need. tools that tell you something is wrong may not speed up a human developer, but they will allow LLMs to make corrections by itself until the warnings go away. so while it may not be worth it to a human developer, it may well be worth it for an LLM.
- pmontra 3mo agoThe issue with formal proofs is that we might end up with correct code that does the wrong thing. I mean, something that the market doesn't care about. At the same time a buggy set of PHP scripts does what people care about and captures the market. Think about 20+ years ago and you find a lot of examples.
- psd1 3mo agohttps://xkcd.com/224/ https://xkcd.com/224/ lol Zuckerberg became rich on php, which grinds my gears almost as much as the genocide thing. In fairness, my peers at $corp used to ship while I was sad-Wojciech "no you can't create tech debt". The universe is cruel to people who care.
- martl475 3mo agoFriend of mine said "Infuriatingly many people got rich with horribly bad software." (Sounds better in German)