7 ms·

Over 20 years ago, after I had devised a way to use Gray Code to embed a clock into a signal without increasing the signal's modulated bandwidth, one of my engi

by smoyer 7y ago

Over 20 years ago, after I had devised a way to use Gray Code to embed a clock into a signal without increasing the signal's modulated bandwidth, one of my engineers said that someday there'd be a "Moyer's Law". I thought that was funny, so I created one myself: Moyer's Law: "When we can finally print from any computer to any printer consistently, there will be no CS problems left to solve." Since every good law has a corollary, I created one of those too (simply to be funnier): The Corollary to Moyer's Law: "The printed dates will still be wrong." While PDFs have brought us closer to "universal printing", I won't claim we're anywhere close to solving all CS problems. Sadly, date conversion and formatting continue to be problems (hint, consider UTC ISO-8601 or RFC3339 dates/times for the JSON representation). P.S. I don't actually think I'm smart enough to have a law named after me ... nor have I really contributed enough to "our art". - https://en.wikipedia.org/wiki/Gray_code https://en.wikipedia.org/wiki/Gray_code - https://www.electronics-notes.com/articles/radio/modulation/frequency-modulation-fm-sidebands-bandwidth.php https://www.electronics-notes.com/articles/radio/modulation/...

thrtythreeforty 7y ago
Do you mind explaining the gray-code-clock technique?
vbezhenar 7y ago
Temporal literals really deserve dedicated syntax in JSON. I'm bored to parse yet another "18.2.2020".
- smoyer 7y ago
  I agree but I'd like the generic implementation of that. JSON schema never really took off and I believe that part of the reason is that there's not a way to indicate what type might be contained in a string or number (I'm okay with JSON booleans and null). As ugly as it could get, adding XML Schemas to XML documents did in fact help the parser. The reason I stated I'd like the generic version is that there are other types that we use consistently. There's a very nice RFC available for telephone numbers that we've started following and we can marshal/unmarshal pretty easily from strongly typed languages (where we control the code), but wouldn't it be nice if there was a standard way (within the JSON to let systems know it was a telephone number? - https://tools.ietf.org/html/rfc3966 https://tools.ietf.org/html/rfc3966
  - optimiz3 7y ago
    Adding a schema meta language just creates unnecessary complexity. Instead of 1 language now there's two. If you're going to invent a new language like json-schema, you might as well skip to json2. People who care about schemas already enforce this at the serialization layer where the objects being mapped to implicitly are the schema. Pushing the schema down to the protocol just adds complexity and bloat.
    - hyperpallium 7y ago
      > the objects being mapped to implicitly are the schema Dynamic languages don't have an enforced schema. You can do it manually, but a schema is easier, special-purpose, declarative. Plus, data schema languages are typically far more expressive than programming languages. e.g. java doesn't even have nonnullable (which C had, as non-typedef structs). They're closer to a database schema.
  - osmarks 7y ago
    CBOR (https://cbor.io/ https://cbor.io/) allows custom types, but it's a binary format and not anywhere near as popular.
  - eropple 7y ago
    I dunno, JSON Schema seems to have certainly found a lot of traction where it makes sense--web responses, etc. That may to some extent be a POV thing, as I work on a lot of OpenAPI-consuming and -producing systems myself, but I never really have to dig around to find schemas and the like for stuff I really care about. VSCode even has JSON Schema support built in, which is cool. I use that a lot.
  - hyperpallium 7y ago
    My theory is that XML has got all the uglies you could ever want (and more), so why not just use that instead of defiling JSON? Also, thingo aggressively protected JSON's simplicity, banishing comments because people were using them as parser directives.
  - silvestrov 7y ago
- cortesoft 7y ago
  Just use Unix time everywhere.
  - vbezhenar 7y ago
    I would just use ISO-8601 everywhere. I would happily use it for ordinary life! But it's not always me who builds API.
    - saber6 7y ago
      Yeah but what about relativity? ISO8601 won't scale to universe-level applications! :)
      - deleted 7y ago
        [deleted]
  - stickfigure 7y ago
    Presumably you mean unix time as a numeric scalar in the JSON. That is still not self-describing - is it time, or just a number? Which scalar data type should your parser use? And is it seconds since epoch or milliseconds since epoch?
    - cortesoft 7y ago
      It should be maintained as a numeric scalar until you are going to do something with the value... and if you are going to do something with the value, you should know if it is a date or not. JSON isn't meant to be self-describing format. There is JSON schema or the like if that is what you are after.
      - stickfigure 7y ago
        JSON isn't meant to be self-describing format. And yet to a very large extent, it is. Strings, numbers, booleans, arrays, and associative maps made the cut. Timestamps would be a pretty reasonable addition. It would certainly cut out all the controversy here.
- elygre 7y ago
  "18.2.2020" seems easy. I once walked into a meeting room where the whiteboard said "Deadline: 4/7/3". No idea what I was reading.
  - deleted 7y ago
    [deleted]
  - thaumasiotes 7y ago
    18.2.2020 is easy if you recognize that 2020 must be a year and 18 can't be a month. But if you want to parse 18.2.2020, you probably want the same parser to handle 1.2.2020.
  - 2007 7y ago
    Well, we know the year probably wouldn't have been 2007, because, I mean, come on, who does that? The year in the middle? Really? So that means... 2004/7/MAR APR/7/2003 If they're both in the past, you can erase it, since it's obviously not a deadline anymore. If one's in the past, then only the other possibility, March 7, 2004 might matter. If they were both in the future, you have to assume April 7, 2003 to be safe and early. Nonetheless, depending on project scale, a one year margin of error might only make sense for some realities. So, context could probably inform the truth, and outsiders can take it on the arches.
- carapace 7y ago
  That's a can of hairy worms right there. Check out "Falsehoods programmers believe about time": https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...
  - gombosg 7y ago
    Hairy indeed. I just spent 2 days programming a timezone selector in a React form that changes the displayed date/time as you switch timezones but the underlying UTC representation wouldn't change. All this without loading 500k JS timezone libraries. I only used Intl API and tz.js [1]. The trick simply was to temporarily shift the date by the difference between the local time and the edited time zone. :) [1] https://github.com/dynasty-com/tzjs https://github.com/dynasty-com/tzjs
    - daurnimator 7y ago
      > The trick simply was to temporarily shift the date by the difference between the local time and the edited time zone. :) If you're near a change in daylight savings then that will go wrong.
      - carapace 7y ago
        Yeah, not to be rude (we've all been there) but that hack is bound to be borken somehow. Really this time & timezone stuff should be handled by the OS, system calls or libs should be more sophisticated so we aren't "solving" these problems over and over again. But I'm about to start ranting about Unicode, so I'll shut up now... ;-)
- l0b0 7y ago
  To be universally applicable it would have to support at least date, time, time zone and time zone database version (since time zone definitions keep changing). You would then have to define how each of these look in a backward- and forward-compatible manner and define what every combination of them means. For example, a time and time zone but no date or time zone database could mean that time of day in that time zone on any day, using the time zone database active at that date and time. Not saying it can't be done, but it's a big job.
downerending 7y ago
PDFs notwithstanding, I think we've actually moved backwards over the last thirty years, in terms of printing "just working". Fortunately, we now have teleconferencing to take our minds off of it.
- jimbokun 7y ago
  "Fortunately, we now have teleconferencing to take our minds off of it." "Does anyone have an HDMI to DisplayPort adapater on them? What's the phone number for this conference again? What? You only have Slack installed? No, we decided to start using Microsoft Teams for these. Can you speak up? I'm having trouble hearing you. Maybe try dialing in again?"
  - fphhotchips 7y ago
    "Hey does anyone know the guest wifi password?" "Sorry, I was double muted" "Can you turn mute on? There's a lot of echo on your end" "Sorry, we're just trying to work out which mic works"
    - smoyer 7y ago
      We had to contact our desktop support group to program the bridge number into the conferencing telephone we use for our stand-ups every day because they'd disabled the ability to program it from the touch-screen and keypad. Cisco VoIP phones now have echo cancelling that I think is as good as the old Polycom Star Trek phones, but having them managed by CCM may be a step backwards. P.S. We're still manually dialing every day while waiting for our ticket to be processed.
- quickthrowman 7y ago
  Perhaps home printers are a wasteland, but the copy/printers and plotters at my work are pretty dang reliable, considering they do thousands of pages or thousands of linear feet a day sometimes.
  - downerending 7y ago
cek 7y ago
Moyer's Law is legit. Thank you for coining it. For some reason I've gravitated to printing since my earliest computing days and your law speaks to me deeply. I've recently been working on a source code printing app (yes, I'm nuts) and have been blown away by how bad printers are today. I thought the troubles I had at home were "just me". Cheers to you!
dwmkerr 7y ago
Love it :) I think the "consistently connect to a projector" is similar. Moyle's Law seems popular here and has generated a great conversation, I'll raise it as a suggestion on the repo and see what people think!
- smoyer 7y ago
  I guess since it's lasted 20+ years, perhaps it's more prescient than I thought? EDIT: I see that you've submitted an RFC but it misses (what I think is) the point. It's really the corollary of the law that is important as it states how hard it is to do date/time correctly (and you'll notice that the bulk of the discussion here is on the corollary). As I noted above, this was intended to be funny and including it in a list with real laws is just that much funnier!

by smoyer 7y ago

thrtythreeforty 7y ago

Do you mind explaining the gray-code-clock technique?

vbezhenar 7y ago

Temporal literals really deserve dedicated syntax in JSON. I'm bored to parse yet another "18.2.2020".

smoyer 7y ago
I agree but I'd like the generic implementation of that. JSON schema never really took off and I believe that part of the reason is that there's not a way to indicate what type might be contained in a string or number (I'm okay with JSON booleans and null). As ugly as it could get, adding XML Schemas to XML documents did in fact help the parser. The reason I stated I'd like the generic version is that there are other types that we use consistently. There's a very nice RFC available for telephone numbers that we've started following and we can marshal/unmarshal pretty easily from strongly typed languages (where we control the code), but wouldn't it be nice if there was a standard way (within the JSON to let systems know it was a telephone number? - https://tools.ietf.org/html/rfc3966 https://tools.ietf.org/html/rfc3966
- optimiz3 7y ago
  Adding a schema meta language just creates unnecessary complexity. Instead of 1 language now there's two. If you're going to invent a new language like json-schema, you might as well skip to json2. People who care about schemas already enforce this at the serialization layer where the objects being mapped to implicitly are the schema. Pushing the schema down to the protocol just adds complexity and bloat.
  - hyperpallium 7y ago
    > the objects being mapped to implicitly are the schema Dynamic languages don't have an enforced schema. You can do it manually, but a schema is easier, special-purpose, declarative. Plus, data schema languages are typically far more expressive than programming languages. e.g. java doesn't even have nonnullable (which C had, as non-typedef structs). They're closer to a database schema.
- osmarks 7y ago
  CBOR (https://cbor.io/ https://cbor.io/) allows custom types, but it's a binary format and not anywhere near as popular.
- eropple 7y ago
  I dunno, JSON Schema seems to have certainly found a lot of traction where it makes sense--web responses, etc. That may to some extent be a POV thing, as I work on a lot of OpenAPI-consuming and -producing systems myself, but I never really have to dig around to find schemas and the like for stuff I really care about. VSCode even has JSON Schema support built in, which is cool. I use that a lot.
- hyperpallium 7y ago
  My theory is that XML has got all the uglies you could ever want (and more), so why not just use that instead of defiling JSON? Also, thingo aggressively protected JSON's simplicity, banishing comments because people were using them as parser directives.
- silvestrov 7y ago
cortesoft 7y ago
Just use Unix time everywhere.
- vbezhenar 7y ago
  I would just use ISO-8601 everywhere. I would happily use it for ordinary life! But it's not always me who builds API.
  - saber6 7y ago
    Yeah but what about relativity? ISO8601 won't scale to universe-level applications! :)
    - deleted 7y ago
      [deleted]
- stickfigure 7y ago
  Presumably you mean unix time as a numeric scalar in the JSON. That is still not self-describing - is it time, or just a number? Which scalar data type should your parser use? And is it seconds since epoch or milliseconds since epoch?
  - cortesoft 7y ago
    It should be maintained as a numeric scalar until you are going to do something with the value... and if you are going to do something with the value, you should know if it is a date or not. JSON isn't meant to be self-describing format. There is JSON schema or the like if that is what you are after.
    - stickfigure 7y ago
      JSON isn't meant to be self-describing format. And yet to a very large extent, it is. Strings, numbers, booleans, arrays, and associative maps made the cut. Timestamps would be a pretty reasonable addition. It would certainly cut out all the controversy here.
elygre 7y ago
"18.2.2020" seems easy. I once walked into a meeting room where the whiteboard said "Deadline: 4/7/3". No idea what I was reading.
- deleted 7y ago
  [deleted]
- thaumasiotes 7y ago
  18.2.2020 is easy if you recognize that 2020 must be a year and 18 can't be a month. But if you want to parse 18.2.2020, you probably want the same parser to handle 1.2.2020.
- 2007 7y ago
  Well, we know the year probably wouldn't have been 2007, because, I mean, come on, who does that? The year in the middle? Really? So that means... 2004/7/MAR APR/7/2003 If they're both in the past, you can erase it, since it's obviously not a deadline anymore. If one's in the past, then only the other possibility, March 7, 2004 might matter. If they were both in the future, you have to assume April 7, 2003 to be safe and early. Nonetheless, depending on project scale, a one year margin of error might only make sense for some realities. So, context could probably inform the truth, and outsiders can take it on the arches.
carapace 7y ago
That's a can of hairy worms right there. Check out "Falsehoods programmers believe about time": https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...
- gombosg 7y ago
  Hairy indeed. I just spent 2 days programming a timezone selector in a React form that changes the displayed date/time as you switch timezones but the underlying UTC representation wouldn't change. All this without loading 500k JS timezone libraries. I only used Intl API and tz.js [1]. The trick simply was to temporarily shift the date by the difference between the local time and the edited time zone. :) [1] https://github.com/dynasty-com/tzjs https://github.com/dynasty-com/tzjs
  - daurnimator 7y ago
    > The trick simply was to temporarily shift the date by the difference between the local time and the edited time zone. :) If you're near a change in daylight savings then that will go wrong.
    - carapace 7y ago
      Yeah, not to be rude (we've all been there) but that hack is bound to be borken somehow. Really this time & timezone stuff should be handled by the OS, system calls or libs should be more sophisticated so we aren't "solving" these problems over and over again. But I'm about to start ranting about Unicode, so I'll shut up now... ;-)
l0b0 7y ago
To be universally applicable it would have to support at least date, time, time zone and time zone database version (since time zone definitions keep changing). You would then have to define how each of these look in a backward- and forward-compatible manner and define what every combination of them means. For example, a time and time zone but no date or time zone database could mean that time of day in that time zone on any day, using the time zone database active at that date and time. Not saying it can't be done, but it's a big job.

downerending 7y ago

PDFs notwithstanding, I think we've actually moved backwards over the last thirty years, in terms of printing "just working". Fortunately, we now have teleconferencing to take our minds off of it.

jimbokun 7y ago
"Fortunately, we now have teleconferencing to take our minds off of it." "Does anyone have an HDMI to DisplayPort adapater on them? What's the phone number for this conference again? What? You only have Slack installed? No, we decided to start using Microsoft Teams for these. Can you speak up? I'm having trouble hearing you. Maybe try dialing in again?"
- fphhotchips 7y ago
  "Hey does anyone know the guest wifi password?" "Sorry, I was double muted" "Can you turn mute on? There's a lot of echo on your end" "Sorry, we're just trying to work out which mic works"
  - smoyer 7y ago
    We had to contact our desktop support group to program the bridge number into the conferencing telephone we use for our stand-ups every day because they'd disabled the ability to program it from the touch-screen and keypad. Cisco VoIP phones now have echo cancelling that I think is as good as the old Polycom Star Trek phones, but having them managed by CCM may be a step backwards. P.S. We're still manually dialing every day while waiting for our ticket to be processed.
quickthrowman 7y ago
Perhaps home printers are a wasteland, but the copy/printers and plotters at my work are pretty dang reliable, considering they do thousands of pages or thousands of linear feet a day sometimes.
- downerending 7y ago

cek 7y ago

Moyer's Law is legit. Thank you for coining it. For some reason I've gravitated to printing since my earliest computing days and your law speaks to me deeply. I've recently been working on a source code printing app (yes, I'm nuts) and have been blown away by how bad printers are today. I thought the troubles I had at home were "just me". Cheers to you!

dwmkerr 7y ago

Love it :) I think the "consistently connect to a projector" is similar. Moyle's Law seems popular here and has generated a great conversation, I'll raise it as a suggestion on the repo and see what people think!

smoyer 7y ago
I guess since it's lasted 20+ years, perhaps it's more prescient than I thought? EDIT: I see that you've submitted an RFC but it misses (what I think is) the point. It's really the corollary of the law that is important as it states how hard it is to do date/time correctly (and you'll notice that the bulk of the discussion here is on the corollary). As I noted above, this was intended to be funny and including it in a list with real laws is just that much funnier!