Rick Welykochy was once rumoured to have said: > On Mon, 26 Jan 2004, Crossfire wrote: > > > > Compared to Perl, Java is an insecure platform that does *not* reach > > > its goal of write once run anywhere. Perl can do this admirably. And > > > securely. > > > > *cackle* > > > > You think Perl is a Java competitor? > > > > I haven't laughed quite so hard in a while. > > Competitor? Maybe in the eyes of the programmer. I never implied > they are competing in the marketplace.
I never said the marketplace. > > Why is this an issue? > > As I stated: one of the mos popular O-O patterns is using the constructor > to allocate resources and the destructor to return resources. That can be > done in any O-O language I can think of, except Java. <flame> Haven't you heard of rhetoric? :/ </flame> >> This is one of the reason swhy Java doesn't have explicit deconstructors. >> Its to prevent you from doing something stupid with object referneces. > > Java does have destructors. The programmer can create them and have them > called automatically when the object is GC'd. Sorry, I meant destructors. > There is a really simple fix for this problem: > > Java *should* be calling the object's destructor when the object goes out > of scope. Then who cares when its memory is GC'd? The return of the objects > (now uninitialised) memory to the free pool can be done later: Ah, but objects have global scope! References have limited scope... So you're proposing putting a reference count GC system into Java? Please, the source is there, go do it. You might even have a few people thank you afterwards. Sun chose not to use reference count. Again, this doesn't fix the actual problem, it just makes it seem like you have better control over it. It doesn't actually give you a direct method for destroying an object since a forgotten external reference to the object in question will prevent it from being GC'd. >> Perl's system is Ref Counting, which may work most of the time, but allows >> you to leak memory if you create reference rings and lose the entry >> reference to that ring. That's not exactly ideal either. > > It is quite fine. I have worked on large ecommerce systems built from the > ground up in Perl. And yes, we inadvertantly had two (count 'em: two) cases > of circular references. We wrote a tool to find memory leaks, discovered the > circs and broke them. A very small price to pay for a far more powerful > language. So, I've made Ref Counting work *all the time*. But you had to go to that much effort to find them - a Java programmer need not worry because the GC system doesn't suffer from this problem. > Have you actually ever tried to do sophisticated array / list / assoc.array > / string processing in Java? I think not. e.g. we found that what we could > do in a couple lines of perl takes literally 50-100 lines in Java. A couple > lines of code is far far easier to debug and peer review than hundred :) > Have you tried to perform biometric data processing (gene analysis) and that > kind of thing in Java? O'Reilly has published a book on how and why Perl > is great at doing so. Perl is a very elegant language. Perl6 even more so: > it will support all the best O-O and functional stuff I've been waiting > for (drool). And I'll rapidly be deploying it in the workplace once it is > stable. Actually, I have - you assume too much about me Rick. Java's strength is as a Rigid langauge, not as a flexible one - typically, a rigid language is less terse than a flexible one, but this pays off in the long run from the reduced amount of effort in auditing and debugging. Because its harder to do something stupid, and the compiler can often catch such attempts much earlier, it makes life easier. Have you ever tried to track down single character typos in perl hashes when you've typo'd the key? (Yes, I was referring to Hash::Util previously when I mentioned about 5.8.x implementing some features to make this less problematic). Have you tried to verify long chains of dereferencing in perl only to miss small typos, or errors in the order in which names are accessed? The java compiler traps this sort of stuff long before the code can possibly go into deployment. Overflow in numbers? Java throws a trappable exception where Perl silently hides the error. Sure, Java sucks for some things, but its design is flexible enough to deal with most things, without letting you shoot yourself horribly in the foot, at the expense of having to write more code. > Java is a commodity programming language, less powerful than C++ and suited > for basic business programming, and nothing much more exciting than that. I > do computing because it is interesting, ever changing and rewarding. I have > met others who do it as a rather boring 9-5 job ... and they never seem to > question the language, platform, IDE or OS on which they work ... they just > get the job done. And they are rather bemused that people like myself even > question things like that. Fine for them. They can have Java. > I'll dip into the more challenging and interesting aspects of the new > languages. See previous point. Again, you're deluded if you think that a langauge like Perl is suitable for large scale systems. Anything larger than a few thousand lines needs a rigid language to help keep it maintainable, unless you happen to have a team of nothing but brilliant, perfect programmers. I'm also sorry that you belive I'm promoting Java as The Solution, because I'm not - I'm pointing out that its not all bad. > I suppose if I was speaking purely theoretically, mentally wanking without > any experience, you could punch holes in my arguments. As I have used Perl > for over five years in the enterprise, and helped my clients earn huge > revenues on perl-based Linux systems, any arguments you have promoting > Java over Perl are spurious to me. It'll be a cold day in hell before this > propeller-head touches Java ever again. And I'm feel fortunate I'm able to > make the choice. :) I've been using Perl for coming up to 5 years now too - Don't think for a second that because I'm defending Java, that I don't have experience with what I'm combatting against - in fact, I feel you have no right to slam a language until you've seriously used it for larger scale projects. > Back to the original thread: no, it is not more secure to allow code to > run on the client side. The server will always be more secure from the > persepctive of the web browser. You obiviously didn't consider my previous assertation. A java client is perfectly fine in terms of security if the implementation is correct. (ie: the server doesn't trust it, in fact -if the server trusts it, you have a problem already since you've just compromised your security model). As I was trying to say, the Java client gives you the security that you know what its behaviour will be in the norm - Java behaviour is well defined. Browser behaviour is not. How do you know that a browser will not cache all the financial details your customers just reviewed? At least with Java you know that if the VM is implemented correctly, your java client won't be storing any of that data, and it will not be cachable by the browser, and hence will be discarded. If client/server computing is a problem for you, stay away from internet programming since you obviously don't understand that all existing services are merely client/server arrangements - including the web itself. Sorry if I sound harsh, but I'm kinda sick of people who slam Rigid langauges without ever seriously considering why they're a good thing in the longer term, and why you should be using them over flexible languages for large scale projects. C. -- --==============================================-- Crossfire | This email was brought to you [EMAIL PROTECTED] | on 100% Recycled Electrons --==============================================-- -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
