4 ms·

I doubt you are in the minority, if only experienced developers are considered. JavaScript developers really do hold skewed ideas about what kinds of things ar

I doubt you are in the minority, if only experienced developers are considered. JavaScript developers really do hold skewed ideas about what kinds of things are useful and worth the overhead that they incur. Binary protocols are easier than JSON, to me, and to most people I would say, who have actually implemented a binary protocol or wrote code to read or write binary files.

onion2k 7y ago
JavaScript developers... JSON isn't really anything to do with JavaScript any more. It's a format that's used with practically every language. Any experienced developer should know that.
- naikrovek 7y ago
  > JSON isn't really anything to do with JavaScript any more. JSON has a lot to do with JavaScript. I don't know why you think JavaScript doesn't have anything to do with JSON. JSON and JavaScript are used together every day.
  - onion2k 7y ago
    JSON is a universal data transport protocol. It's used with JavaScript, obviously, but it's used with practically every language as well. When someone says they use JSON it doesn't mean they're a JavaScript developer.
rmetzler 7y ago
I don’t get it. First every language brings a JSON parser. It’s easy to debug. You also don’t have any overhead for parsing in JavaScript based editors like VSCode and Atom. And second, When the protocol is robust and needs to be faster, you can still switch to protocol buffers or something similar.
- Crinus 7y ago
  C doesn't bring anything. If i want to implement an IDE in C for performance and portability reasons, with a binary protocol that works over sockets i'd only need to worry about that binary protocol and sockets are provided by every OS. With DAP i'd need to implement a JSON parser, a subset of HTTP and of course the DAP itself. (yes, there are 3rd party libraries that provide some or all of the above, but they may not be applicable for a variety of reasons, including API stability, maintainability, compiler support, host/target OS support, tooling support, C language version support and a bunch of others)
- TeMPOraL 7y ago
  > You also don’t have any overhead for parsing in JavaScript based editors like VSCode and Atom. Of course you do, something has to actually read the strings and parse them into JS data structures.
- naikrovek 7y ago
  I can't believe that people have communally forgotten how easy binary protocols are. You don't need protobuf, you don't need json, you don't need any of these things that just add bloat and cost you performance. Writing and reading binary is easy, and is FAR easier than JSON if you are using something like C. Most languages have convenience methods for strings, yes, and those can be stacked on top of each other so that JSON libraries can be written, of course. Those libraries are FAR slower than just reading and writing bytes, and deserializing those bytes into structs or serializing those structs into a byte array, and the binary data is much smaller than a JSON document containing the same data would be. People these days are acting like binary protocols are hard, or that they are suboptimal for one reason or another. I guarantee you that someone who was trying to find a bug in a JSON library will spend as much time or more than someone trying to find a similar bug in a method that reads or writes binary data, and at the end of it, the person who looked at the methods that handle binary data will FULLY understand what is happening in that code. The person debugging the JSON library will almost certainly not have a full understanding of the JSON library after finding and fixing a bug unless they wrote it to begin with. It comes down to this - all computer programs do is process data. All UX problems, all usability problems, all computer problems boil down to problems transforming data. Transforming data is literally the only thing a computer can do. Any work spent writing code that does not directly solve the data transformation problem at hand is wasted time and work on the part of the developer. Any performance lost using code that does not directly solve the data transformation problem at hand is time away from the CPU for other tasks, time away from a consumer of that data, and so on. It adds up, and it adds up quickly.
BoorishBears 7y ago
If only "experienced developers" are considered, they won't start attacking their choice to use JSON without greater insight into the parameters under which they choose it and whether the "overhead" is actually a problem. Especially not with broad vagaries like "Binary protocols are easier than JSON".
- naikrovek 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. 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.

onion2k 7y ago

JavaScript developers... JSON isn't really anything to do with JavaScript any more. It's a format that's used with practically every language. Any experienced developer should know that.

naikrovek 7y ago
> JSON isn't really anything to do with JavaScript any more. JSON has a lot to do with JavaScript. I don't know why you think JavaScript doesn't have anything to do with JSON. JSON and JavaScript are used together every day.
- onion2k 7y ago
  JSON is a universal data transport protocol. It's used with JavaScript, obviously, but it's used with practically every language as well. When someone says they use JSON it doesn't mean they're a JavaScript developer.

rmetzler 7y ago

I don’t get it. First every language brings a JSON parser. It’s easy to debug. You also don’t have any overhead for parsing in JavaScript based editors like VSCode and Atom. And second, When the protocol is robust and needs to be faster, you can still switch to protocol buffers or something similar.

Crinus 7y ago
C doesn't bring anything. If i want to implement an IDE in C for performance and portability reasons, with a binary protocol that works over sockets i'd only need to worry about that binary protocol and sockets are provided by every OS. With DAP i'd need to implement a JSON parser, a subset of HTTP and of course the DAP itself. (yes, there are 3rd party libraries that provide some or all of the above, but they may not be applicable for a variety of reasons, including API stability, maintainability, compiler support, host/target OS support, tooling support, C language version support and a bunch of others)
TeMPOraL 7y ago
> You also don’t have any overhead for parsing in JavaScript based editors like VSCode and Atom. Of course you do, something has to actually read the strings and parse them into JS data structures.
naikrovek 7y ago
I can't believe that people have communally forgotten how easy binary protocols are. You don't need protobuf, you don't need json, you don't need any of these things that just add bloat and cost you performance. Writing and reading binary is easy, and is FAR easier than JSON if you are using something like C. Most languages have convenience methods for strings, yes, and those can be stacked on top of each other so that JSON libraries can be written, of course. Those libraries are FAR slower than just reading and writing bytes, and deserializing those bytes into structs or serializing those structs into a byte array, and the binary data is much smaller than a JSON document containing the same data would be. People these days are acting like binary protocols are hard, or that they are suboptimal for one reason or another. I guarantee you that someone who was trying to find a bug in a JSON library will spend as much time or more than someone trying to find a similar bug in a method that reads or writes binary data, and at the end of it, the person who looked at the methods that handle binary data will FULLY understand what is happening in that code. The person debugging the JSON library will almost certainly not have a full understanding of the JSON library after finding and fixing a bug unless they wrote it to begin with. It comes down to this - all computer programs do is process data. All UX problems, all usability problems, all computer problems boil down to problems transforming data. Transforming data is literally the only thing a computer can do. Any work spent writing code that does not directly solve the data transformation problem at hand is wasted time and work on the part of the developer. Any performance lost using code that does not directly solve the data transformation problem at hand is time away from the CPU for other tasks, time away from a consumer of that data, and so on. It adds up, and it adds up quickly.

BoorishBears 7y ago

If only "experienced developers" are considered, they won't start attacking their choice to use JSON without greater insight into the parameters under which they choose it and whether the "overhead" is actually a problem. Especially not with broad vagaries like "Binary protocols are easier than JSON".

naikrovek 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. 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.