Hacker News Reader

Comment by kayodelycaon | Hacker News Reader

> The LSP specification is big. Really big. Last time I checked it had 90 (!) methods and 407 (!!) types. Printing it to a PDF gives you 285 pages (!!!).

Given what it does, that’s pretty dang small. You don’t get all those features across every programming language without some complexity.

Compared to the 3,000+ pages specifications I’ve dealt with, this is easy.

I have a very tiny violin and a cricket to play it for anyone complaining about a few hundred pages. :)

View on HN

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.

For comparison, YAML is 77 pages.

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.

YAML is known to be incredibly complex and nuanced, which is why I choose it as a comparison.

Also, 77 is 37% of 285.

> Also, 77 is 37% of 285.

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.

> 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?

Reminds me of this quote:

> 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

Written by Alan Perils, shared in "Epigrams in Programming" (1982): https://cpsc.yale.edu/epigrams-programming

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.

I was gonna say, I’ve had to pore over 800+ page PDFs from the 3GPP describing like, the possible fields for one particular protocol in the LTE spec. 285 pages for the whole shebang feels Hemingwayesque.

Your argument basically boils down to "I am cooler than you because I have worked on larger specs". The fact that there are hilariously larger documents doesn't offer any perspective on whether you need 300 pages to describe how to color source code in a text editor.

But good for you! Here's a very tiny award.

I pulled up a random section and saw a method the editor sends right before a save so that the lsp can do format on save. I think format on save is pretty handy. Would you cut it?

(There's two methods, one with a timeout. In an ideal world maybe that would be one but I totally understand how initially they maybe assumed format on save would always be reasonably quick and then had to backtrack)

In all seriousness, I do have a point. I’ve read enough documentation to know the size of LSP’s documentation is what I would expect for something of that complexity.

The author’s surprise speaks more to their unfamiliarity with projects at this scale than anything special about LSP.

And I had to be sarcastic about it. That’s why I had :) at the end of my comment.

As far as being cooler, I’m not. If anything the author is way cooler. I’m just a random snarky dog on the internet. :)

Reply on news.ycombinator.com