Slashdot Mirror
New Language CURL Merges HTML And Javascript
jluxe writes: "CNN reports that a new language, Curl, was presented at the Software Development Forum in Palo Alto. This language works via a plug-in to browsers, and attempts to merge the gap between HTML, javascript, java, and even C++. It also supports the Macromedia Flash plug-in. Interesting to note that Tim Berners-Lee is listed as a financial backer of this venture, as well as an adviser." Here's the Curl Corporation's official website as well.
(python.org)
Free Techno/Jazz/DNB/MI Music by guys obsessed with monkeys!
As someone who knows many of the people involved in CurlCo, I can assure you that the hidden business plan was to be bought out by Microsoft which, at the time of CurlCo's incorporation, was thought to need something to compete with Java.
Your post indicates that you have a pretty limited view of the programming language space. PHP is "Perl and C/C++ wrapped into one" because it has "classes", "great string manipulation", "support for CGI" and "now GTK" These are all supported by Python, Perl, Ruby and a host of other languages. PHP is just one among many. PHP's real virtue is that it is totally embedded in the web server environment. It is hard to justify it purely in terms of language features as you seem to want to. It is a mediocre language embedded in a great dynamic web pages environment.
And anyhow, the existence of these many server side languages do not really have any impact on the need for languages on the client side. Yes, PHP can generate JavaScript, HTML, Flash and other stuff that works on the client-side. But really Curl is competing with those client-side languages, not with PHP. PHP could just as easily generate Curl if it turned out to be better than JavaScript et. al. So PHP is great at what it does but not really relevant to the question of Curl's utility or viability.
The first is that Curl is not free (don't stop reading, I'm not a zealot). If you are a commercial entity wishing to publish Curl content, you have to pay Curl Corp. a licensing fee. Writing a free Curl enginge is likely to be irrelevant, as you pay Curl Corp. to use Curl content, not to use their software. HTML, JavaScript, C++, Java and many others are free. Write a compiler or interpreter, and anybody can use them.
To gain widespread use on the web, a language should not require the publisher to pay where the current languages don't. Unless it's incredibly much better than anything available today. It must surely have some real killer features if companies are to be interested in converting their sites to Curl. The larger the company, the less likely they are to convert (Curl licensing is by volume), and the more likely they are to influence what the smaller companies do.
The second reason, and it's a smaller but still relevant question, is cross platform portability. Curl's homepage lists the system requirements as Windows 95/98/NT, Netscape or IE, with Linux and Mac "coming soon". But there are an incredible amount of browsers out there already for platforms that are not on the desktop.
One of the things that made the web great is that it is not dependant on a particular manufacturer to implement their product on a particular platform. Anybody can write a HTML- and JavaScript-browser if they have the time and skills. Opera wouldn't have seen the light of day had Curl been the standard.
Then there's the question of e.g. proxies. There are lots and lots of products in use today that work on HTML, e.g. cacheing and filtering proxies, that will not work with Curl. Whether Curl publishes standards so that proxy/filter manufacturers can implement Curl support remains to be seen. As does whether a proxy counts as a publisher and should thus pay royalties to Curl Corp.
I don't see Curl as a serious replacement for HTML/Java/JavaScript/C++ anytime soon. Perhaps under a modified licensing agreement, with published standards, big corporations would consider a switch and smaller would follow. But for today I don't think Curl stands a chance, regardless of technical merits.
You're thinking "what end-user would want to spend that kind of money and put up with those restrictions?" The proper question, though, is "how many corporations would consider the benefits of Curl to be worth setting up a Curl server on their intranet?"
(Of course, the answer may be "not enough to give the VCs anything close to the return on investment they were hoping for"...)
send all spam to theotherwhitemeat@ropine.com
I had no idea who Tim Burns-Lee was.
I found him here.
http://www.w3.org/People/Berners-Lee/
Ascii artist &
First, Javascript is a good idea. The language is small easy to use and gets the job done.
Second the implementation in current browsers leaves a little to be wanting.
Lets talk about the merits of the language if we are going to slam it. Do not talk about a language being inherently good or bad OR the implementation of the LANGUAGE being good or bad if you are just going to be critical of the stupid things people do with JavaScript.
People do stupid things in ANY programming language on ANY platform EVERYWHERE.
I am not sure what the point was to your post other than to be sarcastic or funny.
Any web developers worth a grain of salt knows that you can't trust data from the client. For every bit of JavaScript data validation I have written there is a nice set of validation routines the data is put through ON the server.
I think inexperienced developers may put the work to the client exclusively but this again has nothing to do with the merits or flaws of JavaScript as a language IMO.
I have been using client side validation for as long as I have developed web applications (almost five years now). When people use our intranet we require them to use JavaScript. Why? It enhances the user experience enough that the use of JavaScript is justifiable. 999/1000 times the client is not trying to hack you. What does it hurt to do a little client side validation. This will get 99% of your bad data. Then you ship it to your server validation routines and it all goes smoothly. No extra trips back to the client/server just to validate the data and get the required information in the proper format... all done in one trip to the server. This not only makes an application more robust it makes the application feel smoother for the end user.
My point being people complain about JavaScript when truly they are complaning about the implementations of other developers, Not the browser implementation and Not the actual language itself. It is just easier to say its all crap and ignore it and blame other developers for being idiots right?
Jeremy
and the downside to that woudl be?????
Which I wouldn't mind, except I think I already have something like that called the MacroMedia Flash Plug-in, well in my case Flash.
Only with Flash, I don't have to worry about too much about the learning curve that comes with Curl's seven different integer primitives because ActionScript is a weiner'd down version of ECMAScript.
Moreover, I can leverage Flash & ActionScript on the client side with languages I already know, and are usually available on the server side, such as PHP, Ruby, Perl ... along with the vast libraries associated with languages (fun stuff).
Similarly, MacroMedia has opened up it's file format that has given rise to a variety of UNIX, Win and MAC development solutions.
Considering all this, do I really need CURL ?
healyourchurchwebsite.com - WWJB?
If there is one thing the web needs right now, it is freedom from the vision of the semantic web, and all those other idiotic visions keeping us from progressing further. There is nothing wrong with the semantic web per se, but it is not, and should not be the solution for everybody's needs. If the people at W3C had realized this when they started, instead of making overly complicated standards trying to catering for everyone's need, we might even have had a useful web by now. A simple presentation language for people wanting to describe layout precisely, and a still-simple HTML-variant for describing content. If you were worried about both, you would be fucked of course, but very few people are.
If you are still not convinced, let's look at a few examples:
...etc. The layout/content separation theory is good in theory, but I think it's on time to start liberating ourselves a bit from it now. It has been over 10 years with the web, and still very few are happy with the way it works.
Unless, of course, Tim's been thinking 'bout how everybody 'cept him got to ride the gravy train he shoveled all the coal for, and decided it was time for him to hit the jackpot too.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Touting this as being a cross between HTML and Javascript makes me wonder why anyone would want to use it.
Javascript is one of the worst implimentations of a bad idea that I've seen.
One of the basic tenets of client server programming is "Never Trust The Client". Yet still, people write shopping carts that calculate totals and shipping charges in javascript, then trust the client to send back accurate data. I'm sure that TBL knows this, but is he expecting that every curl developer has even taken a basic CS class and will remember that? I doubt it. Developers will look to push as much of the processing as possible off to the client, imposing more security risks. They say they use a 'sandbox' - doesn't VBScript say the same thing?
Also, their micropayment scheme is going to turn a lot of people off. First they say how this has been developed using the same grant as the WWW, (my tax money?) then they explain that if I put up 'curl' code on my site, I've got to pay them per user. Sure. No problem. Next!
Why don't I just put up a page of C++ source and tell people to "lynx -source http://code_url|gcc"?
Sure, whatever...
Cheers,
Jim in Tokyo
-- My Weblog.
"New language CURL ditches all existing web work for a proprietary, windows-only format."
Even shockwave is more cross-platform.
I doubt that anyone will implement this in websites. It's taken five years to get a decent implementation of CSS1, and that's still not used widely.
Got friends?
Today, compuer hardware can be had for almost nothing. Bandhwidth, if it can be had at all, is costing more, as DSL companies die out because they realized they weren't charging customers enough.
The client is powerful, the network is not. If you want cross-platform compatibility, sacrifice some speed by running within a VM. Java is slow, yes. But you couldn't possibly get that framerate if it were streamed over today's cable modem.
http://slashdot.org/article.pl?sid=01/04/06/133524 1&mode=thread
How hard is it to do a search of your own website for "Curl"?
"And like that