Slashdot Log In
Curl Instead of Java or JavaScript?
Posted by
michael
on Fri Apr 06, 2001 02:56 PM
from the catch-the-wave dept.
from the catch-the-wave dept.
janpod66 writes: "Tim Berners-Lee is putting his weight behind a new programming language designed by David Kranz intended to replace existing client-side programming languages like Java and JavaScript, as well as HTML. You can find more information at InteractiveWeek. Dertouzos, head of MIT's Lab for Computer Science is also involved.
You can also find more information at the startup company's web site. They have programming manauls on their web site. It looks vaguely like a mix of Tcl, Lisp and C (lots of low-level type declarations possible). They also provide a brief rationale. Now, I'm the first to admit that HTML, XML, DOM, JavaScript, Java, and style sheets have become rather complex. Actually, Curl looks pretty nice and clean. But does it stand a chance? And is going with something new, untried like this better than going with mature, widely understood technology?"
This discussion has been archived.
No new comments can be posted.
Curl
|
Log In/Create an Account
| Top
| 252 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:Won't reach critical mass (Score:3)
That's why we should give up on html and java/javascript and return to a language that everyone already has on his computer: Basic. Etc, etc.
When they "brought Basic into the 21st century", Microsoft had to introduce so many new features as to make Basic just as complex to use as Java or C++, or any other modern language really (ok, maybe I shouldn't go that far, they do take away a lot of flexibility that you would get from C or C++ for the additional cost of a lot more knowledge of APIs). Just because you learned Basic back in junior high doesn't mean you would have the foggiest idea how to use it's current and upcoming incarnations. Hell, Basic is the first language I ever encountered too. But I didn't stick with it very long. Other languages were much more powerful and made more sense to use. While the intricacies of any given language can take a significant effort to master, the effort can be well worth it if the language offers enough benefit over whatever you are currently using.
I suppose what I'm trying to say is that it really doesn't matter what language programmers grew up using. If it was Basic, they've long since moved on to other languages (including VB which is much much different than the Basic that many of us started off with), so it wouldn't do all that much good to move back to developing in Basic at this point.
My proposal (Score:3)
Recent complications to HTML - CSS1 + 2, XHTML, DHTML; have not made things easier and cleaner as they should have. Rather, they raise the enterence requirements for beginning coders. HTML had the potential to break the "leave it to the professionals" attitude that is one of the worst aspects of IT and CS. These additions threaten to move us back to the stone age.
If Tim really wanted to make the web a better place, he should push to get rid of the requirements for XHTML to be properly nested, well-formed, and closed. It may seem like a good idea to us coders, but a bad idea to people who find HTML confusing enough already.
It will do well (Score:3)
At LEAST as well as Scriptics Tclets did. You see those all OVER the place...
"Beware by whom you are called sane."
Re:ANYTHING!!! (Score:3)
What are you talking about?
Java applets are portable in exactly the same way that Java applications are. Both rely on the presence of a Java Virtual Machine having been ported to the computer on which you want to run your applet|application. The only differences between applets and applications are:
1. Applets by default have fairly severe security restrictions (can't access local file system, can't make network connections to any machine other than the one they were loaded from). Signing an applet removes this restriction.
2. Applets run inside of a browser window (or an Applet Viewer) and can take advantage of some of the resources of the browser (easy to launch another browser window, for example).
-jon
Problem not the standards but the tools. (Score:3)
Secondly I think that Jane Average will be able to take advantage of CSS, XHTML and DOM, they just won't need to know they are doing so.
We are just getting the next generation browsers that support these standards properly. Next is the software used to create webpages for those who don't want to code by hand. Such software will take care of the hassles of these standards for the user and allow them to just build what they want.
I don't have to understand postscript to print my word document, they won't have to understand CSS/XHTML/DOM to publish their page to a browser.
Especially when rebol is around. (Score:3)
It too is commercial but it's much much cheaper.
It has a tiny download and very small code which runs faster. It runs on just about any platform you could think of.
Oh yea the obligatory link [rebol.com]
rant on, brother man (Score:3)
Down with crap-ass workarounds!
"Smear'd with gumms of glutenous heat, I touch..." - Comus, John Milton
Chicken and Egg problem? (Score:3)
Likewise, the browser companys aren't going to build in support for an un-used language, because it's a waste of money....
Open Source to the rescue?!?!?
Compatibility! (Score:3)
I hate that I have to trap in my code for different browsers and handle them all differently. In case no-one at Netscape or MS know - the browser SHOULD SUPPORT XXX language the SAME, STANDARD WAY everytime!!
-----
Code and data integration (Score:3)
Applications - Web or otherwise - consist of code and data. In the current architecture of Web applications, there must be a strict partition between code and data because HTML can only describe data and has no ability to compute. But there is no real difference between an application and an interactive document. An interactive document is just an application housing mostly static data (text and graphics) with very little code (the interactive part).
I couldn't disagree more with this theory. After years of web development, including for one of the highest volume dynamic sites in the world, I believe there should be a strict separation between data, formatting, and interactivity. Every place I've worked has eventually come to the same conclusions:
- content writers don't want to know layout
- layout designers don't want to know programming
- programmers don't want to do layout or writing
Of course these are generalizations, but keeping these things seperate (at least keeping programming separate from the other two) has proven to work for the better. It's easier to find people, too.It's kind of like suggesting that a novel include alternating languages from paragraph to paragraph. Few people would be able to enjoy it!
Re:Commentary (Score:3)
Jay
Brilliant idea (Score:3)
Let's see: it's free to use if you aren't selling something, but if you are, then you'll have to pay metered fees. Shouldn't cost companies too much though, since the number of users who will download, install (and <cough> debug) the proprietary client plug-in will be negligle, so I guess the risk is minimal.
Oops, did we just invest 27 man-months and half a million dollars deploying a great new e-Commerce site entirely written in this thing?! And if we didn't want to go immediately out of business, we should have spent over twice as much deploying a non-Curl version of the site as well, and supporting both -- completely curtailing all of the so-called benefits?
And who's that I hear mumbling something about "separation of content and logic?"
Yeah, sounds like a winner to me. It's gonna fly like a lead balloon... but then again, that's what Keith Moon said to Jimmy Page, isn't it?
Won't reach critical mass (Score:3)
You have to reach a certain critical mass before you can dominate a market. This is doubly true for communication applications, because how can you communicate with a fellow on the other end unless you both speak the same language? Since we gave up on the glorious and noble enterprise of Esperanto, we've conceded the human-language field, but we're still working on the computer-language ones.
How can they expect enough people to adopt this new language? If you're writing for Flash or Shockwave, then you're already leaving out a lot of your userbase. Even if you write standard html, you're leaving out lots of user userbase, because of browsers' bugs (though IE, I have to say, doesn't have a single bug with rendering standard html). You're in the business of delivering your product, information, and you have to do it in a form your clients can understand.
That's why we should give up on html and java/javascript and return to a language that everyone already has on his computer: Basic. Thanks to the diligent efforts of Microsoft and other companies, who have brought Basic into the 21st century, Basic already enjoys a bigger userbase than any other language (except perhaps Fortran's). Because so many programmers grew up writing their first programs in Basic, there exists a fluent userbase already. Basic is easily extensible and rather object-oriented when you consider its vast legacy.
We should stick with the languages we already know and know well. It's better to improve what we already have than to open ourselves up to new incompatibilities and build ourselves another penthouse suite on the Tower of Babel.
Re:Chicken and Egg problem? (Score:4)
Re:Java, anyone? (Score:5)
Exactly. This is nothing more than a Flash or Java Applet substitute. Unfortunately for the folks working on Curl they seem to have forgotten the most basic premise of computer economics.
Curl is competing with several entrenched technologies, and both Flash and Java Applets have progressed a great deal over the last couple of years. More importantly, both of these solutions are easier and less expensive to deploy than Curl. So even if Curl has serious cool points it doesn't stand a chance.
What's most amazing to me is that apparently these folks just don't see that. That absolutely boggles my mind. Surely they must realize that the last thing that the web needs is yet another plug-in. Especially a plug-in that requires you to pay by the character for commercial content. The folks at Curl must be targetting the demographic of billionaires who recently had a botched frontal lobotomy.
Commentary (Score:5)
Free for non-commercial use, pay whatever they say for commercial use
.NET)
Basically, in today's environment, this will make it hard to get developer support. Open source tools or at least reliably free for use (Java) are the systems that will get adopted (exception: MS
Custom client simplifies client-server information sharing, using SGML-like language
Even if orgs want this, they are more likely to just use custom java client and XML. I don't see how there will be any substantial web browser support for this, so it will be just another plugin.
I definately understand the complexity of creating web apps, and they need to be simpler to create. But we should create simple frameworks for existing technology, and improve those platforms. I guess they think this will be some kind of quantum leap, but we'll see.
I got yer Basic right here (Score:5)
20 GOTO 10
Curl == Spyware (Score:5)
Then wander over to http://www.curl.com/html/products/pricing.jsp and look at the fact that you have to commit to sending Curl a minimum of $1000/month (max of $50,000/month) to use Curl to deliver content. And the cost is based on how many characters you serve. Not, on how much revenue it generates.
This product looks more like misguided megalomania than like product that stands a chance of actually being used by anyone.
Technically, it acutally looks pretty good. But, the business model and the privacy policy are, well... They're insane.
StoneWolf
Some more words... (Score:5)
Curl was dead before the press release.
Move along folks. Nothing to see here.
-----------------------------
kaaaameeeeeeehaaaaaameeeeeha!
-----------------------------