What sticks out to me is that there's less than one method per every four types. Given that, I assume that most of these types are just plain structs or type aliases; in other words, just names for things. I'm not sure what the author is trying to convey with that; would it be better if there were half as many types but they all had twice as many fields and methods and had to get used for multiple purposes?
If the scope of the project is too large, that's certainly a valid complaint, but independent of somehow measuring the expected "size" of an API to cover a given scope, I don't really see how these raw numbers are particularly concerning. I'd be more concerned if the ratio of methods to types were reversed, but still a bit skeptical of any significance without more context.
Maybe I'm lisp-damaged, but I agree with this quote and parent, more functions (not methods) and less data structures tend to be easier to manage when things grow in scope.
Interesting, I hadn't heard this before! My immediate reaction is that yes, I agree with principle as he states it exactly, but that's because anything with two dimensions where one of them is "1" is always going to be simpler because it's effectively one-dimensional. I don't think the comparison is fair because of that; I'd rather 100 functions and one data structure than 10 of each, but I'd prefer 100 data structures and a single function compared to that.
YAML is a data serialization language that doesn't have any concept of "execution"; LSP needs to encode not just one full programming language semantics, but _arbitrary_ programming language semantics. YAML's spec being over 3/4 the size of LSP is a lot more damning to YAML to me.
Not sure why I misremembered the number of pages so inaccurately; I must have gotten so focused on the method/type numbers to the point of ignoring the page count
I do think that "incredibly nuanced" is a relative term; it's nuanced and complex because it's competing in a space where the default option is JSON, which for all of its faults is extraordinarily simple. In my mind, a data format is just a set of "nouns", compared to a protocol which has to also define "verbs" alongside those nouns. It's not even comparing apples and oranges; it's comparing an apple with the act of growing an apple from a seed into a tree. Maybe I'm misunderstanding, and the YAML specification includes an API definition?
I wasn’t trying for an orange to orange comparison. I assumed developer familiar with YAML would be able to make a rough guess how they compare.
Maybe I’m assuming too much? I’ve read a lot of documentation.
As a side note, YAML does have internal templating. You can give an object a name and use it elsewhere like a class. I think that feature makes it turning complete.
If the scope of the project is too large, that's certainly a valid complaint, but independent of somehow measuring the expected "size" of an API to cover a given scope, I don't really see how these raw numbers are particularly concerning. I'd be more concerned if the ratio of methods to types were reversed, but still a bit skeptical of any significance without more context.