|
i personally don't need the feature. i'm designing an API. the feature is for others, so the question is, do you use XML to do the job these days?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
If you need to guarantee that your objects stay in order, use XML. JSON is subject to the engine that's parsing it, where XML is - well - XML.
The only thing I think most real programmers hate is any form of visual basic.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: The only thing I think most real programmers hate is any form of visual basic.
That sounds like a challenge  .
Let's see.- Windows installer and writing install packages for it
- Writing Windows device drivers
- Writing Windows device driver installers
- Creating Windows install images when a new revision of the OS comes out
- The MSDN web site, which Microsoft redesigns to obscure the fact they're removing content so they don't have to support it
and that's just the crap I can think of associated with Microsoft and Windows. If I got started on software management in a hardware-centric company, two things would happen. One, I'd probably exceed Chris' message length limit, and two my ass would be terminated with extreme prejudice.
Software Zen: delete this;
|
|
|
|
|
I use XML for lots of things but mostly where I need a desktop app to communicate with a web resource either to receive/send bulk data (usually via sql to xml) or little things like FTP credentials (encrypted of course) or program/file updates.
I've always found XML to be extremely easy to use. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
It's probably one of those cases where, unless you need to use XML, use JSON.
From your problem statement it seems that you need to use XML, so use it. Tough if everyone hates it.
Kevin
|
|
|
|
|
Unfortunately, i can't readily use JSON because node order is significant, and JSON allows for reording of child nodes.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
XML is widely used. And, it's often a lot more convenient than JSON, since you can create a DTD that lets the parser do a lot of the grunt work for you. I use it all over the place. I only use JSON if it's already part of the protocol of a device I'm talking to or it's stuff related to talking to Javascript in a browser.
Explorans limites defectum
|
|
|
|
|
I mostly use JSON these days for data interchange, but I hear you about typing. That being said, there's a spec for JSON schemas, and many engines already support validation using them.
I don't use them myself. In the real world, most JSON is machine generated, which means it doesn't necessarily need heavy validation unless its coming from somewhere external (to avoid possible exploits)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
For me lots of it is user configuration, or data from external devices or servers, none of which can be assumed to be even reasonably correct. And, ultimately, it all really probably should get good validation. If your program croaks because of an error in another program, that's not a good thing.
Explorans limites defectum
|
|
|
|
|
that's what error handling is for. Validation just lets you throw sooner. A lot of times that's not even necessary.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I would not use XML if there was serious volume involved, I've seen systems fail using xlm when attempting to transfer gb between systems.
As others have said use the correct tool for the job no matter whet the "popularity" you perceive is.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
There’s a way around the big-ass file problem, but it comes with restrictions. A few months ago, I wrote some code to load files that were as large as 8gb. It could probably go larger, but that’s the largest file I had.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I design pretty much everything assuming my files are going to be 16GB
meaning i use streams and (when necessary) pull parsers.
I *always* chunk, absent the narrow case where it doesn't make sense to.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It was a few years ago and was basically transferring a daily snapshot of a banking system to a reporting/analysis tool with biztalk in the mix. System was totally unwieldy and got canned before it was completed. XML was never used again as a transfer medium.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
The "job" is undefined. I'm making an API.
Anyway, I'm not sure I'm going through with this bit.
Besides I have other stuff to work on that has taken precedence.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
For what it's worth, XML has been my preferred persistence format for a long time. It makes it relatively easy to manage arbitrary structure and schema changes, UNICODE, and so on. It also translates well to other programming environments and languages, given that support is fairly ubiquitous.
It's no longer "flavor of the month", but it has the advantage of... it works.
Software Zen: delete this;
|
|
|
|
|
Prolly stating the obvious, but can you package subelements as items in an array?
/ravi
|
|
|
|
|
they need names.
i could, but the resulting json isn't worth it
[ {a: b}, {c: d} , {e: f} ]
sucks, you know?
better to just use xml
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Use PostScript.
It's like a version of XML that hasn't had its bollocks lopped off.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
107. C question on expression container (4)
|
|
|
|
|
C ... question ... container
leads me to CASK, but
on expression
just leaves me confuzzled.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Well, you got it anyway 
'express' C + ask?
I mean, there's just so many synonyms for 'mix'
|
|
|
|
|
Oh my, so I know how to "hack" (using math basically) an LL(1) parser to allow for very expressive grammars.
I can describe it on a whiteboard, but I'll spare you the details, except to say it makes LL(1) competitive with LL(k) for any k value, as far as I know.
What does all that mean? It means a beautiful parser generator, that is very easy to use and extremely expressive.
Meh, I just want to share it with everyone, but you know how that goes. I'm sure you all have had something code-wise that has got you hot and bothered, too.
I'm debating about monetizing it. It's brilliant. Too brilliant for me to have designed it, and yet there it is. 
Gosh I just love this.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Quote: I'm debating about monetizing it. It's brilliant.
Sorry, but I think you are a little bit late. All you described in your posts is allreday available here: Niklaus Wirth[^]
Among others:
- Compiler Compiler
- EBNF Parser based on EBNF
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Actually it's not. Wirth shows you how to generate parsers, but not how to make LL(1) more expressive *without* bloating the parse tree <--- this is the part that isn't covered and doesn't seem to be implemented by offerings like Coco/R
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
