 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2006Java sucks, Perl Rules.
in java to set a variable to a string mutable requires using the string bulder class. but in perl you can just do this $a = "hello"; in java to print that string you have to do this System.out.println(a); but in perl you just do this print $a; java is a staticly typed single pardigram languige thats why it sucks > in java to set a variable to a string mutable requires using the > string bulder class. When will trolls learn how to spell? > java is a staticly typed single pardigram languige thats why it sucks Ditto. Please don't feed the troll. Sinan  SignatureA. Sinan Unur <1usa@llenroc.ude.invalid> (reverse each component and remove .invalid for email address) comp.lang.perl.misc guidelines on the WWW: http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html atbusb...@aol.com wrote: > in java to set a variable to a string mutable requires using the string > bulder class. but in perl you can just do this [quoted text clipped - 9 lines] > > java is a staticly typed single pardigram languige thats why it sucks i'll have to direct my manager to this post :-). You nead a 100 meg IDE because the languige is so bad that you nead code completion and code check because of a crummy languge > You nead a 100 meg IDE because the languige is so bad that you nead > code completion and code check because of a crummy languge you must have java mixed up with VB.net we (can) use dos edit to write code, compile, and run java programs. Anyway, we were all wondering what you thought about java, and by george, you were nice enough to post your opinion. Don't forget to tell the other 99,000+- newsgroups as well, and let us know when you have written an office suite in Perl (like OpenOffice.org has in Java). Have fun in your adventures in perl. > Anyway, we were all wondering what you thought about java, and by george, > you were nice enough to post your opinion. Don't forget to tell the other [quoted text clipped - 3 lines] > adventures > in perl. Er, your point is sound but your example's not. The majority of OpenOffice.org is written in C++. It is possible to write add-ons in Java, Python and one or two other languages though. Dan. SignatureDaniel Dyer http://www.dandyer.co.uk > Er, your point is sound but your example's not. The majority of > OpenOffice.org is written in C++. It is possible to write add-ons in > Java, Python and one or two other languages though. > > Dan. oops - my bad. I thought open office.org was written in Java since it originated at Sun. Yeah I almost tried Jython to check it out. OTOH perl is a great language, I especially like its treatment of Regular expressions and the way you can throw a variable into a double-quoted string. But its not made for the larger projects. >> Er, your point is sound but your example's not. The majority of >> OpenOffice.org is written in C++. It is possible to write add-ons in [quoted text clipped - 4 lines] > oops - my bad. I thought open office.org was written in Java since it > originated at Sun. Open Office has its roots in StarOffice, which was originally developed by the German company Star Division, who were later purchased by Sun. Star Office still exists as a commercial version of Open Office with some added features. Corel produced a Java office suite in the late 90s. It was not a big success. It would be much more feasible now with the huge strides Java has made in terms of performance and GUI toolkits, not to mention the much more capable machines we have these days. Dan. SignatureDaniel Dyer http://www.dandyer.co.uk why dose java have to be so wordy. it is the opisit of lisp and you spend more time typeing than thinking Java is not wordy in the sense of having a large syntax tree with many options. C++ is three times larger (i have not checked this, but read it in article). Java does use english words instead of single character indicators. I like that aspect. It makes java code is readable. I like how often java code is readable and reusable, even if made by less than mediocre programmers. Besides there is little difference in the quantity of key presses someone expert at text editing needs to carry out between the various languages. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > Java is not wordy in the sense of having a large syntax tree with > many options. C++ is three times larger (i have not checked this, > but read it in article). Do you have a cite for this? In my experience, for a given amount of functionality C++ is somewhat less verbose than Java. > Besides there is little difference in the quantity of key presses > someone expert at text editing needs to carry out between the > various languages. This is not the case. C++ and Java are probably of the same order of magnitude in terms of verbosity. This is partly due to the fact that Java was designed to provide a certain level of comfort to attract C++ programmers and partly due to their similar static type systems. Perl and other "scripting" languages can be significantly less verbose. The most expressive language I've used is Common Lisp. This is a factor of both its type system and its macro facility that supports creation of syntactic abstractions. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML) > Do you have a cite for this? In my experience, for a given > amount of functionality C++ is somewhat less verbose than Java. I'm talking about the size of the grammar, the complexity of the language. I did not locate the article I read previously but found some other comparisons of java and C++ grammars. This is an extract: "because development of Java grammar parser is not a simple task (even through Java grammar is simpler and less ambiguous than C++ grammar)" from http://www.ispras.ru/~knizhnik/jlint/ReadMe.htm I'm sure java's grammar grew in size with the addition of enums, generics, etc. I wonder which grammer is larger now and by how much. > This is not the case. C++ and Java are probably of the same > order of magnitude in terms of verbosity. I'm not talking about the resulting source code's verbosity. I'm talking about the amount of keys (raw count) I need to hit in order to get a lot of java code characters on screen. I am comparing this quantity to the amount of keys I need to hit to get, admitadly shorter, perl code. Being a competant user of editors I frequently end up with considerably more characters on screen then number of keys hit. I'm saying that number of characters and verbosity are very minor considerations when it comes to generating code fast. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > > This is not the case. C++ and Java are probably of the same > > order of magnitude in terms of verbosity. [quoted text clipped - 7 lines] > keys hit. I'm saying that number of characters and verbosity are > very minor considerations when it comes to generating code fast. You're making my point for me: Java is more verbose. The fact that you've come up with techniques to avoid some of the negative consequences of that verbosity indicates just how bad the situation is. If you spent the same amount of time adjusting your editing style for Perl, for example, is there any reason why you wouldn't see a similar reduction in the amount of typing required to deliver similar functionality? Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML) > You're making my point for me: Java is more verbose. You were disagreeing with a statement I made, then I replied with a clarification as you appeared not to comprehend the statement. That is when you started off with "This is not the case." it sure seems you were disagreeing with a point I stated. I was making a practical point: the amount of typing for Java is not a burden. > If you spent the same amount of time adjusting your editing style > for Perl, for example, is there any reason why you wouldn't see a > similar reduction in the amount of typing required to deliver similar > functionality? Similar reduction? Percentage wise? Yes, here are two reasons: a) the concepts are about the same b) java has better examples available freely on the internet to incorporate. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > You're making my point for me: Java is more verbose. The fact > that you've come up with techniques to avoid some of the negative > consequences of that verbosity indicates just how bad the situation > is. Perhaps I'm being pedantic, but I think it's very important to make the distinction between the Java programming language, and the Java API. The Java programming language, like most any other language, has a very limited number of keywords and language constructs. The API on the other hand has a lot of packages, libraries, classes and methods. I completely agree that some of the names used in the API are too long. This may enhance readability, but it can hamper it at the same time by making lines too long to fit on screen. Anyway, to compare the verbosity of two languages you have to either compare the language constructs and keywords of each, or compare API libraries that have the same purpose. As an example, it is possible to compare the traditional C/C++ for loop with Java's enhanced for-each loop, and say that in that particular case, Java is shorter. On the other hand one cannot say that creating a window/frame in Java is shorter or longer than in C++, simply because there is no standard C++ library for creating windows. You could compare creating frames in the Java API with creating windows in the Win32 API, in which case Java is a lot shorter. But note that you would not be comparing languages, but APIs. In this type of discussion it is always presumed that Java is the combination of the language and the API. This is completely inaccurate. Theoretically it is very possible to create a completely different API that is completely conform to the Java language specification. And even in practice there are different (although related) Java APIs - the J2SE API, JME, JavaMail, etc. I have never studied Perl, so I don't know how verbose it is. What I do know is that comparing programming languages is, in most cases, nonsensical - and all the more so if the distinction between the language and the libraries is not made. As a final note, it shouldn't matter how verbose a language or an API is (within reason of course). Programming is not typing, no more than playing chess is the physical action of moving a piece. Zero > > You're making my point for me: Java is more verbose. The > > fact that you've come up with techniques to avoid some of the [quoted text clipped - 4 lines] > the distinction between the Java programming language, and the Java > API. [ . . . ] > Anyway, to compare the verbosity of two languages you have to either > compare the language constructs and keywords of each, or compare API > libraries that have the same purpose. While both of these have an impact on verbosity, what really matters is the expressiveness of the language. As an example, last week I had to write some proxies that are drop-in replacements for some Jini services. The proxies had to catch exceptions thrown when using remote objects, determine if the exception indicated a situation that could be recovered from by binding to a different service instance, and either perform the binding or rethrow the exception. In Lisp I would have probably used a macro to create the new language construct I needed, or possibly used :before and :after methods. In C++ I would have used templates, possibly with some pointers to functions. In Java, because of functions not being first class concepts, its lack of a macro facility, and its incredibly limited implementation of generics, I had no alternative but to write a wrapper for each method, by hand. I reduced the amount of typing by judicious use of Emacs, but the amount of code that must be maintained is much greater than it would be with other languages. > As a final note, it shouldn't matter how verbose a language or an > API is (within reason of course). Programming is not typing, no > more than playing chess is the physical action of moving a piece. I agree with this, as far as creating the software in the first place goes. The ability to express concepts clearly and concisely in a language does, however, greatly increase the maintainability of code. Compared to other languages, Java's verbosity makes it more difficult for a programmer to understand the structure and purpose of code. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML) > While both of these have an impact on verbosity, what really > matters is the expressiveness of the language. As an example, last [quoted text clipped - 3 lines] > that could be recovered from by binding to a different service > instance, and either perform the binding or rethrow the exception. > In Java, because of functions not being first class concepts, its > lack of a macro facility, and its incredibly limited implementation of > generics, I had no alternative but to write a wrapper for each > method, by hand. Sounds very much like you could have saved yourself a lot of work... and code... by using java.lang.reflect.Proxy. Reflection looks ugly in Java and abandons the type-safety provided by the default language (which, of course, is also abandoned by all the alternatives you mentioned). Nevertheless, given a large enough task and your desire to accomplish it in a general-purpose way, it sounds like it would apply. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > > While both of these have an impact on verbosity, what really > > matters is the expressiveness of the language. As an example, [quoted text clipped - 17 lines] > task and your desire to accomplish it in a general-purpose way, it > sounds like it would apply. I did consider using reflection, but in practice it wouldn't have resulted in significant code reduction given the variable number of arguments, different return types, and variations in behavior required by each method wrapper. It would also decrease understandability and maintainability -- as you noted, reflection looks pretty ugly. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML) Just jumping in. > You're making my point for me: Java is more verbose. Of course it is. I haven't reaqd the thread to this point, but I'd be shocked if someone disagrees with that statement. > The fact that you've come up with techniques to avoid some of the > negative consequences of that verbosity indicates just how bad the > situation is. Or, of course, that it's not really bad at all. Only if you've already assumed that a verbose language is bad does this prove that the situation is bad. That's called begging the question. > If you spent the same amount of time adjusting your editing style > for Perl, for example, is there any reason why you wouldn't see a > similar reduction in the amount of typing required to deliver similar > functionality? Of course there is. The biggest reason is static typing in Java, which means that decent editing tools can be far more helpful and provide things like auto-completion of method names. Another is that every major popular development environment for Java provides high-level commands to update things throughout large numbers of source files, and those tools don't seem to exist for Perl. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >why dose java have to be so wordy. it is the opisit of lisp and you >spend more time typeing than thinking Because it was originally designed to program set-top boxes and the guys who designed it were primarily interested in the JVM, not the Java language. They were not application programmers. The mindless verbosity of Java does not start piling up until you write a gui with listeners and you have 10 pages of code to display single screen. The solution is not to maintain such code as ASCII text, but as a tree structure where you can open and close various nodes to see detail. much would be done by tick-off boxes rather than code. E.g. select fonts, colours, borders, icons etc for various components. the high level "routine" would be the display itself. You would right click on components to get details about them and their events. see http://mindprod.com/projects/scid.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > in java to set a variable to a string mutable requires using the > string bulder class. but in perl you can just do this > $a = "hello"; $a has a special meaning in sort(), therefore it is poor practice to use is as a generic variable. You may want to pick a different name. jue > atbusb...@aol.com wrote: > > in java to set a variable to a string mutable requires using the [quoted text clipped - 6 lines] > > jue Yeah, that's what $foo was designed for. i did not know that how about $foo > i did not know that how about $foo You did not know _what_? If you had quoted an appropriate context -as has been a proven custom for two decades- then people might have been able to know what you are talking about. jue There are benefits to String being immutable. You can concat String instances with a + making new String instances along the way. As for printing, you can: final static private void print(String msg) { System.out.println(msg); } and then write: // assuming s is a String print(s); Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > java is a staticly typed single pardigram languige thats why it sucks Can someone tell me why we are comparing apples to oranges? If the title of this thread was "Java Sucks, C++ Rules," then I can see having some kind of intelligent debate. Otherwise, silly statements such as: "Java is a statically typed language, therefore it sucks." are completely stupid IMHO. As Hal pointed out, you wouldn't use Perl to write the next version of Star Office, Microsoft Office, or Fred's Office. Perl is simply an excellent tool for extracting information from files using regular expressions. We all know what can be developed using Java. It all boils down to selecting the best language to solve a particular task. So let's send this troll packing, and move on to discussing Java issues. Go away, troll... Mike. --- ACGNJ Java Users Group (http://www.javasig.org/) > Perl is simply an excellent tool for extracting information > from files using regular expressions. We all know what can be > developed using Java. Wow, that has to be one of the stupidest assessments of Perl I've ever read. I would suggest you go back to discussing Java, because it appears you know little else. Matt > Wow, that has to be one of the stupidest assessments of Perl I've ever read. > I would suggest you go back to discussing Java, because it appears you know > little else. Michale's is not the whole picture of perl, missing much of the variety, but stupidest you've ever read? That's harsh; especially since you don't add anything positive. Anyway, I'm bailing on this thread. Good day to all. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > Wow, that has to be one of the stupidest assessments of Perl I've ever read. > I would suggest you go back to discussing Java, because it appears you know > little else. Matt: PERL - Practical Extraction and Report Language This is direct from http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/rgs/pl-intro.html: "Perl is an interpreted language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. It's also a good language for many system management tasks. The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal). It combines (in the author's opinion, anyway) some of the best features of C, sed, awk, and sh, so people familiar with those languages should have little difficulty with it. (Language historians will also note some vestiges of csh, Pascal, and even BASIC-PLUS.) Expression syntax corresponds quite closely to C expression syntax. Unlike most Unix utilities, perl does not arbitrarily limit the size of your data -- if you've got the memory, perl can slurp in your whole file as a single string. Recursion is of unlimited depth. And the hash tables used by associative arrays grow as necessary to prevent degraded performance. Perl uses sophisticated pattern matching techniques to scan large amounts of data very quickly. Although optimized for scanning text, perl can also deal with binary data, and can make dbm files look like associative arrays (where dbm is available). Setuid perl scripts are safer than C programs through a dataflow tracing mechanism which prevents many stupid security holes. If you have a problem that would ordinarily use sed or awk or sh, but it exceeds their capabilities or must run a little faster, and you don't want to write the silly thing in C, then perl may be for you. There are also translators to turn your sed and awk scripts into perl scripts. OK, enough hype." OK, so shoot me for giving an abstract overview of Perl. But I believe that I highlighted the main point about the language, don't you think?. So, I would suggest that you should consider thinking *twice* before criticizing... Mike. --- ACGNJ Java Users Group (http://www.javasig.org/) >>>>> "MR" == Michael Redlich <mike@redlich.net> writes: MR> Matt Garrish wrote: >> Wow, that has to be one of the stupidest assessments of Perl I've >> ever read. I would suggest you go back to discussing Java, because >> it appears you know little else. MR> Matt: MR> PERL - Practical Extraction and Report Language MR> This is direct from MR> http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/rgs/pl-intro.html: MR> OK, so shoot me for giving an abstract overview of Perl. But I believe MR> that I highlighted the main point about the language, don't you think?. no, you didn't. but what do you know about perl? finding poor descriptions on the web isn't knowing perl. BZZZT! try again. MR> So, I would suggest that you should consider thinking *twice* before MR> criticizing... pot, meet kettle. have a good time in java where you belong. you are obviously not mature enough for perl. my lang can outcode your lang! NYAH! NYAH! NYAH!!! this thread has to die already. uri SignatureUri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org > no, you didn't. but what do you know about perl? Micheal, having evidenced some information, as compared to 0 from you, currently appears to know infinitly more than you. Cheers. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ >>>>> "ocofo" == opalpa@gmail com opalinski from opalpaweb <opalpa@gmail.com> writes: >> no, you didn't. but what do you know about perl? ocofo> Micheal, having evidenced some information, as compared to 0 from you, ocofo> currently appears to know infinitly more than you. evidence?! i don't need no steekin' evidence!! perl is used for so much more than text processing. it just happens to be the best text processing lang out there. you are like those kiddies who think perl is only used for cgi since it was the most popular cgi lang for years. that is typical of limited understanding of perl. take a look at cpan sometime. tell me what percentage of those modules are only for text processing. seems to be stuff in every conceivable technical field. i call that solid evidence. but i don't know if i can find the proper glasses for you so you can see it. so stop with the FUD about perl being a text oriented lang. it is such bullshit. uri SignatureUri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org I've been to CPAN many times. I like the variaty -- used MQ Series stuff from CPAN, used various time/date libraries from CPAN, FTP libs, etc. Yes, big variaty, I've stated this multiple times in this thread. > tell me what percentage of those modules are only for text processing. A lot less than the percentage of those modules that are used in programs which in part process text, using regular expressions. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ >>>>> "opalpa@gmail" == opalpa@gmail com opalinski from opalpaweb <opalpa@gmail.com> writes: opalpa@gmail> A lot less than the percentage of those modules that are used in opalpa@gmail> programs which in part process text, using regular expressions. Can't believe I'm getting sucked in to this, but... That's like saying Java is about *multiplication*. "Look how many Java programs perform multiplication! Nearly all of them!" And your point? SignatureRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! >>>>>> "opalpa@gmail" == opalpa@gmail com opalinski from opalpaweb >>>>>> <opalpa@gmail.com> writes: [quoted text clipped - 5 lines] > > Can't believe I'm getting sucked in to this, but... I know. I shouldn't have gotten sucked in by the idiocy of the original comment, but such gross over-simplifications are an anathema to me... : ) Matt > > Can't believe I'm getting sucked in to this, but... > > I know. I shouldn't have gotten sucked in by the idiocy of the original > comment, but such gross over-simplifications are an anathema to me... : ) You got sucked into this because you totally over-reacted to my original post which, by-the-way, was to point out that comparing Java to Perl was like comparing apples to oranges. I'll give everyone a couple of minutes to go back and re-read it... Is everyone done re-reading my original post? OK, good... I tried to make my point by quickly stating the fundamental differences between the two languages. It wasn't supposed to be a dissertation on what Perl can do for developers. I wasn't claiming to be an expert in Perl because I'll be the first to admit that I'm not. If I need some Perl training, Matt, you'll be the first person that I contact. Fair enough? So let's all settle down, and get back to work. Oh yes, I think Uri needs to grow up. If I had to guess, he's probably about 15 years old. I was ready to puke up my dinner with his childish remarks. Later... Mike. --- ACGNJ Java Users Group (http://www.javasig.org/) >>>>> "MR" == Michael Redlich <mike@redlich.net> writes: MR> Oh yes, I think Uri needs to grow up. If I had to guess, he's MR> probably about 15 years old. I was ready to puke up my dinner MR> with his childish remarks. i hope your dinner tasted good in both directions. <SARCASM_ALERT> NYAH NYAH NYAH!!! </SARCASM_ALERT> does that make it clearer? so we have can't understand what perl is and can't comprehend obvious sarcasm. seems to be a trend here. by the way, i am enjoying this. i rarely troll but you guys are making it so easy and fun. how about this one. java and all those fancy IDE tools are for those who need all those crutches. i would like to see one of you code on punch cards (not even a screen editor) and wait 2 hours for your batch job to print out and then analyze the results. the children are the ones who demand the toys and who can't use their brains to code and debug. the fanciest tools can't help bad coders become better coders. so the claim you have better tools is empty. good coders can work in any language. bad coders demand IDEs. <hint: that was a java insult> can't wait to see the response from the java camp. <MORE_SARCASM_ALERT> and i am 16 dammit!! respect my experience!! </MORE_SARCASM_ALERT> uri SignatureUri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org > i hope your dinner tasted good in both directions. I managed to keep it down, thanks... > <SARCASM_ALERT> > NYAH NYAH NYAH!!! > </SARCASM_ALERT> > > does that make it clearer? Yes, it's very clear that you are very immature for a person with 25 years of programming experience and an officer in a small company. Sarcasm or not, your conduct is no-doubt childish and unacceptable. > how about this one. java and all those fancy IDE tools are for those who > need all those crutches. i would like to see one of you code on punch [quoted text clipped - 6 lines] > > can't wait to see the response from the java camp. I never said that Java was better than Perl. If you remember, oh wait, you probably didn't re-read my original post like I suggested earlier. OK, I'll wait a few minutes so that you can finally do that now... Done? OK. So, if you remember, I didn't even *compare* Java to Perl. I actually said that Perl was an *excellent* language. Everyone started to get upset because I underestimated what Perl can do. I just looked out my window, and the sky hasn't fallen yet. And by-the-way, I don't use no stinkin' IDEs. The Java SDK and Ant are all I use. Why don't you come see for yourself at the next ACGNJ Java Users Group meeting on February 14. I see that Stem Systems is in Iselin, NJ. You're not too far from Scotch Plains, NJ where the meetings are held. Send me a note offline to mike@redlich.net, and I will be glad to give you directions and more information about the user group. Would you be interested in making a Perl presentation at one of the other user group meetings that ACGNJ sponsors? The club doesn't have a Perl Users Group. Would you be interested in leading it? Mike. --- ACGNJ Java Users Group (http://www.javasig.org/) >> i hope your dinner tasted good in both directions. > > I managed to keep it down, thanks... Uri has been overtaken by aliens, or my memory is bad. SignatureJohn Small Perl scripts: http://johnbokma.com/perl/ Perl programmer available: http://castleamber.com/ I ploink googlegroups.com :-) In comp.lang.perl.misc Michael Redlich <mike@redlich.net> wrote: >> <SARCASM_ALERT> >> NYAH NYAH NYAH!!! >> </SARCASM_ALERT> >> does that make it clearer? > Yes, it's very clear that you are very immature for a person with 25 > years of programming experience and an officer in a small company. > Sarcasm or not, your conduct is no-doubt childish and unacceptable. Unacceptable to whom? His comment made a good point regarding the childishness of arguing about which programming language is better. Such arguments are really only valid when a particular goal is being considered and even then factors outside purely programming considerations may need to be taken into account. A bit like the old emacs versus vi debate. No right answer, unless you are a sys admin in which case vi is a necessity since it comes as a standard piece of software. > I never said that Java was better than Perl. If you remember, oh wait, > you probably didn't re-read my original post like I suggested earlier. > OK, I'll wait a few minutes so that you can finally do that now... What makes you think that your original post will still be around on everyone's server. > Done? OK. So, if you remember, I didn't even *compare* Java to Perl. > I actually said that Perl was an *excellent* language. Everyone > started to get upset because I underestimated what Perl can do. I just > looked out my window, and the sky hasn't fallen yet. It was on mine, and your words were, "Perl is simply an excellent tool for extracting information from files using regular expressions." Axel Ya perl might be good but I'd like to see you create an applet with it, lmao. I'm not much on java but I do like the fact that you can make applets which are a very powerful tool IMHO. I've not done any programming in perl but coming from a lot of C programming I've jumped right into PHP and from what I can see, PHP blows away PERL as far as server side programming languages go. I think the apples to oranges comparison is appropriate here, PERL and Java are two languages that are so totally different in their intended purpose, functionality and reason for existence that it is senseless to try and compare the two of them. All languages have their strong points and situations that they are best at. Instead of useless comparisons, why not just use a specific language for the programming situation that it is best suited for. I just wrote a little ticker (like a stock ticker) for a website. I used PHP to parse info and write a data file on the server, from some third party HTML files, used javaScript to determine which of two differing applet versions to load in a webpage, used a Java applet (downloaded to the client computer so it would run fast) to read the PHP data file. Three different languages, all doing tasks that they are best suited for, and all functioning to produce a product that the customer likes and couldn't give two bits about what language you used to get the job done!!! I love C! Only 32 keywords to the language, tons of libraries to chose from and very fast. Java on the other hand seems to require tons of reading and FAQs to find out how to get a specific API function to work if you are not familiar with it. And as far as speed goes, ... it sucks the big one!!! But having said that, I can't imagine trying to create an applet in C, lol Garry >>>>>> "MR" == Michael Redlich <mike@redlich.net> writes: > [quoted text clipped - 32 lines] > > uri page x, preface, "Programming Perl, 2nd edition", (dated stuff, yes, part of the point coming): "The hitherto well-kept secret is now out: Perl is no longer just for text processing." You thought Perl was for more than text processing in 1996. The "no longer" implies there was a time before then when you thought it was "just for text processing". Let's compare what percentage of Java programs use regular expressions and what percentage of Perl programs use regular expressions. By the java code I've got available I see less than 1% of Java sources using regular expressions. I'm having a hard time thinking of a grep to identify which perl code uses regular expressions. Let's approach this a little more intuitively: Say you wrote a program to categorize newsgroup posts and had yourself features for each newsgroup post. If for a particular message a "regular expression" feature was present that would be more strongly correlated with a perl newsgroup than a java newsgroup. Same for a "text processing" feature. The point is multipart:a) although you have long accepted Perl to be more than text processing and regular expressions that opinion spreads slowely, b) the label "stupidest assessments of Perl I've ever read" was perhaps the poster dating himself and not knowing that you held a similar opinion prior to 1996. For those who don't know: Mr. Schwartz was one of the authors of "Programming Perl 2nd edition". Useful book. All the best. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ <opalpa@gmail.com> wrote in message news:1138576819.297478.234980@f14g2000cwb.googlegroups.com... > b) the label "stupidest assessments of Perl I've ever read" > was perhaps the poster dating himself and not knowing that you held a > similar opinion prior to 1996. > > For those who don't know: Mr. Schwartz was one of the authors of > "Programming Perl 2nd edition". Useful book. So because you found something that might have been true prior to 1996, that's somehow relevant today? And I should forgive you because you have a decade-old opinion of the language? I give up... Matt > And I should forgive you because you have a > decade-old opinion of the language? This is a non-sequitor. Nothing to apologize for -- my messages are polite and thoughtful. Your messages, on the other hand, contain name-calling, baseless claims of superiority, irrelevant spelling corrections, and rudness. bye Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ opalpa@gmail.com schreef: > irrelevant spelling corrections, and rudness. Rudness is good. If only all people were more like Rud. SignatureAffijn, Ruud (is not Rud) "Gewoon is een tijger." >Let's compare what percentage of Java programs use regular expressions >and what percentage of Perl programs use regular expressions. By the >java code I've got available I see less than 1% of Java sources using >regular expressions. If people in Java don't use regular expressions to, as you say in another post: : In a sys admin context one example is when I extracted timezone : information from a text file where it was stored. where in Perl it's the most natural thing to use, this seems to imply that using regular expressions in Java is just too hard, to be the first choice. Well, perhaps. SignatureBart. >>Let's compare what percentage of Java programs use regular expressions >>and what percentage of Perl programs use regular expressions. By the [quoted text clipped - 10 lines] > that using regular expressions in Java is just too hard, to be the first > choice. It also depends on the background of the programmer. I would use a regex in Java, if that would solve my problem the best. There are plenty of times people use regexp in Perl just because it's the shortest way to write it down. Which might be a good or a bad reason. Ages ago, when I discovered hash tables, I made my own little C lib for hash tables. When I discovered Perl, I immediatly loved the language: hash tables built in. But it didn't keep me from using hash tables in other languages. But it kept me from using hash tables if there was a better option available (i.e. a better reason at that moment, for that problem, taking as much things into account, etc.). SignatureJohn Small Perl scripts: http://johnbokma.com/perl/ Perl programmer available: http://castleamber.com/ I ploink googlegroups.com :-) >Ages ago, when I discovered hash tables, I made my own little C >lib for hash tables. When I discovered Perl, I immediatly loved >the language: hash tables built in. "Hash tables built in" are not such a progress. The progress is: hash tables in a language /with a garbage collector/. Using dynamic datastructures in C requires the programmer to take care of memory management, which makes it much more difficult. >>Ages ago, when I discovered hash tables, I made my own little C >>lib for hash tables. When I discovered Perl, I immediatly loved [quoted text clipped - 4 lines] > dynamic datastructures in C requires the programmer to take > care of memory management, which makes it much more difficult. Ones advantage is anothers disadvantage. In some situations control over memory management is desired. Look at all the nice gc options Java has. I wouldn't call it progress, just something that can be very handy at times and a pita at other. SignatureJohn Small Perl scripts: http://johnbokma.com/perl/ Perl programmer available: http://castleamber.com/ I ploink googlegroups.com :-) Stefan Ram schreef: >> Ages ago, when I discovered hash tables, I made my own little C >> lib for hash tables. When I discovered Perl, I immediatly loved [quoted text clipped - 4 lines] > dynamic datastructures in C requires the programmer to take > care of memory management, which makes it much more difficult. There is no real difference between "built in" and using a good library. Especially so if the language is great with libraries (and glue). Dynamic datastructures are accessed via handles. For bulk operations, it is good that the language allows you to lock the datastructures in memory, to access them directer and faster. But only if you need so, and only for a moment. SignatureAffijn, Ruud "Gewoon is een tijger." Also sprach opalpa@gmail.com opalinski from opalpaweb: > page x, preface, "Programming Perl, 2nd edition", (dated stuff, yes, > part of the point coming): [quoted text clipped - 5 lines] > longer" implies there was a time before then when you thought it was > "just for text processing". There were times when Perl was mostly used and useful for text-processing. These things changed with the release of perl5.000 which happened in late 1994. It took another few years until perl5 was more widely in use than perl4. Had perl5 in fact been perl1, this tight association of text-processing with Perl might never have happened to such an extent. > Let's compare what percentage of Java programs use regular expressions > and what percentage of Perl programs use regular expressions. By the [quoted text clipped - 8 lines] > correlated with a perl newsgroup than a java newsgroup. Same for a > "text processing" feature. As you've said yourself a little later: Things spread slowly. Java didn't have regular expressions as powerful as Perl's until 1.5 whereas Perl had regular expressions right from the beginning. The availability of certain features and the way they are integrated into a language have an educational effect on its user base and influence their way of thinking. Perl programmers are used to be thinking in terms of regular expressions, sometimes even when the problem at hand is not related to text-processing at all: A very infamous Perl hacker devised a technique to use regular expressions for testing if a given number is a prime number. Likewise with Java: Java programmers are used to be thinking in certain terms of object-orientedness simply because that's the way it has been done in their language ever since (and this way differs from the thinking enforced by C++ and Perl because their object-orientedness has had a different flavour altogether). > The point is multipart:a) although you have long accepted Perl to be > more than text processing and regular expressions that opinion spreads > slowely, It's about time that certain things sink into the mindset of a Java programmer: Namely even when a lot of text-processing is involved on the surface of the source code, this does not necessarily mean that the program itself is so obviously text-based. I frequently hear Java in connection with terms such as XML and DOM. This is nothing but text-processing (in which, incidentally, regular expressions could come in extremely handy). Tassilo Signatureuse bigint; $n=71423350343770280161397026330337371139054411854220053437565440; $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200); > As you've said yourself a little later: Things spread slowly. Java > didn't have regular expressions as powerful as Perl's until 1.5 whereas > Perl had regular expressions right from the beginning. It's much older than that. Java 1.4 had regexs. A number of well known, free libraries were available before that. > The availability > of certain features and the way they are integrated into a language have [quoted text clipped - 4 lines] > to use regular expressions for testing if a given number is a prime > number. Using a domain specific technique as a hammer isn't necessarily a good thing. > Likewise with Java: Java programmers are used to be thinking in certain > terms of object-orientedness simply because that's the way it has been > done in their language ever since (and this way differs from the > thinking enforced by C++ and Perl because their object-orientedness has > had a different flavour altogether). OO is not domain specific. > It's about time that certain things sink into the mindset of a Java > programmer: Namely even when a lot of text-processing is involved on the [quoted text clipped - 3 lines] > text-processing (in which, incidentally, regular expressions could come > in extremely handy). Parsing XML with regex is just plain dumb. I've seen Perl programmers attempt it though. Because of the limitations of XML you'll often see embedded mini-languages. In some situations you might want to use regexs for parsing that, but as a general mechanism for parsing languages it makes little sense to let them escape from lexical analysis. Tom Hawtin (Followups set to: comp.lang.perl.misc, comp.lang.java.advocacy) SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >> Wow, that has to be one of the stupidest assessments of Perl I've ever >> read. [quoted text clipped - 3 lines] > > PERL - Practical Extraction and Report Language Perl is not an acronym. http://perldoc.perl.org/perlfaq1.html#What's-the-difference-between-%22perl%22-a nd-%22Perl%22%3f > This is direct from > http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/rgs/pl-intro.html: Ahh, a quick Google for Perl 4 info. That's convincing. > OK, so shoot me for giving an abstract overview of Perl. But I believe > that I highlighted the main point about the language, don't you think?. > > So, I would suggest that you should consider thinking *twice* before > criticizing... The main point of the language? Text extraction and processing with regular expressions is such a tiny component of the language it's laughable that you continue to think you're somehow in the right. There is no text extraction by regular expressions for all the sys admin work you can do with Perl, none for all the database work, XML (unless your robic0, for those who follow clpm), dynamic web generation, bioinformatics, and on and on. As I said, if all you know is Java please stick to it and save us your uninformed and over-arching statements about other languages. Matt Personally having used regular expressions for text extraction in a sys admin context and database work and dynamic web page generation, I assure other folks reading this thread Matt is incorrect in his assertions. In a sys admin context one example is when I extracted timezone information from a text file where it was stored. In a dynamic web page generation context I extracted connections history and sent out html. In a database context I used perl to re-engineer schemas on some very large databases using regular expressions all over. I haven't touched XML with perl and I haven't touched bioinformatics with perl, but so far, Matt, you are 0 for 3. Is your vituperative attitude popular among perl fans? Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ <opalpa@gmail.com> wrote in message news:1138565442.152139.46390@g49g2000cwa.googlegroups.com... > Personally having used regular expressions for text extraction in a sys > admin context and database work and dynamic web page generation, I > assure other folks reading this thread Matt is incorrect in his > assertions. I suspect I've used Perl a lot more and a lot longer than you. You aren't convincing anyone with the ridiculous examples you provided that Perl is all about regular expression parsing. Anyone who actually knows Perl knows who the fool is here. I don't need to keep my own count. Matt > I suspect I've used Perl a lot more and a lot longer than you. Maybe. Ten years here, on and off. > You aren't convincing anyone with the ridiculous examples you > provided Ridiculous? Hardly. I'm pleased with what will be recorded for posterity. > that Perl is all about regular expression parsing. In previous post I stated there is variaty to perl. Processing text, using regular expressions, is common. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ <opalpa@gmail.com> wrote in message news:1138569327.578755.286830@g49g2000cwa.googlegroups.com... >> that Perl is all about regular expression parsing. > > In previous post I stated there is variaty to perl. Processing text, > using regular expressions, is common. Then why are you jumping in here to defend the claim that that is all Perl is? Your examples are ridiculous because they're so limited to you. Did you stop and consider that few admin tasks that can be done in Perl ever need regex processing? That few database applications need regex processing? That few web pages or web tools that can be written in Perl ever need regex processing? As Uri tried to explain to you, it's a lot of FUD. Out of curiosity, though, because I can write regexes in Java, and often process text when I write Java programs, does that make Java simply a text processing language? Who cares what anyone else does with the language; my experience supersedes all. Beginning to see why defending a fool makes you look like a fool? There is no such English word as variaty, by the way. Matt Matt Garrish first wrote: "There is no text extraction by regular expressions for all the sys admin work you can do with Perl.." Matt Garrish later wrote: "few admin tasks that can be done in Perl ever need regex processing?" You're more accurate now. > There is no such English word as variaty, by the way. I admint I'm not prickly about spelling. Glancing over posts today I've spelled that word inconsistantly. I'm a perfectionist about code not about newsgroup spelling. Take care. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ s/Opalinski/fool/ ; there is a great use of regexes in perl. let's see how fast you can code that in java! your conflation of tools used and the purposes of programs is boggling. would using a regex in bioperl to process gene data mean that that work is just plain text processing? or parsing XML? or writing internet protocols? you don't get the difference between a popular and powerful feature of a language and the goals of a particular program. given such a lack of discriminating logic, as i said before please stick to java. it needs more coders like you. just let it go. you will never understand perl or anything beyond your little java applet world. and don't come back with some balderdash about my not knowing other langs and such as i could swat you like a fly in too many langs. and back to the mature part of this useless thread. you ain't a perl hacker and we are glad! NYAH!! NYAHH! NYAHH!! <one day those nyahs will finally be understood by you. i won't hold my breath. now go away before even the java groups start thinking of you as a fool.> uri SignatureUri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org lol. bye. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > s/Opalinski/fool/ ; > > there is a great use of regexes in perl. let's see how fast you can code > that in java! Java does have regexp support that's not that hard to use. I just dropped in, and see that this is just another language war, so I go :-D > just let it go. you will never understand perl or anything beyond your > little java applet world. and don't come back with some balderdash about > my not knowing other langs and such as i could swat you like a fly in > too many langs. or pissing contest for that matter. Altough I guess Uri got hijacked. SignatureJohn Small Perl scripts: http://johnbokma.com/perl/ Perl programmer available: http://castleamber.com/ I ploink googlegroups.com :-) > s/Opalinski/fool/ ; > [quoted text clipped - 22 lines] > > uri So this is how the President and Chief Technical Officer of Stem Systems, Inc. conducts himself on these groups. I shudder at the thought of how he runs the company... Mike. --- ACGNJ Java Users Group (http://www.javasig.org/) >>>>> "MR" == Michael Redlich <mike@redlich.net> writes: MR> So this is how the President and Chief Technical Officer of Stem MR> Systems, Inc. conducts himself on these groups. I shudder at the MR> thought of how he runs the company... i am having fun here. too bad you don't get it. fun is good. uri SignatureUri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org Michael Redlich schreef: > [uri] > So this is how the President and Chief Technical Officer of Stem > Systems, Inc. conducts himself on these groups. I shudder at the > thought of how he runs the company... You are trying to play the man now, so you are trying to lose. Why don't you succeed? SignatureAffijn, Ruud "Gewoon is een tijger." > You are trying to play the man now, so you are trying to lose. Why don't > you succeed? Dr. Ruud: No, I am not trying to play "the man." I don't even want to be "the man." If you want to be "the man," then be my guest. I just feel that there should be some level of professionalism in a medium such as this. If one wishes to act childish and foolish, then I believe the alt.* groups are just the place for that kind of behavior. Call me old-fashioned or even a fuddy-duddy if you wish, but that's how I feel. So, get over it... Mike. --- ACGNJ Java Users Group (http://www.javasig.org/) > I just feel that there should be some level of professionalism in a > medium such as this. It's just Usenet. What made you think that this is a meeting place for professionals? Think of it as a pub, or the square in a village. > If one wishes to act childish and foolish, then I > believe the alt.* groups are just the place for that kind of behavior. You're mistaken. OTOH, I do agree that Uri's post was weird, and have been wondering if it was really Uri or a troll. SignatureJohn Small Perl scripts: http://johnbokma.com/perl/ Perl programmer available: http://castleamber.com/ I ploink googlegroups.com :-) Hi John: > It's just Usenet. What made you think that this is a meeting place for > professionals? Think of it as a pub, or the square in a village. Agreed, but despite the occasional troll and students looking for a code handout, I find that most people come here with legitimate Java issues, concerns, questions, and problems. Some of the regulars that answer these questions seem to be professionals with extensive experience. Maybe I feel this way because I facilitate a Java Users Group of my own. I'm also 44 years old and work for a Fortune 5 company. I guess that I'm used to being in a professional environment. I do like your pub or village square analogy. > > If one wishes to act childish and foolish, then I > > believe the alt.* groups are just the place for that kind of behavior. > > You're mistaken. Well, maybe. I remember visiting some of these alt.* groups about ten years ago, and I remember seeing some outrageous content. Maybe things have changed?? > OTOH, I do agree that Uri's post was weird, and have been wondering if it > was really Uri or a troll. Uri admitted to trolling in one of his last posts to this thread, but this whole thread was seemingly started by a troll... Anyway, I think this whole thing was blown way out of proportion. Sincerely, Mike. --- ACGNJ Java Users Group (http://www.javasig.org/) Michael Redlich: > Dr.Ruud: >> You are trying to play the man now, so you are trying to lose. Why >> don't you succeed? > > No, I am not trying to play "the man." Yes, you were trying to play the man. http://en.wikipedia.org/wiki/Ad_hominem SignatureAffijn, Ruud "Gewoon is een tijger." > Yes, you were trying to play the man. > http://en.wikipedia.org/wiki/Ad_hominem Fair enough, but everyone seems to forget that I didn't start this thread, and all of the Perl folks jumped all over my assessment of Perl. So, me thinks that all of us (including myself) were trying to be the man... I mentioned in a previous post that I didn't claim to be a Perl expert. I'm definitely not, and all of you guys made it very clear that there's more to Perl than just regular expressions. Mea culpa, and consider my wrist slapped. My 2nd edition of O'Reilly's "Learning Perl" book is dated July 1997, so obviously things have changed dramatically since then. I believe that Perl 5 had object-oriented programming support, yes? And I also never said one language was better than the other. My main point was that Java shouldn't be compared to Perl because they are different (again, the apples to oranges comparison). To me, a programming language should be chosen for its attributes in how it is a better tool for developing an application. My offer still stands to Uri Guttman to visit our next Java Users Group meeting on 2/14 (or any upcoming meeting) since his company is located near the place where we hold our meetings. The organization that sponsors all of the user groups use a Perl Users Group as well. Anywho, I think it's time to put all this mess behind us, and move forward, don't you think??? Mike. --- ACGNJ Java Users Group (http://www.javasig.org/) > I mentioned in a previous post that I didn't claim to be a Perl expert. > I'm definitely not, and all of you guys made it very clear that [quoted text clipped - 3 lines] > dramatically since then. I believe that Perl 5 had object-oriented > programming support, yes? Some people would say that "Learning Perl" aka The Llama aka Schwartz and Phoenix is a big part of the problem Perl has. Not only doesn't it cover objects, it skips references. You can think of these as Perl's equivalent of pointers. Without them you can't construct the equivalent of C-structs, or write a reasonable function that takes two arrays as parameters, let alone do something as funky and Pythonesque as returning two arrays. Try to imagine a C book that did cover pointers and structs - the Llama book is THAT silly. And unfair to readers, who aren't warned that such a fundamental topic has been neglected. This means that anyone who learns Perl from the one of the mostly highly hyped and community supported Perl books will conclude, quite reasonably, that Perl is more a life support system for its regexp system than a language. If he then utters this belief, based on carefuly reading the book the Perl community told him he *should* read, he will then be publicly gang-stomped for his ignorance. By comparison, postponing discussion of objects as an advanced topic is quite uncontroversial. Oh, and Perl 5 (which introduced references) shipped in 1994. And, yes, I expect to get flamed. >>>>> "umptious" == umptious <umptious@gmail.com> writes: umptious> Some people would say that "Learning Perl" aka The Llama aka umptious> Schwartz and Phoenix is a big part of the problem Perl has. Not only umptious> doesn't it cover objects, it skips references. You can think of umptious> these as Perl's equivalent of pointers. Without them you can't umptious> construct the equivalent of C-structs, or write a reasonable umptious> function that takes two arrays as parameters, let alone do something umptious> as funky and Pythonesque as returning two arrays. Try to imagine a C umptious> book that did cover pointers and structs - the Llama book is THAT umptious> silly. And unfair to readers, who aren't warned that such a umptious> fundamental topic has been neglected. Have you seen the third or fourth edition of Learning Perl? Have you read the Alpaca book (formerly Learning Perl Objects References and Modules, soon Intermediate Perl, because we hated the title as much as you did)? Have you designed a course curriculum before? Are you aware of the time constraints of the class that goes with the llama book and alpaca book? Are you aware of the huge wealth of programs that can (and are) written *without* introducing references or objects except in passing? Our students are happy. They pay our bills. In some ways, the books are merely a side-effect of how happy we've kept our clients, because there's no money in books, ever. (If anything, it's a net loss in income, compared to what we could have put into more trainings or more consulting.) Yes, it would have been nice for you *personally* to have a tutorial book that covered what *you* wanted out of Perl. But that's not the way the mass-market works. We write what works for our clients, and what sells in the marketplace. You're not alone, but there aren't enough of you to give us bread on the table. References and objects *are* advanced topics, and that's why they're in the second book, not the first. Perl *is* useful without them. print "Just another Perl hacker,"; # and someone who has trained far more people than you ever will SignatureRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! > print "Just another Perl hacker,"; # and someone who has trained far more people than you ever will Randal L. Schwartz is also "Just another Convicted Felon,"; # convicted of knowingly accessing and using a computer and computer network for the purpose of committing theft >> print "Just another Perl hacker,"; # and someone who has trained far more people than you ever will > > Randal L. Schwartz is also "Just another Convicted Felon,"; # convicted > of knowingly accessing and using a computer and computer network for > the purpose of committing theft That's a rather... limited view of the situation... More informative data can be found at http://www.lightlink.com/spacenka/fors/ dha SignatureDavid H. Adler - <dha@panix.com> - http://www.panix.com/~dha/ I believe myself to be the daughter of a one-eyed space robot named Malcolm. -Fallon Young, http://www.bobbins.org/d/20000915.html |
Enable EMail Alerts
Start New Thread
Reply to this Message