> wtff "convert my_video.avi to mp4 with no sound"

English is not my mother tongue but I think the model should correct the user that it should be: "convert my_video.avi to mp4 without sound"

I do not think I would need an LLM for making something like that

Yes, absolutely. I certainly don't need an LLM to do something like that.

When I ask for the weather, I want to know exactly what the Met Office says the weather is. Not what an LLM guesses the Met Office might have said, with a non-zero chance of introducing a hallucination.

This habit of inserting LLMs into otherwise deterministic tasks is frustrating. Why take something that can be solved accurately and deterministically (like parsing the Met Office's data) and make it probabilistic, error-prone, and unpredictable with an LLM?

LLMs are appropriate for problems we cannot solve deterministically and accurately. They are not appropriate for problems we can already solve deterministically and accurately.

I'm pretty sure the idea is to use an LLM to parse the natural language into a query, not for guessing the weather.

I didn't assume either that the LLM is to guess the weather. I said that using LLM for parsing the Met Office's data is maybe not such a good idea if you can do it deterministically.

The idea was "forward $@ to a LLM to make a structured request", not to parse a structured response.

Fun fact: The fire from a strawman this size could warm a small town for many days.

Impressively snide for such a bad point.

I take the request:

> $ weather in san francisco, today evening?

To be an example of some free-form written request without any special format. Parsing that input seems like a reasonable job for an LLM, right? Otherwise we will have the typical adventure game problem of “use thumb on button” doesn’t work because it expected “finger,” or whatever.

Exactly, this is what I meant. No matter how much or for which reasons one might dislike LLMs, you can't deny that they are the best general NLP tools we have right now.

I’m quite confused as to how you could have possibly been misunderstood, and kinda wonder if it is just some folks who wanted to find an interpretation that makes you wrong.

It's nice that there are options but i'm sticking with maven. I hate programming my build; maven is just a configuration file.

Which works fine.....until it doesn't. Many non-trivial builds require custom logic, and trying to do that in maven was painful the last time I tried it.

Yeah. It's Greenspun's tenth rule.

If you have any complexity, programming against a good abstraction (Gradle is not good good, but decent) beats finding the magical incantation of configuration to get the tool to do what you want.

I think folks just get used to Maven-induced constraints (this applies to SBT, Bazel, others too). When you free yourself from that you realize: builds just aren't all that hard, it's often the tooling that becomes a real limitation.

Of course, sometimes the limitations are good: preventing you from doing "the wrong thing", or encouraging cacheability, etc. But as with any abstraction layer - getting a model that fits across so many disparate use cases can be very challenging.

I have found that if it is hard to do in maven you probably shouldn't be doing it or there is a better way.

That is why maven offers a plugin model for your custom logic that can be written in Java/Kotlin and a well defined lifecycle model where you can configure your plugin declaratively.

You can also download custom CLI tools and invoke them as part of a well-defined build lifecycle.

And then fail to do proper incremental builds, leaving you with no choice but a faulty build or clean installing on every occasion.

At the very least, I would move to Gradle which does have proper knowledge of your build graph. But Mill is also a good choice and fills the same niche, with the added benefit that imperative-looking ordinary scala code will simply become a parallelizable, cacheable build graph.

Out of curiosity, what is non-trivial in this context?

> maven is just a configuration file

Even better, Maven "POMs" are written in a common, standard format (XML); so we can transform and manipulate it using off-the-shelf tools, if we really want to. I've found this useful e.g. in pre-commit hooks (tidy the formatting, checking/linting, etc.); in Nix builds (e.g. removing the version number, so it doesn't affect the hash and avoids spurious rebuilds); etc. That was a nice bonus when I switched some projects from SBT to Maven (due to SBT being wildly unreproducible).

I hate wrangling with configuration to make an amalgamation of plugins do what's expected in the expected order for my build; Gradle is just code and a DSL

If I would've gotten a Euro for every time "is just a DSL" was a reason everything was hard to debug and prone to failure, I'd have many Euros by now.

Well, good luck debugging a multi-module maven pom file, then. You can get terrible error messages from both, to be honest.

It’s two DSLs which are versioned and whose behaviors are different.

Gradle groovy is extremely permissive (eg: you can access private class instance variables without even knowing that you are doing so)

Kotlin lacks that permissive quality in exchange for much easier introspection.

It’s often trivial to move from one to the other but those edge cases can find you in a codebase of any complexity.

Author here. What most people don't realize is that "I hate programming my build." is a symptom of your existing build tools making programming your build dangerous and risky endeavor.

For example, in Maven you typically extend your build in Bash scripts + maven-exec-plugin, Ant script + maven-antrun-plugin, or custom Maven plugins entirely. None of these are "nice" programming environments, with proper IDE support, typechecking, introspectability, and so on. Writing lots of logic in Bash or Ant is risky, so you would be right to minimize writing code in it

Similarly, in Gradle you extend your build in Groovy/Kotlin, but it's a kind of "weird" Groovy/Kotlin unlike anything you'd write in application code. For example, your IDE support in Gradle-Kotlin is much worse than what you get in normal-Kotlin. Despite Gradle-Kotlin being the same language and same IDE, it's a much worse experience writing it, it's much easier to make mistakes, and so you are right to minimize the code you write in it.

In Mill, the build scripts are in Scala, but that's not the important part. The important part is you write normal code using classes, methods, and overrides. IDEs are very good at navigating classes, methods and overrides, and developers are very familiar with working with classes, methods, and overrides. And so build code in Mill feels as comfortable as your application code in Java/Scala/Kotlin: same quality of IDE experience, same typechecking, even can use the same Java third-party libraries (if you wish).

So it's understandable you hate programming your build. In Maven or Gradle or SBT, I'd hate programming my build as well. What Mill offers is that you can program your build where necessary without the hate that comes with doing so in other build tools!

I am old. I used ant, ported to maven when I discovered it (yes Maven 1). Always stuck with it. Maven has been a really nice consistent build tool. I never had to build something so complex it did not know what to do. And no I never used the ant plugin; it's an anti-pattern for Maven. Custom maven plugin's is perfectly fine (I never needed it) but if you need them you probably are doing it wrong (IMHO). My build are never that complex as I mainly write reasonably standard software for businesses.

Nice how you say "your IDE support in...", to refer to IntelliJ. I avoid that. I use Visual Studio Code and Netbeans.

BTW: writing something in bash means it will work for at least a decade. All people on my team will know how it works and understand it and maintain it. Introducing something new mean we all need to learn it. Yesterday my build for a simple website failed because gulp was updated and I ported the entire build to a bash script. It was faster and way simpler.

Let me make it clear here: I hate Grails. I think you have the same gripe as I do. They keep changing the DSL so you need to rewrite your scripts. Since it is a programming language each project has a different build even though most projects are the same. Because people do the same stuff differently.

When I have an issue with maven I will try Mill. Promised.

A few days ago I saw a nice tweet being shared and it wend something like: I am not allowed to use my airco as it eats to much power and we must think about the environment. Meanwhile: people non-stop generating rule 34 images using AI...

Ok tried to execute 'ls'. Worked and it showed me some files. Tried to type 'less' and it just kept doing weird stuff. Removed my input and tried it again; it interpreted it as 'ls' and again showed me the content.

Thank you; I thought I was the only one that did not get that

Thank you; this is exactly what was bothering me. This is my opinion as well you just found the words I could not find!

I am too dumb for this. I get a salary and maybe a bonus. I never worked at a company that gave stock or options. When I do I will share the offers to someone that understands this. But I will most likely choose the company that shares my values and ignore the payout (unless it's realky a bad pay)

This is the way.

Even when I had multiple startup offers, "Likelihood of becoming rich" was only one column in a 13 column ranking. I ranked them in sorted order on each column, added up their ranks across columns, and accepted the one with the lowest sum of ranks. I have done this for every of my jobs and it's fine. I add or change columns each time. It has led me (eventually) to my current job which is far and away my favorite.

I kept former offers in the ranking as well, as a sort of "secretary problem" running solution.

I do not know anything about that SOC 2 (or any official sounding framework for that matter). I work at a large municipality in the Netherlands and they also meticulously document every step so that the auditors can trace and verify everything. Seeing what they did to achieve this goal I would say that the next step (their suggestion) to do ISO would be a breeze as all those 'frameworks' require meticulously documentation.

... and visual basic 1.0 for DOS