I presume he's just referring to the use of tags and how they're parsed

I got that job!

Grats! Just in time for Destiny 2 drop next week!

Jsx gets turned into html not javascript

Well, I mean, HTML is a subset of XML and JSX is too. So I guess? I don't know what "under the hood" means because that's usually a reference to how something is done rather than what it's made of.

Anyway we are now at the point where daveT doesn't think either XML or JSON is appropriate for "large data" so I am still curious: what the hell are we supposed to use?

true but i was just saying in the sense of

React.createElement("h1", null, "title")

Congrats!

Parquet.

I'll be honest. I have no idea what "large data" means in this context.

Or it could be that my entire experience with JSON and XML is dealing with strange / unusual / bad APIs.

A baked-in DTD, typing, and cleaner distinguishing between sections would be nice.

I would like to look at this and be able to say what each end bracket is referring to:

I'd like better language support for JSON. The best JSON parser I've used is SQL, that's not good.

I have no idea what would be better, but it's not a problem I can fix either. I suppose mixing the best parts of both XML and JSON, with some added features, would be nice.

HUGE

Nice work

congrats Larry!

[QUOTE=daveT;52536252]
A baked-in DTD, typing, and cleaner distinguishing between sections would be nice.

I would like to look at this and be able to say what each end bracket is referring to:

Well, this data is terribly formatted. There's no real protection from that.

JSON Schemas are a thing, I think they're roughly analogous to DTDs although I don't really remember that much about how DTDs work. But a JSON schema can tell you everything that's allowed and where it goes and what types it can take and so forth.

But pretty much any data format is going to leave you having to know what things "mean." It is helpful if it's fairly obvious, but, you know, good luck with that.

I tend to make data structures that are invariant: if a field exists, you'll always get it, though it may be "null" where it doesn't apply. I don't like people to have to guess what fields are available or have to go crazy with checking to see if this or that field is present in THIS record.

What language do you use? I've used JSON with C++, python and a little bit with Java and they all seem to do OK. Python does great with json, because python's syntax for data structures is fairly close to json to start with (not that this is without it's problems, I wish json adopted some of the more loose aspects of python DS)

Actually, I've used JSON a tiny bit in mysql and it seems OK there too, as long as you're quite sure what the syntax should be like when searching and inserting and stuff (mostly, how much to quote and where)

But I mean, like, Sturgeon's law applies: 90% of everything is crap. So yes, 90% of APIs that provide XML or JSON do it in some brain dead way. That isn't actually a comment on the features or lack thereof of the data formats.

I worked someplace once that insisted on essentially recreating SQL as an XML DTD because they thought it would be too hard for people to learn SQL. It was just as hard to learn our pseudo SQL and it had the disadvantage of not actually working right or supporting every feature. Plus it took 6 months to develop and was never really deployed at scale.

Because, y'know, everything sucks.

Congrats Larry!

I think I might have missed it, Larry - what were you applying for?

[QUOTE=RustyBrooks;52536327] This would be nice... I haven't used JSON in Python for a little while, but I recall a ton of error handling to deal with this (though to be fair, I may have been doing it wrong at that time). Postgres just converts over to null, though it's possible I'm confusing myself with this, as the processing language would have upfront declarations default to null.

Think of how much nicer it would be if you declare your schema, and even if you didn't put null in a field, that schema could be passed to the receiving system and converted to null rather than an error?

Or, sheesh, if you don't follow the schema, then the JSON doesn't work at all. You can't get a broken XML because it simply won't render. I've received more than one broken / partial JSON and that's messed up.

I'd take back all complaints if it was impossible to render and send mal-formed JSON by default.

I'm saying "large" more in the sense of receiving a few hundred records with deeply nested nodes. Just think about the traversal to get to any of those prices in the snippet above. It takes a ton of testing to get every record variation handled with something like that. If JSON you are receiving is relatively flat, say no further than 3 deep, fine, but when it's 10 deep with mistakes tossed in, it's a pain.

This is trivial in many languages/libraries. Worst case its a tiny wrapper around how you interface with the json object to return null whenever a field doesn't exist.

I don't think I want to be part of a data transfer that requires a 10-nested json document but also needs a strict schema to be followed.

In terms of broken/partial json, I have no idea what this complaint is. A broken/partial JSON object is easy to detect and most parsers will do this for you.

I don't know what this means.

I'll still take deeply nested json over deeply nested XML. I don't see how switching the response you showed from ebay to XML improves a single thing.

No data format in the history of the universe has intrinsically supported the notion of "it is IMPOSSIBLE to render malformed data"

The notion is ridiculous. There are hundreds of web servers and frameworks and all kinds of bull**** and even ones that check data formats for you are also going to let you write arbitrary data to output and say it's XML or JSON or YAML or whatever, even if it's not properly formatted.

only skimming the argument, but i think he just means that type checking and validation is "built into" xml (via dtd) -- practically speaking, if ppl are using XML, they're validating their xml documents most of the time.

validating JSON, otoh, is less standardized, though there is JSON Schema: https://davidwalsh.name/json-validation. practically speaking, if ppl are using JSON, they may be doing no validation, some ad hoc validation in code (ie, in python or ruby or whatever their server is using), or "real" validation.

there's nothing inherent in either format that makes this true, but it seems to be culturally true.

All any of us has is their own experience, but in mine, I have received many many ****ty xml documents that are malformed. But also, some that are clearly validated. So I dunno.

It is a UI Software Engineer position using react + redux, mostly front end. Healthcare tech company.

It's a really interesting environment and one I think I'm gonna be really productive and happy at.

Managed to get eighty plus bonus plus stock, which according to the instructors at the bootcamp is very very solid, especially 2 weeks out.

Seems pretty damn good for a bootcamp grad. What metro area - Boston?

I'm supposed to be finishing some stuff up on the side job. Watching wall-to-wall WSOP instead. Motivation non-existent.

Yea Boston

I'm just super pumped to start doing stuff. It's a very diverse team, the engineer who started a week ago got their computer science degree in 1980, and many others with tons of experience. But also working on new stuff that I can immediately make an impact in. Should be a premier experience.

They're doing a rebuild in react so I'll get to build many of the baseline components with the team.