|
Gratifying innit?
The only exception is when i write something I expect to *not* work the first go-round and then it does.
Usually that means it's broken, but i haven't figured out how to break it yet. 
hack everything.
|
|
|
|
|
Yes! 
For me; the surprise was not that it worked, but that is compiled with out syntax errors or warnings.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
John R. Shaw wrote: but works the first time out of the gate
That would make me suspicious.
|
|
|
|
|
Jörgen Andersson wrote: That would make me suspicious.
Are you kidding me? "Suspicious" is putting it mildly. I'd be second-guessing everything if my code worked the first time I tried it.
|
|
|
|
|
I always second guess everything before I even compile the code. The surprise is not that it worked, but that there were no syntax errors.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
Well...editors themselves are already vocal enough about syntax errors; it's kinda hard nowadays to miss them.
Or are you coding in Notepad? 
|
|
|
|
|
So, Newtonsoft is the premier library for JSON in C#. If you create a stringdictionary in C# and serialise it, the resultant JSON will not deserialise using the same library and same CLASS. I had to use Dictionary<string, string="">
|
|
|
|
|
I never used theirs. I just wrote my own.
And as far as JSON being better than XML, it all depends on what you need.
For example, parse trees cannot be accurately represented in JSON because JSON doesn't preserve field order of objects, while XML does preserve order of sub elements.
hack everything.
|
|
|
|
|
Yeah, the header is meant as a joke.
I'm paid to code, I don't waste time rewriting stuff that exists, is well tested and free
|
|
|
|
|
I do if the learning curve is bigger than me simply rolling my own. JSON is trivial to parse and emit
hack everything.
|
|
|
|
|
Yeah, lots of things are trivial without being a five minute job
|
|
|
|
|
Sounds like you already spent that 5 minutes trying to get NewtonSoft's lib to serialize a dictionary, which is rather my point about the learning curve.
hack everything.
|
|
|
|
|
Well, sure, but, I still think I've spent less time dealing with this frustration than it took to write JSON.Net which, again, is widely used so I get the benefit of tons of testing.
When I was new to dev, I mocked the idea of paying for things I knew I could write. Now I know the most important thing is giving my boss a result as quickly as possible. Would you roll your own auth or use Identity, for example?
|
|
|
|
|
I agree with you in general. But in JSON's case, I've never found a good reason *not* to use what I've built, as by now it's tested, and unlike NewtonSoft it does exactly what i want how I want it.
It did take me time to get it there, so I probably wouldn't have built it professionally unless i needed like, a little REST/json-RPC layer and nothing else at which point I know from experience that deving that took less time than learning to do the same thing with NewtonSoft, whose offering is actually more complicated in that regard.
So it all depends.
hack everything.
|
|
|
|
|
honey the codewitch wrote: while XML does preserve order of sub elements.
Does it? By definition?
I am aware that a schema can specify that a sequence is to be preserved. Of course, even if you are not required to preserve the order of elements, you are allowed to do so in your processing, which is often the simpler solution. But unless explicitly declared as a sequence, I would not rely on preservation of order.
|
|
|
|
|
The order of sub elements is preserved.
Schemas can only restrict the order they may appear in. (order=any or whatever means no restriction, but it still keeps the subelements in document order)
I'm pretty darned confident of this, but do correct me if I'm wrong. The *only* exception i could think of would be something that allows reordering by schema "key" field, or perhaps "id" field but i've never seen an implementation that does this, and I think it's not cool to do.
So I'd put rent money on this assertion. I don't rent, but still.
hack everything.
|
|
|
|
|
|
I like JSON but at the same time, you're not wrong. 
hack everything.
|
|
|
|
|
Ouch, that article is awful!
I would try to justify my claim but I just don't have enough spare time to point out all the wrongs with it. Let's just say it's very biased and the examples are not practical and have been cherry picked to fit the agenda.
For example, at one point it uses XPath to show how easy it is to get elements with a certain attribute using XML, but then suggests you need to write a multiple line for-loop to deal with the JSON equivalent...  
Personally I don't have a problem with either, pick what best suits the requirements, as is true with most things.
|
|
|
|
|
Quote: Ouch, that article is awful!
Maybe. I posted the link just because it mentioned C# troubles with JSON.
Quote: Personally I don't have a problem with either
Me too. Nowdays I use more JSON, because often I need the serialization of trivial objects.
|
|
|
|
|
(Yes, I see below that you are being tongue-in-cheek.)
SQL Server supports XML as a datatype, so when I'm reading JSON to store data in SQL Server I convert it to XML then store the whole elephanting thing in an XML-typed field. 
But, really, it's like saying that apples are better than oranges.
Nearly all the places I see people rationalizing that JSON is "better" than XML, it's just completely unconvincing.
I can consume either (and convert to XML as necessary) and I can produce either. No big deal.
|
|
|
|
|
Yeah, the only benefit i see is that it's more concise. And doesn't have namespaces that I know of.
Yeah, instead of a JSON type there's just JSON parsing to turn it into a table, which I've done quite a bit of lately
|
|
|
|
|
well, the other benefit is native support in javascript. Just sayin
hack everything.
|
|
|
|
|
Javascript supports JSON, that's why we hack around with it in C#. it is of no intrinsic use otherwise, except perhaps for another serialisation format
|
|
|
|
|
i mean, that's what it is - a serialization format.
but textual serialization formats are useful for all kinds of things - like remote procedure calls over text based protocols.
IMO, it's not JSON's format so much that matters, but what people do with it.
The fact that it *is* native to javascript makes calling JSON services with Javascript basically built-in to existing browsers, unlike XmlHttpRequest was for so long.
But aside from that, yes, it's just another serialization format.
The structure is easy to query though, unlike XML (which can be simple, but gets complicated quickly)
hack everything.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
