Debug Adapter Protocol

You're speaking super hand wavy though. What specific protocol is better than JSON? I'm sure there are plenty, but that's not the point.

The point is, if it's not as common as JSON then it can hardly be considered easier, can it? If I have to write a implementation of X protocol just to work with this DAP or LSP, is that really easier?

Imo, commonality is hugely important when you're trying to work with every editor and every language (that editors are written in) out there.

I'm not saying there isn't a binary protocol that would be in every language out there. However JSON basically is, at the very least. So lets talk apples to apples about what you think is better, because "Binary protocols" is the vague sense are not even remotely as common and widely supported as JSON.

Don't get me wrong, I sort of hate JSON. Yet for many applications, especially those seeking compliance with everything under the sun, it has merit.

You're describing easier for a computer, which isn't really relevant. For a developer, parsing JSON is clearly easier than parsing a binary format. For effectively every major language nowadays, it's a single function call, and you're done, it's hard to beat that.

In practice, sending & parsing JSON instead of a binary format is not going to make your debugging experience here any _noticeably_ slower (if you have a DAP case where it does, I'd love to see it) and it is going to make development quicker & easier, and make the traffic inflight easier to debug too.

It's a tradeoff of course, but for most cases it's worthwhile.

Does not mean anything.

Who defines the "difficulty" of a protocol based on serialization?!

What is that even supposed to mean?

The protocol can be hard to understand, it can make unreasonable demands of users, it can have a ton of bloat or complex backwards compatibility rules.

But the serialization method literally orthogonal to complexity of the protocol itself

Implementing a protobuf serializer or implementing a JSON serializer would be completely 100% outside of the scope of a protocol that uses either.

Doubly so when you're talking about JSON, which has serializers just about everywhere, so you can't even say "oh well the protocol is easy to understand but the serialization method is hard to implement".

If anything using a custom binary serialization implementation would be the worst of both worlds, now consumers have to implement custom serialization AND you have to solve all the issues other solutions did like endianness, backwards compatibility... not having gaping security vulnerabilities...

This is like saying a protocol is "difficult" because you used it over HTTP so now somehow it inherited the entire complexity of HTTP.

Their protocol's complexity isn't defined by it's serialization any more than it is by the transport they're using.

I won't even bother replying to the rest of that, just very vague handwavy rhetoric that's not saying anything much.

Can I use the protocol with simple command line tools or do I have to spend several hours coding up a protocol handler?

Will implementers be more or less likely to fuck up their implementation of a binary protocol?

How will you version the binary protocol? How will you maintain backwards compatibility?

I call them the peanut gallery and the best way to deal when them is to pat them on their head for being so smart, thank them for their opinion and ignore everything they said. Failure to mute them will derail any project lead by a junior dev who doesn’t get know how to deal with pot shots from the peanut gallery. The poor junior dev will actually listen to the worthless feedback and stall the project.

I’m sure the folks who worked on this protocol are rolling their eyes at this comment thread...

1) Write a JSON library from scratch.

2) Write a method to handle a binary format from scratch.

3) Compare them.

I understand that you are likely relying on some JSON library or language feature, and I would argue that you will bear the weight of that all of that code the instant it has any problem, and that you bear the performance cost every time you use it. Maybe that library or language feature doesn't have any functionality bugs that you encounter; you will still pay for the loss in performance for as long as you use it.

Maybe this is acceptable. For me, if I'm writing a tool that either delivers a result that a human relies on, or is a tool that a human uses, I consider it immoral to waste that human's time without a very good reason.

I always try to avoid wasting my own time. Reasoning about code that reads and writes binary files is much easier for me than reasoning about an entire JSON library.

Desktop, laptop, and tablet CPUs are not getting faster overall. In fact, they're getting slower as cores are added to the silicon dies.

We've lived as developers for far too long under the performance gains provided by hardware advancement. Software has generally improved performance only when put on newer and faster hardware platforms. As a general rule, faster hardware platforms aren't a guarantee anymore. We may have more cores to run on, or more CPUs thrown at us to improve performance, yes. We can improve performance in other ways, with zero hardware cost. Avoiding JSON unless it is actually needed is one way we can reclaim performance from the debt of our previous decisions.

First of all, there's graphemes are inherently not one-to-one with code points, e.g. Á = A + `. There's simply no Unicode encoding that will let you safely index into an array without paying attention to the meaning of the underlying codepoints. (and no, using NFC won't solve this either, because there are combinations for which there's no composed equivalent)

Secondly, general formatting info won't fit into 11 bits (italic, bold, underline, strikethrough - that's already 4 bits, and we haven't talked about color, font weights other than bold, etc.), so why bother baking in a limited, intentionally gimped version into your character encoding?