Category: Uncategorized

Uh oh. Another reactive rant. Am I turning into a grumpy old man? This time it’s about layers of abstraction. And Javascript. And the meaning of life. No? Maybe not the meaning of life.

Nikhil posted about his new pet project, Script#. Although I had fun reading the article and admiring the work, I am not enthusiastic about the approach. Google had posted their GWT a bit earlier and it evokes a similar reaction from me. Here it is:

Hiding Javascript behind another language’s layer of abstraction is like killing puppies.

It’s one thing to build a compiler to a language that’s more appropriate for machines. CLR or Assembly ain’t easy to code with for any human being.

But Javascript is a fully-featured, widely used, and beautiful language. Sure, it’s different from C# of Java, but it holds its own rather well. Sure, it lacks strong typing and traditional C++ form of object orientation, but that doesn’t make it less versatile.

Why do I think it’s a bad idea? Well, primarily because I get to experience firsthand what layers of abstraction do to code. In ASP.NET, the developers were shielded from needing to learn how Web works — a lot of effort was put in to emulate WinForms. You click a button, and here’s your OnClick handler, voila! Unfortunately, shielding developers from learning the inner workings results in some of the crappiest and undebuggable code you can imagine. Don’t believe me? Check out thedailywtf.com. Or go look into the vast repositories of code, written for ASP.NET. I know, I am making a non-verifiable statement here, but hey, it’s my frikin blog.

In the comments to Nikhil’s article, there are sentiments to keep the Morts in the loop. One of the users is worried poor slobs won’t be able to keep up with yet another language that they need to learn.

I have a very simple answer to this: if you can’t handle Javascript, you shouldn’t be writing code for Web applications. HTML, CSS and Javascript are the three prerequisites for this ride.

And to those of you who do know all three, please, let’s stop proliferation of poorly-drawn boundaries in layers of abstraction. If you need futher motivation, just realize that you will be debugging that insanity, written without understanding how things really work.

So, where do we draw the boundaries? Well, for starters, not across the languages. I totally don’t mind a Javascript 2.0 compiler that produces common Javascript 1.4. I don’t mind seeing a CLR implementation of Javascript (not the JScript.NET, of course). I don’t mind a powerful JS toolkit. Anything that flows along the lines of the Web style is great.

But please, pretty please, don’t repeat the disasterous attempts to “simplify” the Web by allowing only one form element per page (which has to post to itself!) or requiring Javascript for the framework to react to a link click. Please? For the puppies?

Have you ever dreamed to be in a real movie? You know, pointing out the tiny speck that is your head in a great sea of other hapless extras during a classic flick to your grandkids. “Yeah, I’ve been in a movie. Here! Look! It’s me!”

Here’s your chance. Yuri Shapochka and his crew are going to shoot a short film in town this weekend and they are looking for extras. No pay, naturally, but a guaranteed all-day excitement of creating something cool… and who knows, maybe even rubbing shoulders with future celebrities.

He is looking for people on either or both Saturday and Sunday. It’s a whole-day thing, meals provided (I think).

If you are in Birmingham, AL this weekend (May 6 and 7) and you’re interested, please email him at shapochka@earthlink.net.

Here’s more info on the movie: http://www.highexpectationsthemovie.com/

Tags are foregin keys with no corresponding primary key structure. Using a foreign key implies creation of a primary key, if it didn’t exist before. The resulting nebulous collection of keys is often visualized as a tag cloud.

Those who worked with me have seen it — my trusty ol’ notebook. Now you, the reader, can also peek in on the latest ideas brewing. Experience tells me that about 60% of these will be obsolete or deemed definitively crazy shortly after being doodled down, but some of these may just be the next big thing. For what it’s worth, here it is. I am addicted to them darn Ampad Computation Books. Good graph paper, rounded corners, stamped page numbers, hard covers — what else can you ask for?

Gee, we will never run out of clever name permutations with this one, will we? Anyways…

Where did this idea come from that in order to be RESTful, an app has to use all four HTTP verbs? How did that become the criteria? I don’t get it.

The crux of REST is in uniform, immutable representations that reflect the state of a uniquely identifiable resource at a given time (i.e. stateless), and these representations travelling between client, server, proxies, and caches (i.e. multiple layers). That’s all (jump in if I am missing anything).

You can still design a RESTful application that doesn’t allow PUT or DELETE,
and even GET or POST. Architectural style does not dictate the use of
the verbs — the application needs do.

I agree, though — the debate does seem to have a certain religious war flavor to it. It just pains me to see people define architectural styles in terms of the building materials. HTTP is bricks and mortar, REST is Baroque. Bricks and mortar by themselves don’t make Baroque. Baroque by itself doesn’t require bricks and mortar. Failure to see the distinction is the sticking point.

As for defining the subset(s) of HTTP and applicable architectures that tend to work well in the modern Web, I am all for it. Tim Bray has the right idea.

Chris has the right idea with the Mapendar. Relevant content is always location- and time- based. Organizing event-driven information into a continuous time stream and supplanting it with illustrated geography is a pretty intuitive way to put it together. Me likey.

Over at fuzzy, Bob dug up some more ridiculous patent claims. The more you browse the patent database, the more you realize the impossibility of enforcing and navigating (or should I say litigating?) through this tangled mess.

Just  a quick heads-up: it looks like the CNN.com came out with fresh, new look for their front page. I think I like it. But please don’t pull up the covers: the markup is still a mess, and inner pages haven’t been switched to the new, more horizontal layout.

Okay, this one is probably going to sting a bit. But here it goes. Don Box, my hero of adventures long gone, has coined (or as much as that) a new term: Lo-rest. He provides a list of bullet points to define it, and even comes out as the first member of the newly minted congregation. Almost immediately the poision-pill meme catches on, appearing on smart people’s blogs and mailing lists.

Well, fellas, somebody ought to come out and say it: there’s no REST in Lo-REST. It’s barely good HTTP. It seems, after years of trying to bend HTTP into a donut with the WS-* spec and somesuch, Don wants to get back to basics and normalcy of what HTTP was intended to be. And I applaud that. But please, pretty please, don’t call it REST. Or Lo-REST. Or Hi-REST.

For as long as you use “invoke”, and “service-oriented” in your jargon, you are not applying REST architectural style. If anything, it’s REV. Please, Don, you’re well-known and well-respected and your words are picked up and carried by crowds like you’re some sort of religious cleric. RTFM?

As you may have heard, Bill Gates ushered in a new era by saying: “We need microformats” from stage at Mix’06. It was a long time coming. Slowly but surely the purists in us are realizing that this might be the only way to bring the vision of semantic web into fruition. Slowly but surely the mechanics in us are grokking the importance of semantic markup and the benefits that come with it. And I say with open arms: “Welcome to the fray!”. Kick the tires, join the discussion, learn the process, participate in development — and start using them, dang it!