Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Norway Problem

hitchdev.com

Post reply on HN
Print view View original

281–290 of 339 posts

Re: The Norway Problem

#281

Post by wongarsu »

mcv wrote: post #269
wongarsu wrote: post #209

Earlier quoted context omitted.

Also JSON's complete lack of many commonly used types, and no way to define any new ones.

Isn't that a problem with most of these config languages, though? XML is the only one where I think this might be possible.

Allowing you to define types is quite uncommon, but many config languages allow more types than JSON (so more than boolean, number, string, list, dict). Date datatypes are a big one and are provided by about every second JSON variant, in addition to TOML, ION and others.

Re: The Norway Problem

#282

Post by erik_seaberg »

goatinaboat wrote: post #91
WalterBright wrote: post #47

> The most tragic aspect of this bug, howevere, is that it is intended behavior according to the YAML 2.0 specification. This is one of those great ideas that sadly one needs experience to realize are really bad ideas. Every new generation of programmers has to relearn it. Other bad ideas that resurface constantly: 1. implicit declaration of variables 2. don't really need a ; as a statement terminator 3. assert shoul…

This is one of those great ideas that sadly one needs experience to realize are really bad ideas. Every new generation of programmers has to relearn it. It's a bad idea because ASCII already includes dedicated characters for field separator, record separator and so on. These could easily be made displayable in a text editor if you wanted just as you can display newlines as ↲. Anyone who invents a format that involves…

US-ASCII only has four information separators, and I believe they can only be used in a four-layer schema with no recursion, sort of like CSV (if your keyboard didn’t have a comma or quote or return key). When you need to pass an object with records of fields inside a field you’re out of luck, and everyone has to agree on quoting or encoding or escaping again.

I think SGML (roll your own delimiters and nesting) was pretty close to the Right Thing,™ but ISO has the specs locked down so everyone had a second-hand understanding of it.

Re: The Norway Problem

#283

Post by erik_seaberg »

tralarpa wrote: post #70
lixtra wrote: post #65

Earlier quoted context omitted.

I’m surprised that with your experience you come to such unbalanced conclusions. Everything in engineering is about trade-offs and while your conclusions may be indisputable for the design goals of D they may wrong in other contexts. 1. If I scribble some one time code etc. the probability of having an error coming from implicit declarations is in the same order of magnitude as missing out edge cases or not getting t…

> 1. If I scribble some one time code .... and here is another entry for Walter's list of bad ideas: 4. "It's okay. I will use this code only once"

My favorite Red Green quote is “now, this is only temporary … unless it works.”

Re: The Norway Problem

#284

Post by neop1x »

rubyn00bie wrote: post #226
atombender wrote: post #191

The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…

Your list is like a graveyard of my dreams and hopes. Anything that doesn't validate the format of the underlying data is pretty much dead to me... The problem with most of these is they're useless to describe the data. Honestly, it is completely not useful to have the following to describe data: email => string name => string dob => string IMHO, it is akin to having a dictionary (like Oxford English) read like: emai…

Amazon Ion [1] supports schema [2] and it all looks quite nice to me. Maybe it deserves wider adoption.

[1] https://amzn.github.io/ion-docs/ [2] https://amzn.github.io/ion-schema/

Re: The Norway Problem

#285

Post by ufo »

samatman wrote: post #276
ufo wrote: post #189

Earlier quoted context omitted.

Another inreresting example is Lua. It's a free form language without semicolons. It's not indentation sensitive.

Lua does have semicolons! It even has semicolon insertion, but because the language is carefully designed, this doesn't cause problems, and most users can go a lifetime without knowing about it. Our coding style requires semicolons for uninitialized variables, so you'll see local x; if flag then x = 12 else x = 24 end As a way of marking that the lack of initialization is deliberate. `local x = nil` is used only if x…

I don't like saying that it's semicolon insertion because it might give people the idea that the semicolons work similarly to Javascript. In Lua, inserting a semicolon is always optional and it's an stylistic matter (like in your example). It even allows putting multiple statements on the same line without a semicolon.

    -- Two assignment statements
    x = 10 y = 20

Re: The Norway Problem

#286

Post by Meniteos4 »

They decided to go against the YAML standard and therefore are no longer a YAML parser. The actual answer to this problem would have been to use a better storage format. Perhaps JSON5? or TOML?

Re: The Norway Problem

#287

Post by jhugo »

_kdhr wrote: post #265
alpaca128 wrote: post #153

Earlier quoted context omitted.

> E.g. sort by this field will happily do a decimal sort instead of the string 00.10. So that system is not consistent with type checking? How is this not considered a bug?

I mean if the value is imported as a decimal, then a sort by that field will sort as decimal. This might not be obvious if a system imports 23.53, 53.98 etc - a user would think it looks good. It only becomes clear that it was an error to import as a decimal when we consider cases like “00.10”. E.g, package versions: 10.10 is a newer version than 10.1. Types only help if you pick the right ones.

Sure. In most static type systems though, you would be importing the data into structures that you defined, with defined types. So you wouldn’t suddenly get a Decimal in place of a String just because the data was different. You’d get a type error on import.

Re: The Norway Problem

#288

Post by nullsense »

keeperofdakeys wrote: post #25

This is part of more general problem, they had to rename a gene to stop excel auto-completing it into a date. https://www.theverge.com/2020/8/6/21355674/human-genes-renam... Edit: Apparently Excel has its own Norway Problem ... https://answers.microsoft.com/en-us/msoffice/forum/msoffice_...

Easiest solution is just to rename Norway.

Re: The Norway Problem

#289

Post by fmakunbound »

MrPatan wrote: post #274
takeda wrote: post #262

Earlier quoted context omitted.

Because it offered all these things parent responded, but that made it too complex. You either provide schema and get commodities of describing it or you don't. I had a chance of using SOAP at one point. It was a F5 device and I used a python library. What I really liked is that when it connected to it it downloaded its schema, and then used that to generate an object. At that point you just communicated with device…

Parent didn't say it was harder to use from JS. Parent said "It had to be replaced with JSON by the web developers though, so they could just “eval() it” to get their data." First of all, I was there 20 years ago. I had to deal with XML, XSLT, one kind of Java XML parsers that didn't fully do what I needed, another kind of Java XML parsers that didn't fully do what I needed. And oh boy was it a pain. I just wanted to…

> Second, JSON always had a parser in JS, so I don't know where that eval nonsense is coming from.

Firstly, it sounds like XML ran over your dog or something. Sorry to hear about that. It wasn’t particularly hard to use at all, and if you’re dealing with the possibility of emojis in your JSON UUIDs in 2021, one might even say it’s easier to use.

If you’re referring to JSON.parse() in “had a parser” above, then you have a temporal problem. Regarding eval(), it’s suggested right in the original RFC for JSON. Check it out. Web developers at the time were following that advice.

Re: The Norway Problem

#290

Post by kstenerud »

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…

The media object is for embedding media within a document (an image, a sound, an animation, some bytecode to execute in a sandbox, or whatever). It's not intended to be used as an archive format for storing files (which, as you said, could be trivially accomplished with a byte array for the data, a string for the file name, and some metadata like permissions etc). A file is just one way among many to store media (in this case as an entry in a hierarchical database - the filesystem - keyed by filename). CE is only interested in the media itself, not the database technology.

The media object is a way to embed media data directly into a document such that the receiving end will have some idea of how to deal with it (from its media type). It won't have or need a "file name" because it's not intended to be stored in a filesystem, but rather to be used directly by an application. Yes, it could be built up from the primitives, but then you lose the canonical "media" type, and everyone invents their own incompatible compound types (much like what happened with dates in JSON and XML).

Post reply on HN