And the whole point about "slop" is exactly that the communication is not adequate (despite superficial eloquence), because it's "sloppy" thinking full of unnecessary verbiage that goes nowhere and disrespects the reader, making for an extremely frustrating communication experience.

But if AI (re-)phrasing helps communicate a message clearly then it's not slop. It's just AI assisted. Being able to spot common AI patterns isn't proof of slop, no-matter how sensitive to slop one might be.

And I'm saying this as a person who's VERY much against slop.

Let alone an explanation on why it's "slop" rather than just AI (re-)phrasing etc.

Reminds me of this: https://www.youtube.com/watch?v=k9ojK9Q_ARE

I thought it was a perfectly cromulent article making a perfectly reasonable point.

Instant betterness.

E.g. back when you were coding BASIC, you probably had magazines and either ended up copying a lot of code by hand, or if you were lucky the mag came with a floppy disk. Now no such magazines exist. Manpages were all local, now it's readthedocs online. Fat local-friendly standard libraries in almost all languages have been modularised and package managers for the most part expect to install stuff by fetching it from the net.

So unless you have heavily prepared for the cyberapocalypse or sth, there really is not much you can do on your machine when the internet goes down.

On the other hand, however, when you can prepare in advance, it's great to shut off the net for a while. I do my most productive coding during flights, for example.

One has to appreciate the irony on the use of the word "trust" there ...

So maybe this tells you more about the funders and their vision than it does about the researchers and their vision?

So my first impression is that either this is a non-evolutionary algorithm mascarading as one and diluting concepts like mutation and crossover that have well defined meanings, or it is one but you're abusing terminology from other fields (like RL and "rewards") instead. Either way it's a confusing first impression, and one gets the subtle vibe that word choices are more there to create a "buzz" than to create clarity.

(not trying to be dismissive, I genuinely hope this is useful feedback)

Paper does look interesting, I'll try to read properly when I have time.

> Java is a resource hog when you use patterns and libraries popular in Java land

Which java land. The java 8.0 land which is all about design pattern hell? Or modern java in 2026 which is largely about terseness and functional programming? From the tone, they're referring to the former.

> Deployment is super simple in Go, upload a single cross compiled binary it's done

To me this just sounds like OP is unaware of simple things like jlink or jpackage, and their idea of deploying a java application probably involves launching an IDE.

> But when you'll code the same thing in Go using the same method

Same method would mean using "Springboot for Go". Or, conversely, doing a clean implementation in pure java or with equivalent lightweight libraries. If all you want to do is basic calculations, you don't compare using a computer to a calculator and then complain the computer is heavy and slow to boot.

I agree and appreciate that there's a lot of legacy bloated java libraries out there which are "popular" and possibly for the wrong reasons, and that this is a problem. But, that aside, they're comparing building a bespoke lightweight tool from scratch in a language they enjoy, to using a bloated framework they can't be bothered to fine-tune on a language they associate with pre-2000 patterns. Just say you're more familiar with Go than modern Java and enjoy it more and leave it at that. Java has made great leaps into becoming a very beautiful language recently, and biased rants like this aren't helping.

well there's your answer, isn't it?

however, if all you have is a hammer, then every problem looks like a nail: it's when meetings are used inappropriately or to solve the wrong problem that it becomes an issue, and many people make this mistake, which is why meetings end up so universally despised and get such a bad rep

Deadlines don't make things more efficient by definition, unless it's a case of "within-task" inefficiency (i.e. "laziness"). But while this is almost always assumed to be the case by managers, it almost never is the case on the ground. And then you get into this hare-brained vicious cycle of "oh we're falling behind despite the deadlines (read "context-switching interruptions with non-trivial overhead enforcing suboptimal task selection"), we should probably add more!" [facepalm]