ultrafilter posted:

https://twitter.com/chrisjrn/status/1232016100038266880

Winter Stormer posted:

Shout out to CMake, which treats all of the following as false (matched case-insensitively): 0, OFF, NO, FALSE, N, IGNORE, NOTFOUND, the empty string, and any string that ends in "-NOTFOUND".

ultrafilter posted:

https://twitter.com/chrisjrn/status/1232016100038266880

Xarn posted:

Less "helpful" YAML would be really nice though

Soricidus posted:

Or just better specified json, like with an actual standard behavior for numbers. And comments and trailing commas goddamnit

NihilCredo posted:

dick traceroute posted:

So XML?

DoctorTristan posted:

Use csv for everything. Especially that huge numerical data dump. Be sure to include thousands separators in approximately 10% of the entries

For a real pro move, create it as 5 different files with different column separators then cat them before sending

Tei posted:

The point of yaml or json is not to be "feature complete" - Its not sgml or xml

Anyone pointing out how for some case is not a valid tool is missing the point

Soricidus posted:

The point of a thing is related to how it is actually used, not how you think it is intended to be used.

And the prevalence of json parsers with support for extensions like comments, and the endless arguments over whether it’s ok to silently lose precision by interpreting large integers as doubles, indicate that these things do matter in the real world.

Tei posted:

The point of yaml or json is not to be "feature complete" - Its not sgml or xml

Anyone pointing out how for some case is not a valid tool is missing the point

NihilCredo posted:

CSV/TSV is fine. Not great, but fine.

The horror in your case is that your ETL flow apparently doesn't include a validation step.

However the file is delivered, up to and including sneakernet, the specs should give you the option to respond with the equivalent of a 400 Bad Request "Every line must contain exactly 25 commas, sorry fuckos".

b0lt posted:

JSON, the JavaScript Object Notation, is incapable of representing all POD JavaScript objects.

Tei posted:

If you have a solution for a problem that only solve 90% of your problems - then get that solution and use it for these 90% of problems

If you try to create a solution to solve 100% of your problems, you have created a problem so large that it may take your entire life to solve and the result may still be unusuable, economic unsound, hard to use, ugly looking and so on so on.

JSON is more popular today than XML because is not tryiing to be the best tool for every use. One of the starting points of JSON was... "Okay lets use UTF-8 for strings". ...from that decision they come limitations, but also it make life easier.

XML declare the character set in the document -- so to know what character set is written the document you are going to read -- you have to read the document, then going back with that idea. .... From flexibility comes hard to solve problems, social problems, political problems, problems that create other problems..

quote:

If you try to create a solution to solve 100% of your problems, you have created a problem so large that it may take your entire life to solve and the result may still be unusuable, economic unsound, hard to use, ugly looking and so on so on.

Munkeymon posted:

What is "POD" there? Plain Old Dumb?

Also, are you complaining that JSON can't natively represent a reference cycle?

Volte posted:

JSON is pretty objectively bad for round-tripping arbitrary data which is what it's mostly used for, and it's pretty bad at being human readable/writable. There's no use case that I can think where JSON is appropriate and something else wouldn't be equally or more appropriate.

Volte posted:

POD means 'Plain Old Data' i.e. just a structure full of data without any object semantics involved, like a C struct. The issue is that undefined and Symbol are primitive JavaScript types that have no analogue in JSON. That's not even mentioning function types or dates, but I dunno if I'd call those plain old data.

Munkeymon posted:

Delivering data to a web browser, hth

Munkeymon posted:

I would not consider functions or dates plain old data, either, but we at least have ISO date formats to exchange a very usefully large subset of them in.

Volte posted:

Cool, what happens if I need to send a date, the number 2^59, one out of an enumeration of possible values, or a list of values that are all the same type? I need to rely on the client-side having the exact right bespoke JSON extensions to validate and process the data, rendering the entire point of a standardized interchange format moot. If I'm expecting XML, I only need an XML library and the schema to validate and parse it. If I'm expecting JSON, I need a JSON library to parse the string into a JSON object, and then a bespoke parser on top of that to parse and validate the JSON object into something else that I can use.

Volte posted:

Cool, what happens if I need to send a date, the number 2^59, one out of an enumeration of possible values, or a list of values that are all the same type? I need to rely on the client-side having the exact right bespoke JSON extensions to validate and process the data, rendering the entire point of a standardized interchange format moot. If I'm expecting XML, I only need an XML library and the schema to validate and parse it. If I'm expecting JSON, I need a JSON library to parse the string into a JSON object, and then a bespoke parser on top of that to parse and validate the JSON object into something else that I can use.

Volte posted:

Yeah ISO date formats are cool, too bad JSON doesn't support any of them. "Just throw it in a string and let the client's a priori knowledge of the expected format carry them through" is not actually a solution, it's the entire problem that standardized interchange formats are meant to solve. Look at the absolute fiasco that is JSON.NET date handling if you need more info.

Tei posted:

Forks can't cut meat, you use a knife for that.

That don't mean "forks" are wrong, or that is a good idea to eXtend forks with a blade. Only pain and misery waits that path. It means if you need to cut meat, you use a knife.

People on this thread point to a fork and say "it can't hammer a nail".

People on this thread say "Maybe we should make the fork weight a lot, so it can hammer the nail".

People on this thread say "The author of Forks probably forgot that nails exist"

People on this thread say "People often need to hammer nails, Forks are clearly flawed".


Here I say, if you need a hammer a nail, use a hammer. A fork is for food.

JSON is not for everything. It don't need too. And is great because is not tryiing to be everything for everyone.

Space Gopher posted:

Oh, hey, we're right back to the "just never write bugs, or integrate with people who do, and this is the best possible solution" approach.

Space Gopher posted:

What you end up with is a half-baked schema, with a whole bunch of special cases and poorly documented extensions that you have to integrate with anyway.

Munkeymon posted:

Someone has to do the work of turning your internal business object graph into reasonable user-facing output at some point(s) no matter how you serialize it. I've worked with people who made thoughtful JSON APIs and people who just poo poo the graph out over the wire and made front-end figure it out. There are advantages to each, actually.


I'm really baffled as to why you're pretending exchanging ISO date formats as strings is some terrible abomination here? It's at worst a minor inconvenience until a library author makes a bad decision about handling them but that's not evidence of some massive underlying problem with the format the library deals with. Yeah, real date support would be nice, but dates are complicated as gently caress so fobbing that off to the user makes the transport format that much easier to deal with. I'm guessing date format validation would have added a whole lot of JSON parser bugs over the years, just off the top of my head.

Tei posted:

People put light bulbs inside their rear end and then these are stuck

Volte posted:

Have you ever actually had to deal with these issues? Do you think I'm making these things up? Date handling in JSON has taken up literal weeks of my time. Dates are complicated. That's exactly why there should be one single place that's responsible for the uniform interpretation of these dates that everyone can rely on, so the only thing the clients need to care about is "what do I do with this date" and not "what the gently caress is this string, is this a date? Let's hope so"

Munkeymon posted:

Blaming JSON on date formatting incompatibilities makes as much sense to me as blaming TCP

Volte posted:

Am I missing something again??? How is this not the JSON experience to a T?

Beef posted:

Of course I notice after a week of debugging (print debugging, no gdb for platform) that my modifications are breaking randomly BECAUSE TYPES ARE POINTERS TO GLOBAL VARIABLES. WHO DOES THIS

Space Gopher posted:

Perfect-world XML experience: everything is rigorously defined by a machine-readable schema. Import that schema, point a client at the right endpoints, and your integration work is done in a few minutes. You can get to work building out logic. The sun shines and you get a lollipop.

Real-world XML experience: there's still a machine-readable schema, but importing it doesn't begin to describe the data. You need to implement a bunch of mapping logic on top of that schema to handle a legacy of bad decisions and quick hacks. If you're lucky, there's a second set of human-readable documentation that describes these special cases and extensions. Everything you implement needs to take multiple sources of truth into account. Good luck if they conflict.

It's easy to say "just don't do this, do it the perfect way," but that just doesn't happen. I've integrated with generally well-architected systems that run major business operations for a company you've heard of, which used mostly coherent and mostly standards-compliant XML. The system I was working against was one of the better-maintained ones I've seen in my career. We still spent weeks going over everything that would, in a perfect world, be in the schema, and all the special cases we needed to know about, before we could start integrating anything. That was probably the best experience with XML that I've ever had - and I've had quite a few others. Sometimes it gets to the point where you need to write your own "XML" parser, because it's really just "we put some tokens in angle brackets with no other consideration."

Real-world JSON experience: there's no schema, just some API documentation. It's still probably out of date and doesn't cover everything, but at least it's easier for everyone to keep up to date, and there's less trouble integrating two sources of truth. It's nowhere near as good as the perfect-world XML experience could be, but it's miles better than the one that crops up whenever an XML-based system evolves over time.

There are reasons people go for JSON.

pokeyman posted:

Objective-C I think.

Was the answer to serialize something other than the address of the type, then look up the type's address on deserialize?