Curl[1] was a project at MIT to produce a unified web language that combines aspects of HTML, Javascript, and Java. There is now a company, Curl Corporation, that is trying to sell this language commercially. I believe the effort will fail.
Curl Features
Curl is a pretty cool language. It uses a Lisp-like syntax (except it uses {keyword arg arg} instead of (keyword arg arg)), which is more compact than the nested tag syntax of HTML and XML. It has an explicit set keyword for assignment (which is something I’ve wanted for a long time). It has things like rest arguments and dynamic typing, which seem like good ideas for a web language.
Philosophy
Curl is positioned as a better web tool than HTML/CSS/Java. But it’s missing the separation that the existing solutions give you. Right now, you can write your content in HTML, your presentation in CSS, your scripting in Javascript, and random other stuff in Java. With four separate languages, I can get one without another. I can get HTML without Javascript for example, or HTML without CSS. Or I can get the same HTML with different CSS. (Note: if you are using Mozilla, you can do this by using View -> Use Stylesheet[2].) This is really useful for wireless hand-helds, internet appliances, automobiles, and anything else that isn’t a “normal” Windows PC. It’s useful when I want to turn off a malicious script. In an all-in-one language, where content is generated by the script, I can’t get the content if I want to turn off the script.
HTML and CSS allow you to write flexible pages that work with different fonts, screen sizes, or even non-screen formats like audio. The user has some control over presentation. I can set a large font size if my vision isn’t so great. Pages adapt to the user’s needs. With Java, I lose all of that. If it’s hard to read, I can’t increase the font size. If I can’t see, I can’t have things read to me. From the promotional material I’ve read about Curl, it sounds like it’s even worse. At least Java wasn’t designed to replace plain old HTML pages. Curl is. And if you replace HTML pages that I can make easy to read with Curl pages that some web designer with 20/20 eyesight finds easy to read, I’m going to be unhappy.
Mixing code and data leads to flexibility but you lose information. Consider for example a list {5, 17,
32} compared to a function f(i) that returns 5 when i=1, 17 when i=2, 32 when i=3, and Undefined for any other values of i. The function is more flexible. Perhaps it generates those output values dynamically without storing a list internally. Perhaps it gets them from the network. Perhaps the values change each time you call the function. You can’t tell. But how do you write something that outputs all the elements of the list? With plain data, it’s easy because you can examine the data, find out how many elements there are, and so on. With a function, it’s impossible. The output can vary in so many ways that there isn’t a well defined notion of outputting all elements.
Curl mixes code and data. The code is written for presentation. But what about other ways to look at the data? If the author didn’t explicitly write ways to examine the data in a different way, it’s hard for someone else to do. In particular, search engines can’t examine Curl code and find out what words and phrases are going to be generated, because what gets generated can depend on any number of things, or could be random. Suppose the Curl code had something like if f(3) then output "free
mp3 files available here" else output "your IP has been sent to
RIAA". If the search engine indexes “free mp3 files available here” and sends a user to this page, and the page actually shows “your IP has been sent to RIAA”, then it’s not so useful to the user. Even worse, what if the content is available, but only if you press Shift-Control-Y followed by B B X and three mouse clicks? Should the search engine return the page or not?
By not presenting content without going through a script, you run into undecidability. A third party (like a search engine) cannot examine the content of a page. And that means search engines won’t index your page. Note that another new technology, XML, goes in the opposite direction: it takes out all presentation, which increases the number of ways in which the XML data can be used. You can have one XML file that gets interpreted by many different applications and scripts. You can have one application that gets used with many different XML files. Separating code and data allows for more reuse and more tools. Compared to the HTML/CSS used currently, XML moves in the direction of enabling more communication between machines while Curl moves in the direction of less of this communication. Curl shares this trait with Flash and Java.
Pricing
The Curl Corporation plans to charge for each byte downloaded by each client. So if your page using Curl gets more popular, they charge you more. In order to charge properly, The Curl Corporation will be tracking every use of Curl, anywhere. Spying on the entire world in order to charge people is just scary, and I think this will lead to less use of Curl. What happens if the network is down? Can you not view content anymore? What happens if you want to view your own page? Do you feel comfortable with The Curl Corporation watching every reload and charging you based on how much code you wrote?
I’d rather use tools that don’t have any central control. I can view HTML without being online. When I edit my page and hit reload, I don’t have to worry about how much it’s going to cost me. (Note: I know, this is irrational because it’s a tiny amount of money. But it’s non-zero, and it makes me think “this is costing me”. I think this is why micropayments are doomed to fail. That’s a rant for a different day.)
Distribution
For Curl to succeed in a big way, browsers need to include it in their distribution. If 90% of your users don’t have the plug-in, are you going to develop a page that only 10% of them can view? When you see “download so and so plugin”, do you download it or do you hit the Back button?
Which browsers are likely to include Curl? I don’t think Microsoft will include it in theirs. They don’t even include Java anymore. They’d rather push people towards ActiveX and C# and .NET. And including Curl only in Mozilla isn’t going to give you enough market share to make developers use Curl.
So in the end, Curl is only going to be used on a really small scale, where you have a lot of control over the clients. There aren’t going to be that many Curl developers out there—nothing like Java. And unlike Java, which attracted a lot of developers that moved to server apps, I don’t see Curl as being a great language for server apps. So why would I develop an app in Curl instead of Java? I don’t know. Curl looks like a nicer language than Java. But given that there are a lot more Java developers, a lot more Java clients, a lot more Java tools, and that Java is available on a lot more platforms, any advantages of Curl as a language seem small compared all the disadvantages as far as developers and tools and support.