a relative time formatting library that contains no code
The library is two text files (code) that are processed by an LLM (interpreter) to generate code of another type. This is not that new in terms of workflow.
I think what makes this the worst is the fact that the author admits that you can’t be sure the library will work until you generate the code and test it. Even then you cannot guarantee the security of the generated code and as you do not understand the code you also cannot give support or patch it.
When Performance Matters
If performance of a datetime processor is not relevant, what is? The author mentions they would like a browser implementation to be fast, documentable, fixable. However, operative systems, browsers, and other complex systems are made of little utilities like this that have very well documented functionalities and side effects.
But the above isn’t fully baked. Our models will get better, our agents more capable.
The whole assumption is that instead of creating a good stable base that anyone can use we should be just shtting out code until it works.
Eventually the hardware will be good enough to support a shitty bloated browser so we don’t need to optimize it.
Eventually people will harden their PC enough so we shouldn’t care about security.
The library is two text files (code) that are processed by an LLM (interpreter) to generate code of another type. This is not that new in terms of workflow.
I think what makes this the worst is the fact that the author admits that you can’t be sure the library will work until you generate the code and test it. Even then you cannot guarantee the security of the generated code and as you do not understand the code you also cannot give support or patch it.
I’ve tried explaining how LLMs are not equatable to compilers/interpreters in the past, and it’s usually to people who aren’t in software roles. What it usually comes down to when I try to explain it is determinism. A compiler or interpreter deterministically produces code with some kind of behavior (defined by the source code). They often are developed to a spec, and the output doing the wrong thing is a bug. LLMs producing the wrong output is a feature. It’s not something you try to fix, and something you often can’t fix.
This, of course, ignores a lot of “lower level” optimizations someone can make about specific algorithms or data structures. I use “lower level” in quotes, of course, because those are some of the most important decisions you can make while writing code, but turning off your brain and letting a LLM do it for you “abstracts” those decisions away to a random number generator.
The library is two text files (code) that are processed by an LLM (interpreter) to generate code of another type. This is not that new in terms of workflow.
I think what makes this the worst is the fact that the author admits that you can’t be sure the library will work until you generate the code and test it. Even then you cannot guarantee the security of the generated code and as you do not understand the code you also cannot give support or patch it.
If performance of a datetime processor is not relevant, what is? The author mentions they would like a browser implementation to be fast, documentable, fixable. However, operative systems, browsers, and other complex systems are made of little utilities like this that have very well documented functionalities and side effects.
The whole assumption is that instead of creating a good stable base that anyone can use we should be just shtting out code until it works.
Eventually the hardware will be good enough to support a shitty bloated browser so we don’t need to optimize it.
Eventually people will harden their PC enough so we shouldn’t care about security.
I’ve tried explaining how LLMs are not equatable to compilers/interpreters in the past, and it’s usually to people who aren’t in software roles. What it usually comes down to when I try to explain it is determinism. A compiler or interpreter deterministically produces code with some kind of behavior (defined by the source code). They often are developed to a spec, and the output doing the wrong thing is a bug. LLMs producing the wrong output is a feature. It’s not something you try to fix, and something you often can’t fix.
This, of course, ignores a lot of “lower level” optimizations someone can make about specific algorithms or data structures. I use “lower level” in quotes, of course, because those are some of the most important decisions you can make while writing code, but turning off your brain and letting a LLM do it for you “abstracts” those decisions away to a random number generator.