291–300 of 396 posts
Earlier quoted context omitted.
Are you saying controversial is good or bad?
Neither, that's up to your individual preference. Although I think that controversial threads have more noise, but sometimes provide a more enjoyable read.
Earlier quoted context omitted.
That is a completely different category. I've never experienced a logic error due to a managed runtime and only once or twice ever due to a C++ compiler.
I certainly already experienced crashes due to JIT miscompilations, even though it was a while back, on Websphere with IBM Java implementation. Also it is almost impossible to guarantee two runs of an application will trigger the same machine code output, unless the JIT is either very dumb on its heuristics and PGO analysis, or one got lucky enough to reproduce the same computation environment.
As long as the JIT is working properly, it shouldn't matter: the code should always run "as if" it was being run on an interpreter. That is, the JIT is nothing more than a speed optimization; even if you disable the JIT, the result should still be the same.
Earlier quoted context omitted.
Neither, that's up to your individual preference. Although I think that controversial threads have more noise, but sometimes provide a more enjoyable read.
So what use is it to filter them? It seems you still have to judge their worth based on their actual contents.
Earlier quoted context omitted.
You'll need to share with the class because compilers are pretty damn deterministic.
Not if they are dynamic compilers. Two runs of the same programme can produce different machine code from the JIT compiler, unless everything in the universe that happened in first execution run, gets replicated during the second execution.
And the vast, vast majority of the time, adding a new line to the source code will not result in an unrecognizably different output.
With an LLM changing one word can and frequently does cause the out to be so 100% different. Literally no lines are the same in a diff. That’s such a vastly different scope of problem that comparing them is pointless.
Are these kinds of articles a new breed of rage bait? They keep ending up on the front page with thriving comment sections, but in terms of content they're pretty low in nutritional value. So I'm guessing they just rise because they spark a debate?
This comment has even lower nutritional value. It's just a "dislike" with more words. You could have offered your counterarguments or if you're too tired of it but still feel you need to be heard, you could have linked to a previous comment or post of yours.
If the LLM is a high level language, then why aren't we saving the prompts in git? Last I checked with every other high level language, you save the source and then rerun the compiler to generate the artifact. With LLMs you throw away the 'source' and save the artifact.
The intermediate product argument is the strongest point in this thread. When we went from assembly to C, the debugging experience changed fundamentally. When we went from C to Java, how we thought about memory changed. With LLMs, I'm still debugging the same TypeScript and Python I was before. The generation step changed. The maintenance step didn't. And most codebases spend 90% of their life in maintenance mode. Th…
Aren't you telling Claude/Codex to debug it for you?
Are these kinds of articles a new breed of rage bait? They keep ending up on the front page with thriving comment sections, but in terms of content they're pretty low in nutritional value. So I'm guessing they just rise because they spark a debate?
This comment has even lower nutritional value. It's just a "dislike" with more words. You could have offered your counterarguments or if you're too tired of it but still feel you need to be heard, you could have linked to a previous comment or post of yours.
To me the claim of the article was silly on the surface of it, silly enough that I was surprised that folks consider it worthy of discussion.
Is there just a large number of upvoters here without even a basic understanding of the topic at hand? Or is there some other explanation beyond that?
If we consider the prompts and LLM inputs to be the new source code, I want to see some assurance we get the same results every time. A traditional compiler will produce a program that behaves the same way, given the same source and options. Some even go out of their way to guarantee they produce the same binary output, which is a good thing for security and package management. That is why we don't need to store the…
Anyone doing benchmarks with managed runtimes, or serverless, knows it isn't quite true. Which is exactly one of the AOT only, no GC, crowds use as example why theirs is better.
If the LLM is a high level language, then why aren't we saving the prompts in git? Last I checked with every other high level language, you save the source and then rerun the compiler to generate the artifact. With LLMs you throw away the 'source' and save the artifact.
There are now approaches were the prompt itself is being structured in a way (sort of like a spec) so you get to a similar result quicker. Not sure how well those work (I actually assume they suck, but I have not tried them).
Also some frameworks, templates and so on, provide a bunch of structured markdown files that nudges LLM assistance to avoid common issues and do things in a certain way.