Slashdot Mirror
Curl Instead of Java or JavaScript?
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?"
BTW, I for one wouldn't put HTML/XML/DOM(???) in the same sentence as Java, Javascript. HTML/XML et cetera are page or data desciptions while Java/Javascript/VBScript are programming or script languages ...
My browser supports the XXX language very well; perhaps you need to look harder for your porn?
Everyone is missing the real reason behind Tim Berners-Lee's advocacy of Curl. He's an investor and on the board of Curl. Need to say more?
Just look at the Common LISP Object System (CLOS).
Java also runs programs as applications, not merely applets for your browser.
Try starting your next project like this:
#!/usr/bin/env python
And you too will know the secret.
A truly nifty multi protocol grabber:
http://curl.haxx.se/
has the same name as this.... erms.. thing.. though I can't verify it.. I do belive the curl.haxx.se folks have been using the curl name longer then the language dudes..
Too bad the curl.haxx.se folks didn't trademark.. now I'm going to have constant confusion with the term Curl!
I realy wish the language dudes would change their name!
The name "Curl" has been in use for years by a open source url downloading program by Daniel Stenberg. This program is now in its seventh major release version. See the Curl web site for more information.
As an erstwhile contributor to the original Curl, I am a little annoyed they did not bother to check freshmeat.net first to see if the name they had chosen was already in common use.
Other than that, I do not see how this technology has any serious potential unless they plan to submit it as a fully documented, patent-free international standard capable of independent implementation.
Now I can scream "HURRRRRRRRY!!! HURRY HARRRRRRRRRRDDDD!!!" at my computer and have an excuse!
Sun's Java is not portable. Just write complicated code according to the Sun specs and it will not run on Microsoft VM and vice versa.
Provide a code sample, or shaddup...
As and when they open source it and kill any patents, I'll look again. You cannot beat good enough and cheap with perfect and expensive, especially not when good enough is already ubiquitous - ask NeXT.
And, lose the monitoring crud and silly EULA; anyone who thinks they can make money from a tollbooth on an empty road is nuts.
--
Because they haven't gotten their time's worth out of Java yet. If you spend a couple of years learning & practicing Java (or any language/utility), you don't want to just throw away that knowledge and move on for no good reason. Plus, Java was/is a better solution than most of the other tools available at the time; it doesn't look (at this point) like this offers that much of an advantage over Java to make the move compelling.
Just junk food for thought...
CobolScript
Nice site. When you mouse over a nav link it disappears. And the date is displayed as
Friday, April 6, 101
I guess it *is* Joe COBOL programming it.
Pains me to see stuff like that; I work at The Company Formerly Known As MicroFocus. :-)
-=Maggie Leber=-
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.
Rather than interesting this post should have been moderated as funny. While not wanting to start a flame war I have to say that Basic is one of the least expressive languages that I have ever worked with. On top of that the syntax is just horrible. Just my 2 though. I know that there are many skilled vb programmers out there. It's just that I have never found one. ;)
When I want your opinion I will beat it out of you.
Actually, with the Scripting Host support built into Windows, you can run client-scripts in IE and ASP-scripts in IIS in any language supporting it. This includes MS' own VBScript and JScript (of course) plus Python and Activestate PerlScript, at least. But those aren't deployed much so people simply assume that scripts in web pages == J(ava)Script and ASP == VBScript.
I can't see this going far, especially without offering plugin-free demos. Some screenshots and example code is all I ask for.
--
I can do that... Hey wait a minute....
:-P
Hexy - a strategy game for iPhone/iPod Touch
We *just got* two browsers (Mozilla 0.8.1 and IE 5) to do a reasonably good job of displaying HTML, CSS and Javascript similarly, after years of effort. This is not the time to replace the current system.
Another client-side language sounds like a great idea, and I'm all for it, especially if it makes certain kinds of things easier. However, there is something to be said for stable, mature technologies, and building something new usually means several years of debugging and learning curves.
Can any of this work be contributed to the *current* languages, to see if they can be improved?
http://www.curl.com/html/technology/documentation. jsp
This message is NOT intended to ignite a rehash of the mozilla-feasibility flamewars.
C# and NET?
Never....
Rick B.
what should replace js and java is flash, not these bullshit. I havn't seen one single java applet run as fast as an identical functioned swf file. Flash is optimize for graphic and render and interaction. Imagine a security updated netscape3 with latest flash plugin. It can do all the things the newest browser can do and footprint in probably 2 meg.
That's how bs html 4.0 and other bs VRML perprosal has become.
CY
(if you think i don't know anythng about web design, check out my homepage yeche.org)
-- sayke, v2.3.05
That their web pages are all .jsp :-)
Or that the dumbass install program
doesn't even know how to use a damn
zip file. Not a good first impression.
bmac
... since it's not an open standard (something about usage fees???)
--------
Genius dies of the same blow that destroys liberty.
Nope, it was right the first time.
Later...
KangarooBox - We make IT simple!
No.
I don't like
Answers:
Oh wait. You wanted well reasoned answers :-)
---
You were a moderator with 5 points. You should have read the moderator guidelines before you did any moderating
There is way too much bullshit required to write cool web pages. If someone was designing a decent solution from the start, a "page" would be meaningful data (xml tagged, probably, to allow for decent data mining and Googlification) and real code married together reasonably in a non-suckhole language. Requiring eight-billion different pieces to make cool stuff is just retarded, although inevitable considering how this whole thing evolved in the first place.
That said, even if Curl was the mutt's nutts and solved every one of these problems, there would still be a better chance of Rosie O'Donnel giving Charlton Heston a blowjob than getting the world en-masse to adopt and pay to use proprietary web protocols.
plain text works pretty well on both browsers.
If your html is so complex that the differences on NS and IE really affect usability, then you should ask yourself whether you're putting form over content.
Of course, unfortunately, if you work for a company, usually your job IS to put form over content....
---
... though IE, I have to say, doesn't have a single bug with rendering standard html ...
As much as I love IE (compared to netscape), there's still plenty of annoying bugs. For example; some block elements don't render correctly (namely forms). They leave whitespace at the bottom, no matter what's inside, AND no matter what immediately follows it.
And until both Netscape and IE agree on using the Javascript standard, you might as well call that a 'bug' too (bug = something that needs to be fixed).
-Egon
If they've designed a new, supposedly better web langugage, then why did they build their website using Java Server Pages?
j sp
j sp
http://www.curl.com/html/index.jsp
http://www.curl.com/html/technology/technology.
http://www.curl.com/html/products/products.jsp
http://www.curl.com/html/developers/developers.
http://www.curl.com/html/partners/partners.jsp
http://www.curl.com/html/about/overview.jsp
...
Rather, "Define a new comment indicator"...
"The area of penetration will no doubt be sensitive." ~ Spock
java is compilied code while the script is not meant to be compilied and it just tossed into HTML code and is run by the client. Java is portable, but to compile it into a standalone app you need a compilier for each system you intend to take it to.
Wheeeee
Oh yeah? It doesn't run on IBM mainframes, on OS/400, on OS/2, on Compaq Tru64 UNIX, or on Compaq OpenVMS.
All of the above run Java. I think all but one of the runs Perl (OS/400?). Most of those support Python and TCL.
It doesn't run on HP MPe/ix, nor on the popular PalmOS.
With such a small footprint, you'd think porting of the REBOL/core would be easy to these environments.
---
I just hope they give http://curl.haxx.se/ the name back
Metered code execution? I think not. It really doesn't matter how good it is, there is enough free technology out there already.
This is a manual virus. Copy it to your sig and help me spread!
Look at C++. Hard to imagine a messier combination of ill-suited features that interact badly, but we're stuck with it now.
HTML (+Java+CSS+whatever) is, by now, equally entrenched. I really can't see it being replaced by something else.
--
ROFL! Indeed, most browsers do support the XXX languange!
-----
I agree with you for the most part, when I tell people I used JavaScript to write something, they always ask "Oh, is Java cool?". But, I disagree with you here:
:-)
I think the best way to tell the difference is the salary difference between JavaScript and Java programmers.
I get paid quite well, thanks, and I don't program in java because I use SQL, JavaScript, HTML, and Cold Fusion or PHP to write sweet looking dynamic web pages.
It's not that you chose to hire Java developers that you only paid $50-70K a year, it's because you chose to hire second-tier developers.
Less experienced developers in any language are going to be paid less. You could have hired a group of green programmers of C++, VB, or virtually any language for the same amount of money and had them develop and deploy the system.
Of course you make sacrifices in the quality of the work, but obviously your company is willing to do that...
C# and Java do no more than a necessary and useful cleanup of C. But neither fits my concept of an object oriented language. These days OO has come to mean 'support for inheritance and methods bound to data structures'. I remember when the core idea of OO was considered message passing.
Well, this is not so true. The core concept of Object Oriented languages is data abstraction. The ability to define datatypes that act like primitive types is what OO programming does for you. That's it. Message-passing is just a term used for objects to interact with each other... while hiding the helper methods and internal data structures away.
Why they're using Java Server Pages?
If a corporation is a personhood, is owning stock slavery?
First let me state that I am always in favor of more options and new technology. I think that it is possible that Curl may become a very useful language for some web developments. But as someone who makes my living based on developing dynamic web applications, there are a few thoughts/concerns I would like to share.
The first concern is reliability. Anyone who has used client-side javascript is bound to have noticed that it's very difficult to get it to work reliably in multiple browsers. Ok, so the people behind Curl knows about this, and will probably do a better job of getting different browsers to at least try to use the same specs. Nevertheless, I don't like to trust any important script to the client. Furthermore, my customers also are generally wary of that. Keeping everything server-side is much more predictable and reliable, even if it does require better hardware.
Another reason I wouldn't like this is intellectual property. I know there's a big tendency here to trash ip, and generally I agree. But I have to admit, sometimes you need to protect your code. I don't want my competitors to be able to get my code (source or binaries) merely by hitting a site. Keeping the code running on the server keeps the code out of your competitors hands.
The final reason is, ironically, one of the same arguments given in favor of Curl: integration. If you're starting a product from scratch, or don't mind rebuilding what you have, then this is not a problem. But if you already have a working system, how well will Curl integrate with it? Will it be any better than the current technologies? Will it further complicate already complex integrations? I don't know the answers to these questions, but they would definitely affect the chances of Curl becoming a widely-used language.
So those are my concerns. I don't mean any of this as a slam to the Curl people; in fact, I'll be very happy if they have some good answers to them. But for now, I think I'll keep my eyes and my mind open, but I won't be using Curl until I've seen some results.
That's funny...especially the widely understood part of it!
Galego
Que Deus te de em dobro o que me desejas
[May God give you double that which you wish for me]
Re-drawing the entire page is a red herring - the issue here is speed of response, which is ruled by three factors: 1. processing speed, 2. available system resources, and 3. web connection speed. Their assumption is that server-side processing is inherently slower than client-side, but that isnt true nowadays by default because server-side processing actually is more efficient than client side on all these fronts.
It's not necessary slower, the response is "poorer". If I have users inserting items into a list, it's pretty damn stupid to refresh the entire page everytime I need to do that. The only time they really need to communicate with the server is when they "commit" something or when they need to receive some data. But no, every single minor operation requires a reload (there session has to be loaded, they have to validated, all the content on the page has to be re-read from the database or file). I hardly call that a red-herring.
Compare that hardware and software environment to a typical client-side desktop which suffers from M$ bloat, multi-tasking, and limited hardware. Unless you have server-grade hardware and don't use any other programs while surfing, you're probably not going to be able to execute code a.out in less time than it would take the server to execute it AND deliver it to you.
Oh my god.. do you think the average 400mhz machine (or hell 233mhz) machine - which aren't even being sold anymore is actually using even a fraction of its processing power most of the time that it's being used. Sheesh. Client-side processing should not be worse than using any other type of client-side application.
speaking of delivery, consider that the trend is towards cable modems, ISDN, and DSL and away plain old dialup. True not everyone has fat pipes (I don't , myself) but why design a technlogy for the past?
I have a big fat pipe (well sorta).. cable modem. It still "stupid" that ever little operation on a web application requires a reload. No really because of performance, but because of user-friendiness.
To be fair they should compare CURL vs HTML + CSS, not CURL vs HTML alone, if they want to talk about layout affecting code design.
I agree that for page layout this thing offers pretty much nothing. CSS and HTML are pretty slick for that. CSS/HTML/Javascript suck for web applications which need to do anything meaningful.
For any real client side application requirements you would probably want stable Java anyway.
Java still sucks on the desktop. It's an OS in an OS. What we need is something like Java, but not so huge. Curl is not it. But there is room for this kind of technology.
Well, it IS Friday, and the weekly fish fry is a popular staple of restaurants in my neck of the worods.
I guess it's not too far removed from the Christmas Fish.
--
Freaking hilarious!
The Computer Science instructor reached into his desk drawer. *click* "You have fifteen seconds to write me a 'Hello, World' program, ya damn bitchy undergrad." ;p
Where do you get the idea that Curl has less overhead? Not only is the plugin much larger than Flash's plugin (Curl is 17 MB), but, at least under windows 2000, it takes over 40 MB or RAM to run a simple calculator. That's overhead. It also isn't very well-behaved. The stupid dog game crashed, and took the browser down with it.
Granted, the download sizes may be a bit lower... but is HTML really that much data? And - for all of you who hate Flash - what do you think Curl will do to UI standards? Hm?
This strikes me as a bad idea.
[|]
10 PRINT "Nice troll";
20 GOTO 10
Amazing magic tricks
Notice how the links on their webpages use JSP?
Phear my l33t homepage.
Frankly, I've never understood why you would want your client to do less.
You may not be able to trust the client. To go back to your Quake example: If the server did all the real work and the client's only job was to feed user input to the server and display a stream of images sent back by the server, a lot of the cheating that happens on Quake 1 multiplayer games would become impossible.
instead of Java and Javascript !!!
--
Je t'aime Stéphanie
Would you put the future of the web in the hand of these guys?
--
Je t'aime Stéphanie
Of course, any company that would do a Curl-only web site is probably so stupid that they wouldn't stay in business very long anyway, but I see no reason to introduce more opportunities for stupid people to screw themselves.
But users of M$ are use to this kind of pricing and privacy policies. I look for my employer to jump on Curl sometime in the near future, but of course they buy alot of stuff that they don't need and an awful lot of stuff that does nothing for their bottom line and don't even want me to tell them about it.
My other car is a motorcycle!
It is not documented but you can run Curl scripts using the 'curl' executable that is included in he Surge Lab download.
For instance, here is a trivial script that
outputs its args:
echo.xcurl:
{curl 1.5 script}
{for arg in script-args do {output arg}}
$ curl echo.xcurl hi there
hi there
You can also run the 'curl' program interactively using the --shell argument.
Being a web developer and seeing this on slashdot and the Tim Berners-Lee connection I decided to download and preview. Here's what I think: 1. Animated Tea Pot/graphics type demos - seen those before (flash,java applets), not very impressive. 2. Plug in requirement is major roadblock. Tell someone that a plug-in required to view your site and they are headed out the door. 3. And the most absurd thing is the licensing agreement. What kinda KoolAide have these folks been drinking that they think sites are going to pay them money based on transmission volumes. The monthly minimum is also a big joke. Have these people read a newspaper lately? Web shops aren't exactly swimming in cash. Okay end of rant. This thing is Dead on Arrival.
By whose count?? The world is not ruled by Microsoft, not should it be.
The second you develop a site to support only one browser you hand control of your site to one vendor.
You might as well bend over and kiss your freewill good-bye. This is the kind of blind goose-stepping that fascists love.
By the way, in six months when IE 6 comes out it will break everything in IE 5 because Microsoft doesn't give a rat's ass about compatibility. But you can go right ahead and bow to the God of consumer reaming.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
I've never played Goldenaxe so I can't comment on it but I remember a lot of games stopped working after I upgraded from MS-DOS 3.3 to 5.0. I switched to IBM PC DOS 5.0 because it had better compatibility with previous versions of MS-DOS than MS-DOS itself.
I also remember that there was some pain upgrading from Windows 3.1 to 3.3. Hell, upgrading from Windows 3.3 to 3.33 broke some programs. Even Windows 95 couldn't run a lot of 16-bit apps properly which was one of it's supposed features.
I work for a large insurance company and the pain of upgrading from Windows 3.3 to 95 was so great that we're reluctant to go through it again until we have to. Now we have to. Microsoft forces us to pay to downgrade new PC's preloaded with 98 to 95. Also, Microsoft will be dropping official support for Windows 95 at year end.
Now I wouldn't suggest that compatibility for all previous incarnations of an operating system should be supported by the current release. That would be impractical and unnecessarily complicate the operating system. Although, compatibility with at least the last couple of releases would only seem fair to the consumer if the consumer even mattered to Microsoft beyond the contents of their wallets.
I won't even try to argue statistics because clearly IE has the largest percentage of usage. However, I would like to point out that Microsoft couldn't make a dent in Netscape's market share until they started forcing preloads of IE and blocking preloads of Netscape. I'm sure that if Microsoft did the reverse and forced preloading of Netscape and blocked the preloading of IE then Netscape's market share would soon be where IE's is now.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
Absolutely right on. Locking yourself into a closed platform is suicide in such a rapidly changing environment. The only reason MSFT can get away with it is that they have a monopoly. Curl will never
fly until it is open source.
-I like my women like I like my tea: green-
Ya know, for guys promising quicker, faster downloads of content, their "plugin" sure is fat at 17MB...
Then why did't they name it LISCB?
...to address the problems/complexities web apps currently face. As long as we have to use browsers to access information, we'll use the standards that come with those browsers to deliver that information.
.gifs and .jpegs that cause headaches.
Until then, however, I just can't imagine the entire web content delivery infrastructure being dropped to support some new technology.
And by the way, since when is Java a client side programming language like JavaScript???
They give these problems to be addressed by Curl:
* Slow response. To dynamically update any new data within a page, the Web server must re-send and the browser must redraw the entire page. Compare this to a typical application, where only a small part of the screen - the part being updated - is redrawn.
* Inflexibility. Data is transmitted inefficiently from server to client because HTML forces data and layout information to be fully expanded. This increases the size of the data packet delivered - and the cost to deliver it.
* Big downloads. HTML requires extra coding to handle layout, boosting download size.
A) Last I saw (when this page was rendered for me) Gecko was doing a pretty good job with that re-rendering. Plus, using frames in your HTML can eliminate the need to redraw an entire page.
2) When was the last time you left a web site/page because it took to long to download the text? It's the
D) This would seem to be an extension of their second point, and I would still maintain the problem is with the graphics happy designers, not the html itself...
Anyway, I won't deny there is a need for a technology like this, but as long as someone will have to download a plugin for it, it'll likely be just another proprietary tool, like Flash.
Just my 43 Lira
Sounded good until the word Lisp showed up. There is nothing worse in life than programming in a functional programming language (except maybe a logical one (prolog))
After installing this, my hard drive got whiped out. Coincidence?
"And is going with something new, untried like this better than going with mature, widely understood technology?"
With that attitude I'm suprised you're not banging out your message in morse code with rocks!!
Every "mature" and "widely understood" technology that is in use today was at one time "untried."
Great like obfuscated uncommented code wasn't already a problem!! I can't wait: 1 letter variable/function names. Prolific use of recursion. And if spaces/newlines count as characters, well... Kiss any leftover readability goodbye... ;)
OK I'm a programmer who wants a quick evaluation of their tool. So I want to see source code and screenshots.
To begin grasping the concepts of Curl, to see if I want to go any further with it, I have to download either PDF manuals or a zipfile of source-code. PDF is an offline format - a nice bonus, but not the primary form of documentation. And no, I don't want to download the plugin so that I can view the gallery.
Here's some advice: Before creating a new standard for interactive web programming, try adopting HTML!
If I had a hot new app (that was capable of replacing HTML/Java/etc), I'd at least create a version of my site that showed off the capabilities, ie here is the site in the old school sense, here is what it is capable of using our technology. Of course the may have this, I didn't look around exhaustively.
there are no stupid questions, but there are a lot of inquisitive idiots
Anyone else notice their website pages are JSP?
there are no stupid questions, but there are a lot of inquisitive idiots
If you can't hack it together in vi, notepad and whatever the simple Mac text editor is called, then I think it's not so likely to catch on. It appears that they have this 'you must use our tools' attitude.
And talk about blinkered - you can't get the impression of what it looks like until you download a damn plugin. Which no doubt they'll count in a '5000000 users worldwide' counter...
The short description - to replace Java and JS sounded just what I'm after (I've dabbled with both, and they both have too many weaknesses for me to want to get seriously into) so I went there with not just an open mind, but a positive bias. And they've turned me into a (negative) critic already. That surely can't be considered as good.
FP.
--
Also FatPhil on SoylentNews, id 863
--
it doesn't include pop-up windows of any kind?!
sulli
RTFJ.
I agree 100%!!!!!!!! Client side scripting == Pure evil
Sheesh.
"Not an actor, but he plays one on TV."
People have spent a lot of time learning and developing with java and javascript...will people really have the time to spend on learning a new language?
Well they all had to stop working in some earlier language to learn Java/JavaScript at some point. If they had the time then, why won't they have the time now?
--Dave
That is: probably well-intentioned, kind of a neat idea (for about 30 seconds), but totally proprietary and not really noticed by anyone but the originator.
(BTW, Zaplets are little e-mail messages that were supposed to be interactive; they used some combination of e-mail attachments, HTML forms, and server-side Java. Never heard of them? Don't worry, you're not missing anything :-P )
I don't really understand this comment. First of all, who says that everyone has Basic on his computer? Similarly, what version of Basic are we referring to here? GW-BASIC? QuickBasic? VB? VBA? VBScript?
Secondly, the majority of the browsers in use (ie: IE, versions 4 and up) already support VBScript embedded into HTML documents. However, pretty much no one writes VBScript into web pages. Why? No other browser (Netscape, old versions of IE) supports it, yet some do support JavaScript. JavaScript is supported by more platforms, thus JavaScript is more popular.
Thirdly, I think that most of the problems with JavaScript are not because JavaScript is a poor language (and thus replacing it with another language would improve the situation). Most of the problems I have with it are due to incompatibilities in different browsers, bugs in a browser's implementation (more prevalent in earlier versions), and poor/buggy/untested code written by inexperienced or lazy developers. None of these problems are specific to JavaScript, and each could happen just as easily with Basic, Curl, or anything else.
While a good standard language/ architecture for client-side web programming would be nice, I don't think one will appear unless the W3C puts its full weight behind one and the browser developers adhere to it fully.
Frankly, I've never understood why you would want your client to do less. I didn't pay a couple grand for a dumb terminal.
One final thought: the applet is a good idea (presuming they can work out a more stable environment than most JVMs seem to be). The scripting part will be at the mercy of MS.
---
---
Gort! Klatu Barata Nikto!
Informative??!?!?!? Mod this down you fuckheads.
You'd think that supposedly smart people would stop making the same stupid mistakes over and over again. If you want a new computer language to become popular, regardless of its niche, you have these options:
Otherwise, forget it. Don't believe me? Look at how popular Rebol and Eiffel are compared to python and java.
(quoted directly from here)
If I'm reading this right, the plug-in that executes the code reports back how many characters it has executed for billing purposes. I'd think there would be privacy concerns with this, not to mention how cheesy it is to bill based upon executed characters. Couldn't they easily fanagle their compiler to be really inefficient just to boost the character count?
--
All opinions presented here aren't mine.
Initially, Curl Corporation will only require payment for Curl content that is deployed for commercial use. Non-commercial users will be able to deploy Curl content at no charge. INITIALLY free, like "try this free sample and get hooked. If you want more later, we can talk money then." Maybe they'll only charge non-commercial users half the $1000 per month minimum. No thanks, Bubba!!
Got friends?
Basic has reached critical mass--everyone has Microsoft TM Qbasic on his or her or its computer. (All your basic are belong to us.) Those who use linux or BSD can easily get basic interpreters from freshmeat. But the question remains: how do we integrate BASIC into the web browser? I believe the peer-to-peer paradigm of buzzwords requires that we sucessfully implement a proprietary closed-source plug-in that is high-content and pro-validity with full customer compliance in order to sucessfully reach the goals instated.
Got friends?
Mozilla ;)
Got friends?
As far as I can tell from the website and the pdf documentation (pdf?!) this whole Curl thingy is only about visual presentation: computer screen and print out(?).
Ordinary HTML is not locked to any particular medium. It could just as well be read with a braille reader or a voice browser (or in smelloglyphs by Martians...).
But then again, who seriously uses Netware? Who seriously believes Novell has a fighting chance against, well, everyone?
Not me :o)
I recon Novell heared Java and thought it would be kewl to use it, but Java still sucks, no matter how many Novell's use it. Java still sucks, repeat after me...
This sig is intentionally left blank
Why haven't they upgraded? There is no need to upgrade. Going from Netscape 4.7* to 6 gives you what? Bloat, a bigger, slower, & less usable interface. <rant> I personally can't find a browser I like. IE dosen't render html properly & dosen't work under linux (without wine). Netscape & Mozilla are too slow. Lynx dosen't do graphics. and I don't want all of Koffice just to browse </rant>
This sig intentionally left blank.
Because Sun has it locked up tighter than an Martha Stewart's hieney.
My hypothesis regarding monkeys and typewritters revolves around the concept of broken typewritters and smeared feces on
All they have to do is to convince Microsoft to include it in their next release of IE.
Haven't you heard of it? C Gots an Interpreter. :P
While your compassion for non-professionals is laudible, your request for a simple markup language that allows users to code as they please isn't. Why repeat history?
HTML is a simple language even for non-professionals. Please don't try for a rebuttal that I am sitting upon my high horse. I've worked in several positions where my sole job was to instruct computer illiterates. I've taught many people (even senior citizens) to write HTML. The foundation of the WWW was built upon HTML, it's logical and easy to learn. Many designers found the language inadequate for their needs, so they developed more advanced languages. The majority of which were created to assist the end user. DHTML is an excellent tool for creating navigation schemes for large websites. I agree that these "advancements" have made it slightly more difficult for the non-professional. Where the real problem begins is with the adoption of these new languages. This has made webdesign difficult for professional and non-professional alike.
When companies begin throwing in proprietary code or only adopting a portion of a language - then the real problems begin. We've been tumbling down this rabbit hole for a few years now. And finally, we may be getting somewhere. Microsoft and Netscape are slowly becoming more standards compliant, and the W3C is waiting with open arms. Read: XHTML.
XHTML may be the first language that both browsers will adopt completely. And the days of coding for two completely different browsers will be over!
Oh wait, what about those old browsers? Nevermind. Guess we'll keep tumbling down this rabbit hole.
One is slow and buggy and the other is slow and buggier? You moron. Java provides an elegant syntax for writing quality software. Are you a programmer? I don't think so, you are a fucking moron and I hope someone beats the shit out of you quick!
Ya know what what; maybe this new language will make a difference. Maybe this new technology will enable many thousands of people the ability to create the types of pages and applications that usually require more knowledge to create. and that would be a good thing as i see it. The more people know, the more we will have, and the more you will know. Its just the plain truth. Also who cares if its a plugin. If this language really stands out then most likely it will be implemented inside the next versions of the browsers getting rid of the plugin. The same thing with Flash...that started as a plugin, and still is, but its also implemented inside many new browsers and how many people use it now?...some couple hundred million or so. I wouldnt be so quick to bash a new technology that may have the potential to change certain things.
Information Technology White Papers and Research
Who are these guys trying to kid? I can't belive I wasted my time on that!
You're an idiot.
If not, you're an idiot.
Let me be the first to say "Bite Me."
At the moment, we do not have a good answer for small commercial sites.
At the moment, you don't have an answer at all. You have created a solution looking for a problem. Given the wide spread adoption of Java, COM, VB, ColdFusion, and other "web" tools that are available at no cost, do you realy think you're going to get deep penetration into a a market by charging for what is easily available for free?
"No one wants to buy my rocks! Whatever could be wrong?"
Our intent has always been to obtain revenue from people who are making money off of Curl technology.
Those people are going to continue to make money off their existing technology. Future developers will make money by not assuming an ongoing cost liability in their platform choices.
Our business folks were faced with the interesting problem of how to take this technology and make it into a commercial product. They thought about it for a (very) long time, and this is what they came up with.
Fire them. They are idiots.
Can you think of a better idea?
Absolutely. But I don't work for free, and you already have a staff of professionals that thought about this for a (very) long time.
Driving adoption isn't some new science. If you have staff getting paid to come up with ideas, and this is what they give you, get new staff.
--
--
You sure got a purty mouth...
Seems like yet another Flash/Java -like bloated technology. You can count me out.
But if what they say about reducing the amount of bytes sent down, I'd pay for that, since I'm paying for sending bytes from my Web host anyway. I'd rather not give those Web hosting bastards any more of my money.
Have some balls coward.
You should enter their coding contest
Reading over their site, I get the distinct impression that they are just making a new implementation of an old idea - Java applets. Why not spend the effort making java work the way it should instead of creating a whole new mess?
-- Give me ambiguity or give me something else!
right on. html is pretty hard to comprehend all by itself, let alone messing with fancy client-side scripting. sure, i can figure all that stuff out, but i'm a programmer. my wife is not, and she's the one with a burning need to throw pictures of our daughter on the web with accompanying text.
anyway, if java and javascript were all that useful, then they would be included in slashcode, right?!
James
With just a quick parusal of the above links, I don't see how they think their doing anything different from Java or Flash. Where's the difference? What makes this so special?
I'd love to see someone come up with a revolutionary way of enhancing the net experience without increasing the need for bandwidth exponentially. However, this looked more like a bunch of Marketing speak for "We want you to use our stuff rather than the current tools." Heck, they even use a browser plugin just as Java or Flash do.
Note that by mentioning Java and Flash in the same sentance that I am not saying that they work the same way. I understand that they are two very different ways in which a lot of the same interactive content issues can be solved.
--
--
Unscrample my email, win a prize.
There already is a tool called cURL (see http://curl.haxx.se). It's a handy tool to use when scripting website walkaround scripts and the like.
> Present html clients have existed for several years now, but people still haven't upgraded to the latest and greatest (for whatever reason).
Actually, IE 5 has about 70% of the market, you can bet that within 6 months of IE6 being out, it will be in a strong position too.
And you already can program webpages with Basic.
It's called VBS, and work on more than 80% of the browsers.
--
Two witches watched two watches.
Which witch watched which watch?
Why can't I do client side programming on any of those languages?
On a related note, do you know if there are Windows Script Host extention for those languages?
--
Two witches watched two watches.
Which witch watched which watch?
Not according to MS, according to www.thecounter.coms er .html
http://www.thecounter.com/stats/2001/March/brow
IE 5 has 77% of the market share, IE 4 has 9%
I believe the numbers speak for themselves.
And IE6 will support all the features of IE5 & 4, just like IE5 supported all of IE4's features. It's netscape that breaks everything in browser releases.
You really don't know MS, do you? Backward compatability is a very important matter to them, sometimes even to the point of madness (9x, frex)
Hell, I can still play goldenaxe on XP, and the OS it was written for was about as different from the one I run it on as possible.
--
Two witches watched two watches.
Which witch watched which watch?
A> HTML was *never* meant to look the same on every machine, that is some other standard job (PDF?)
B> IE makes a good job in rendering webpages, Opera does it as well. Mozilla should be great when it's around 2.0 version.
The problem would've been much simpler if you had to write a HTML renderer alone, but you also have to write for Javascript, CSS, DHTML, etc.
C> I agree that translation is hard, I'm just pointing out that no compiler, as of now, has completed implementing the standard. No a *single* one. Ada is much harder standard to write for, and there doesn't seem so much of a problem with it.
--
Two witches watched two watches.
Which witch watched which watch?
Yeah, right!
No one has succeeded in implementing C++ correctly yet, and it's much older than the web as we know it.
You often can't move code from one compiler to another, so you complain about lousy HTML?
--
Two witches watched two watches.
Which witch watched which watch?
Perhaps I'm some kind of techo-Luddite, but really, I yearn for those days, when substance won over style.
Ryan T. Sammartino
Ryan T. Sammartino
"Ancora imparo"
How hard is it to balance parentheses, brackets, and braces? Sure people make a lot of misteaks [sic], but I think the promise of XHTML is worth the extra closing tags.
Anyway, this is a moot point. The majority of novice coders are going to use HTML-authoring software. Those can be made to create well-formed and valid code. The next group of inexperienced HTML coders will use a text editor, and most of the good ones have syntax coloring.
I don't think XHTML is all that hard to learn compared to old-style HTML, it's just changing the bad habits of the user who won't RTFM.
So is your proposal that we throw out XHTML because we want to save the doofi that use have bad habits and use M$ Notepad? Are we embracing and extending for them now? I didn't get the memo. ;-)
My father is a blogger.
Windows Only
-----------------------------
kaaaameeeeeeehaaaaaameeeeeha!
-----------------------------
-----------------------------
kaaaameeeeeeehaaaaaameeeeeha!
-----------------------------
Add a proprietary license.
Shake well, without a lid.
(BTW, anyone see their un-spell-checked home page? Or is there something called a "source cod" that I haven't heard of before?)
"Hardly used" will not fetch you a better price for your brain.
I think it was John Entwhistle who said that. Right band, wrong instrument.
"Hardly used" will not fetch you a better price for your brain.
It's shame though. Some uniformity to this part of the web-development world would really be nice some days.
In fact, I find this aspect of it much more intriguing than the issue of whether Curl will succeed. I have little doubt that Curl will go down in flames. The question to me is: why is Berners-Lee listed as a founder and what are all those people thinking?
with faster downloads, anyone who switches to Curl has a better chance of surviving the slashdot affect?
Help find a cure for cancer!
Good point
Disclaimer: There is no guarantee that the content has been read or understood
C'mon. There are plenty of good languages out there. May I suggest Standard ML? APL? Scheme?
How about another name. Div? Grad?
------ 1001001
Oh frettled gruntbuggly,
thy micturations are to me,
As plurdled gabbleblotchits on a lurgid bee.
Groop I implore thee,
my foonting turlingdromes.
And hooptiously drangle me with crinkly bindlewurdles,
Or I will rend thee in the gobberwarts
with my blurglecruncheon,
see if I don't!
------ 1001001
Well, it ain't gonna happen. After the finishing exams I'll be jumping over to webdesign-class. Much easier on my eyes.
sig sig sputnik. we love.
<hit-and-run-mode>Write your own browser! Only then will you be able to feel happy about yourself. :P </hit-and-run-mode>
sig sig sputnik. we love.
And I'm learning Java in the programming class. It's a great language to teach OOP-newbies like me, and with Supercede's native-mode compiler speed is pretty much decent.
sig sig sputnik. we love.
Aw, come on! Just like every technology out there it can be both used and abused. Personally, I think that guns == Pure evil!!!!!!! Come join my crucade!!!1!11!!. :P
sig sig sputnik. we love.
The only reason we monitor what you view is to allow us to charge commercial content providers. As much as possible, the information is collected and used only in summary.
We are well aware that end users do not like being monitored, and we are well aware that they do not like to pay metered rates. We have designed our revenue model and associated metering mechanism with this in mind. Apparently, we need to make our privacy policy more clear.
Our present revenue model is directed at two groups:
At the moment, we do not have a good answer for small commercial sites. We do not yet have enough sales staff to support a huge number of small customers anyway.
Our intent has always been to obtain revenue from people who are making money off of Curl technology. Doing this directly based on their profits is very difficult in practice. So for now, we are going with this metering model.
But if you are not making money off of Curl, we have no desire to bother you in any way. In fact, we want to encourage you, because we want Curl to spread. Hence we have no charge for non-commercial use, and we provide lots of free resources for developers.
Our business folks were faced with the interesting problem of how to take this technology and make it into a commercial product. They thought about it for a (very) long time, and this is what they came up with. Can you think of a better idea?
Yes, it is a browser plug-in. It started as a standalone application, but we figured end users would not be interested if it did not run in their browsers.
We still use the standalone version internally to build Curl, because most of the Curl client is written in Curl itself.
We have had a Linux version internally from the very beginning, but we are not comfortable making it a supported product yet (sound familiar?). About 1/3 of our developers have Linux machines on their desktops, and nothing gets committed to the source tree unless it passes all tests on both Linux and Windows. So releasing a Linux version would not be too hard.
The Mac version will be... tricky. :-)
The principle you are espousing is the same one which has driven Curl's design from the beginning. We call this design principle the "gentle slope".
The idea is that an ordinary text document is a valid Curl program. You can do simple markup using a syntax about as complex as HTML. If you want a more interactive page, you can do it by learning a little more Curl; you do not need to suddenly learn a completely different technology like Javascript. As you learn more Curl, you can create more complex dynamic documents. Eventually, perhaps before you know it, you have gone beyond documents and are writing full-blown object-oriented applications. The author has been led down the gentle slope and has become a programmer.
That was the idea, anyway. The "gentle slope" concept permeated every design discussion we had, and we always considered it the principal architectural goal. It was not always an easy goal, and how well we succeeded remains to be seen. But we did try.
The gentle slope also extends all the way down into the heart of the runtime. All of the components in the Curl system (including the layout engine, the rendering engine, the debugger, and so on) are themselves written in Curl, so you can invoke them directly when you need them. For example, you do not need to learn some disparate "document object model" to create complex layouts on the fly; you can just invoke the object oriented interface which is already present in the guts of the system. The full benefits of this tightly integrated environment are hard to describe, but they do become obvious if you spend some time playing with it. Or so we hope.
By the way, this integrated "universal" environment, with its easily composed and reused pieces, is squarely in the tradition of the great Lisp machines. Exactly how Curl is like Lisp, and unlike Lisp, and why, is a topic for another time...
I hope that people realize that the current paradigm of the WWW is workable but has flaws. HTML is in fact a very limiting paradigm that severely limits your range of expression. For many applications this is not only bearable but good. Limitations can be advantages, in terms of security, for example. You don't necessarily want you .doc to be a full executable... oops, did I mention that? :)
But frankly, the science-fiction vision should be more along the lines of easy loading of networked software that looks good, performs well, and has the power that I expect from a desktop application. Does HTML + JS fulfill that task? No, it doesn't. Reload is a silly paradigm for refreshing content. Does Java? Maybe, but it depends on who you ask.
The Curl language is an entrant into the field of client-side computing with some advantages and disadvantages. Let's visit a couple of points raised to date in this discussion:
1) Client-side computing. HTML is a form of client-side computing: the client has to render the markup, right? It's not really CSC, but it is a mark near the edge of the spectrum. All operations involving two+ computers involves interactions between them, and there are operations that are better suited for one or the other. E.g. databases on the server, graphics on the client. Curl language is a powerful client-side language, so better lets YOU, the developer, choose where any given operation should take place. Isn't that a plus?
2) Integration. They say you can use the Curl language with EMBED. You can create source code on the fly with server scripts in any language and pass them down normally. See the various .jsp comments. This leads into point 3.
3) Content and markup. There is nothing forcing you to mix the two, but you have to option to. This allows you to integrate with existing systems that assume markup. Or you can write a rendering system that pulls down pure XML. Your choice.
4) Editors. Note that they have an emacs mode in the Tools section of their Web site...
(Plus, anonymous procedures are the bomb. :-) Try them, you'll like them.)
In other words, we should be arguing about whether this new (though under development for years) client-side technology is a good realization of client-side technology, not dismissing it offhand because it is not HTML. HTML is HTML, and is not going away anytime soon... in any of its countless flavors/versions/acronymns. But maybe it's not the best for every task. I think there is also room in 'computing space' for an integrated language that does JS++--+-+ and friends one better. Legacy solutions are not always preferable just because they already work, albeit poorly.
I'll take a thousand clients running at 50% of theoretical maximum rather than a dedicated server rendering and serving GIFs for each of those thousand, please. :)
Be that as it may, there will always be an advantage in using the minimum amount of bandwidth necessary to do the job. Any pipe can be filled with cruft, no matter how large the pipe. I predict that someone will always find a way to fill whatever is available -- streaming 3D with video textures, or something awful (or useful!) like that. If you only really asked for 30 Kb worth of info, then that's what the server should send, if at all possible.
The way around this is to provide an applet that queries the server without reloading itself, then updates the GUI state as required. Curl language applets can open connections back to the server. No recompilation required until the user shuts down and restarts the next day, or you rewrite the applet, etc.
Also -- I have a broadband connection, and I still wait on large pages. Not just for graphics, but textual data and for very complicated layouts. It happens today.
Having used/tried to use CSS, I can safely say that the Curl language's GUI options are much saner to use. CSS gets really complicated really fast, even without all the current differences in implementation between browsers.
Disclaimer: My employer, Curl Corporation, does not necessarily share the views expressed in this message.
Why would anyone actually use this...they want you to pay royalties if you're doing a commercial site. That's so unrealistic it makes me sick. Stick with javascript, get a clue curl. Brian
Taking over browser functionality is probably a must, since, among other considerations, rendering standards still go lacking. That doesn't excuse the approach, but it does (once again) point up the need for a uniform client standard. I don't know if that alone would negate the need for a CURL style language, but today, I'd settle for real uniformly functioning CSS and complete adoption of HTML4.0. Suppose that makes me a cheap date- oh well!
Besides the completely irrelevant whinings about Curl's website using JSP pages (geez people, that's like saying a web page promoting Java is using _HTML_ to disseminate information about the language.. oh the horror!), we seem to be getting some good informed feedback here which I think is great! I've read through most of it and would like to both summarize a few points that have been made, as well as comment on my expectations and view of the language.
;) Java extraordinare that I may be, they will likely have my support. In the meantime, I look forward to seeing what changes might be included in future releases of Curl.
Applications at present are almost universally server-dependant, and the average client machine isn't using a fraction of its own processing power. While bandwidth may be increasing, we're also wasting it with unnecessary server requests. On the whole it would seem logical to reduce server load and increase client load since servers are in general overloaded and clients are underloaded. Client computers are getting cheaper and faster, but current internet architectures don't take advantage of this at all. Curl does, and this is makes it a good thing!
Yet as with all things, there is a downside. What about those of us with slow computers? Receiving purely HTML content is not a big deal, but the minimum requirements for installing the Curl plugin are somewhat high. This worries me. Without improvements in this respect, I do not think Curl will be a viable replacement for HTML, or even the current HTML + CSS + DHTML + Javascript model. Why? Because it's a bit too powerful, complicated, and requires a bit too much computing power for the simple things. Slightly dynamic, nicely laid-out documents should not require this kind of processing power. And this is too bad, because I like the idea of using one language with the capabilities of all four. (I especially want to get rid of Javascript, that hacked crap language that gives Java -- which I know and love -- a bad name.)
On the other hand, I can see Curl as a serious competitor to some of the "Flash"-ier sites, with its native 3D support and built-in 2D library. Flash development sucks ass. (Whoops, pardon my language.) Curl also has the advantage of integrated powerful layout capabilities. Text/graphic layout using HTML/CSS still has me smashing my head against the walls in frustration, especially when I get things JUST right in Netscape only to have it be a complete mess in IE. Frankly, it's too much of a pain to do simple layout with HTML+CSS and I've been itching for something better all these years, even if it means learning a new language.
Hopefully improvements will be made in reducing the requirements for the plugin. (And btw, I think the fact that it is a plugin and not a whole new browser is a good idea. That makes it more compatible with existing technologies, and means the company spends more time on making the Curl language work rather than making HTML/everything else work.) Curl is still a new language and we really have to give it time to develop. The underlying concepts are good though... utilizing client processing power, providing powerful graphics capabilities and much simplified layout functionalities. What the company aims to do -- address the shortcomings of current client-side web languages -- is very ambitious. I think the specification is pretty cool even if the implementation leaves some things to be desired.
I sincerely hope the company is working really hard to get the Mac/Linux plugins running as soon as possible, since that's a big selling point. And that it works as specified... no platform inconsistencies and real platform independence would be a real win. It would, of course, have to be faster than Java to REALLY sell though (JVM was a good idea for this but in the end, makes Java slower than I'd like).
I too would like Curl to rethink their marketing strategy. Although they initially only charge for commercial sites, the wording they use implies that they may start charging everyone. If they ever start charging noncommercial sites employing Curl content I will likely never support them, not while there are alternatives. Even for commercial sites, charging on an executionary basis is less than ideal; for example, what about those sites with high browse to buy ratios? The pricing scheme really sounds very bad to me. The solution? Make it open source and free. This is the one true path to enlightenment and eventual perfection.
I hope Curl survives long enough to work out their initial bugs (and work through the initial criticism of the largely uninformed public). I think it could be a really revolutionary thing for the internet community, but it needs support/acceptance and before that, more development and marketing work. I'd say that starting with educational facilities is definitely the way to go... the current generation of web programmers already knows alternative languages that are widely accepted and thus marketable. I also point out that Java will also always likely be easier to learn for those who already know C/C++, and the fact that it is THE hot language to know for internet application development gives Curl little leeway to break through in today's market without a carefully thought-out marketing strategy.
At the moment, I simply don't have the free time/resources to spend learning a new language that might conceivably turn out to be a waste (though I really hope not!) no matter how easy it is to learn and use, so I am not investing much energy into learning Curl. I already know enough about programming in general that I probably won't gain anything by learning yet another new language. However, students just starting to learn web programming might find it educational to begin with Curl as opposed to HTML (I never thought the HTML syntax was pretty anyway)... another reason why I think Curl should consider targetting the younger generation.
So in short, if Curl Surge is included as a plugin packaged in the basic install of Netscape and IE for every platform, free of charge, I think over 85% of Curl's problems would be solved.
A few quick observations from a "seasoned" Curl beta user:
1. Reliability: Although it may be easier for an end user to have the browser bundle up required software instead of the user needing to download a plugin, one major advantage of a plugin technology IS reliability. As long as the software vendor controls the engine (i.e., the "compiler") itself, reliability is in the hands of the vendor, not the hands of diametrically opposed and relatively disinterested browser vendors.
2. There is a means for obscuring code. Application code can be processed such that the code is compressed and obscured, yet can still be interpreted by the plugin.
3. Curl seems to have identified integration as a key component in their quest for acceptance. Although there is supposed to be very little you couldn't do all in Curl, they've very heavily promoted interoperability with existing technologies.
It seems to me that forcing the nested-container format makes HTML less confusing: one need not memorize the strange exceptions where they don't need closing tags. And it makes it easy for tools to find where the document is malformed. It's a win for novices and coders alike.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
The difference, of course, is that I can use Java and JavaScript for the low price of FREE, and support is included in most browsers without the hassle of a plug-in.
Curl, on the other hand, wants to charge by the character for commercial content, and your customers will be forced to install their goofy plug-in to boot. Oh, and they want to force you to learn another language as well, that makes sense.
Face it, the folks behind Curl are clearly insane. Their mousetrap might be better at killing mice, unfortunately it irradiates the entire neighborhood and makes your house unsuitable for human habiation for the next 1e237 years.
The minimum payment for commercial Curl usage is $1000 per month and the maximum is $50000 per month based on the characters of Curl content sent. I don't know what kind of magic Curl claims to be doing. But the bits from your images and text have to get to the client somehow. My guess is that they aren't doing a better job than PNG, JPEG, and Apache with mod_gzip.
Well said. There is no way that Curl has any chance of being succesful given that it is competing with several well tested (and well-known) systems that do essentially the same thing for free.
It seems that these people are from the old Dot COM school of business. Invent something cool, but try and make money on something that is competing against that is free! Netscape knows quite well what happens when you try that. (BTW I pretty much ONLY use Netscape)
I am all for making money off internet based products, but there are some things that don't lend themselvs to be "for charge". What would have happened if CERN charged for every character served out to an HTTP Browser? Do you think the net would have taken off? Just think of the cost of relearning a new language, making sure all your clients are compatable, and then paying for thier licencing... Customers commit to an annual volume of between $12,000 and $600,000, payable in equal monthly installments, with a minimum of $1,000 per month.
I say kill it now quietly before clueless CIO's get suckered into paying for something that will go the way of the DODO in a couple months...
Personally, I'm still waiting for a language that will replace current server-side languages, rather than client-side.
You know -- things like shell scripting, TCL, Ada, and C.
--
Breakfast served all day!
Yesterday, Eazel just announced Reef, yet another attempt to do the same thing Microsoft announced with .NET which is similar to Dave Hyatt's XUL (+CSS+JS) for the Mozilla project which promised to do what Java was supposed to do.
All this so I can subscribe to my word processor on a monthly basis?
Kinda depressing.
Seriously, can't we all get together and decide on a single system without everyone going off doing their own thing?
Answer: No.
-------------------
-------------------
This is my SIG. There are many like it, but this one is mine.
Oh geeze, it's the Basic guy again...
C-X C-S
CobolScript
Personally I am looking for a server side language that is better than JSP and Servlets. Perl is okay, and mod_perl is better, but can get messy, Php is good, but does not cache like Story Server.
On another note this is exclusionaly technology in its current form. It does not work with Netscape 6, it does not work on Linux or Unix at least that is what there system requirements say, no not even Mac either. So they inventeda new plugin.. BFD there are lots of those, and unless it is an open standard that anyone can implement then it is useles to me and would deter me from visiting that site.
Hey M$ is even talking about making there C# an open standard. Of course they wont make it open enough it will still have COM/DCOM/ActiveX hooks.
Who would have thought that the WWW would have become the World Wide Divide? Maybe they should detect a browser and say, "your browser maker is to dumb to make a browser that works with the standards! Please go away. (lol)
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
Nice try Bill! We're on to you!
As for the "people who find HTML confusing enough already", in my experience, they mostly use products that allow them to avoid dealing with HTML.
CGI is a scripting language?
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
The main pox infecting the pustules of the web is client side scripting. Every browser invented by the mind of man treats every client side language differently, making the authorship of working code a Death March.
Browsers as they exist can barely (and sometimes not) handle the much easier task of rendering a page, and until one put a standards compliant page on the web AND HAVE IT APPEAR SIMILARLY on 99.5% of the browsers in use WE DON'T NEED NO STINKING CLIENT SIDE SCRIPTING!!!
MOVE 'ZIG'.
Could you please clarify what, exactly you mean by those terms? To me, "mature" would mean little or no cross platform/cross browser compatibility issues... which is clearly not the case with JavaScript or CSS... to say nothing of HTML.
] D
At my last company, resumes that featured "Java/JavaScript" went instantly into the atomic shredder.
That reminds me, I have a flash animation I want to run in lynx, but it says "plug in not available, use color xterm" ... who knows what this means? I'm running on a Diablo teleprinter.
One red flag that went off immediately is the advocating of integrating code and data.
I dont understand the rationale behind integrating them - they are 2 very different things. Developers need to be able to change one without the other, hence the recent rise of the old MVC paradigm in the JSP world (mixing the Java code in the HTML page makes for a mess because designers have to work around it, and it gets hard for coders to manage.)
So why does Curl suddenly think it grand to re-mix all the code and data? Can anyone explain this to me?
Aside from this, I don't see any reason to code in Curl. There's lots of mindshare and knowledge out there in HTML + DOM + CSS + JavaScript. Sure, it can be a pain sometime, but there are a lot of people out there working to make it better. Why turn that distributed responsibility over to a company with a proprietary technology? I'd rather just improve upon the current open standards.
My initial impression of the language itself after looking at the text formatting example is that it looks hard to parse. There's no clear distinction between control syntax and data. I think HTML/SGML/XML looks easier to parse (at least initially)
Though, having spent all day dealing with javascript, I'd rather that I could someday, within my lifetime, code to a single standard.
Then all I have to do is fix shitty dreamweaver code.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
According to their web site OS/2, OS/400, MPe/ix ports are on the way.
As for the others it's already been ported to 45 platforms I am sure if the there is any demand it will be ported. How hard would it be port it tru64 unix when it already runs on aix, irix, solaris etc.
It's kind of odd that there is no palm support however.
War is necrophilia.
-------
CAIMLAS
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Anyone who thinks JavaScript is mature has obviously not seen this :)
God Fucking Damnit
Does anyone know if there are alternatives for LiveConnect out there that give greater cross-browser compatability? Javascript is OK to get done what you want to, but it's singlethreaded. LiveConnect allows me to tap into the JavaVM and have a multithreded codebase. We're presently using Liveconnect to connect the browser to XML-RPC on the clients JavaVM, and making multiple simultanous asyncronous calls...
We're planning on coming up with an alternative, cause JavaVm is slow to load, hard to configure on the client.
Does anyone know of a JavaScript only implementation of RPC server calls that works asynchronously (multithreaded) on both NS and IE?
Even a "synchonized" block in Javascript would be helpful. (You could use the multiple frames of a browser and use the *browser* to make the calls as a POST request and let JavaScript wait for the server to give a response, but it's hard to synchronize the JavaScript to control the frames....
2) Redefine a new comment indicator.
/* */
//
/** **/
shell: #
C:
C++:
asp: '
curl: ||
SQL: -- (some, not all?)
Javadoc:
lisp: ;
vim: "
Forth: \
These are just the ones I know...
"The area of penetration will no doubt be sensitive." ~ Spock
What are the chances that TIBET will ship?
Seastead this.
- Classes
- Class Members
- Strings
- Collections
- Hash tables
...
- Memory Management
...
Note that this documents follows the 200 page "beginners/basic features guide"...I can see it now: "our language is so technologically advanced that you can use STRINGS if you become an expert in it." and "yeah well sure perl has nice hash's that they tell you about in the first chapter of learning perl. You can read about it on page 99 of the advanced features guide!"
-Chris
The last time that I heard of a "CURL" was when it was in reference to that POS system that Vignette hacked together, and when I was shipped off against my will to one of their training seminars. They used to refer to "Custom" URL, where you do some thing ugly like wired news: http://www.wired.com/news/culture/0,1284,42774,00. html the comma separated shit actually keys to a cached file in your database system...
BTW, the first "0," means absolutely nothing.
- passion
But, there are things like PHP whose rise has been nothing but astounding...
But that is a server side technology, so you can change your site over to php and nobody will even know (except that is has some cool new features). To adopt a new client side standard (like Curl) you need support from a lot of people: the major browser makers (to add support in their browsers), and most users (to upgrade to that new browser).
Most companies will still want to support older browsers anyway, so doing Curl will just add another level of complexity to the mess.
I'm much more interested in server side tech like XML/XSL that lets me use logical formatting for the data, but to then render it out in standard html (or SWF, or WAP, or PDF). If I want to change the data, I change only the data. If I want to change the formatting, I change only the template. I've been doing this for a long time with my own perl/database kludges, but it would be nice to have a standard format for it.
1) It's a damn browser plug-in.
2) Does this sound familiar?
Surge [Curl] is currently for Microsoft Windows only - Macintosh and Linux coming soon!
Translation: Windows development takes priority and we release for this platform first (versus other projects that *truly* support all platforms and develop their releases in tandem).
3) How much space?!
Total installation will be ~ 17Mb depending on system configuration.
People will rush out ASAP and download this you say?
Riiiiiiiiiiiiiiiiiiiiiiiggggggggggggghhhhhhhtt.
Moderators need an additional choice: "Karma Whore" for people who cut-and-paste articles as their comments!
It just seems like this isn't going to stand a good chance against the already established tools out there today. People have spent a lot of time learning and developing with java and javascript, not to mention such things as flash and things like that. Will people really have the time to spend on learning a new language? (even if it is cleaner or slightly easier to use?) With so many different methods out there now, I'm afraid even a good alternative will be lost inthe jumble.
I can't believe Bernars-Lee is behind this. The documentation for it is in PDF.
http://www.curl.com/html/technology/documentation. jsp
I guess they can't afford to pay per-character for the use of CURL on their pages... :)
If you open yourself to the foo, You and foo become one.
One is slow and buggy, the other one is slower and even more buggy.
--
Je t'aime Stéphanie
I've looked at it, it's EXACTLY like LISP except they replaced the parentheses with curly brackets just to say that it isn't LISP. Looks like everyone is trying to avoid to look to lispish these days. I wonder why.
--
Je t'aime Stéphanie
http://www.curl.com/html/technology/documentation. jsp
Seriously though, any new language is good, despite what anybody says. A different way to attack a problem always brings insight into solving others.
IMHO the basic rationale they provide for eth existence of CURL is flawed, based on mistaken assumptions. From their site:
re-drawing the entire page is a red herring - the issue here is speed of response, which is ruled by three factors: 1. processing speed, 2. available system resources, and 3. web connection speed. Their assumption is that server-side processing is inherently slower than client-side, but that isnt true nowadays by default because server-side processing actually is more efficient than client side on all these fronts.
the trend of most content-heavy websites is towards heavy duty server hardware with efficient server-side engines like PhP or mod_perl. Compare that hardware and software environment to a typical client-side desktop which suffers from M$ bloat, multi-tasking, and limited hardware. Unless you have server-grade hardware and don't use any other programs while surfing, you're probably not going to be able to execute code a.out in less time than it would take the server to execute it AND deliver it to you.
speaking of delivery, consider that the trend is towards cable modems, ISDN, and DSL and away plain old dialup. True not everyone has fat pipes (I don't , myself) but why design a technlogy for the past?
The first rationale basically is saying, "if you have a really slow connection, super-expensive hardware, and don't multi-task when browsing, you can benefit!" - what subset of users fit this profile?
odd they are talking about cost of delivery, when you can deliver content for free using PhP and HTML and it costs you PER CHARACTER to deliver content via CURL :P
granted, server-side processing sends the Whole Enchilada. Your 5-line PHP file expands to 100 lines of HTML and jscript. so what? if your connection is fast you won't notice, and if your hardware isn't state of the art you will wait for local compile time anyway. Just like you do now for Java (which is why IMHO Java sucks for web but rules for everything else).
well, actually if you follow CSS you can separate content and layout without installing Yet Another Plugin and also minimize complex nested tabling. Assuming you use Opera or IE anyway :) To be fair they should compare CURL vs HTML + CSS, not CURL vs HTML alone, if they want to talk about layout affecting code design.
they should rethink these issues a bit moreDon't blame me - I voted for Howard Dean. http://dean2004.blogspot.com
you can reassign a function pointer at runtime, something you cannot do in Java.
Just change the object.
Rate me on Picture-rate.com
"and dear god does this website suck now." -- CmdrTaco
Looking at some of the technical docuemnts, it seems that they are designing "curl" to be fairly comprehensive. It can be run as an applet inside a web browser, compiled and run as an application, run as a script, or preprocessed and distributed for faster linking and runtime of reusable code.
:(
.NET initiative. It seems to be a direct competitor to those technologies. The only drawback seems to be the syntax - very different from Java and C/C++
Currently, the scripting option is not supported
Some of the syntax is a little strange, but I am assuming that it is related to LISP. It appears to support object and object orientated coding paradigms, but also incorporates some cool ideas from LISP - you can reassign a function pointer at runtime, something you cannot do in Java.
I wonder how this will stack up against Micro$oft's C# and the
-----------------
the web logs of one of the top three busiest sites in the world shows that people do in fact use late-model browsers.
This isn't intended as flamebait, but is something that needs to be pointed out. It seems that Slash's editors have long since written off Java as "something for web browsers", but in fact (as those of us who do this stuff for a living know) Java these days is FAR AND AWAY most used in back-end software - enterprise applications, application servers, etc. Granted, these aren't tools that most websites use, or ever will - and that's the point; Java is NOT JUST A WEBSITE OR WEB-BROWSER LANGUAGE! It has great stuff for that, sure. But that's not it's strength.
Probably everyone to read this either (1) already knows that or (3) could care less and wants to get back to trolling. Well, fine. Have fun. But just keep that in the back of your mind.
Comment removed based on user account deletion
first, what exactly does curl offer that Java doesn't? It is a programming language plus client side environment ( say java), it offers a rich GUI,( say java) etc.
Second, the idea is that the separation of interactive code and static content is a hurdle. I don't think so. This separation allows different professionals to deal with their aspect of the product. It may be that some better way to deal with this separation is needed, but having every web developer be in charge simultanuously of programming the interaction and formatting the content seems to me less than desired.
Third, I am not sure that the need to combine various technologies is a liability either. This is after all a continuation of the Unix philosophy. I suspect that sooner or later someone will find out that Curl lacks something and people will come up with ideas of how to glue Curl and _your_favorite_technology_here_.
I do agree that the HTML browser GUI is unacceptable. What could solve this problem better would be a browser capability of delegating widgets defined in HTML to a toolkit ( tk, Gtk, etc.)
-- look, cheese ahoy!
Link on the Curl download page: "System Requirements"
Not really two concepts that go together are they?
as per the web site they would be charging for using curl for commercial usage. well nobody charges u for using HTML, javascript or java?? that sucks..i cant imagine that tim-b can propose something like that. and i guess it requires a plugin..huh? how many more??
As a Java developer, I don't much like the name of JavaScript, since it really isn't Java. java is no more a client side programming language than VB is. Both can be used for client-side in-browser apps (applets, activex), but as far as the web goes are more popular for the server-side (ASP, JSP).
:-)
I think the best way to tell the difference is the salary difference between JavaScript and Java programmers.
reech bee-yond ur clip-0n
So the PR description of Tim and Michael 'throwing their weight behind' Curl strikes me as unlikely and out of character. If Tim was interested in money he could have an options package almost certain to be worth seven figures from any number of profitable Internets.
What would be more Tim's scene would be a conference on scripting languages with lots of alternative proposals.
It strikes me though that rather than just rehashing for the nth time specification of yet another ALGOL or LISP like language it would be good to see use been made of other ideas that are not currently mainstream.
C# and Java do no more than a necessary and useful cleanup of C. But neither fits my concept of an object oriented language. These days OO has come to mean 'support for inheritance and methods bound to data structures'. I remember when the core idea of OO was considered message passing.
Surely there is much that could be done with message passing, direct support for parallel processing concepts etc.? The Inmos Occam language had many features that would be exceptionally useful in the context of programming for Internet applications.
Nothing could be less interesting however than merely tweaking the syntax of C to make it less eggregious. Syntactic sugar is important but ultimately an editor or preprocessor can be programmed to do the same work. Anyone can remember using RATFOR? Or the days when C++ was a preprocessor?
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
{paragraph CURL is pretty neat to use, and extremely simple to write in however, for someone to think it can do much to compete with JAVA... your wrong} (by the way, thats more or less how you would write for an applet)
Simplicity, ease of use, is not enough to compete with the marketing resources of Sun, so its going to be a difficult obstacle to overcome.
Now should they actually go over Sun, they would also have to hope company's would be willing to switch over from JAVA to CURL, and it can be difficult to convince a company to switch technologies altogether. Not only that, but you also run into issues such as, just how great this is on x platform running x backended to x, and when I say x I don't mean X as in the desktop environment. It does not have much by way of experience.
I like it though, its pretty neat.
curl free
360 degrees of Karma
The good language exists yet. It's name is OCaml and it's supported by INRIA France. It is far better than Java C++ and any scripting like Perl Python PHP ... It is 4 - 10 times more productive than Java, 2 - 4 times faster with a perfomance near C++, less memory usage, strict typing system don't let you make stupid mistakes, automatic type inference (you dont need to waste your time writing and checking among modules useless declarations messed by casting). It is functional, with imperative and OO support, extensible semantics and easy C or C++ interface,
GC, high level native types like tuples lists. It runs with a very fast bytecode interpreter and a superb native compiler, GUI, database ... libs. I have being programming more than 10 years C++ and 5 years Java and OCaml is far ahead. About Basic no comments (I don't want to offend anybody).
Arturo Borquez
Back then, you could download the source off of a university server (IIRC, they had a JIT even back then). All the documentation was in Curl, and there were neat things like a falling blocks game.
I kept watching for something interesting to happen, but the page disappeared. A while later (still years ago), a "coming soon" commercial page popped up.
I mailed the guy who wrote it, and he made it pretty clear that it was going proprietary all the way.
A real shame. It was a great idea that got hung up for years while they decided to develop in private, hidden away from all the potential volunteer contributors, then killed by a decision to try to sell a programming/document language like a pile of cabbages. They don't seem to have realized that there have been better hypertext languages than HTML since before HTML was made, it's that HTML was an open standard supported by free software that made it so important.
--
I have several major reservations about Curl:
First off I downloaded SurgeLab to check out some of the code and the development environment. The curl code itself is extremely verbose, (aka takes lots of typing to create simple things) and is not very intuitive.
Second, I think the whole idea of an "everything including the bathroom sink" technology like this will make the development of even semi-large applications difficult. I much prefer to be able to seperate data from logic and to have a language for each that is taylored to its specific purpose. The whole idea of trying to mix display elements with the programming logic that controls the display is crazy. Anybody that has worked on even a decent sized web-app knows this.
Third, the licensing policy for curl is obscene. Can you imagine a start-up company having to fork over $1000/month (minimum) at the very begining just to pay for usage? Curl is the anthesis of the open source movement.
I saw a couple people remark that it would great to have a new web technology that is not controlled by one of computer giants. That's crap! Everybody wants to stand behind some David that is waging war against a giant, but I have no reason to believe that the people behind Curl aren't trying to make a giant of themselves.
I'd rather keep my text & images in resource & XML files, the display formatting information in stylesheets and XSL files, and the code all by itself.
There are lots of things out there that are better that no one uses: compression formats, languages, systems, cars, voting systems, etc. Its going to be a long while before HTML goes away, especially with the less sophisticated, the incidental web-happy people who make up the bulk of internet users. I would wager that a good percentage of AOL kids and geocities flunkies can code a little HTML and know enough to cut/paste/modify a Javascript into there NSYNC or Pokemon page. XML, Javascript, etc aren't going to disappear amongst the middle-brow webbies either. The only people who might be bold enough to try are the ubergeeks. Like the guy said ^ unless MS or another behemoth takes it under their wings, it would have to be damn luck to make headway. But, there are things like PHP whose rise has been nothing but astounding...
Disclaimer: There is no guarantee that the content has been read or understood
(disclaimer: I work for Curl and love programming in Curl. However, the following is not 'officially' signed off on by Curl Corp., this is a personal diatribe.)
...
Unfortunately, the motivation behind developing the Curl language has not been accurately portrayed in this discussion. This is understandable due to many factors, mainly that our demos may not represent our vision completely (they are admittedly applet oriented while Curl is much, much more than that) and our pricing page not conveying the fact that employing Curl powered Web pages/sites can significantly reduce current operational costs such as Web hosting and backend infrustructure charges.
I have been developing database driven HTML/JS/CSS/DHTML/... Web pages/sites for quite some time now and have always run into the same problems. Cross browser incompatibility problems (not even just btwn NS and IE, but btwn different *versions* of the same browser), difficulty with maintainence, debugging, stability, and extensibility, and limitations inherent to the languages/protocols themselves.
One of Curl's missions is to provide a way for Web programmers get away from this restrictive situation by placing the programming power back into the Web developer's hands. Since Curl is a full fledged OO programming language (including multiple inheritence) with native support for text formatting and scripting, Web developers can very rapidly produce Weby UIs with the programming power only available outside of Web UIs - like in a C/C++/Java application. Sure you can embed a Java applet in an HTML page but only through liveconnect can that applet talk w/ JS - and then only through DOM can JS modify the page dynamically - now you are back dealing with cross browser incompatability issues
With Curl, you can really start thinking about advanced DHTML-like things in a cross browser environment with a development environment previously only available outside the DHTML world.
Additionally, there is a SAX2 compliant XML parser in the Core of the Curl runtime. So, writing a Curl Web page which gets its data from an XML stream opened to a server side PHP script based upon a user's interaction w/ the page (like clicking a button, filling out a form, or mousing over some text) is possible without embedding Java in an HTML page or refreshing the entire HTML page by applying an XSLT to the XML response. XML has been searching for a way to be employed on the client side in a Web environment and Curl is, in my opinion, a great answer.
How about graphics - many of the graphics on the Web are curves, gradients, and so on - graphics which can be procedurally generated. Curl's 2D library allows Web developers to reduce the number of little gifs their pages contain (obviously many situtations like pictures of people don't apply here).
And then there is 3D. With native 3D support, a Scene can be placed anywhere in a Curl page. Since it is not a third party 3D Scene embedded in an HTML page, but rather a single semantic framework that contains 3D objects, everything can talk to everything else. Drop down lists, buttons, text, etc. can contain events which interact w/ the Scene and vice versa. There is no break btwn components on the page - everything is uniform, knowledgable about each other, and live.
So, sorry for the rambling, I know that was long winded, but I just wanted get out some thoughts as to why I love programming in Curl and do not want to go back to the old environment where I'm always concerned as to whether my tables will line up right in both IE and NS. Let alone the whole other host of incompatabilities.
Open to discussion, I love talking about Curl...
Ok, let's say that some website that I don't like uses CURL. What will stop me from hacking up something that will keep reloading a certain page and causing them to be charged by CURL corp hundreds (if not thousands) of time. Even better, what if a CURL employee visits a site with CURL, s/he would be generating revenue for CURL corp. It can get more interesting. What if CURL corp. hires people all over the world (where US law does not apply, and FBI can't investigate) just to visit their customers' web-pages tens of times a day. The victim would not even know!
Just my $.02
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.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
I also have a proposal for improving the quality of web pages everywhere: stop using Javascript in your pages. Really -- DHTML is cool and all, but IMO not worth the price of wrestling control of web development away from non-professional HTML coders. The web is a revolution because anyone can do it - anyone can understand HTML with a little work. The ability of people to publish their own content unrestricted to an unlimited audience is unprecidented, and should not be ignored.
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.
At LEAST as well as Scriptics Tclets did. You see those all OVER the place...
"Beware by whom you are called sane."
Potato chips are a by-yourself food.
Firstly I think you are wrong in stating that the barrier to entry is being raised. Whatever the new standards bring, Jane Average can still code their pages to "HTML 3.2 standards" and have them rendered as well as they ever were. The sheer weight of pages coded that way will continue to demand that browsers render them. CSS, XHTML and DOM don't take anything away from such people, they just give more to those who want it.
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.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Go look at rebol.
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
War is necrophilia.
Take all that anger and do something constructive with it: webstandards.org
Down with crap-ass workarounds!
"Smear'd with gumms of glutenous heat, I touch..." - Comus, John Milton
The House Between - Original Sci-Fi Series
It's not going to suceed until it's built into all the browsers, 'cuz writing code for non-existent interpretars is a waste of money..
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?!?!?
-- You can't idiot-proof anything, because they're always coming out with better idiots.
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!!
-----
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!
I tested it out, and actually installed the dang thing.. I don't think it will ever cut it, because it lacks a few things that people have come to know and love: Consistency in UI design (it uses its own renderer.. this is not always a bad thing, just if oyu used standard system renderers it would look the same on all the platforms that it supports, ie, on a mac, it would look the same as any other mac (or those that are made to look the same), same on win, same on linux..) Also, it does not integrate with the browser very well.. sure, it is a plugin, but it is basically its own application, it takes over ALL browser functionality. The back and forward buttons of the browser no longer work, thats a BIG minus... and, it is DOG SLOW... The sample content they have is large, a set of HTML pages of the same would be larger than it is, of course, but that download speed is spread out over each page, and not as one huge download. ALSO, the rendering engine is slow, not optimized very much.. Most of this stuff can be overcome, but you need to overcome it fast to even be thought of again.. this project is doomed to failure because it tried to do too much on its own, without using standard things already available.. Anyhow, done with my rant.. "I" won't be using it anytime soon, thats for sure..
Jay
"What's this script do? unzip ; touch ; finger ; mount ; gasp ; yes ; umount ; sleep Hint for the answer: not everyth
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?
Present html clients have existed for several years now, but people still haven't upgraded to the latest and greatest (for whatever reason).
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.
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.
10 PRINT "Nice troll"
20 GOTO 10
sulli
RTFJ.
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
They charge for commercial deployment. On top of that they charge by the 'volume' of curl usage.
Curl was dead before the press release.
Move along folks. Nothing to see here.
-----------------------------
kaaaameeeeeeehaaaaaameeeeeha!
-----------------------------
-----------------------------
kaaaameeeeeeehaaaaaameeeeeha!
-----------------------------