7 ms·

I think OSC is interesting, but Armstrong goes too far in his disparagement of XML and JSON: > I think it is totally crazy to send JSON or XML “over the air” s

by ggreer 11y ago

I think OSC is interesting, but Armstrong goes too far in his disparagement of XML and JSON: > I think it is totally crazy to send JSON or XML “over the air” since this will degrade the performance of the applications giving a bad user experience and higher bills - since ultimately we pay for every bit of data. If every JSON and XML API switched to OSC, the difference in data usage would scarcely be measurable. First: The vast majority of mobile data is video, audio, images, and application updates. Second: When sent over the wire, JSON and XML are typically compressed with gzip or deflate. And let's not forget: JSON and XML have some significant advantages over most other serialization formats. They're ubiquitous. Practically every programming language has libraries to parse and generate them. Practically every programmer knows how to work with them. They're human-readable. No special programs are needed to view their contents. In other words, JSON and XML are only "wasteful" if you don't count developer time. Once you do, it suddenly makes a lot of sense to "waste" hardware resources. After all, programmers are expensive. Hardware is cheap.

colordrops 11y ago
> After all, programmers are expensive. Hardware is cheap. Except in China. I worked at a US company that did almost zero optimization on their code, deploying to 5000 AWS instances with a team of about six. In China, bandwidth closely followed by CPU were the cost centers, and the Chinese team of 30 engineers optimized the same code to run on around 50 (admittedly beefy) servers.
- lostcolony 11y ago
  Doesn't invalidate the point; another EC2 instance is a few dozen bucks a month to run full time; another developer, even overseas, is going to cost you more, at just 40 hours a week. But that said, it's rather a good thing to point out for the OP, as Joe Armstrong himself tends to value programmer time over a machine's, and that micro-optimizations are rarely ever worth it (as opposed to yours, which sounds like there were huge, glaring algorithmic issues to fix with macro optimizations, complete replacements of algorithms rather than tightening up code, careful profiling and tweaking to get a 30% speedup in one critical section, etc)
  - colordrops 11y ago
    I guess your response brings out the fact that it's not an either-or proposition. It's a sliding scale between dev resources and computer resources, based on the costs in your situation.
    - lostcolony 11y ago
      Yes, the exact tradeoff has to be calculated per instance, exactly how much programmer time would it take to reduce how much machine time. However, getting X hours of average programmer time, vs X hours of average machine time...machines are cheap. You should default to optimizing programmer time, not machine time.
  - im2w1l 11y ago
    4950 instances times a few dozen bucks a month, is like 2 million a year, just saying.
    - kuschku 11y ago
      And then you notice that companies that have to be profitable care, while that are just burning through VC money don't.
      - vidarh 11y ago
        This matters for VC funded companies too. I just moved a customer off EC2. A small startup. I've billed them about $20k for the work. It will take them ~2.5 months to repay in saved hosting costs at current load levels. But if they're still at current levels in 3 months time, something is wrong. On top of that their ops costs have dropped as we have more control over the environment. Basically, with rapidly growing hosting needs, getting a more cost effective setup was a matter of survival: They'd be unlikely to close another round of funding in the next few months if they didn't get that cost under control. I wonder how many startups fail because they don't understand how to get their hosting costs under control, as it's way too common that I see developers that seem to think that servers are basically free, and managers that have no clue they need to seriously question why developers are making the server choices they are making..
rozap 11y ago
I think part of what he's getting at is that if things embrace simplicity in their design, suddenly fact that "every programming language has a json parser" becomes less compelling, because it's easy to write this stuff yourself. Perhaps he goes a little bit far, but I'd agree that shoehorning your data serialization problems into a ubiquitous format can be a real headache.
rdtsc 11y ago
> And let's not forget: JSON and XML have some significant advantages over most other serialization formats. They're ubiquitous. Practically every programming language has libraries to parse and generate them. One of the interesting things about Erlang is it has binary pattern matching. Matching any binary in it is just as trivial or even more trivial than parsing json in other langauges. Here is what an IP packet parsing might look like: <<4:4, HeaderLength:4, _DiffServ:8, _Length:16, _Identification:16, _Flags:3, _FragOffset:13, _TTL:8, Protocol:8, _HeaderChecksum:16, SrcAddr:32/bits, DstAddr:32/bits, OptionsAndData/bytes>> It looks almost like casting a binary blob to a C struct, but you can do even crazier things like take Length and match it later in the pattern, if it specifies a length prefixed binary, for example. > the difference in data usage would scarcely be measurable It depends. See, Joe's background is from Ericsson. Their stuff controls access of 50% of world's smartphone <-> internet traffic. When people say "but who uses functional languages in the industry?" the answer is if functional languages won't work, chances are high, you won't see picture of cats on your smartphone. But the idea is that mobile bandwith is still a precious resourse. Even if our CPU and hard drives are getting bigger. That is one shared resource that is expensive. Maybe if a 1M clients use JSON vs a binary protocol doesn't make a difference much for some startup, when we talk about billions of connected devices talking over radio waves, those things add up. Well, also, game servers use UDP and binary often because of latency. Facebook knows a thing or two about chatting with lots of users, so they use Flatbuffers https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ https://code.facebook.com/posts/872547912839369/improving-fa... that's binary as well.
- viperscape 11y ago
  I think it's also important to note that json isn't exactly something that can be streamed while parsed.
  - viraptor 11y ago
    There are multiple libraries doing just that. For example https://sites.google.com/site/gson/streaming https://sites.google.com/site/gson/streaming
  - 11y ago
woah 11y ago
Compression only works well if there is a lot of repetition of key names in the stream being compressed. If you are sending individual objects it may not be able to do much. And compression will never be able to eliminate brackets and commas. You are right that for the majority of applications json is fine.
- cyphar 11y ago
  > And compression will never be able to eliminate brackets and commas. Isn't that the whole point of compression: to minimise repetition of common features in data?
  - voltagex_ 11y ago
    This'd be worth testing. Isn't the way gzip works to build up a dictionary of characters/phrases and then store pointers to the dictionary? I'm not sure you can compress { or } but }); is another story.
    - ggreer 11y ago
      I just ran that experiment: https://gist.github.com/ggreer/4eb3ad61e97926e559f6 https://gist.github.com/ggreer/4eb3ad61e97926e559f6 ASCII is extremely repetitive. 1MB of random braces gzips down to 163KB. That's a compression ratio of 6.1:1. Optimal compression would be close to 8:1 (since each byte really contains only one bit of information).
      - forgottenpass 11y ago
        for (let i = 0; i < 1024 * 1024; i++) { buf += Math.random() > 0.5 ? "{" : "}"; } Your sample data is bunk for determining the compression characteristics of braces in a realistic json file.
        ggreer 11y ago
        The point was to show that compression works at the level of bits, not characters. Realistic JSON is mostly content, which means your compression ratio depends more on content redundancies than braces or quotes. So too for binary serialization formats.
herval 11y ago
JSON and XML can also be wasteful on developer's time. I've seen a lot of time wasted in organizations where JSON was used as the communication medium between microservices (hundreds of them). Lots of time spent implementing parsers, watching out for changes, etc (of course, there's many process & culture "solutions" for these problems). Most of this goes away easily when you adopt a binary/IDL-based format (in the latest case I've been through, Thrift) JSON/XML are the "dynamic language" of the transport protocols: flexible and quick to prototype, but can become very hard to "refactor" and performance suffers, as the thing grows. As for public APIs, obviously agree with your point - it's a lot easier to roll out a JSON interface as parsing libraries are widespread, etc etc
- boomlinde 11y ago
  I don't see how using JSON/XML or not has anything to do with the problem of communicating changes. The problem isn't the underlying serialization format, but what kind of schema validation, versioning and type definitions you build around it and how you make sure that all consumers know or may find out about it. Interestingly you mention Thrift, which can seamlessly use both XML and JSON as its underlying protocol.
  - herval 11y ago
    Thrift and Protobuf both support JSON as transport, yes - it's useful when dealing with clients that can't support the binary encodings (eg browsers, last time I checked). It's an added benefit: you can use the fast encoding between clients that support it, but can fallback as needed. The difference between communicating changes by setting a bunch of rules on how to do versioning/structure/etc vs changing an IDL is akin to verifying a program structure with unit tests and code reviews vs enforcing them with a compiler (sure, you can always use stuff like Json Schema or XSLT - personally never had a good experience w/ those). The latter is far easier, in my experience.
- Too 11y ago
  Fully agree, the human readability of json and xml is "fake productivity", it tricks you into thinking the format is easy and invites you to do hacks like manually writing the serialization and only helps you short term. I've worked in places where binary serialization + deserialization functions were generated automatically by just adding a field and the bit-mapping into a message-spreadsheet. This was way more productive than misspelling the property name of a json-field between serializing and de-serializing and spending a whole day troubleshooting that. This also automatically documented the format instead of sending an example xml-file to your counterpart who is to implement loading of the data elsewhere and saying "the data will look aproximately like this". Viewing the data for debugging was done with a special program (similar to wireshark) that understood the protocol and rendered a much nicer view of the data than pasting a json-file into notepad++, there you need indentation and highlighting plugins anyway so the number of programs you need installed is not an argument either, streaming data through notepad++ doesn't work so well either if you want to view data on the fly. Security is also one aspect, at every place i've worked there is always one smartass that thinks xml can be created by string-concating, that's impossible if the serialization-functions are totally encapsulated. All this isn't a problem inherent to xml/json as it can all be solved with proper processes, it's just that it invites to that type of culture.
evincarofautumn 11y ago
> When sent over the wire, JSON and XML are typically compressed with gzip or deflate. …which probably amounts to CPU-years of wasted time and electricity, considering how ubiquitous this is.
- skewart 11y ago
  This could make for a really interesting data visualization. There are probably lots of things we do as programmers that are insignificant in the context of our own systems, but are so culturally ubiquitous that they add up to an enormous impact globally. I wonder how even things like different application architecture would consume different amounts of power. Or,is there a side effect of shifting computation to the client side of causing more energy to be consumed from dirtier sources, if, say, data centers tend to draw from cheap and clean hydro power.
- ggreer 11y ago
  Even with binary protocols, compression is worthwhile. No matter your serialization format, most of the bytes transferred are going to be payload. And most of the time, that payload is going to have redundancies. Also, modern implementations of decompression algorithms are very efficient. Mobile SoCs can approach 100MB/sec for deflate. In other words: If your phone downloads 10GB of compressed data a month, it's going to use an extra 3-4 seconds of CPU time per day. That's a rounding error. In fact, it's quite possible that the radio power savings outweigh that extra CPU usage.
  - ben_bai 11y ago
    The problem with compression is, it's everywhere. Sending a jpeg, over compressed http(s), throught a compressed and encrypted VPN is too much compression. Then the client may save the jpeg to a local compressed NTFS cache... This is just wasted performance, plus compressors are a common place for bugs, so this is also a security issue. Just stop adding compression to everything and think about it first, and then Mobile phones and modem lines may very well be an exception.
dschiptsov 11y ago
You probably would be surprised to realize that sane engineers nowadays are using this or that variant of "protocol buffers". Also there is a theoretical knowledge that nothing could beat messages of fixed-length headers with adjustable-length payloads of binary tagged data.
rdc12 11y ago
The other question about compressed JSON/XML, is how may clock cycles are getting spent on this that wouldn't be otherwise. Which on mobile devices is going to translate to power consumption.

by ggreer 11y ago

colordrops 11y ago

> After all, programmers are expensive. Hardware is cheap. Except in China. I worked at a US company that did almost zero optimization on their code, deploying to 5000 AWS instances with a team of about six. In China, bandwidth closely followed by CPU were the cost centers, and the Chinese team of 30 engineers optimized the same code to run on around 50 (admittedly beefy) servers.

lostcolony 11y ago
Doesn't invalidate the point; another EC2 instance is a few dozen bucks a month to run full time; another developer, even overseas, is going to cost you more, at just 40 hours a week. But that said, it's rather a good thing to point out for the OP, as Joe Armstrong himself tends to value programmer time over a machine's, and that micro-optimizations are rarely ever worth it (as opposed to yours, which sounds like there were huge, glaring algorithmic issues to fix with macro optimizations, complete replacements of algorithms rather than tightening up code, careful profiling and tweaking to get a 30% speedup in one critical section, etc)
- colordrops 11y ago
  I guess your response brings out the fact that it's not an either-or proposition. It's a sliding scale between dev resources and computer resources, based on the costs in your situation.
  - lostcolony 11y ago
    Yes, the exact tradeoff has to be calculated per instance, exactly how much programmer time would it take to reduce how much machine time. However, getting X hours of average programmer time, vs X hours of average machine time...machines are cheap. You should default to optimizing programmer time, not machine time.
- im2w1l 11y ago
  4950 instances times a few dozen bucks a month, is like 2 million a year, just saying.
  - kuschku 11y ago
    And then you notice that companies that have to be profitable care, while that are just burning through VC money don't.
    - vidarh 11y ago
      This matters for VC funded companies too. I just moved a customer off EC2. A small startup. I've billed them about $20k for the work. It will take them ~2.5 months to repay in saved hosting costs at current load levels. But if they're still at current levels in 3 months time, something is wrong. On top of that their ops costs have dropped as we have more control over the environment. Basically, with rapidly growing hosting needs, getting a more cost effective setup was a matter of survival: They'd be unlikely to close another round of funding in the next few months if they didn't get that cost under control. I wonder how many startups fail because they don't understand how to get their hosting costs under control, as it's way too common that I see developers that seem to think that servers are basically free, and managers that have no clue they need to seriously question why developers are making the server choices they are making..

rozap 11y ago

I think part of what he's getting at is that if things embrace simplicity in their design, suddenly fact that "every programming language has a json parser" becomes less compelling, because it's easy to write this stuff yourself. Perhaps he goes a little bit far, but I'd agree that shoehorning your data serialization problems into a ubiquitous format can be a real headache.

rdtsc 11y ago

> And let's not forget: JSON and XML have some significant advantages over most other serialization formats. They're ubiquitous. Practically every programming language has libraries to parse and generate them. One of the interesting things about Erlang is it has binary pattern matching. Matching any binary in it is just as trivial or even more trivial than parsing json in other langauges. Here is what an IP packet parsing might look like: <<4:4, HeaderLength:4, _DiffServ:8, _Length:16, _Identification:16, _Flags:3, _FragOffset:13, _TTL:8, Protocol:8, _HeaderChecksum:16, SrcAddr:32/bits, DstAddr:32/bits, OptionsAndData/bytes>> It looks almost like casting a binary blob to a C struct, but you can do even crazier things like take Length and match it later in the pattern, if it specifies a length prefixed binary, for example. > the difference in data usage would scarcely be measurable It depends. See, Joe's background is from Ericsson. Their stuff controls access of 50% of world's smartphone <-> internet traffic. When people say "but who uses functional languages in the industry?" the answer is if functional languages won't work, chances are high, you won't see picture of cats on your smartphone. But the idea is that mobile bandwith is still a precious resourse. Even if our CPU and hard drives are getting bigger. That is one shared resource that is expensive. Maybe if a 1M clients use JSON vs a binary protocol doesn't make a difference much for some startup, when we talk about billions of connected devices talking over radio waves, those things add up. Well, also, game servers use UDP and binary often because of latency. Facebook knows a thing or two about chatting with lots of users, so they use Flatbuffers https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ https://code.facebook.com/posts/872547912839369/improving-fa... that's binary as well.

viperscape 11y ago
I think it's also important to note that json isn't exactly something that can be streamed while parsed.
- viraptor 11y ago
  There are multiple libraries doing just that. For example https://sites.google.com/site/gson/streaming https://sites.google.com/site/gson/streaming
- 11y ago

woah 11y ago

Compression only works well if there is a lot of repetition of key names in the stream being compressed. If you are sending individual objects it may not be able to do much. And compression will never be able to eliminate brackets and commas. You are right that for the majority of applications json is fine.

cyphar 11y ago
> And compression will never be able to eliminate brackets and commas. Isn't that the whole point of compression: to minimise repetition of common features in data?
- voltagex_ 11y ago
  This'd be worth testing. Isn't the way gzip works to build up a dictionary of characters/phrases and then store pointers to the dictionary? I'm not sure you can compress { or } but }); is another story.
  - ggreer 11y ago
    I just ran that experiment: https://gist.github.com/ggreer/4eb3ad61e97926e559f6 https://gist.github.com/ggreer/4eb3ad61e97926e559f6 ASCII is extremely repetitive. 1MB of random braces gzips down to 163KB. That's a compression ratio of 6.1:1. Optimal compression would be close to 8:1 (since each byte really contains only one bit of information).
    - forgottenpass 11y ago
      for (let i = 0; i < 1024 * 1024; i++) { buf += Math.random() > 0.5 ? "{" : "}"; } Your sample data is bunk for determining the compression characteristics of braces in a realistic json file.
      - ggreer 11y ago
        The point was to show that compression works at the level of bits, not characters. Realistic JSON is mostly content, which means your compression ratio depends more on content redundancies than braces or quotes. So too for binary serialization formats.

herval 11y ago

JSON and XML can also be wasteful on developer's time. I've seen a lot of time wasted in organizations where JSON was used as the communication medium between microservices (hundreds of them). Lots of time spent implementing parsers, watching out for changes, etc (of course, there's many process & culture "solutions" for these problems). Most of this goes away easily when you adopt a binary/IDL-based format (in the latest case I've been through, Thrift) JSON/XML are the "dynamic language" of the transport protocols: flexible and quick to prototype, but can become very hard to "refactor" and performance suffers, as the thing grows. As for public APIs, obviously agree with your point - it's a lot easier to roll out a JSON interface as parsing libraries are widespread, etc etc

boomlinde 11y ago
I don't see how using JSON/XML or not has anything to do with the problem of communicating changes. The problem isn't the underlying serialization format, but what kind of schema validation, versioning and type definitions you build around it and how you make sure that all consumers know or may find out about it. Interestingly you mention Thrift, which can seamlessly use both XML and JSON as its underlying protocol.
- herval 11y ago
  Thrift and Protobuf both support JSON as transport, yes - it's useful when dealing with clients that can't support the binary encodings (eg browsers, last time I checked). It's an added benefit: you can use the fast encoding between clients that support it, but can fallback as needed. The difference between communicating changes by setting a bunch of rules on how to do versioning/structure/etc vs changing an IDL is akin to verifying a program structure with unit tests and code reviews vs enforcing them with a compiler (sure, you can always use stuff like Json Schema or XSLT - personally never had a good experience w/ those). The latter is far easier, in my experience.
Too 11y ago
Fully agree, the human readability of json and xml is "fake productivity", it tricks you into thinking the format is easy and invites you to do hacks like manually writing the serialization and only helps you short term. I've worked in places where binary serialization + deserialization functions were generated automatically by just adding a field and the bit-mapping into a message-spreadsheet. This was way more productive than misspelling the property name of a json-field between serializing and de-serializing and spending a whole day troubleshooting that. This also automatically documented the format instead of sending an example xml-file to your counterpart who is to implement loading of the data elsewhere and saying "the data will look aproximately like this". Viewing the data for debugging was done with a special program (similar to wireshark) that understood the protocol and rendered a much nicer view of the data than pasting a json-file into notepad++, there you need indentation and highlighting plugins anyway so the number of programs you need installed is not an argument either, streaming data through notepad++ doesn't work so well either if you want to view data on the fly. Security is also one aspect, at every place i've worked there is always one smartass that thinks xml can be created by string-concating, that's impossible if the serialization-functions are totally encapsulated. All this isn't a problem inherent to xml/json as it can all be solved with proper processes, it's just that it invites to that type of culture.

evincarofautumn 11y ago

> When sent over the wire, JSON and XML are typically compressed with gzip or deflate. …which probably amounts to CPU-years of wasted time and electricity, considering how ubiquitous this is.

skewart 11y ago
This could make for a really interesting data visualization. There are probably lots of things we do as programmers that are insignificant in the context of our own systems, but are so culturally ubiquitous that they add up to an enormous impact globally. I wonder how even things like different application architecture would consume different amounts of power. Or,is there a side effect of shifting computation to the client side of causing more energy to be consumed from dirtier sources, if, say, data centers tend to draw from cheap and clean hydro power.
ggreer 11y ago
Even with binary protocols, compression is worthwhile. No matter your serialization format, most of the bytes transferred are going to be payload. And most of the time, that payload is going to have redundancies. Also, modern implementations of decompression algorithms are very efficient. Mobile SoCs can approach 100MB/sec for deflate. In other words: If your phone downloads 10GB of compressed data a month, it's going to use an extra 3-4 seconds of CPU time per day. That's a rounding error. In fact, it's quite possible that the radio power savings outweigh that extra CPU usage.
- ben_bai 11y ago
  The problem with compression is, it's everywhere. Sending a jpeg, over compressed http(s), throught a compressed and encrypted VPN is too much compression. Then the client may save the jpeg to a local compressed NTFS cache... This is just wasted performance, plus compressors are a common place for bugs, so this is also a security issue. Just stop adding compression to everything and think about it first, and then Mobile phones and modem lines may very well be an exception.

dschiptsov 11y ago

You probably would be surprised to realize that sane engineers nowadays are using this or that variant of "protocol buffers". Also there is a theoretical knowledge that nothing could beat messages of fixed-length headers with adjustable-length payloads of binary tagged data.

rdc12 11y ago

The other question about compressed JSON/XML, is how may clock cycles are getting spent on this that wouldn't be otherwise. Which on mobile devices is going to translate to power consumption.