Yes, but at least you get blazing performance in exchange for all the tedious typing. Java is all the pain, none of the gain.
That's because Perl has built-in syntactic sugar for Hashtable and Array manipulation......This hardly makes it the language of choice.
Not unless you value your time.
But when it comes time to write the final implementation, why should I care about syntactic sugar vs readability and documentation
This is the type of programmer Sun is aiming at - mediocore coders who rely on utterly verbose syntax to keep them a good arm's length away from ever having to THINK.
By the way, perldocs offer great inlined documentation, and perl has a convenient comment delimiter ('#') like any other language...what you do with it is up to you.
Perl's lack of named parameters
...is what allows perl to do freaky-friday dynamic programming tricks that Java programmers can't conceive of, because they're stuck in the mentality of making a better C++. Rewriting code on the fly, interpreting and modifying packages based on run-time events...creating and using subroutines at will during execution...do Java programmers even understand the power of these techniques???
But the fact is, you're wrong. Java is *packaged* as bytecode for platform independent distribution, but at runtime, on the vast majority of Java VM's in production use, Java is *NOT* interpreted, but *JUST IN TIME* compiled
Then you need to make the distinction. javac and alternative JIT systems are considered distinct in Java-lore, and you know it.
Like I said, byte-code is merely a convenient compression technique for source code as far as Java is concerned.
This is not correct - bytecode can include compile-time optimizations.
All modern VM's compile to native x86 code during the loading process.
That must be a real drag on a Sun box.
Perl typically executes faster on text processing benchmarks because of the builtin regexp. But you cannot conclude from this, that Perl is faster than Java per se.
Benchmarks are irrelevant - I care about the speed of working code I use everyday, in which case Java gets easily trounced by a number of other languages. If you want benchmarks, try The Practice of Programming by Kernighan and Pike. Its unbiased, unambiguous, and clearly shows what a dog Java is.
Objects in perl for example (if you can call them that)
Oh please, Java has the worst performing class library anywhere, even Javaworld.com lists articles describing this in detail. Besides the absurd object churn and heavy syncrhonization, Java's approach to objects is heavily verbose and basically treats developers like idiots.
Perl isn't even always faster than Java at text processing.
More conjecture. Provide hard data or clam up, cuz common wisdom says your full of it in this regard.
There is no doubt that OO is the biggest bit of snake oil to come out of the programming "gurus" in ages. Think about it folks, OO has been pushed down our throats in one form or another for over twenty years. If it hasn't worked by now, it ain't working.
Work on any sufficiently large real project and you'll find it easier said than done to decompose your project into a whiz-bang hierarchy that actually works...and once it does, look out for the bloat on your object files, and the horror that ensues when you realize you made a mistake somewhere back there in a base class and you have to tear the thing to shreds.
The fact remains that Python/Perl are interpreted, and Java, while being bytecoded, is compiled on the fly to native instructions.
Java code is compiled to bytecode, not native code.
Perl is also compiled to a bytecode format before execution.
But Perl/Python can't beat Java unless you write a program that is almost entirely made up of calls to Perl's native facilities (perlfunc functions, regex, and hashtables).
Which is almost every perl program. Perl has everything and the kitchen sink built in....most userland programs are executing compiled functions...this is why perl typically executes much faster than Java.
Even too this day the core collection classes are oversyncrhonized (and most programmers don't even know what synchronization is)...the GUI stuff is still shoddy...no parametric polymorphism (STILL)...WORA (write-once-run-anywhere) is a complete joke...the list goes on.
The amusing thing about Java is how broken the language and implementation are to this day. Java2 addresses some issues, but Java is at least two years or more away from being as useful for big and small problems as its competition.
If Sun wasn't pouring millions of dollars into hyping Java, it wouldn't even be an issue - Java would have vanished long ago. Only Sun's PR budget keeps it alive now...and let me add that even this is changing - Java is falling off the radar of most developers who are sick of waiting it to become a half decent development tool.
I find the number one culprit behind most crappy code is an inability to really understand the problem at hand. Most programmers still rush to code before they know what they are trying to solve. I see this as slightly different that requirements analysis, which focuses more on what the customer wants than the subtle dimensions of the problem itself.
If you can find the computers used in the attack, you may have a hope of finding log files that will lead further up the foodchain. Finding the comprimised systems is not "clueless".
The French? Come on, these are the people that elected a known member of the Vichy Regime to a high political office. If that's not pathetic, I don't know what is.
Don't forget the story of the French fighter pilot doing unsolicited flybys on the Russian SST at an airshow years ago.
The fighter, taking pictures of the plane, came out of the clouds as if from nowhere and forced the Russian pilot to dive in order to avoid collision. A fatal stall resulted. The Russian pilot pointed the plane downward, putting it in a steep dive in order to draw air into the engines, but was unable to succesfully restart the engines. The Russian SST crashed into a group of homes.
Like all major web companies, Yahoo supports a backbone network at their colocation (globalcenter in their case) that is quite capable of thrashing any server with legitimate or malicious traffic.
Typically this isn't the case - the traffic flowing through the network is about what the servers can handle.
Think of it this way - if you try to drink from a firehose, you're fine when the water is trickling out. When the hose cranks up, you're knocked on the ground no matter how fast you can swallow.
Hence because the network yahoo is sitting on has much higher capacity than yours, they are at potenitally much higher risk...although the caveat here is that to flood a network like globalcenters, you need to distribute the attack (as was done) in order to muster the packet flood required.
Larry - how do you feel about VA's stock generally falling like a Led Zeppelin? Would you ever try skiing on a slope as steeply downward as your stock graph?
But it's also wrong. Extensibility is the "X" of XML; XHTML added nothing to XML's extensibility.
Nor did I claim it did. I simply stated XML is the machanism by which the extensions are provided...and I count contractions as expansions as "extensibility".
I understand your concern - the management of links, and possibly the inclusion of bidirectional links, has been on the minds of many people.
As part of the "suite" of XML standards, XLink is a standard for the management and declaration of more advanced linking features.
I'm not sure if you ever took a look at HyperG, an experimental hypertext system from a few years back, but it had an excellent link management system. Dead links didn't exist by design, and there was an excellent link navigator that showed you the structure of links, not just the page text.
If someone could enlighten me as to the advantages of this protocol it would be helpful
The general goal is to allow people with special domain needs to extend HTML for their own purposes without breaking the standard.
How this will translate into rendering is another issue, although the folks at mozquito are building work-around tools to allow XHTML to be used in current browsers.
What, pray tell, does XHTML 1.0 do? Is it extensions onto HTML?
It is a method for making compliant extensions to traditional HTML.
XHTML presumes that HTML will always need extensions, most of which will focus on small problem domains, so it no longer makes sense to grow HTML itself into a larger monolithic standard.
The primary goal of XHTML is to allow you to extend the core set of tags with your own tag sets so that you may add markup functionality without breaking the standard (as has been done in the past). The "X" comes from the fact that extensions are XML-compliant markup structures.
While it might not be realistic, the W3 likes to envision a future where clients become much more lightweight and flexible by putting all parsing and presentation into standard XML parsers and stylesheet tools. Currently a significant amount of browser bloat is due to the fact that the browsers pretty much render anything you throw at them. Hopefully this will change lest our HTML parsers grow to 20MB.
I once attended a lecture by the brilliant Edward Tufte (who was lecturing on his three great visual design books), and the one point that was hammered in again and again was to "inline" information. Instead of using a silly icon or shape that users must "follow" to find the information they want, put the information right there, inlined.
It appears that is what TOG is discussing here as well. He seems to be pointing out that Aqua places too much emphasis on the usefulness of graphical representations (which look gorgeous but do not relay much information).
That is why I have always found primitive interfaces such as TWM so useful - more often than not, informative text takes the palce of a pretty (but useless) graphic.
By the way, anyone who has the chance to see Edward Tufte speak should do so. For $500 you get all his books and a great lecture that was really worth $500, as hard as that might be to swallow. I can actually say that I learned a great deal about interface design.
There is no way around it - Java is slow and already non-portable.
Yes, Sun is touting it as a server side language for the enterprise, but that doesn't mean you have to believe their PR. Where are all these hidden Java "enterprise" programs???
Poeple have been telling me for a year now that "Java rules enterprise computing - almost all enterprise code is Java now" - well, so far I've seen very little and I've looked very hard at a number of progressive companies.
Its a myth folks! Do yourself a favor and quit perpetuating it!
There has been a significant amount of research that has demonstrated that OO simply doesn't work as promised. There is a real indication that the future is efficient platforms (linux, Apache, Oracle) with extension languages (perl, python).
C will always be the language of choice for platforms.
Why? Is this for technical or social reasons?
Obviously, tweaked C code will always be smaller and faster. As for your examples, the success of Lisp machines speaks for itself, Squeak is going nowhere, and I've never even heard of the other projects.
Slashdot Mirror
Yes, but at least you get blazing performance in exchange for all the tedious typing. Java is all the pain, none of the gain.
That's because Perl has built-in syntactic sugar for Hashtable and Array manipulation......This hardly makes it the language of choice.
Not unless you value your time.
But when it comes time to write the final implementation, why should I care about syntactic sugar vs readability and documentation
This is the type of programmer Sun is aiming at - mediocore coders who rely on utterly verbose syntax to keep them a good arm's length away from ever having to THINK.
By the way, perldocs offer great inlined documentation, and perl has a convenient comment delimiter ('#') like any other language...what you do with it is up to you.
Perl's lack of named parameters
...is what allows perl to do freaky-friday dynamic programming tricks that Java programmers can't conceive of, because they're stuck in the mentality of making a better C++. Rewriting code on the fly, interpreting and modifying packages based on run-time events...creating and using subroutines at will during execution...do Java programmers even understand the power of these techniques???
Sun's crappy licensing has scared off anyone who knows how to read.
Contrary to all the hype and BS, Java is closed and Sun knows it.
Then you need to make the distinction. javac and alternative JIT systems are considered distinct in Java-lore, and you know it.
Like I said, byte-code is merely a convenient compression technique for source code as far as Java is concerned.
This is not correct - bytecode can include compile-time optimizations.
All modern VM's compile to native x86 code during the loading process.
That must be a real drag on a Sun box.
Perl typically executes faster on text processing benchmarks because of the builtin regexp. But you cannot conclude from this, that Perl is faster than Java per se.
Benchmarks are irrelevant - I care about the speed of working code I use everyday, in which case Java gets easily trounced by a number of other languages. If you want benchmarks, try The Practice of Programming by Kernighan and Pike. Its unbiased, unambiguous, and clearly shows what a dog Java is.
Objects in perl for example (if you can call them that)
Oh please, Java has the worst performing class library anywhere, even Javaworld.com lists articles describing this in detail. Besides the absurd object churn and heavy syncrhonization, Java's approach to objects is heavily verbose and basically treats developers like idiots.
Perl isn't even always faster than Java at text processing.
More conjecture. Provide hard data or clam up, cuz common wisdom says your full of it in this regard.
There is no doubt that OO is the biggest bit of snake oil to come out of the programming "gurus" in ages. Think about it folks, OO has been pushed down our throats in one form or another for over twenty years. If it hasn't worked by now, it ain't working.
Work on any sufficiently large real project and you'll find it easier said than done to decompose your project into a whiz-bang hierarchy that actually works...and once it does, look out for the bloat on your object files, and the horror that ensues when you realize you made a mistake somewhere back there in a base class and you have to tear the thing to shreds.
Java code is compiled to bytecode, not native code.
Perl is also compiled to a bytecode format before execution.
But Perl/Python can't beat Java unless you write a program that is almost entirely made up of calls to Perl's native facilities (perlfunc functions, regex, and hashtables).
Which is almost every perl program. Perl has everything and the kitchen sink built in....most userland programs are executing compiled functions...this is why perl typically executes much faster than Java.
The amusing thing about Java is how broken the language and implementation are to this day. Java2 addresses some issues, but Java is at least two years or more away from being as useful for big and small problems as its competition.
If Sun wasn't pouring millions of dollars into hyping Java, it wouldn't even be an issue - Java would have vanished long ago. Only Sun's PR budget keeps it alive now...and let me add that even this is changing - Java is falling off the radar of most developers who are sick of waiting it to become a half decent development tool.
I find the number one culprit behind most crappy code is an inability to really understand the problem at hand. Most programmers still rush to code before they know what they are trying to solve. I see this as slightly different that requirements analysis, which focuses more on what the customer wants than the subtle dimensions of the problem itself.
Get your own clue.
no, you still haven't figured it out - you shoot traitors, you don't elect them.
The French? Come on, these are the people that elected a known member of the Vichy Regime to a high political office. If that's not pathetic, I don't know what is.
The fighter, taking pictures of the plane, came out of the clouds as if from nowhere and forced the Russian pilot to dive in order to avoid collision. A fatal stall resulted. The Russian pilot pointed the plane downward, putting it in a steep dive in order to draw air into the engines, but was unable to succesfully restart the engines. The Russian SST crashed into a group of homes.
Typically this isn't the case - the traffic flowing through the network is about what the servers can handle.
Think of it this way - if you try to drink from a firehose, you're fine when the water is trickling out. When the hose cranks up, you're knocked on the ground no matter how fast you can swallow.
Hence because the network yahoo is sitting on has much higher capacity than yours, they are at potenitally much higher risk...although the caveat here is that to flood a network like globalcenters, you need to distribute the attack (as was done) in order to muster the packet flood required.
Larry - how do you feel about VA's stock generally falling like a Led Zeppelin? Would you ever try skiing on a slope as steeply downward as your stock graph?
Nor did I claim it did. I simply stated XML is the machanism by which the extensions are provided...and I count contractions as expansions as "extensibility".
Reread the post - I said that XHTML allows you to extend the tagset without breaking the standard - I never mentioned older browsers.
Frankly, if you've read any of the abundant documnentation available you'd know what I was talking about.
Once again, XHTML allows you to extend the tagset while still staying within the XHTML standard.
As part of the "suite" of XML standards, XLink is a standard for the management and declaration of more advanced linking features.
I'm not sure if you ever took a look at HyperG, an experimental hypertext system from a few years back, but it had an excellent link management system. Dead links didn't exist by design, and there was an excellent link navigator that showed you the structure of links, not just the page text.
The general goal is to allow people with special domain needs to extend HTML for their own purposes without breaking the standard.
How this will translate into rendering is another issue, although the folks at mozquito are building work-around tools to allow XHTML to be used in current browsers.
It is a method for making compliant extensions to traditional HTML.
XHTML presumes that HTML will always need extensions, most of which will focus on small problem domains, so it no longer makes sense to grow HTML itself into a larger monolithic standard.
While it might not be realistic, the W3 likes to envision a future where clients become much more lightweight and flexible by putting all parsing and presentation into standard XML parsers and stylesheet tools. Currently a significant amount of browser bloat is due to the fact that the browsers pretty much render anything you throw at them. Hopefully this will change lest our HTML parsers grow to 20MB.
It appears that is what TOG is discussing here as well. He seems to be pointing out that Aqua places too much emphasis on the usefulness of graphical representations (which look gorgeous but do not relay much information).
That is why I have always found primitive interfaces such as TWM so useful - more often than not, informative text takes the palce of a pretty (but useless) graphic.
By the way, anyone who has the chance to see Edward Tufte speak should do so. For $500 you get all his books and a great lecture that was really worth $500, as hard as that might be to swallow. I can actually say that I learned a great deal about interface design.
Yes, Sun is touting it as a server side language for the enterprise, but that doesn't mean you have to believe their PR. Where are all these hidden Java "enterprise" programs???
Poeple have been telling me for a year now that "Java rules enterprise computing - almost all enterprise code is Java now" - well, so far I've seen very little and I've looked very hard at a number of progressive companies.
Its a myth folks! Do yourself a favor and quit perpetuating it!
i see this url everywhere now - who is paying you people ?
Scripting languages tied to efficient platforms (linux, Apache, Oracle) are the future.
There has been a significant amount of research that has demonstrated that OO simply doesn't work as promised. There is a real indication that the future is efficient platforms (linux, Apache, Oracle) with extension languages (perl, python).
Why? Is this for technical or social reasons?
Obviously, tweaked C code will always be smaller and faster. As for your examples, the success of Lisp machines speaks for itself, Squeak is going nowhere, and I've never even heard of the other projects.