6 ms·

Good idea, but why JSON? And why HTTP content headers? I much prefer binary protocols, but I'm probably within a minority on that one.

MrBuddyCasino 7y ago
Yeah I can see this being a bottleneck for inspecting large arrays. Maybe they‘ll add more transports over time.
- royjacobs 7y ago
  Indeed, there's no reason this can't be extended in the future (and indeed content negiotated through regular HTTP).
- naikrovek 7y ago
  It uses JSON-RPC which isn't held to a specific transport that I'm aware of. Currently in VSCode if you use a language server for Go, it launches the language server and appears to simply pipe data in and out using STDIN and STDOUT. That should be pretty fast if there isn't a cmd.exe somewhere in the mix. There's a lot of talk about fast C++ JSON libraries and how they can parse 1GB of JSON per second, and that's a lot of data, for sure, if you only count the data that's wrapped up in JSON. 1GB of JSON data contains a lot of waste that is not even usable data, and that's before you consider the textual encoding of what may better be represented by binary data, which inflates the size of a JSON file even further than the JSON syntax itself does. A binary file that is read at 1GB per second would contain far, far more actual data, and binary files can be read and written much more quickly than 1GB/s. I'm really starting to lose patience with all the JSON and web technologies that are finding their way into non-web use cases. using binary formats and simple programs to handle them is really, truly, easier to rationalize about, easier to maintain, easier to write, and easier to replace when the time comes.
  - rmetzler 7y ago
    Sorry, this is for debugging. How much state are you planning to transfer in a debugging session?
    - saagarjha 7y ago
      Perhaps a dump of a section in memory?
    - 0xffff2 7y ago
      Practically by definition, anything up to and including the total program state (i.e. the total amount of memory being used).
  - icholy 7y ago
    Unless you have fixed width messages which you can directly map to a packed struct, json is waaayyy simpler to write and maintain.
    - naikrovek 7y ago
      100% complete and total disagreement from me. 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.
      - icholy 7y ago
        100% complete and total disagreement from me. 1. Write your own C compiler. 2. Implement your binary encoding/decoding. I understand that you're relying on gcc or clang, and I would argue that you will bear the weight of that all of that code the instant it has any problem.
        7y ago
irq-1 7y ago
This is the debugger counterpart to the Language Server Protocol. (Which also uses http/jsonrpc) https://microsoft.github.io/language-server-protocol/specification https://microsoft.github.io/language-server-protocol/specifi...
naikrovek 7y ago
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)
spookthesunset 7y ago
What problem, specifically, are you trying to solve for? Given all the other constraints on the product, how does making a binary protocol fit in? What trade offs will be made if they used a binary protocol?
- reallydude 7y ago
  Binary data is lossy over json without more encoding/decoding, for example. HTTP is slooow, which is fine for stepping. But step debugging is not a problem that needs solving...unless.... This is a move toward being able to debug programs on Azure with VSCode remotely.
Matthias247 7y ago
For something without high performance requirements (like the command&control messages for this debugging adapter) I don't care too much about the efficiency of the serialization and the protocol. But what I would care about is that it's easy to create a protocol specification and to generate most of the boilerplate code out of it - so that the schema gets automatically verified and that developers can focus on building their application logic instead of getting the serialization right. That can be done with JSON too (e.g. with json-schema or by generating code out of typescript definitions). However I haven't yet checked whether LSP and the debug protocol make use of this.

MrBuddyCasino 7y ago

Yeah I can see this being a bottleneck for inspecting large arrays. Maybe they‘ll add more transports over time.

royjacobs 7y ago
Indeed, there's no reason this can't be extended in the future (and indeed content negiotated through regular HTTP).
naikrovek 7y ago
It uses JSON-RPC which isn't held to a specific transport that I'm aware of. Currently in VSCode if you use a language server for Go, it launches the language server and appears to simply pipe data in and out using STDIN and STDOUT. That should be pretty fast if there isn't a cmd.exe somewhere in the mix. There's a lot of talk about fast C++ JSON libraries and how they can parse 1GB of JSON per second, and that's a lot of data, for sure, if you only count the data that's wrapped up in JSON. 1GB of JSON data contains a lot of waste that is not even usable data, and that's before you consider the textual encoding of what may better be represented by binary data, which inflates the size of a JSON file even further than the JSON syntax itself does. A binary file that is read at 1GB per second would contain far, far more actual data, and binary files can be read and written much more quickly than 1GB/s. I'm really starting to lose patience with all the JSON and web technologies that are finding their way into non-web use cases. using binary formats and simple programs to handle them is really, truly, easier to rationalize about, easier to maintain, easier to write, and easier to replace when the time comes.
- rmetzler 7y ago
  Sorry, this is for debugging. How much state are you planning to transfer in a debugging session?
  - saagarjha 7y ago
    Perhaps a dump of a section in memory?
  - 0xffff2 7y ago
    Practically by definition, anything up to and including the total program state (i.e. the total amount of memory being used).
- icholy 7y ago
  Unless you have fixed width messages which you can directly map to a packed struct, json is waaayyy simpler to write and maintain.
  - naikrovek 7y ago
    100% complete and total disagreement from me. 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.
    - icholy 7y ago
      100% complete and total disagreement from me. 1. Write your own C compiler. 2. Implement your binary encoding/decoding. I understand that you're relying on gcc or clang, and I would argue that you will bear the weight of that all of that code the instant it has any problem.
      - 7y ago

irq-1 7y ago

This is the debugger counterpart to the Language Server Protocol. (Which also uses http/jsonrpc) https://microsoft.github.io/language-server-protocol/specification https://microsoft.github.io/language-server-protocol/specifi...

naikrovek 7y ago

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)

spookthesunset 7y ago

What problem, specifically, are you trying to solve for? Given all the other constraints on the product, how does making a binary protocol fit in? What trade offs will be made if they used a binary protocol?

reallydude 7y ago
Binary data is lossy over json without more encoding/decoding, for example. HTTP is slooow, which is fine for stepping. But step debugging is not a problem that needs solving...unless.... This is a move toward being able to debug programs on Azure with VSCode remotely.

Matthias247 7y ago

For something without high performance requirements (like the command&control messages for this debugging adapter) I don't care too much about the efficiency of the serialization and the protocol. But what I would care about is that it's easy to create a protocol specification and to generate most of the boilerplate code out of it - so that the schema gets automatically verified and that developers can focus on building their application logic instead of getting the serialization right. That can be done with JSON too (e.g. with json-schema or by generating code out of typescript definitions). However I haven't yet checked whether LSP and the debug protocol make use of this.