5 ms·

> 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 tha

> 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.
- cookiecaper 7y ago
  Definitely feel your frustration re: JSON for something as close-to-the-metal as a debugger. It seems like the issue is understood: people prefer string-based protocols because they can read and interpret them at a glance with no ramp up time, whereas a binary protocol requires extra tooling and manual translation (at least until the programmer memorizes it). Whether or not programmer comfort/ease should be the primary driver of development decisions, it's hard to pretend like it's not at this point. Probably competes only with "buzzword needed for my resume" in terms of the true rationale behind system design, regardless of the flimsy justifications that people may try to make up. Taking that into consideration, the reason MS may release a debug protocol based on JSON is that they want developers to use it, and developers will always use the thing that looks simplest at a superficial glance. I've found, for example, that most devs will cram arbitrarily large quantities of production-critical data into anything that vaguely resembles a data hole and then yell and scream when you try to explain the meaning of "cache", "ramdisk", or even "temporary" to them. Expecting more from the developing public at large is just setting oneself up for failure.
  - BoorishBears 7y ago
    > I've found, for example, that most devs will cram arbitrarily large quantities of production-critical data into anything that vaguely resembles a data hole and then yell and scream when you try to explain the meaning of "cache", "ramdisk", or even "temporary" to them. Expecting more from the developing public at large is just setting oneself up for failure. I was going to point out how disgustingly condescending this was and how it reeks of someone who overinflates their own sense of ability via ego... but then I read your profile which brags about getting muted and whatnot and realized that's exactly what you take pride in so...
    - cookiecaper 7y ago
      /shrug It's a conclusion that's been burned into me after many years of attempting to recover from data loss events precipitated by people who just want to get their boxes ticked in the most convenient way possible and get home, with no regard for whether what they're doing is sustainable or appropriate. If you haven't been exposed to that in the course of your career, then I'm happy for you. As for "bragging" about HN's censorship, the snippet was added after people emailed to ask why I had stopped responding to them. I can see where you're coming from on the tone and I'll try to make a few adjustments and see where that gets us. Thanks for sharing your POV -- honest feedback is hard to come by. :)

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.

cookiecaper 7y ago
Definitely feel your frustration re: JSON for something as close-to-the-metal as a debugger. It seems like the issue is understood: people prefer string-based protocols because they can read and interpret them at a glance with no ramp up time, whereas a binary protocol requires extra tooling and manual translation (at least until the programmer memorizes it). Whether or not programmer comfort/ease should be the primary driver of development decisions, it's hard to pretend like it's not at this point. Probably competes only with "buzzword needed for my resume" in terms of the true rationale behind system design, regardless of the flimsy justifications that people may try to make up. Taking that into consideration, the reason MS may release a debug protocol based on JSON is that they want developers to use it, and developers will always use the thing that looks simplest at a superficial glance. I've found, for example, that most devs will cram arbitrarily large quantities of production-critical data into anything that vaguely resembles a data hole and then yell and scream when you try to explain the meaning of "cache", "ramdisk", or even "temporary" to them. Expecting more from the developing public at large is just setting oneself up for failure.
- BoorishBears 7y ago
  > I've found, for example, that most devs will cram arbitrarily large quantities of production-critical data into anything that vaguely resembles a data hole and then yell and scream when you try to explain the meaning of "cache", "ramdisk", or even "temporary" to them. Expecting more from the developing public at large is just setting oneself up for failure. I was going to point out how disgustingly condescending this was and how it reeks of someone who overinflates their own sense of ability via ego... but then I read your profile which brags about getting muted and whatnot and realized that's exactly what you take pride in so...
  - cookiecaper 7y ago
    /shrug It's a conclusion that's been burned into me after many years of attempting to recover from data loss events precipitated by people who just want to get their boxes ticked in the most convenient way possible and get home, with no regard for whether what they're doing is sustainable or appropriate. If you haven't been exposed to that in the course of your career, then I'm happy for you. As for "bragging" about HN's censorship, the snippet was added after people emailed to ask why I had stopped responding to them. I can see where you're coming from on the tone and I'll try to make a few adjustments and see where that gets us. Thanks for sharing your POV -- honest feedback is hard to come by. :)