271–280 of 310 posts
Earlier quoted context omitted.
> If you're not being paid well, what's the motivation to post things you know don't make any sense to try and sell a brand? Because it works. Because it does in fact make sense despite your frustration with the concept.
Right. So why did you deny it earlier?
Are you this dense in real life or is this an act?
Earlier quoted context omitted.
Annotations add a seemingly infinite amount of new semantics. You can’t predict anything with confidence just looking at the code without also studying the annotation processors in depth, which regular Java tools don’t help you with.
Well, that's just metaprogramming. Also, java annotation processors are strictly "append-only", they can't change code written as is. They may subclass it, or build new classes that make use of the annotations. In my experience LLMs are more than happy with annotations, especially from the widely used ones (spring/jakarta ee, lombok though it's not an annotation processor, etc). If you think about it, an annotation l…
There is no case where annotations are superior to the meta programming facilities built into the language proper. Annotations only became popular because Java didn’t have easy syntax for function references or anonymous functions for a very long time.
Earlier quoted context omitted.
how about not making the error in the first place
If you have an LLM that doesn't make errors ever, then you have an ASI, at which point the conversation is meaningless. In the meantime, having a lower error rate but more uncaught errors is less important than making incorrect code impossible to compile, and/or flagged by strict linters.
given a system that can ascertain the same level of overall non-business logic errors as one that makes a ton of non-business logic errors that are all catchable, your LLM's ability to correctly implement business logic amid the noise will be greatly impaired along the way.
I've been saying this for maybe nine months vis-à-vis my consulting work keeps proving it. Go is an excellent language for LLM code generation. There exists a large stable training corpus, one way to write it, one build system, one formatter, static typing, CSP concurrency that doesn't have C++ footguns. The language hasn't had a breaking version in over a decade. There's minimal framework churn. When I advise teams…
This lines up neatly with the kind of low‑abstraction systems I like running: 2021 HP PC with i7, bare‑metal‑ish, Crunchbang++, no desktop, openbox window manager. Boots to login in 17 seconds. Terminal front and center — local AI bare-metal inference, no wrapper, ffmpeg, ffplay, etc.
Go’s “no abstraction ceiling” feels like the same preference at the language level: shallow stack, no indirection, and code that stays close to the metal. That’s why LLMs work so well on Go: it’s opinionated, predictable, and there’s usually one obvious way to do things. Personally, I've come to love a LACK of abstraction.
Earlier quoted context omitted.
I think Rust is great for agents, for a reason that is rarely mentioned: unit tests are in the same file. This means that agents just "know" they should update the tests along with the source. With other languages, whether it's TypeScript/Go/Python, even if you explicitly ask agents to write/run tests, after a while agents just forget to do that, unless they cause build failures. You have to constantly remind them to…
> if you explicitly ask agents to write/run tests, after a while agents just forget to do that Add a single task using your project's preferred task-runner that performs all the checks you want the agent to adhere to: linting, test coverage, style checks, test, etc, and add a rule in AGENTS.md that agents should always run this tasks after edits, and fix any warnings or errors produced. Add the same task to your vers…
Earlier quoted context omitted.
Well, that's just metaprogramming. Also, java annotation processors are strictly "append-only", they can't change code written as is. They may subclass it, or build new classes that make use of the annotations. In my experience LLMs are more than happy with annotations, especially from the widely used ones (spring/jakarta ee, lombok though it's not an annotation processor, etc). If you think about it, an annotation l…
It’s even simpler to have a “register” method that takes the path specification, the HTTP verb, and a function to handle the request. There is no case where annotations are superior to the meta programming facilities built into the language proper. Annotations only became popular because Java didn’t have easy syntax for function references or anonymous functions for a very long time.
Also, hard disagree on "register" method being simpler. A register method is code, while an annotation is a static declaration, ergo data. The former can happen in a helper function, renaming it from "register" to "path", changing/modifying the parameters, or putting it into some while loop dynamically generating endpoints.
At the very extreme it is Turing complete to figure out what endpoints are registered.
Earlier quoted context omitted.
[flagged]
> As someone familiar with those ecosystems, I'm have trouble envisioning the degree of operator error or imprecision that would cause this to be a problem. Because you are familiar with the ecosystem? Just like python devs saying it's normal to juggle with 3 package managers to run a simple script. Back to your original point: You also are biased by what you are used to use. Thankfully, I don't have to touch any JS…