Five Things I’m Probably Wrong About
Now you would not think to look at him
But he was famous long ago
For playing the electric violin
On Desolation Row
- DESOLATION ROW
A few months ago, I was chatting to a very wise man. He said to me: “If three people tell you that you’re drunk, even if you’ve had nothing to drink, you’d best go home and sleep it off”.
When people tell me that I’m drunk these days, I normally am. But there are some other things people keep telling me that I don’t agree with, so they’re probably right. They’re all related to the fact that I’m an old school control freak dog that probably can’t learn new tricks.
So, I give you Five Things I’m Probably Wrong About But Strongly Believe I’m Not. Maybe some long blog posts about any or all of these if people want to have an argument and educate me, but I’ll keep it short for now.
I prefer XML to JSON. Yes, I know they’re not really competing technologies. One is an interop format, and one is an object serialisation. But they sure feel like they compete from where I’m standing. The kids all seem to prefer JSON over XML as an API response format, even when the client of the API isn’t JavaScript. But not me. I’m old school like Dave Winer, even though he’s sometimes a bit of a cock.
I prefer RDFa to Microformats. And I prefer RDF to XHTML for structured data. I’ll take structure and standards over conventions. Microformats are more popular than RDFa, and people are probably right that RDF is complex and hasn’t taken off. But I can’t help it. I just don’t like using CSS classes to imply semantics.
I prefer XSLT to all alternatives. I love forced well formed markup. I love the fact you can’t be lazy and hack. I love the override model and the terminology they use. I love XSLT so much that I don’t really know what the viable alternatives are. Freemarker? mustache? I hate all web templating languages that end in a P. That includes JSP, ASP(.NET), PHP. It’s not easy to make XSLT spaghetti like you see in the P langauges. I know the kids all think XSLT is complicated, verbose and slow, but I just don’t see it.
I prefer strongly typed to weakly typed languages. The theme of control continues. I’ve seen to many non-typed programmers write hundreds of test cases for their code which pretty much replicated a typing system. Compilers are an automated test suite in my book. While we’re here, I hate Perl more than anything else. Especially if the project team size is greater than one. “There’s more than one way to do it.” Sneaky fuckers just want to write code that is impossible to understand so that the weird guy on the second floor can keep his job maintaining it. I’ll have a double helping of consistency with some control sauce on top, please.
I prefer referential integrity to chaos. I like the fact I can’t get horseshit data into my system. While I believe the repository administrator should be able to disable referential integrity (REFINT) constraints for performance reasons in a tested, production environment, I can’t handle the mess my development repositories get in to. Many smart folk are telling me REFINT is a slow waste of time and a layer above the repo should be responsible for it. But I don’t buy that either. Note that I am a big NoSQL fan and prefer a hierarchical repository to a relational one.
So you see, I’m a freak. My developers are all tree-loving hippies that want flexibility. I want impose technologies that restrict the hell out of all of that. And you all thought I was the hippy! If any of you, dear readers, agree with me on any of the above, I’d feel a whole lot better. I’m feeling rather alone out here. I’m like the guy at the back of the crowd:
Brian: Please, please, please listen! I’ve got one or two things to say.
The Crowd: Tell us! Tell us both of them!
Brian: Look, you’ve got it all wrong! You don’t NEED to follow ME, You don’t NEED to follow ANYBODY! You’ve got to think for your selves! You’re ALL individuals!
The Crowd: Yes! We’re all individuals!
Brian: You’re all different!
The Crowd: Yes, we ARE all different!
Man in crowd: I’m not…
The Crowd: Sch!
- Life of Brian (1979)
RSS Feed
Follow Me
You’re right on all of these. Seriously, nothing to add, I just agree.
Also, you’re probably drunk. Damn hippies.
All hail the chief. discipline rules. You should meet Dr B
Yup. I agree on everything (except maybe XSLT) and I’m stone cold sober. Try maintaining a system for a few years and see where you stand on stuff like referential integrity, strong typing and structured data. Kids today just don’t get it…
1. JSON has less of an infrastructure than XML now, but more simplicity. Simplicity is good… so tending to favour JSON.
2. Actually have you looked at the new HTML5 microformats stuff? Much nicer than the old stuff. Playing field getting more even on this one.
3. XPath is nice, but XSLT may be a good processor, but it is a bad language for humans to write. Even LISP did a much better job of being human readable and writable without the XML verbosity (and LISP was originally meant to have a human readable syntax too). Spending some CPU cycles making programming languages readable and writeable for humans rather than machines is essential for programmer sanity and productivity. The JSON lovers dont advocate making a programming language in JSON, tools for jobs.
4. Type inference ROCKS! If you havent used a language with a Haskell-style type system you dont understand the inbetween world, where types are locked down just as much as they need to be.
5. Referential integrity doesnt scale across the network once you have a distributed system, as any update of a reference needs a global synchronisation. EVen locally with concurrent access it is hard to make it perform. The internet doesn’t have it – you get a 404 sometimes. The coping strategies are things like “Cool URIs”, and not renaming resources.
1. I’m all for simplicity, but don’t think XML is complex.
2. Briefly. Are they ready for the big time now? All seems pretty patchy to me
3. Baaah. XSLT and Jon 2together 4ever. What are your suggested XSLT alternatives?
4. Guilty as changed. I haven’t. So let’s keep this as a comparison between the traditional strong vs no typed languages.
5. Agree. Which I why I want the ability to turn it off in productuion. But I want the repository to do it when I need it to.
Agree with most of what the mercurial Mr Cormack says, but here’s an additional $0.02:
1. JSON isn’t without its own flaws – ever tried to represent a date/time/TZ primitive in JSON in a way that any client can unambiguously comprehend? That kind of “limitation” seems gobsmackingly amateurish in this day and age.
2. RDF (like ER and most Graph DBs) makes the (imvho HUGE) mistake of using “relationships” for two completely and utterly different kinds of things: a) “containment”- the sub-object is “owned” by the parent and has no independent existence outside the parent (i.e. it’s not an object in and of itself); and b) “association” – the two objects are true peers and can exist independently of each other, regardless of the existence (or not) of associations between them. I touch on this in a bit more detail in the “DR” portion of the “DRVCS” discussion in this post.
3. I have a few specific technical issues with XSLT, but have to agree with Justin that’s it’s the lack of “developer usability” that’s my biggest complaint with it. The media-compatible sound bite might be: “XSLT is the Perl of the XML world.”
4. +∞ to what Justin said. If you’re a JVM fanboi, try Scala (whose type system is partially inspired by Haskell) – it’s both more strongly typed and less verbose (in no small part due to type inference) than Java The Language (both of which I consider to be Good Things).
5. I’d argue that in practice it’s rare that a real-world system of the kind we’re likely to be working with (i.e. a CMS) needs to support referential integrity (as per your definition) between anything more than content items that it itself internally manages. Cutting out the distributed piece leaves us with Justin’s “local” case, and I’m not sure I buy the “it is hard to make it perform” argument, given some of the performance statistics people like Neo4J routinely throw around. That said, I do think there’s a need for “relaxed referential integrity” from a purely functional perspective – it’s important to have the ability to blend both strong references and weak references within a single content model, and even to be able to move between the two for a specific reference in a model if need be (e.g. during content model evolution). Of course the tool itself should provide specific facilities for working with weak references – warn the user if they’re about to break a weak reference (but then go ahead and break it anyway if the user decides that’s the correct thing to do), provide efficient means for obtaining the list of broken weak references and fixing them (removing them, repointing them elsewhere), etc. etc.
I think you’re only half-drunk. I’m with you on #4, #5, and could go 50-50 on #3. Your sentiments on #1 and #2 are excessively theocratic. I recall all the SGML weenies making the same critique of HTML 1.0 (and 2.0 and X.0…) in 1995. It was messy in an ecumenical way, but it simply worked. What works, wins.
Yes, I agree. I’m all for keeping things simple and using what works. My problem is that what works in the short term for a quick solution (JSON, microformats, p-languages for templating, weakly typed scripting languages, no REFINT) often don’t produce a system that is maintainable in the longer term. I’m with Ben Morris on this. Enforcing control and consistency means my projects can survive a few years before everything goes to hell
New technology sucks and is flawed. When I was a developer, everything was command line. You had to worry about things like the memory consumption of variables. Pointers were a way of life and not a friendly tip.
To be serious, your points have more validity the larger the system under development. The more order imposed, the easier the maintenance.
But I am an old hack, so I could be wrong. Beer me.
-Pie
To all who said XSLT was developer unfriendly: Such a statement only means you don’t know XSLT.
Have a look at my blog for many examples how elegant and powerful XSLT is — also short and very easy to understand. http://dnovatchev.spaces.live.com/blog/
Nice examples, but where’s the proof that developers in general find XSLT easier to use than the alternatives?
FWIW, my experience (which includes lots of work with “underwhelmingly skilled” developers in exotic locales) has not supported this theory.
My experience with similar developers in similar locales is that the underwhelming can cause a whole lot less damage when stuck inside an XSLT cage. Admittedly they weren’t great at setting up the framework, but the results stayed neat. Not like when the same developers used JSP/ASP.NET/PHP etc …
Perhaps, but most reasonable templating languages (including my current fave – Freemarker) impose at least as tight a sandbox on the template developer as XSLT, but without all the extraneous costs associated with:
1. coding in XML *vomit*
2. having to unlearn imperative programming
3. being forced to deal with the vagaries of output escaping
4. having to jump through painful hoops every time the template has to emit non-XML or non-well-formed-XML output
5. etc. etc.
And no, I don’t like the “P”s (JSP / ASP / PHP) either, but to my mind they are so far from state-of-the-art in templating that they’re not worth discussing.
We must be the drunk ones. All of this effort to reinvent rather than understand and advance. It has gotten to the point where it’s cool to call a project “Yet Another”. Why can’t more people scream at the top of their longs when projects try to reinvent the same things, rather than advance standards based technologies like xslt, xquery, xforms, etc…
Super-Duper blog! I am loving it!! Will come back again.
I am bookmarking your feeds also.
great publish, very informative. I wonder why
the opposite specialists of this sector do not understand this.
You must continue your writing. I’m confident, you’ve a great readers’ base already!