3 ms·

Binary protocols ARE easier than JSON. I'm counting everything involved in handling JSON, and you may not be; Lexing, parsing, and so on. Those things simply

Binary protocols ARE easier than JSON. I'm counting everything involved in handling JSON, and you may not be; Lexing, parsing, and so on. Those things simply don't exist in binary. they add weight to code that simply doesn't need to be there if you're using a binary protocol. A computer program (an IDE in this scenario) talking to another computer program (the debugger) simply does not need to use JSON! By choosing to use JSON, a choice was made to make the protocol far more inefficient than it needed to be. The result will be a slower than necessary debugging experience for all who use it. Debuggers already consume enough developer time per day! Choices should be made to make developer lives better, not worse.

spookthesunset 7y ago
Can inspect a binary protocol in a text editor? Or do I have to go hunt down a hex editor? 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?
pimterry 7y ago
> Binary protocols ARE easier than JSON. I'm counting everything involved in handling JSON, and you may not be; Lexing, parsing, and so on. Those things simply don't exist in binary. they add weight to code that simply doesn't need to be there if you're using a binary protocol. 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.
- naikrovek 7y ago
  > 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. If you're talking about the ability of the human eye and brain to see the binary format and understand it, then yes. JSON is pre-humanized. I would say that it's pretty easy to write a visualizer for binary data if you know the format, and I would add that the time taken to write that visualizer is trivial compared to the execution time saved by using a binary file or protocol over JSON over even a short period of time. > 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. Debugging performance of a debugger is orders of magnitude larger than the time saved by using a binary file/format, you're right. That's a problem with debuggers, not with binary data storage. > It's a tradeoff of course, but for most cases it's worthwhile. Yeah for many cases JSON is a fine choice. For a protocol that goes between a computer program and another computer program (such as the IDE and the debugger process, as in the use case of the Debug Adapter Protocol) it is a bad choice. It's necessarily slower and more wasteful of bandwidth and CPU time than a binary protocol would have been. Debuggers are slow enough, they don't need to be made slower by using JSON.
BoorishBears 7y ago
This sentence: "Binary protocols ARE easier than JSON." 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.
asdkhadsj 7y ago
> Binary protocols ARE easier than JSON. 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.
- naikrovek 7y ago
  > What specific protocol is better than JSON? I'm sure there are plenty, but that's not the point. The format needed to solve the problem you're working on. > 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? If it's easier to understand and to write, then yes. That's what "easier" means. > Imo, commonality is hugely important when you're trying to work with every editor and every language (that editors are written in) out there. "commonality?" Do you mean "usage?" If it's easy to write code to handle a given binary format that you need for your own problems, writing libraries for other languages is essentially trivial, and you avoid sitting underneath all of those JSON libraries, which is a huge win! > 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. It does have merit, you're right; and I am not saying that a binary file/protocol should be used in all cases, and JSON in none. I am saying that the performance lost by using JSON is significant, even though it feels like it is not. I am saying that when you choose to use JSON when a binary format suited to the problem would suffice, that you are necessarily wasting time and effort that could be solved actually solving the problem you need to solve. I am saying that JSON, in most problems that I have seen it applied to, is not the best solution, not the fastest solution, not the most effective solution, and not the easiest solution to fix when something breaks. When those four things are true is when JSON seems to be used the most often, and that is what I have a problem with. Are we software engineers or are we not? I argue that we're not, despite demanding that we be called engineers, in many cases. We don't measure what we do to see what is most efficient or has the best performance or the lowest cost. We don't start with a budget of some kind then write our software so that we do not exceed it. We rationalize our software development decisions away as being "good enough" without doing ANY measurement against our own imaginary acceptance criteria or really any solid justification of that position at all. We count on users not noticing delays or not caring enough about them so we can be lazy and/or save time in development. I think those things are a problem. Programming is not an art. Everything about programming and the programs created, including developers and their time, can be measured and improved. Virtually no one does this. Virtually no one seeks to improve their skills solely so they can become better and produce better results; everyone is concerned about the newest technology coming down the pipe because it is "cool" and not even considering its applicability to a given problem. ... Obviously I have a lot to say about this. I think I've said enough, and I'm sorry I dumped this all in a reply to you. It certainly is not all directed at you, specifically.

spookthesunset 7y ago

Can inspect a binary protocol in a text editor? Or do I have to go hunt down a hex editor? 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?

pimterry 7y ago

> Binary protocols ARE easier than JSON. I'm counting everything involved in handling JSON, and you may not be; Lexing, parsing, and so on. Those things simply don't exist in binary. they add weight to code that simply doesn't need to be there if you're using a binary protocol. 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.

naikrovek 7y ago
> 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. If you're talking about the ability of the human eye and brain to see the binary format and understand it, then yes. JSON is pre-humanized. I would say that it's pretty easy to write a visualizer for binary data if you know the format, and I would add that the time taken to write that visualizer is trivial compared to the execution time saved by using a binary file or protocol over JSON over even a short period of time. > 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. Debugging performance of a debugger is orders of magnitude larger than the time saved by using a binary file/format, you're right. That's a problem with debuggers, not with binary data storage. > It's a tradeoff of course, but for most cases it's worthwhile. Yeah for many cases JSON is a fine choice. For a protocol that goes between a computer program and another computer program (such as the IDE and the debugger process, as in the use case of the Debug Adapter Protocol) it is a bad choice. It's necessarily slower and more wasteful of bandwidth and CPU time than a binary protocol would have been. Debuggers are slow enough, they don't need to be made slower by using JSON.

BoorishBears 7y ago

This sentence: "Binary protocols ARE easier than JSON." 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.

asdkhadsj 7y ago

> Binary protocols ARE easier than JSON. 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.

naikrovek 7y ago
> What specific protocol is better than JSON? I'm sure there are plenty, but that's not the point. The format needed to solve the problem you're working on. > 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? If it's easier to understand and to write, then yes. That's what "easier" means. > Imo, commonality is hugely important when you're trying to work with every editor and every language (that editors are written in) out there. "commonality?" Do you mean "usage?" If it's easy to write code to handle a given binary format that you need for your own problems, writing libraries for other languages is essentially trivial, and you avoid sitting underneath all of those JSON libraries, which is a huge win! > 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. It does have merit, you're right; and I am not saying that a binary file/protocol should be used in all cases, and JSON in none. I am saying that the performance lost by using JSON is significant, even though it feels like it is not. I am saying that when you choose to use JSON when a binary format suited to the problem would suffice, that you are necessarily wasting time and effort that could be solved actually solving the problem you need to solve. I am saying that JSON, in most problems that I have seen it applied to, is not the best solution, not the fastest solution, not the most effective solution, and not the easiest solution to fix when something breaks. When those four things are true is when JSON seems to be used the most often, and that is what I have a problem with. Are we software engineers or are we not? I argue that we're not, despite demanding that we be called engineers, in many cases. We don't measure what we do to see what is most efficient or has the best performance or the lowest cost. We don't start with a budget of some kind then write our software so that we do not exceed it. We rationalize our software development decisions away as being "good enough" without doing ANY measurement against our own imaginary acceptance criteria or really any solid justification of that position at all. We count on users not noticing delays or not caring enough about them so we can be lazy and/or save time in development. I think those things are a problem. Programming is not an art. Everything about programming and the programs created, including developers and their time, can be measured and improved. Virtually no one does this. Virtually no one seeks to improve their skills solely so they can become better and produce better results; everyone is concerned about the newest technology coming down the pipe because it is "cool" and not even considering its applicability to a given problem. ... Obviously I have a lot to say about this. I think I've said enough, and I'm sorry I dumped this all in a reply to you. It certainly is not all directed at you, specifically.