SafeWeb doesn't prevent SafeWeb from abusing users. It's sad that you guys even try to compare yourselves to a cryptographically secure protocol like Freedom.
First, SafeWeb is nothing more than a filter proxy. SafeWeb prevents doubleclick from profiling you, but who is to stop SafeWeb from profiling you?
SafeWeb could easily monitor any HTML FORMs you submit, and over time, build up a profile of you, including your name, address, credit card, etc. There is no theoretical security in SafeWeb, it's just another anonymizer.com/proxymate/etc solution.
Whats more, it slaps irritating ads on top. I'd personally pay $5/month for a privacy service just to get rid of the ads.
And because SafeWeb's only way of making money is advertising, it can't provide services for non-web based services like NNTP, IRC, SMTP, FTP, etc.
Finally, SafeWeb's business model is fundamentally at odds with its service. To sell ads, you have to target users. If you can't profile your users, you can't target ads. Non-targeted ads have extremely low CPM rates.
SafeWeb's only recourse is to sell URL-based targeting. In any case, I predict once the funding runs out, it won't last long.
Last but not least, you are not "first free, complete private, way to surf anywhere, anytime" Lucent's ProxyMate deserves that title.
From the standpoint of Win32, MacOS, and Java, there is no difference between rendering to the screen, and rendering to the printer.
You do not have to write extra code to "render to the printer." You build your GUI, and when the time comes to print, you tell the components to print.
Even though it sounds like they are creating a printer canvas that can be rendered to so that the output goes to a printer, it doesn't sound like they are unifying GTK with an imaging model.
Which means if I want to print anything, I have to use special widgets or special API calls.
Sterling writes "OK" soft-scifi cyberpunk books that require no in-depth knowledge of science of mathematics, but whenever he opens his mouth about real issues, he puts his foot in it, even as he proclaims on his fuzzy-headed Viridian site "I am a futurist!, so I know what I talking about." (Futurists have about zero credibility in predicting anything)
Sterling's ideas about the stock market show he lacks even *basic* ECON 101 knowledge. For starters, if anyone had a super-giga computer that could predict the stock market, other super-giga computers would have to take the predictions of the every other giga-computer into account.
Giga-computers can no more predict the combined result of all other traders using giga-computers than a computer can predict whether or not, in general, an algorithm will halt. And this ignores the other confounding issues, like human fallibility, greed, random events, and impect information.
For an analysis of the real world, stay away from Sterling. Peter Huber has made a much better analogy of market volatility based on the laws of physics.
Volatility and the Laws of Physics Quoting Huber: Financial instability isn't going to abate, it's going to get worse--for companies, industries and nations. That conclusion, I modestly submit, derives from the laws of physics. Nonetheless, the diversified investor who can stomach financial turbulence will prosper as never before.
Fact number one: liquidity. The wired PC and the Web behind it have made it very easy and cheap to move wealth around. Interfaces between investors and global markets have been reduced to clicks on a screen. Brokerage fees have fallen 90% recently, and they're going to fall 90% more. To put it in terms of physics, the viscosity is being removed from the financial system. Yesterday's financial molasses now flows like water.
Fact number two: momentum. More wealth is moving ever faster through the global financial pipeline. This is partly because many political and regulatory impediments have been eliminated, and partly because--recent troubles notwithstanding--there is more wealth to move.
As viscosity falls and momentum rises, fluid flows make a transition from stable to unstable. Water in your kitchen faucet transitions from laminar to turbulent when you twist the tap all the way open. Same with all fluids that move through, over or around pipes, ducts, propellers and wings. Waves, oscillations and shocks all multiply when more mass flows faster with less friction. Honey trickles slowly and quietly; fast-flowing water and air often babble, moan, whistle and shriek. Circuit breakers and rules that limit program trading are the financial regulators' misguided attempt to put baffles and mufflers back into pipes that have lost all the old kind of friction.
By the way, Huber makes clear arguments that destroy the naive environmentalism (ala Viridians) that most greens subscribe, of course, no green would dare read this: http://www.marshall.org/huberroundtable.htm.
The industrial espionage angle is a *RED HERRING* It's a neat little excuse for why the European economy is falling behind in the digital age. It will do nothing but promote nationalism or continentalism "see, now we finally know why Europe's economy is lagging. It isn't our over-regulated socialist consensus-decision-based markets, it's those damn Americans stealing our contracts through NSA listening posts."
In the 80s, when America felt threatened by Japan, there was a similar sort of whining. Americans were complaining about Japanese interns in American companies copying designs and taking them back to Tokyo. Americans made much of the fact that all Japan did was go to Comdex, copy American inventions, and then mass produce them.
Echelon is the new scapegoat to explain the poor French economy. But what is not mentioned is that French Intelligence has been doing this for years.
You don't even need listening posts. Just H1-B VISAs.
The Europeans are basically trying to find some illegitimate/unfair tactic behind the US economy's success. It couldn't possibly be that American venture capital markets are superior, or that American is brain-draining Europe by influencing all the smart/ambitious people comin here to work, or because the US just has a better climate to conduct business.
Oh no... it must be because Microsoft/IBM/Yahoo/Amazon/Boeing/GE/whatever are actually being secretly helped by the NSA.
My suggestion is if you care about your privacy, stop sending private information out in the clear.
You should worry more about the masses of minature hidden $10 webcams exploding on the market, monitoring your every move, and being installed in public bathrooms, so perverts can put you on their web page.
By comparison, your next door neighbor is going to do far more harm to you in the near future.
Come on, what's with this echelon stuff? Have none of you read The CodeBreakers or The Puzzle Palace? Don't you realize this has been going on since the telegraph?
The wrong thing to do is to focus on "Echelon" Look, *ANYONE* can listen in on you, not just the NSA. Use a cell-phone? Use a cordless phone? Your neighbors will soon be able to buy or create scanners to decode digital transmissions. Use the internet? A hacker hacking into an ISP or wherever your mail is located can easily read it. How about cable modems? Opps, anyone can sniff your packets.
If you don't want to install window blinds or curtains on your windows, don't cry when someone uses a telescope to watch you getting undressed.
The only solution to the privacy problem is to use encryption. If your broadcast data in the clear over any medium, you are relying on security through obscurity.
Has anyone noticed how EU centric these articles are? Who's Echelon? Anyone not in mainland Europe apparently. US, Canada, Australia, New Zealand, UK, etc. (the GMO controversy also follows the same sort of dividing line, with the mainland Europeans being the most vocally opposed)
Of course, France, that moral and highly cultured "you don't even know what culture is you Americans", would never engage in something as distasteful as industrial espionage? Would they?
It's patently obvious that the world's spy agencies have been intercepting all the traffic they could, even since World War II and before. Echelon is nothing new, except a "ooh scary" code word.
Well, using Perl to concoct HTML and output HTML is nice and faster to develop in, but I wouldn't argue that it is "cheaper to maintain" or "easier to understand"
Most people are trying to move away from the ugly technique of embedding DB code directly into the presentation view.
Why? Because business logic and data modeling should be separate from presentation layout.
As an examine, I use Java to generate XML, SAX parse evens, or a DOM tree. I then feed this dataset into an XSL or CSS stylesheet that "transforms" it into HTML, WML, PDF, Chinese, Spanish, or any number of output formats.
This XSL or CSS stylesheet can be easily manipulated or edited by non-programmers such as graphic artists.
The converse is the PHP/TCL/Mod_perl/ASP/JSP/embedding technique which is to embed scripts directly into HTML.
Editing this HTML, maintaining scripts, reusuing fragments, etc, becomes a pain. When it comes time to upgrade to XHTML, XUL, WML, or output localized versions, all of a sudden, you have to cut-and-paste code fragments and change the surrounding markup to whatever you need (e.g. WML)
The technique of "streaming" HTML with embedded scripts substituting data (template technique) is quick to develop, and scalable (doesn't waste memory), but it also makes it exceeding hard for non-programmers to modify, makes it hard to reuse presentation code, such as rendering a dataset in multiple markup languages, and generally "locks" you into those templates.
The Model-View (controller) design mattern is superior, but slower to implement and architect. But it pays off well over time in maintainence, reuse, and allowing non-coders to participate.
As a great example of this technique, see Mozilla.
Mozilla has a great XML architecture, using XML for structuring the GUI, CSS for determing their look and feel, JavaScript to control actions, and DTD entities to localize for foreign languages.
You're arguing that a Java programmer would INLINE a for loop to iterate over it, but I would argue that most programmers would provide a subroutine for this idiom.
Neither is really superior. On the other hand, typeless variables cause more confusion the first time a coder looks at them. In perl, I can't just look at a subroutine declaration to determine what it returns. I have to seek out and check all return() statements within the routine to determine the range of types.
The following code
$obj = new MyObject($foo);
$blah = $obj->func($bar);
Provides no clues from context. Whereas
MyObject obj = new MyObject(arg); Record r = obj.func(bar);
makes it clear what 'r' is, and what documentation I should look up.
As for named parameters, in C, C++, Java, Eiffel, and just about every stongly typed language, in addition to Lisp, etc, you can declare the types and names of subroutine variables
public int add(Complex c1, Real r2);
whereas in Perl, this looks like
sub add ($$) {}
With C/C++/Java, the arguments are passed by reference and by copy into the named parameters. With Perl, either peope write code like the following
sub foo ($$) { my $blah = $_[0] * $_[1]; }
which in my opinion, sucks, because looking at the subroutine, you have no idea what the arguments represent. You may as well write a program where every variable name is $x, $x1, $x2, etc. There *are* valid reasons for choosing verbose function and variable names to provide better understandability. You either make the variable names understandable, or you have to write very nice documentation.
To continue on, to name variables, you have to explicitly copy and assign them.
sub foo ($$) { my($interestRate, $principle)=@_; my $interest = $interestRate * $principle; }
The situation gets worse with OO, since you must remember to always pass "this"
sub calc { my($self, $principle}=@_; return $self->{interest}*$principle; }
Finally, Perl encourages broad use of implicit unnamed variables. Like, for instance, $_. Most of the library operates and returns data on these variables by default if unspecified. Convenient, but hard to understand unless you have completely mastered and memorized the function prototypes for all the perlfunc's, otherwise, the functioning of a particular piece of code is unclear. Perl allows either method, my person style is long variable names, argument checking, carp, assertions, and documentation, when I am writing code *for other people's use*
Let's not even mention context-sensitive functions which work differently depending on whether they are used in a scalar or list context. Or, what about all those global $ variables like $;, $>, $, $', $`, $*,... add infinitum (yes, there is the english module now)
I'm not bashing perl, I've been writing Perl since 1991, and I've written some very significant modules and projects using it. I love perl.
But the people bashing verbose languages, strictly-typed languages, etc don't seem to understand the purpose of these languages, or why people want to use them. Hint: It's not because they are "idiots", and it's not purely for performance reasons.
Eiffel's design-by-contract is a perfect example. Eiffel is the language that Java should have been. All the verbosity in Eiffel forces one to do is to *THINK* about what your designing, and declare/document how it works or should work, to both the users of your code library, and to the compiler.
I'm for pluralism. I can't stand the "Linux only!" or "Perl only" crowd. You use what works, and everything has its place.
Even though I primarily do web programming, salary surves contradict you. Leaving aside options, the highest salaries are not among web programmers. Y2K consultants even rakened in more. Even admitting stocks and options, there are far more millionaires at Microsoft and Cisco than there are at Yahoo and E-Bay. Overall, most web startups are losers, not winners, with the stocks/options turning out to be worthless, or worth only a few hundred K. TheGlobe, VA Linux, and other mega-IPOs are the exception, not the rule. Web jockeys are starting to become a dime a dozen, doing web-to-database programming isn't exactly rocket science.
You make two separate references to claims for perl vs. java benchmarks. I already gave you one in my previous post - Kernighan and Pike.
The TPOP benchmark was debunked a long time ago. Even TCHRIST didn't like it, even though it showed Perl leading. In fact, the first sloppy implementation showed C++ to be the slowest. (they retracted it) Pike/Kernigan are not exactly "unbiased" anymore than Bjarne S is, or the creator of Eiffel. And we known Tchrist isn't.
The Perl implementation uses a two-dimensional hashtable which requires an O(1) lookup to locate a prefix.
The Java implementation on the other hand, is totally different. It uses an object as the Hashtable key, it doesn't cache the value of the hashCode() function, the hashCode() function and the equals() method are both O(n) worst case. Thus, a large amount of time is spent calculating hashcodes, and because they don't preinitialize the hashtable, those objects get rehashed as the load factor goes up.
Continuing on, they don't use a BufferedInputStream for reading, they use StreamTokenizer on an interactive stream (docs warn against it), and of course, the benchmark was ran on an old VM.
I modified the code to use buffered I/O, and HashMap/ArrayList, plus hashCode() caching, and ran it on IBM JDK1.1.8 (with javax.util.collections) and JDK1.2.2 -classic. The result? My running time on a Celeron 400Mhz on Windows 2000 running JDK1.2.2 was 2.8 seconds total (not 9 seconds), and subtracting the startup time of the VM yields a runtime of 661 milliseconds, only 50% slower than their C-benchmark and 3 times faster than Perl (1.8 secs). If you leave in the startup time, 2.8 still isn't bad (vs 9 seconds they listed). Under JDK1.3RC1, the startup time reduced to yield 2.1 seconds total.
And of course, this is hampered by the inferior implementation they used. Let's switch to a 2-dimensional associative array approach and then do a comparison.
Except they made Java both idiot proof and poorly performing by removing the virtual keyphrase. With Java you pay for a vtable whether you want it or not
Patent nonsense. In the first place, you can use "final" if you want to. Non-virtual functions are idiotic, and cause a nonstop source of headaches in C++ code. See "Effective C++". virtual functions aren't slow, and in most cases, a C++ compiler can replace it with a direct dispatch.
Nevertheless, what makes it even more nonsense is that Java JIT's have enough dynamic type information at runtime to *INLINE* virtual functions. HotSpot does this, by profiling code at runtime, and replacing dispatch sites an inline version. The technique is no more sophisticated than branch prediction in CPUs.
Smalltalk compilers have been doing this for a while too.
But lets face it, that is what Java is all about - making OO idiot-proof for the masses. Unfortunately, you get pissed on in the performance due to Sun's over-reaching assumptions
Yeah, anyone who wants type safety is a idiot. And of course, you're a master programmer right? Programming in an idiot-proof language with automatic resource reclaimation (Perl), because you're not smart enough to write code in a real man's language like C or C++. Haha!
P.S. You're still wrong on performance. But keep writing your "top 5" website code, haha.
So you've never written anything in perl other than some web scripts. Yawn. Care to mention what the application is or which "top five" site it is? How much of those "50K" lines amounts to << EOF, sections.
Rambone, you are either a troll, or 12 years old, or both. Either way, I'm done arguing with you, even if I've written 1000 times more Perl code than you. Please, point me to your code, and I'll put up mine.
When you write something more significant than a 500 line program, and have to work with a team of people who must understand and re-use your code, then let's talk about "valuing your time"
What does terseness of syntax have to do with THINKing? Except maybe in Obsfucated Perl contests, I don't see what value it has. Why do you use Intercal or ALGOLthen?
Perl's lack of named parameters have nothing to do with dynamic programming, and if you weren't 12 years old, you'd realize people were doing "dynamic" programming with Lisp a long time ago. Lisp can dynamically create and bind new subroutines at runtime *with* named parameters. So can Self, Smalltalk, and Objective-C I believe.
Java1.3 can also do this with proxy classes, and with Java1.0-1.2, it can be done with a custom class loader.
I have little need for Perl's autoloader and symbol table tricks, nor self-modifying or dynamically generated code. Such tricks are hacks to prevent refactoring code, and end up being unmaintainable over the long term.
I await you posting a significant Perl module that you have developed using these tricks.
Every JPython function is translated ultimately, to Java bytecode, so if Java's execution speed is slower than "Python", than JPython cannot be faster than Java since it is doing nothing but executing Java code!
JPython's "optimizer", which executes Java code, cannot run faster than Java, period. If I write a for() loop in Java, and one in Python, Python will be slower. The only way if could possibly be faster if it Python "removed" the loop, but Python doesn't do this.
Besides this, Python isn't much "higher level" than Java.
Umm? It did work. Once that blank screen goes up, go to a Unix box somewhere and run "xterm -display yourmachine:2.0" and the xterm will appear in that applet window. You shouldn't run it as an applet anyway, read the README and launch it from the command line as a Java Application. I had KDE with Enlightment to run through it back to my NT box.
I said: 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
You said: Then you need to make the distinction. javac and alternative JIT systems are considered distinct in Java-lore, and you know it.
What's your point? Nothing in the Java language spec says that "Java must be interpreted", Javachips exist, and even Transmeta demonstrated byte-code executing directly on their CPU. TowerJ, TurboJ, VisualCafe, SuperCede, Jove, and even GCJ all demonstrate direct native compilation of Java.
Java bytecode is nothing more then a intermediate compiler stage, just like GCC's RTL, or other intermediate compiler languages.
What matters is the real world implementations, and in the real world, most Java VM's use JIT compilation, and thus, are not executing intepreter loops, but translated bytecode-to-native code.
You can play semantics all you want, but you're still wrong. Perform a random sampling of Java VM's, and run a numerically intensive benchmark. Next, pick a random sampling of Perl implementations and run a similar benchmark. The result will be that Java will execute most low-level operations faster because of the preponderance of JIT's combined with the usage of real structs vs perl-pseudo datastructures. End result: Java is faster, contradicting your claims.
I said: Like I said, byte-code is merely a convenient compression technique for source code as far as Java is concerned.
You said: This is not correct - bytecode can include compile-time optimizations.
There are also *source code optimizers* out there which can perform transformations of C code without even compiling it. Technically, GCC does a lot of optimization at the RTL level, but again, RTL is just an intermediate representation.
But that's moot. In the real world VMs on Windows, Solaris, HP-UX, inside Oracle, on Tru64 UNIX, under OS/2, in AIX, and even on OS/390, Java bytecode is rarely interpreted. JIT's are used by default on all these platforms. You're basically wrong.
I said: All modern VM's compile to native x86 code during the loading process.
You said: That must be a real drag on a Sun box.
Hahah, trying to score debate points by nitpicking? Must be desperate. By the way, on my Solaris x86 box, it does indeed, translate bytecode to x86 code.
You said: 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.
Let's stick to the topic at hand and compare Java to Perl execution speed, which as your original claim. I don't want to get into the C/C++ systems level debate. I view C personally as barely a step above assembly programming.
You claimed Java is a dog compared to Perl. *PROVE IT* Show me the applications your wrote in Perl and Java, otherwise shutup. For all intents and purposes, Java and Perl perform well enough to do most run-of-the-mill tasks like formatting database data on websites, and processing text.
If you want to bring C into it, I'll note that Perl is total DOG compared to C if you want to write a database, search engine, computational fluid dynamics, symbolic math, ray tracing, or video game in it.
So stop your FUD. You don't like writing Java code? Fine. You don't like Sun? Fine. But don't spew outright lies without backing up your claims, otherwise, someone is going to call you on them and embarrass you.
I said: Objects in perl for example (if you can call them that) (I proceeded to explain Perl's idea of a datastructure vs Java's)
You said: (obviously ignorant) 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.
Hahaha. Java's approach to objects is heavily verbose? Compared to what? C? C++? Eiffel? Objective-C? Smalltalk? Java syntax for objects is virtually lifted straight out of C/C++.
Object churn? Perl excels at this. Before Perl5, there wasn't even a way to pass structures, arrays, or hashes by reference. (Except for a hack technique using globals or aliases). Everytime you passed or returned data, you ended up making a copy, except if you only passed scalars and didn't copy them with the local(named args)=@_ technique. Perl5? Still tremendous object churn with arrays and hashtables being created up the wazoo everytime you do anything.
Boy, you sound ignorant. Please list those Javaworld articles, haha. Yeah, they criticized the old Vector/Hashtable, but of course, the newest HashMap/ArrayList perform much better, even better than the JGL, which they lauded, which is the Collections API won the Editor's Choice award.
I said: Perl isn't even always faster than Java at text processing.
You said: More conjecture. Provide hard data or clam up, cuz common wisdom says your full of it in this regard.
Easy. Just go grab the XML modules for Perl5 and compare the speed of the nonvalidating parsers against AElfred or XT on Java. (the Perl validating parsers would fare even worst) Next, go grab some XSLT modules in Perl for transforming XML. Now compare the performance to James Clark's XT, SAXON, EZ/X, Apache's Java XSLT project, or Oracle XSLT. I'm not going to run the benchmark for you, but if you run a dejanews search, you'll see some comparisons. We're talking an order of magnitude difference in some cases.
But enough about me, you're the person who opened his mouth and made the initial claims. *YOU* back them up. The burden of proof is on *YOU*, the person making the claim. If you can't, shutup.
So? The same goes for C and C++. That's because Perl has built-in syntactic sugar for Hashtable and Array manipulation, plus variable interpolation, so one can avoid concatenation and printf() style APIs.
This hardly makes it the language of choice. It makes it great for quickly prototyping something. But when it comes time to write the final implementation, why should I care about syntactic sugar vs readability and documentation. Verbosity has its benefits too.
Perl's lack of named parameters for instance, makes it exceeding difficult to write something like JavaDoc or LXR.
Well, I have developed pure-java versions of SMTP, POP, IMAP, and a Mailstore object DB, and developed them on Linux, but deployed them on NT and Solaris without any code changes or recompiles. WORA seems to work for me. I have also deployed Java GUI document management systems that worked fine on NT and Mac's without changes and without bugs. Sure, there are VM bugs, but WORA by and large works. Especially for Type-4 JDBC drivers which are marvelous.
Synchronization in the collection classes only has a minor impact on the modern JIT's. Why don't *YOU* try writing some simply benchmarks to test synchronization in Java, or go look up the old Dr. Dobb's articles. In both the Symantec JIT and Hotspot VM, a non-contended monitor has neglible impact. Back when I was a HotSpot beta tester, I run benchmarks on the interpreter vs the classic (symantec) JIT, vs HotSpot, and tests showed neglible differences between synchronized and non-sychronized methods. For pure-interpretative, on the old JDK1.1 VM's, sure, sync'ed methods could have a perform hit of up to 50 times slower.
Even so, the Java2 collection classes solve the "problem", and they are available for JDK1.1 as standard extensions, plus you could always use ObjectSpace's JGL.
Parametric Polymorphism is being worked on, because they are trying to it right, not simply copy C++'s bloated mess and poor implementation (cause by a beyond-dumb linker requirement)
Contrary to your FUD however, Java is not falling off the radar. Recent studies in InfoWeek reveal that the number of Java programmers just edged out C++ programmers for the first time.
Yes, they should. For example, if the mod_perl version of "big HTML + Hello World" employs the < Or, in the JDBC benchmark, are they using the thin driver or the OCI driver? Are they using connection pooling? Are they using PreparedStatements?
What are the parameters the VM is using?
Do they using String's or Sring buffers when manipulating text?
When they load text files, which technique are they using?
How you write the code matters alot. For example, in Perl, @array = <FILE> is faster than while(<FILE>) { push(@array, $_); }
I'm not sure I trust their benchmarks as representative either. The only benchmark that seems relevent is the database benchmark
I said: The fact remains that Python/Perl are interpreted, and Java, while being bytecoded, is compiled on the fly to native instructions.
You said: Java code is compiled to bytecode, not native code.
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 to, for instance, Intel 386 code. You're the one who needs to learn how JVM's work. Today's modern JIT's perform inlining, subexpression elimination, peep-hole optimizations, code-motion, and some even perform a limited amount of global analysis. IBM and Sun also produce "mixed-mode" VMs which mix interpretation and compilation. They compile the 10% of code that is executed most, and spend lots of CPU time optimizing that code. The rest, they leave to be interpreted. As a result, the VM's startup quicker, and the core "tight loops" get agressively optimized and sit in the CPU's cache.
Like I said, byte-code is merely a convenient compression technique for source code as far as Java is concerned. Java's byte-code format almost contains enough information to completely decompile to identical source code. In execution, only on the oldest VM's is it strictly interpreted. All modern VM's compile to native x86 code during the loading process.
I said: 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).
You said: 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.
But you're wrong again. 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. Perl is fast at what it does (and I speak as someone who has written over 100,000 lines of Perl code and have been writing it since 1991).
However, Perl is slow on numerical algorithms, graphical algorithms, data structure manipulation (or lack, thereof), and any other function not related to sucking in files, spliting and matching text, and shoveling it into lists and hash tables. I love Perl, but the idea that Java is slower than Perl is hogwash. I wrote a ray-tracer in Java and I know for a fact that it would run 100 times slower in perl from simple experience of writing a FFT/convolution algorithm in Perl. So would a browser, or 3D modeling program.
Objects in perl for example (if you can call them that), rely heavily on using hashtables and lists to "emulate" datastructures that you get in other languages. There is no way that $ref->get_member_variable() is faster in Perl than in Java, for example. The Perl code yields either an array index operation, or a hashtable operation. Both of which are many orders of magnitude slower than object field references in Java which get translated into a 2-instruction assembly code pattern. (yes yes, Perl can slowly manipulate real data-structs via pack/unpack(), but very few.pm modules use this technique)
Perl isn't even always faster than Java at text processing. In the field of parsers, if Perl has to both parse, and build a parse tree representation of a context free grammar, Java based parsers end up winning, even though Perl has regexp built in, probably because datastructure operations are slow.
You will soon get the chance to try yourself. Someone is bound to take Perl's XML parser, create an XSLT implementation, and then we can benchmark Perl directly against Java at parsing and transformations. Next time, learn something about Java VM's before you speak.
Offtopic: If you don't have an X-server, JavaLobby posted a story about a very nice GPL'ed Xserver/Esound/Truetype server written in Java at called WeirdX Even runs as an applet. Very nice if all you have is a Windows/Mac box, or are at a public terminal/cybercafe and need to remote-X from your Linux box.:) Mostly impressive because a single guy wrote an X server from scratch in a short period of time.
Yawn, union socialist view of work is so out of fashion. It values "sweat" labor, seniority, and geriatrics, over merit and organizational skill. (Hint: most executives nowadays are compensated by bonuses and options now, not skyrocketing salaries. Shareholders prefer to link salary to performance)
People totally underestimate the difficulty of organizing humans, and discount communications skills which make all the difference in the world.
Whether you are managing an open-source project, playing starsiege tribes, team fortress or everquest, leading a military invasion, or running a corporation, being able to persuade, organize, and lead people in a direction to accomplish a unified goal is a difficult skill that few people have (I don't have it). Geeks downplay social skills, but in a world of 6 billion humans, the most important skill you can have is dealing with people.
Let's say you run a company. One of your programmers shows an uncanny ability to get other people to meet deadlines whereas before, they weren't. This person also is able to travel around the country, and has good enough social skills to meet with other companies, forge partnerships, and in general, get lots of people in the public to like him/her (think Linus)
Would I promote this person and pay them 10 times the salary of their peers? I sure would. They're more than likely repay it by getting references for customers, increasing the company's profile through partnerships and positive speech, in addition to getting project managers or programmers in the mood to finish on deadline.
And the rest of the employees in the company would benefit to. Technology is only 10% of the business.
Chances are, if you have a cool business idea, about 100 people have the same idea. The difference is, do you have people who are laser focused on getting things done and growing the business. If you don't, your company stalls and never becomes anything.
If you do, than 24 months later, you have a stellar IPO, and 1000% growth.
Managers really get the short end of the stick in popular media. Employees like to imagine them as high-paid lazy do nothings, but if you have ever managed anything, you know that not only is it 100% stress, non-stop meetings, constant worry, travel, etc but whenever anything goes wrong, you take the heat, in addition to being told you are a fat cat. Don't even factor in having to babysit and deal with office politics.
Work is not just "producing widgets", but I can see how, if that is a person's viewpoint, they can devalue management.
Well, try editing their launching scripts and run them all in the same VM. Or try adding -X parameters to alter the default memory. I run about 6 Java servers on my site: SMTP, POP, Tomcat/Servlets, Enterprise Java Beans, stand alone image generating servlet, and an separate RMI server. The machine has 256Megs of ram and is not stressed (it also runs Oracle8 with 100 instances)
Sorry, but this is bullshit. JPython is written in Java and runs the same speed (and on some benchmarks faster) than CPython. How can JPython run Python as fast as CPython, yet Java be *slower* than Python? I don't think so.
Perl's PP-bytecode execution speed is about 100 times slower than a JIT'ed Java App, just try writing a straight numerical app like a Fast Fourier Transform, or a JPEG-decoder in *pure* perl, with no XS modules that escape to C.
If you look at caucho.com, they have proof that Java servlets are faster than mod_perl.
Perhaps you are refering to the GUI widgets being slow, but the GUI widgets are just a module, like Tk/wxWindows and are just an add-on to the VM, not part of the language. Not only that, but there are numerous third-party replacements for the standard Swing/AWT widgets that run very fast.
The fact remains that Python/Perl are interpreted, and Java, while being bytecoded, is compiled on the fly to native instructions.
There are plenty of code libraries out there that demonstrate Java's relative speed vis-a-vis other interpreted languages.
Java's JMF multimedia framework demonstrates realtime MP3 decoding, and MPEG/AVI decoding in pure Java. http://java.sun.com/products/java-media
www.jcraft.com demonstrates an *XSERVER*, yes, an X11 display server, ESound server, and true-type font server written in Java.
At www.komplex.org you can see real-time "megademos" doing 3D transformations, lighting, texture, and bump mapping. With Java2, some of these run fullscreen (640x480) at 20fps.
Java Cryptography libraries demonstrate very fast encoding performance. Try writing a Pure Perl/Python RSA/DES/RC-4 library, and an SSL stack that can perform.
Yes, we know Java isn't as fast as optimized C. 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). Anything that has to process a large amount of data, *and* isn't related to parsing/manipulating text, will run slow.
If you created a native-library hashtable for java, and native library string and regex libs, Java would exceed at text processing too.
You've been on the net since '94? Give me a break. You don't even know what the old days are. Sheesh, you arrived after the Web existed. You never knew the internet in the pre-Web, pre-graphics, pre-PPP "everyone has their own IP" days .
And by the way, Slashdot and Bluesnews *make money* and the owners are Slashdot are easily millionaires now.
Furthermore, the internet is interconnected, and by pissing in the water, your spoil if for everyone. If you try to take down Yahoo, you end up taking down lots of intermediate networks that host your beloved moral, commercial free,hippie sites. However, no one ever accused socialists/anarchists of logical thinking.
Yawn. High end DVD players are a rip-off. You can pay up to $1000 for items like progressive video, meanwhile, I can go out and buy a $79 DVD-ROM and get superior video on a 21" monitor. I have to chuckle at the people buying the high-end DVDs to hook them up to NTSC TV's, and getting such great features such as, gasp, de-interlacing. Wow.
Anyway, the PSX2's DVD-Player is upgradeable, and since the decoding in done in software by the Emotion Engine (not hardware like expensive DVD players), you could easily upgrade it to progressive-out via software later, especially since some PSX2 models will have DigitalTV/HDTV out.
Slashdot Mirror
You know, I really hate blatant sales plugs.
SafeWeb doesn't prevent SafeWeb from abusing users. It's sad that you guys even try to compare yourselves to a cryptographically secure protocol like Freedom.
First, SafeWeb is nothing more than a filter proxy. SafeWeb prevents doubleclick from profiling you, but who is to stop SafeWeb from profiling you?
SafeWeb could easily monitor any HTML FORMs you submit, and over time, build up a profile of you, including your name, address, credit card, etc. There is no theoretical security in SafeWeb, it's just another anonymizer.com/proxymate/etc solution.
Whats more, it slaps irritating ads on top. I'd personally pay $5/month for a privacy service just to get rid of the ads.
And because SafeWeb's only way of making money is advertising, it can't provide services for non-web based services like NNTP, IRC, SMTP, FTP, etc.
Finally, SafeWeb's business model is fundamentally at odds with its service. To sell ads, you have to target users. If you can't profile your users, you can't target ads. Non-targeted ads have extremely low CPM rates.
SafeWeb's only recourse is to sell URL-based targeting. In any case, I predict once the funding runs out, it won't last long.
Last but not least, you are not "first free, complete private, way to surf anywhere, anytime" Lucent's ProxyMate deserves that title.
From the standpoint of Win32, MacOS, and Java, there is no difference between rendering to the screen, and rendering to the printer.
You do not have to write extra code to "render to the printer." You build your GUI, and when
the time comes to print, you tell the components to print.
Even though it sounds like they are creating a printer canvas that can be rendered to so that the output goes to a printer, it doesn't sound like they are unifying GTK with an imaging model.
Which means if I want to print anything, I have
to use special widgets or special API calls.
Sterling writes "OK" soft-scifi cyberpunk books that require no in-depth knowledge of science of mathematics, but whenever he opens his mouth about real issues, he puts his foot in it, even as he proclaims on his fuzzy-headed Viridian site "I am a futurist!, so I know what I talking about." (Futurists have about zero credibility in predicting anything)
Sterling's ideas about the stock market show he lacks even *basic* ECON 101 knowledge. For starters, if anyone had a super-giga computer that could predict the stock market, other super-giga computers would have to take the predictions of the every other giga-computer into account.
Giga-computers can no more predict the combined result of all other traders using giga-computers than a computer can predict whether or not, in general, an algorithm will halt. And this ignores the other confounding issues, like human fallibility, greed, random events, and impect information.
For an analysis of the real world, stay away from Sterling. Peter Huber has made a much better analogy of market volatility based on the laws of physics.
Volatility and the Laws of Physics Quoting Huber: Financial instability isn't going to abate, it's going to get worse--for companies, industries and nations. That conclusion, I modestly submit, derives from the laws of physics. Nonetheless, the diversified investor who can stomach financial turbulence will prosper as never before.
Fact number one: liquidity. The wired PC and the Web behind it have made it very easy and cheap to move wealth around. Interfaces between investors and global markets have been reduced to clicks on a screen. Brokerage fees have fallen 90% recently, and they're going to fall 90% more. To put it in terms of physics, the viscosity is being removed from the financial system. Yesterday's financial molasses now flows like water.
Fact number two: momentum. More wealth is moving ever faster through the global financial pipeline. This is partly because many political and regulatory impediments have been eliminated, and partly because--recent troubles notwithstanding--there is more wealth to move.
As viscosity falls and momentum rises, fluid flows make a transition from stable to unstable. Water in your kitchen faucet transitions from laminar to turbulent when you twist the tap all the way open. Same with all fluids that move through, over or around pipes, ducts, propellers and wings. Waves, oscillations and shocks all multiply when more mass flows faster with less friction. Honey trickles slowly and quietly; fast-flowing water and air often babble, moan, whistle and shriek. Circuit breakers and rules that limit program trading are the financial regulators' misguided attempt to put baffles and mufflers back into pipes that have lost all the old kind of friction.
By the way, Huber makes clear arguments that destroy the naive environmentalism (ala Viridians) that most greens subscribe, of course, no green would dare read this: http://www.marshall.org/huberroundtable .htm.
The industrial espionage angle is a *RED HERRING* It's a neat little excuse for why the European economy is falling behind in the digital age. It will do nothing but promote nationalism or continentalism "see, now we finally know why Europe's economy is lagging. It isn't our over-regulated socialist consensus-decision-based markets, it's those damn Americans stealing our contracts through NSA listening posts."
In the 80s, when America felt threatened by Japan, there was a similar sort of whining. Americans were complaining about Japanese interns in American companies copying designs and taking them back to Tokyo. Americans made much of the fact that all Japan did was go to Comdex, copy American inventions, and then mass produce them.
Echelon is the new scapegoat to explain the poor French economy. But what is not mentioned is that French Intelligence has been doing this for years.
You don't even need listening posts. Just H1-B VISAs.
The Europeans are basically trying to find some illegitimate/unfair tactic behind the US economy's success. It couldn't possibly be that American venture capital markets are superior, or that American is brain-draining Europe by influencing all the smart/ambitious people comin here to work, or because the US just has a better climate to conduct business.
Oh no... it must be because Microsoft/IBM/Yahoo/Amazon/Boeing/GE/whatever are actually being secretly helped by the NSA.
My suggestion is if you care about your privacy, stop sending private information out in the clear.
You should worry more about the masses of minature hidden $10 webcams exploding on the market, monitoring your every move, and being installed in public bathrooms, so perverts can put you on their web page.
By comparison, your next door neighbor is going to do far more harm to you in the near future.
Come on, what's with this echelon stuff? Have none of you read The CodeBreakers or The Puzzle Palace? Don't you realize this has been going on since the telegraph?
The wrong thing to do is to focus on "Echelon" Look, *ANYONE* can listen in on you, not just the NSA. Use a cell-phone? Use a cordless phone? Your neighbors will soon be able to buy or create scanners to decode digital transmissions. Use the internet? A hacker hacking into an ISP or wherever your mail is located can easily read it. How about cable modems? Opps, anyone can sniff your packets.
If you don't want to install window blinds or curtains on your windows, don't cry when someone uses a telescope to watch you getting undressed.
The only solution to the privacy problem is to use encryption. If your broadcast data in the clear over any medium, you are relying on security through obscurity.
Has anyone noticed how EU centric these articles are? Who's Echelon? Anyone not in mainland Europe apparently. US, Canada, Australia, New Zealand, UK, etc. (the GMO controversy also follows the same sort of dividing line, with the mainland Europeans being the most vocally opposed)
Of course, France, that moral and highly cultured "you don't even know what culture is you Americans", would never engage in something as distasteful as industrial espionage? Would they?
It's patently obvious that the world's spy agencies have been intercepting all the traffic they could, even since World War II and before. Echelon is nothing new, except a "ooh scary" code word.
Well, using Perl to concoct HTML and output HTML is nice and faster to develop in, but I wouldn't argue that it is "cheaper to maintain" or "easier to understand"
Most people are trying to move away from the ugly technique of embedding DB code directly into the presentation view.
Why? Because business logic and data modeling should be separate from presentation layout.
As an examine, I use Java to generate XML, SAX parse evens, or a DOM tree. I then feed this dataset into an XSL or CSS stylesheet that "transforms" it into HTML, WML, PDF, Chinese, Spanish, or any number of output formats.
This XSL or CSS stylesheet can be easily manipulated or edited by non-programmers such as graphic artists.
The converse is the PHP/TCL/Mod_perl/ASP/JSP/embedding technique which is to embed scripts directly into HTML.
Editing this HTML, maintaining scripts, reusuing fragments, etc, becomes a pain. When it comes time to upgrade to XHTML, XUL, WML, or output localized versions, all of a sudden, you have to cut-and-paste code fragments and change the surrounding markup to whatever you need (e.g. WML)
The technique of "streaming" HTML with embedded scripts substituting data (template technique) is quick to develop, and scalable (doesn't waste memory), but it also makes it exceeding hard for non-programmers to modify, makes it hard to reuse presentation code, such as rendering a dataset in multiple markup languages, and generally "locks" you into those templates.
The Model-View (controller) design mattern is superior, but slower to implement and architect. But it pays off well over time in maintainence, reuse, and allowing non-coders to participate.
As a great example of this technique, see Mozilla.
Mozilla has a great XML architecture, using XML for structuring the GUI, CSS for determing their look and feel, JavaScript to control actions, and DTD entities to localize for foreign languages.
That's not terseness, that's just proper design.
... add infinitum (yes, there is the english module now)
The same line of code could be written as
sub_array = grep(pattern, array);
in C/C++/Java. Or
sub_array = array.grep(pattern)
You're arguing that a Java programmer would INLINE a for loop to iterate over it, but I would argue that most programmers would provide a subroutine for this idiom.
Neither is really superior. On the other hand, typeless variables cause more confusion the first time a coder looks at them. In perl, I can't just look at a subroutine declaration to determine what it returns. I have to seek out and check all return() statements within the routine to determine the range of types.
The following code
$obj = new MyObject($foo);
$blah = $obj->func($bar);
Provides no clues from context. Whereas
MyObject obj = new MyObject(arg);
Record r = obj.func(bar);
makes it clear what 'r' is, and what documentation I should look up.
As for named parameters, in C, C++, Java, Eiffel, and just about every stongly typed language, in addition to Lisp, etc, you can declare the types and names of subroutine variables
public int add(Complex c1, Real r2);
whereas in Perl, this looks like
sub add ($$) {}
With C/C++/Java, the arguments are passed by reference and by copy into the named parameters. With Perl, either peope write code like the following
sub foo ($$)
{
my $blah = $_[0] * $_[1];
}
which in my opinion, sucks, because looking at the subroutine, you have no idea what the arguments represent. You may as well write a program where every variable name is $x, $x1, $x2, etc. There *are* valid reasons for choosing verbose function and variable names to provide better understandability. You either make the variable names understandable, or you have to write very nice documentation.
To continue on, to name variables, you have to explicitly copy and assign them.
sub foo ($$)
{
my($interestRate, $principle)=@_;
my $interest = $interestRate * $principle;
}
The situation gets worse with OO, since you must remember to always pass "this"
sub calc
{
my($self, $principle}=@_;
return $self->{interest}*$principle;
}
Finally, Perl encourages broad use of implicit unnamed variables. Like, for instance, $_. Most of the library operates and returns data on these variables by default if unspecified. Convenient, but hard to understand unless you have completely mastered and memorized the function prototypes for all the perlfunc's, otherwise, the functioning of a particular piece of code is unclear. Perl allows either method, my person style is long variable names, argument checking, carp, assertions, and documentation, when I am writing code *for other people's use*
Let's not even mention context-sensitive functions which work differently depending on whether they are used in a scalar or list context.
Or, what about all those global $ variables like $;, $>, $, $', $`, $*,
I'm not bashing perl, I've been writing Perl since 1991, and I've written some very significant modules and projects using it. I love perl.
But the people bashing verbose languages, strictly-typed languages, etc don't seem to understand the purpose of these languages, or why people want to use them. Hint: It's not because they are "idiots", and it's not purely for performance reasons.
Eiffel's design-by-contract is a perfect example. Eiffel is the language that Java should have been. All the verbosity in Eiffel forces one to do is to *THINK* about what your designing, and declare/document how it works or should work, to both the users of your code library, and to the compiler.
I'm for pluralism. I can't stand the "Linux only!" or "Perl only" crowd. You use what works, and everything has its place.
Even though I primarily do web programming, salary surves contradict you. Leaving aside options, the highest salaries are not among web programmers. Y2K consultants even rakened in more. Even admitting stocks and options, there are far more millionaires at Microsoft and Cisco than there are at Yahoo and E-Bay. Overall, most web startups are losers, not winners, with the stocks/options turning out to be worthless, or worth only a few hundred K. TheGlobe, VA Linux, and other mega-IPOs are the exception, not the rule. Web jockeys are starting to become a dime a dozen, doing web-to-database programming isn't exactly rocket science.
The TPOP benchmark was debunked a long time ago. Even TCHRIST didn't like it, even though it showed Perl leading. In fact, the first sloppy implementation showed C++ to be the slowest. (they retracted it) Pike/Kernigan are not exactly "unbiased" anymore than Bjarne S is, or the creator of Eiffel. And we known Tchrist isn't.
The Perl implementation uses a two-dimensional hashtable which requires an O(1) lookup to locate a prefix.
The Java implementation on the other hand, is totally different. It uses an object as the Hashtable key, it doesn't cache the value of the hashCode() function, the hashCode() function and the equals() method are both O(n) worst case. Thus, a large amount of time is spent calculating hashcodes, and because they don't preinitialize the hashtable, those objects get rehashed as the load factor goes up.
Continuing on, they don't use a BufferedInputStream for reading, they use StreamTokenizer on an interactive stream (docs warn against it), and of course, the benchmark was ran on an old VM.
I modified the code to use buffered I/O, and HashMap/ArrayList, plus hashCode() caching, and ran it on IBM JDK1.1.8 (with javax.util.collections) and JDK1.2.2 -classic. The result? My running time on a Celeron 400Mhz on Windows 2000 running JDK1.2.2 was 2.8 seconds total (not 9 seconds), and subtracting the startup time of the VM yields a runtime of 661 milliseconds, only 50% slower than their C-benchmark and 3 times faster than Perl (1.8 secs). If you leave in the startup time, 2.8 still isn't bad (vs 9 seconds they listed). Under JDK1.3RC1, the startup time reduced to yield 2.1 seconds total.
And of course, this is hampered by the inferior implementation they used. Let's switch to a 2-dimensional associative array approach and then do a comparison.
Except they made Java both idiot proof and poorly performing by removing the virtual keyphrase. With Java you pay for a vtable whether you want it or not
Patent nonsense. In the first place, you can use "final" if you want to. Non-virtual functions are idiotic, and cause a nonstop source of headaches in C++ code. See "Effective C++". virtual functions aren't slow, and in most cases, a C++ compiler can replace it with a direct dispatch.
Nevertheless, what makes it even more nonsense is that Java JIT's have enough dynamic type information at runtime to *INLINE* virtual functions. HotSpot does this, by profiling code at runtime, and replacing dispatch sites an inline version. The technique is no more sophisticated than branch prediction in CPUs.
Smalltalk compilers have been doing this for a while too.
But lets face it, that is what Java is all about - making OO idiot-proof for the masses. Unfortunately, you get pissed on in the performance due to Sun's over-reaching assumptions
Yeah, anyone who wants type safety is a idiot. And of course, you're a master programmer right? Programming in an idiot-proof language with automatic resource reclaimation (Perl), because you're not smart enough to write code in a real man's language like C or C++. Haha!
P.S. You're still wrong on performance. But keep writing your "top 5" website code, haha.
So you've never written anything in perl other than some web scripts. Yawn. Care to mention what the application is or which "top five" site it is? How much of those "50K" lines amounts to << EOF, sections.
Rambone, you are either a troll, or 12 years old, or both. Either way, I'm done arguing with you, even if I've written 1000 times more Perl code than you. Please, point me to your code, and I'll put up mine.
When you write something more significant than a 500 line program, and have to work with a team of people who must understand and re-use your code, then let's talk about "valuing your time"
What does terseness of syntax have to do with THINKing? Except maybe in Obsfucated Perl contests, I don't see what value it has. Why do you use Intercal or ALGOLthen?
Perl's lack of named parameters have nothing to do with dynamic programming, and if you weren't 12 years old, you'd realize people were doing "dynamic" programming with Lisp a long time ago. Lisp can dynamically create and bind new subroutines at runtime *with* named parameters. So can Self, Smalltalk, and Objective-C I believe.
Java1.3 can also do this with proxy classes, and with Java1.0-1.2, it can be done with a custom class loader.
I have little need for Perl's autoloader and symbol table tricks, nor self-modifying or dynamically generated code. Such tricks are hacks to prevent refactoring code, and end up being unmaintainable over the long term.
I await you posting a significant Perl module that you have developed using these tricks.
Every JPython function is translated ultimately, to Java bytecode, so if Java's execution speed is slower than "Python", than JPython cannot be faster than Java since it is doing nothing but executing Java code!
JPython's "optimizer", which executes Java code, cannot run faster than Java, period. If I write a for() loop in Java, and one in Python, Python will be slower. The only way if could possibly be faster if it Python "removed" the loop, but Python doesn't do this.
Besides this, Python isn't much "higher level" than Java.
Umm? It did work. Once that blank screen goes up, go to a Unix box somewhere and run "xterm -display yourmachine:2.0" and the xterm will appear in that applet window. You shouldn't run it as an applet anyway, read the README and launch it from the command line as a Java Application. I had KDE with Enlightment to run through it back to my NT box.
I said: 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
You said: Then you need to make the distinction. javac and alternative JIT systems are considered distinct in Java-lore, and you know it.
What's your point? Nothing in the Java language spec says that "Java must be interpreted", Javachips exist, and even Transmeta demonstrated byte-code executing directly on their CPU. TowerJ, TurboJ, VisualCafe, SuperCede, Jove, and even GCJ all demonstrate direct native compilation of Java.
Java bytecode is nothing more then a intermediate compiler stage, just like GCC's RTL, or other intermediate compiler languages.
What matters is the real world implementations, and in the real world, most Java VM's use JIT compilation, and thus, are not executing intepreter loops, but translated bytecode-to-native code.
You can play semantics all you want, but you're still wrong. Perform a random sampling of Java VM's, and run a numerically intensive benchmark. Next, pick a random sampling of Perl implementations and run a similar benchmark. The result will be that Java will execute most low-level operations faster because of the preponderance of JIT's combined with the usage of real structs vs perl-pseudo datastructures. End result: Java is faster, contradicting your claims.
I said: Like I said, byte-code is merely a convenient compression technique for source code as far as Java is concerned.
You said: This is not correct - bytecode can include compile-time optimizations.
There are also *source code optimizers* out there which can perform transformations of C code without even compiling it. Technically, GCC does a lot of optimization at the RTL level, but again, RTL is just an intermediate representation.
But that's moot. In the real world VMs on Windows, Solaris, HP-UX, inside Oracle, on Tru64 UNIX, under OS/2, in AIX, and even on OS/390, Java bytecode is rarely interpreted. JIT's are used by default on all these platforms. You're basically wrong.
I said: All modern VM's compile to native x86 code during the loading process.
You said: That must be a real drag on a Sun box.
Hahah, trying to score debate points by nitpicking? Must be desperate. By the way, on my Solaris x86 box, it does indeed, translate bytecode to x86 code.
You said: 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.
Let's stick to the topic at hand and compare Java to Perl execution speed, which as your original claim. I don't want to get into the C/C++ systems level debate. I view C personally as barely a step above assembly programming.
You claimed Java is a dog compared to Perl. *PROVE IT* Show me the applications your wrote in Perl and Java, otherwise shutup. For all intents and purposes, Java and Perl perform well enough to do most run-of-the-mill tasks like formatting database data on websites, and processing text.
If you want to bring C into it, I'll note that Perl is total DOG compared to C if you want to write a database, search engine, computational fluid dynamics, symbolic math, ray tracing, or video game in it.
So stop your FUD. You don't like writing Java code? Fine. You don't like Sun? Fine. But don't spew outright lies without backing up your claims, otherwise, someone is going to call you on them and embarrass you.
I said: Objects in perl for example (if you can call them that) (I proceeded to explain Perl's idea of a datastructure vs Java's)
You said: (obviously ignorant) 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.
Hahaha. Java's approach to objects is heavily verbose? Compared to what? C? C++? Eiffel? Objective-C? Smalltalk? Java syntax for objects is virtually lifted straight out of C/C++.
Object churn? Perl excels at this. Before Perl5, there wasn't even a way to pass structures, arrays, or hashes by reference. (Except for a hack technique using globals or aliases). Everytime you passed or returned data, you ended up making a copy, except if you only passed scalars and didn't copy them with the local(named args)=@_ technique. Perl5? Still tremendous object churn with arrays and hashtables being created up the wazoo everytime you do anything.
Boy, you sound ignorant. Please list those Javaworld articles, haha. Yeah, they criticized the old Vector/Hashtable, but of course, the newest HashMap/ArrayList perform much better, even better than the JGL, which they lauded, which is the Collections API won the Editor's Choice award.
I said: Perl isn't even always faster than Java at text processing.
You said: More conjecture. Provide hard data or clam up, cuz common wisdom says your full of it in this regard.
Easy. Just go grab the XML modules for Perl5 and compare the speed of the nonvalidating parsers against AElfred or XT on Java. (the Perl validating parsers would fare even worst) Next, go grab some XSLT modules in Perl for transforming XML. Now compare the performance to James Clark's XT, SAXON, EZ/X, Apache's Java XSLT project, or Oracle XSLT. I'm not going to run the benchmark for you, but if you run a dejanews search, you'll see some comparisons. We're talking an order of magnitude difference in some cases.
But enough about me, you're the person who opened his mouth and made the initial claims. *YOU* back them up. The burden of proof is on *YOU*, the person making the claim. If you can't, shutup.
So? The same goes for C and C++. That's because Perl has built-in syntactic sugar for Hashtable and Array manipulation, plus variable interpolation, so one can avoid concatenation and printf() style APIs.
This hardly makes it the language of choice. It makes it great for quickly prototyping something. But when it comes time to write the final implementation, why should I care about syntactic sugar vs readability and documentation. Verbosity has its benefits too.
Perl's lack of named parameters for instance, makes it exceeding difficult to write something like JavaDoc or LXR.
Well, I have developed pure-java versions of SMTP, POP, IMAP, and a Mailstore object DB, and developed them on Linux, but deployed them on NT and Solaris without any code changes or recompiles. WORA seems to work for me. I have also deployed Java GUI document management systems that worked fine on NT and Mac's without changes and without bugs. Sure, there are VM bugs, but WORA by and large works. Especially for Type-4 JDBC drivers which are marvelous.
Synchronization in the collection classes only has a minor impact on the modern JIT's. Why don't *YOU* try writing some simply benchmarks to test synchronization in Java, or go look up the old Dr. Dobb's articles. In both the Symantec JIT and Hotspot VM, a non-contended monitor has neglible impact. Back when I was a HotSpot beta tester, I run benchmarks on the interpreter vs the classic (symantec) JIT, vs HotSpot, and tests showed neglible differences between synchronized and non-sychronized methods. For pure-interpretative, on the old JDK1.1 VM's, sure, sync'ed methods could have a perform hit of up to 50 times slower.
Even so, the Java2 collection classes solve the "problem", and they are available for JDK1.1 as standard extensions, plus you could always use ObjectSpace's JGL.
Parametric Polymorphism is being worked on, because they are trying to it right, not simply copy C++'s bloated mess and poor implementation (cause by a beyond-dumb linker requirement)
Contrary to your FUD however, Java is not falling off the radar. Recent studies in InfoWeek reveal that the number of Java programmers just edged out C++ programmers for the first time.
Yes, they should. For example, if the mod_perl version of "big HTML + Hello World" employs the <
Or, in the JDBC benchmark, are they using the thin driver or the OCI driver? Are they using connection pooling? Are they using PreparedStatements?
What are the parameters the VM is using?
Do they using String's or Sring buffers when manipulating text?
When they load text files, which technique are they using?
How you write the code matters alot. For example, in Perl, @array = <FILE> is faster than while(<FILE>) { push(@array, $_); }
I'm not sure I trust their benchmarks as representative either. The only benchmark that seems relevent is the database benchmark
-Ray
You said: Java code is compiled to bytecode, not native code.
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 to, for instance, Intel 386 code. You're the one who needs to learn how JVM's work. Today's modern JIT's perform inlining, subexpression elimination, peep-hole optimizations, code-motion, and some even perform a limited amount of global analysis. IBM and Sun also produce "mixed-mode" VMs which mix interpretation and compilation. They compile the 10% of code that is executed most, and spend lots of CPU time optimizing that code. The rest, they leave to be interpreted. As a result, the VM's startup quicker, and the core "tight loops" get agressively optimized and sit in the CPU's cache.
Like I said, byte-code is merely a convenient compression technique for source code as far as Java is concerned. Java's byte-code format almost contains enough information to completely decompile to identical source code. In execution, only on the oldest VM's is it strictly interpreted. All modern VM's compile to native x86 code during the loading process.
I said: 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).
You said: 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.
But you're wrong again. 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. Perl is fast at what it does (and I speak as someone who has written over 100,000 lines of Perl code and have been writing it since 1991).
However, Perl is slow on numerical algorithms, graphical algorithms, data structure manipulation (or lack, thereof), and any other function not related to sucking in files, spliting and matching text, and shoveling it into lists and hash tables. I love Perl, but the idea that Java is slower than Perl is hogwash. I wrote a ray-tracer in Java and I know for a fact that it would run 100 times slower in perl from simple experience of writing a FFT/convolution algorithm in Perl. So would a browser, or 3D modeling program.
Objects in perl for example (if you can call them that), rely heavily on using hashtables and lists to "emulate" datastructures that you get in other languages. There is no way that $ref->get_member_variable() is faster in Perl than in Java, for example. The Perl code yields either an array index operation, or a hashtable operation. Both of which are many orders of magnitude slower than object field references in Java which get translated into a 2-instruction assembly code pattern. (yes yes, Perl can slowly manipulate real data-structs via pack/unpack(), but very few .pm modules use this technique)
Perl isn't even always faster than Java at text processing. In the field of parsers, if Perl has to both parse, and build a parse tree representation of a context free grammar, Java based parsers end up winning, even though Perl has regexp built in, probably because datastructure operations are slow.
You will soon get the chance to try yourself. Someone is bound to take Perl's XML parser, create an XSLT implementation, and then we can benchmark Perl directly against Java at parsing and transformations. Next time, learn something about Java VM's before you speak.
Let's see how many we get on this story:
Offtopic: If you don't have an X-server, JavaLobby posted a story about a very nice GPL'ed Xserver/Esound/Truetype server written in Java at called WeirdX Even runs as an applet. Very nice if all you have is a Windows/Mac box, or are at a public terminal/cybercafe and need to remote-X from your Linux box. :) Mostly impressive because a single guy wrote an X server from scratch in a short period of time.
Yawn, union socialist view of work is so out of fashion. It values "sweat" labor, seniority, and geriatrics, over merit and organizational skill.
(Hint: most executives nowadays are compensated by bonuses and options now, not skyrocketing salaries. Shareholders prefer to link salary to performance)
People totally underestimate the difficulty of organizing humans, and discount communications skills which make all the difference in the world.
Whether you are managing an open-source project, playing starsiege tribes, team fortress or everquest, leading a military invasion, or running a corporation, being able to persuade, organize, and lead people in a direction to accomplish a unified goal is a difficult skill that few people have (I don't have it). Geeks downplay social skills, but in a world of 6 billion humans, the most important skill you can have is dealing with people.
Let's say you run a company. One of your programmers shows an uncanny ability to get other people to meet deadlines whereas before, they weren't. This person also is able to travel around the country, and has good enough social skills to meet with other companies, forge partnerships, and in general, get lots of people in the public to like him/her (think Linus)
Would I promote this person and pay them 10 times the salary of their peers? I sure would. They're more than likely repay it by getting references for customers, increasing the company's profile through partnerships and positive speech, in addition to getting project managers or programmers in the mood to finish on deadline.
And the rest of the employees in the company would benefit to. Technology is only 10% of the business.
Chances are, if you have a cool business idea, about 100 people have the same idea. The difference is, do you have people who are laser focused on getting things done and growing the business. If you don't, your company stalls and never becomes anything.
If you do, than 24 months later, you have a stellar IPO, and 1000% growth.
Managers really get the short end of the stick in popular media. Employees like to imagine them as high-paid lazy do nothings, but if you have ever managed anything, you know that not only is it 100% stress, non-stop meetings, constant worry, travel, etc but whenever anything goes wrong, you take the heat, in addition to being told you are a fat cat. Don't even factor in having to babysit and deal with office politics.
Work is not just "producing widgets", but I can see how, if that is a person's viewpoint, they can devalue management.
Well, try editing their launching scripts and run them all in the same VM. Or try adding -X parameters to alter the default memory. I run about 6 Java servers on my site: SMTP, POP, Tomcat/Servlets, Enterprise Java Beans, stand alone image generating servlet, and an separate RMI server. The machine has 256Megs of ram and is not stressed (it also runs Oracle8 with 100 instances)
Sorry, but this is bullshit. JPython is written in Java and runs the same speed (and on some benchmarks faster) than CPython. How can JPython run Python as fast as CPython, yet Java be *slower* than Python? I don't think so.
Perl's PP-bytecode execution speed is about 100 times slower than a JIT'ed Java App, just try writing a straight numerical app like a Fast Fourier Transform, or a JPEG-decoder in *pure* perl, with no XS modules that escape to C.
If you look at caucho.com, they have proof that Java servlets are faster than mod_perl.
Perhaps you are refering to the GUI widgets being slow, but the GUI widgets are just a module, like Tk/wxWindows and are just an add-on to the VM, not part of the language. Not only that, but there are numerous third-party replacements for the standard Swing/AWT widgets that run very fast.
The fact remains that Python/Perl are interpreted, and Java, while being bytecoded, is compiled on the fly to native instructions.
There are plenty of code libraries out there that demonstrate Java's relative speed vis-a-vis other interpreted languages.
Java's JMF multimedia framework demonstrates realtime MP3 decoding, and MPEG/AVI decoding in pure Java. http://java.sun.com/products/java-media
www.jcraft.com demonstrates an *XSERVER*, yes, an X11 display server, ESound server, and true-type font server written in Java.
At www.komplex.org you can see real-time "megademos" doing 3D transformations, lighting, texture, and bump mapping. With Java2, some of these run fullscreen (640x480) at 20fps.
Java Cryptography libraries demonstrate very fast encoding performance. Try writing a Pure Perl/Python RSA/DES/RC-4 library, and an SSL stack that can perform.
Yes, we know Java isn't as fast as optimized C. 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). Anything that has to process a large amount of data, *and* isn't related to parsing/manipulating text, will run slow.
If you created a native-library hashtable for java, and native library string and regex libs, Java would exceed at text processing too.
You've been on the net since '94? Give me a break. You don't even know what the old days are. Sheesh, you arrived after the Web existed. You never knew the internet in the pre-Web, pre-graphics, pre-PPP "everyone has their own IP" days
.
And by the way, Slashdot and Bluesnews *make money* and the owners are Slashdot are easily millionaires now.
Furthermore, the internet is interconnected, and by pissing in the water, your spoil if for everyone. If you try to take down Yahoo, you end up taking down lots of intermediate networks that host your beloved moral, commercial free,hippie sites. However, no one ever accused socialists/anarchists of logical thinking.
The legalese is also pretty clear on most EULA's, like AOL's. This doesn't stop suits from being filed.
Yawn. High end DVD players are a rip-off. You can pay up to $1000 for items like progressive video, meanwhile, I can go out and buy a $79 DVD-ROM and get superior video on a 21" monitor. I have to chuckle at the people buying the high-end DVDs to hook them up to NTSC TV's, and getting such great features such as, gasp, de-interlacing. Wow.
Anyway, the PSX2's DVD-Player is upgradeable, and since the decoding in done in software by the Emotion Engine (not hardware like expensive DVD players), you could easily upgrade it to progressive-out via software later, especially since some PSX2 models will have DigitalTV/HDTV out.