> `mycsv = pandas.read_csv("/path/to/input.csv")`

You have to count the words in the functions you call to get the correct length of the implementation, which in this case is far far more than 20 words. read_csv has more than 20 arguments, you can't even write the function definition in under 20 words.

Otherwise, I can run every program by importing one function (or an object with a single method, or what have you) and just running that function. That is obviously a stupid way to count.

I really can't tell if this is meant as a joke.

Anyway, I just wrote what I, personally, would type in a normal work day to accomplish this coding task.

It isn't a joke, you need the Kolmogorov complexity of the code that implements the feature, which has nothing to do with the fact that you're using someone else's solution. You may not have to think about all the code needed to parse a CSV, but someone did and that's a cost of the feature, whether you want to think about it or not.

Again, if someone else writes a 100,000 line function for you, and they wrap it in a "do_the_thing()" method, you calling it is still calling a 100,000 line function, the computer still has to run those lines and if something goes wrong, SOMEONE has to go digging in it. Ignoring the costs you don't pay is ridiculous.

We are comparing between a) asking an LLM to write code to parse a csv and b) writing code to parse a csv.

In both cases, they'll use a csv library, and a bajillion items of lower-level code. Application code is always standing on the shoulders of giants. Nobody is going to manually write assembly or machine code to parse a csv.

The original contention, which I was refuting, is that it's quicker and easier to use an LLM to write the python than it is to just write the python.

Kolmogorov complexity seems pretty irrelevant to this question.

You actually have to count the number of bytes in the generated machine code to get the real count

Ok but how much physical space do those bytes take up? Need to measure them.