The Norway Problem

Post by kstenerud » Sun, Apr 04, 2021, 6:11 AM UTC

yyyk wrote: post #259

kstenerud wrote: post #232

Earlier quoted context omitted.

Alright that's two votes against unquoted strings so far (plus my wife agrees so that's three against!) I put in octal because it was trivial to implement after the others. The canonical format when it's stored or being sent is binary, and a decoder shouldn't be presenting integers in octal (that would just be weird). But a human might want octal when inputting data that will be converted to the binary format. Markup…

Well, unquoted strings work when a format is built for that. If the default was "it's text unless we see the special sequences" it would be better for unquoted strings. But even then there are too many special characters in this format IMHO. I saw there's a 'Media' type in the spec. It's seems the type is actually for serializing files. But there's no "name" (or we can call it "description") field. Of course we could…

Post by azernik » Sun, Apr 04, 2021, 6:46 AM UTC

adwn wrote: post #92

azernik wrote: post #24

YAML had a worse example, once. For the ease of entering time units YAML 1.1 parsed any set of two digits, separated by colons, as a number in sexagesimal (base 60). So 1:11:00 would parse to the integer 4260, as in 1 hour and 11 minutes equals 4260 seconds. Now try plugging MAC addresses into that parser. The most annoying part is that the MAC addresses would only be mis-parsed if there were no hex digits in the str…

> For the ease of entering time units YAML 1.1 parsed any set of two digits, separated by colons, as a number in sexagesimal (base 60). This is a mind-boggling level of idiocy. Even leaving aside the MAC address problem, this conversion treats "11:15" (= 675) different from "11:15:00" (= 40500), even though those denote the same time, while treating "00:15:00" (15 minutes past midnight) and "15:00" (3 in the afternoo…

Post by Kliment » Sun, Apr 04, 2021, 9:54 AM UTC

ravanave wrote: post #109

Btw, the reason Haskell isn’t used more isn’t type system per se, as all types can be inferred at the compilation time. People would sometimes use this feature even to see if GHCi guesses the type correctly (by correctly I mean exactly how the user wants, technically it’s correct always) first time and save them some time writing it either with an extension or just copy&paste from the interpreter window. When it gets…

Post by lopespm » Sun, Apr 04, 2021, 12:38 PM UTC

Post by BlueTemplar » Sun, Apr 04, 2021, 1:12 PM UTC

wnoise wrote: post #180

pdkl95 wrote: post #171

Earlier quoted context omitted.

edit: fixed formatting problem > sentinel values Using in-band signaling always involves the risk of misinterpreting types. > This is part of more general problem DWIM ("Do What I Mean") was a terrible way to handle typos and spelling errors when Warren Teitelman tried it at Xerox PARC[1] over 50 years ago. From[2]: >> In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PAR…

Eh. "Death of the Author" is a reaction to the text not being dispositive as to what the author meant. It's deciding you don't care what the author meant, no longer considering it a problem that the text doesn't reveal that. Instead the text means whatever you can argue it means. Which can be a fun game, but is ultimately pointless.