3 ms·

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 VS

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.
- spookthesunset 7y ago
  I’ve worked on many projects and nothing is more annoying or tiring than dealing with people that have zero vested interest in the project outcome and have no understanding of a projects requirements, history, schedule and constraints chiming in with their worthless opinions. 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...
camgunz 7y ago
> Every language brings a JSON parser Yeah more or less that's true, but in typed languages especially it's pretty inconvenient (unless you circumvent the type system or dump directly into a hash table, but that's usually bad). > It's easy to debug There are tons of corner cases re: parsing JSON [1]. Plus things like canonicalization and duplicate keys are pretty confounding. > You also don’t have any overhead for parsing in JavaScript based editors like VSCode and Atom. JSON isn't JavaScript and parsing it with `eval` is super bad practice. And there is indeed parsing overhead [2]. [1]: http://seriot.ch/parsing_json.php#4 http://seriot.ch/parsing_json.php#4 [2]: https://github.com/msgpack/msgpack-javascript#benchmark https://github.com/msgpack/msgpack-javascript#benchmark

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.

spookthesunset 7y ago
I’ve worked on many projects and nothing is more annoying or tiring than dealing with people that have zero vested interest in the project outcome and have no understanding of a projects requirements, history, schedule and constraints chiming in with their worthless opinions. 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...

camgunz 7y ago

> Every language brings a JSON parser Yeah more or less that's true, but in typed languages especially it's pretty inconvenient (unless you circumvent the type system or dump directly into a hash table, but that's usually bad). > It's easy to debug There are tons of corner cases re: parsing JSON [1]. Plus things like canonicalization and duplicate keys are pretty confounding. > You also don’t have any overhead for parsing in JavaScript based editors like VSCode and Atom. JSON isn't JavaScript and parsing it with `eval` is super bad practice. And there is indeed parsing overhead [2]. [1]: http://seriot.ch/parsing_json.php#4 http://seriot.ch/parsing_json.php#4 [2]: https://github.com/msgpack/msgpack-javascript#benchmark https://github.com/msgpack/msgpack-javascript#benchmark