Quote:
Originally Posted by ixtab
... However, I disagree to condemn XML entirely. There are valid reasons to employ it, especially when things *do* get complex.
|
Okay, I was employing a bit of levity
(the opposite of gravitas) to the situation, but in reality I come from the opposite end of the programming spectrum, using things like application-specific languages and data-layout-aware custom compression (which by the way can compress FAR more than generic compression that does not know or care about data layout or data content regularities or restrictions, which can be taken advantage of in a HUGE way). And application-specific interpreted languages can vastly shrink and simplify otherwise huge and complex programs. Programming in a custom language that "knows" your data can really make things easy, simple and efficient.
Graphics display lists are one simple example of this, and so is JVM bytecode, but you can extend those to include application-specific extensions where one instruction replaces hundreds of lines of complex code. You can do some of this with C++ operator overloading, but that can get so nasty, and representing your "subroutine call" as an "machine code instruction" is just so damn efficient. 
It is not that I hate XML or other big nasty ways to deal with complex issues, but I prefer to change the rules so that I can define my data and my data management language into a cohesive and simple integrated solution.
We just have different ways of looking at the world of programming, and much to my luck, I have been able to navigate myself into a position in which I have the freedom to do so, unlike so many other unfortunate souls. Well... that and
NIH, of course.
EDIT: And of course, I like streaming display lists across networks instead of JSON or XML, which is essentially what UltraVNC does when it sends windows graphics primitives across the link from its virtual video device driver intercepts, except I do this for all my client/server stuff. What can be more efficient than telling the device on the other side how to "do it yourself" instead of sending all the raw data. And where you cannot tell the other side how to regenerate the data, you use custom compression that knows about your data (perhaps using a pre-shared compression dictionary derived FROM your data).
EDIT 2: Of course, my methods restrict me to data that can be "pre-processed" allowing me to build a custom compression dictionary and/or minimal perfect hash function from my data. It helps that I choose problems that fit my tools, rather that being forced to use nasty XML stuff because there is no other reasonable solution. Like I said, we are coming at this from opposite directions, which define what tools we can use and what problems we can solve. The world needs both of us, or many problems will go unsolved. In my case, XML is not cluttering up my toolbox, and I intend to keep it that way.
P.S. I gave a hint about my perspective when I signed up here (Bare Metal Bit Basher). Here is one of my favorite web pages (which I STRONGLY recommend that you read): http://aggregate.org/MAGIC/
