This will be my last post in this thread. When things get heated there comes a point when or both people have said all that they really had to say. With this post I will try reach that point. Feel free to respond. BTW I ask that everyone read Mark Dominus' rant at http://www.perl.com/pub/2000/12/advocacy.html. It is not particularly Perl specific, he may be complaining about Perl advocacy, but the message applies to most languages. Peter Wood <peter.wood / worldonline.dk> wrote: >On Thu, Dec 14, 2000 at 08:24:44AM +0900, Ben Tilly wrote: > > > Mathematicians don't learn Lisp. They learn things like > > Lesbegue integration. > > > >Fortunately some of them do: ^^^^ It is not part of the standard curriculum, and it is no surprise that prior to coming to programming I knew nothing about Lisp other than the name. Mathematical training for me did not include, and for most does not include, Lisp. >http://www.umcs.maine.edu/~chaitin/lisp.html > >Here's a quote from one of Chaitin's papers: I read that a while ago, thanks. >"But let me start telling you why I think LISP should be loved by >mathematicians. I think it's the only computer programming language >that is mathematically respectable, because it's the only one that I >can prove theorems about!" And then he has to admit that he isn't really talking about Lisp, but only a certain dialect of it that he invented for the purpose. BTW note the "should be". He knows it isn't loved by most mathematicians because most don't actually know it. [...] > > Perl is excellent at data munging. If you know what you are > > doing it is also excellent at parsing and producing structured > > data. It took me less than an hour to find that incrementally > > appending to a string n times in Ruby takes time O(n*n). It > > takes time O(n) in Perl. > > > >Only with *relatively trivial* problems. Did you read the Zacharevich >interview? For some definition of trivial. Yes, I read the whole interview when it came out. I don't happen to agree with him. If, as he does, you think of regular expressions as how Perl processes text, then he is right. For proof you only need grab Mastering Regular Expressions (by Friedl) and look at the huge RE at the end. And then read the whole book to understand the exponential slowdowns that you can encounter so easily by accident. But it works much, much better if you treat the RE engine as a tokenizer... > > Performance on string processing is not something which Ruby > > fans should try to wave as an advantage. (But this problem is > > not hard to solve. I already outlined a sufficient solution.) > >I would not use Ruby for *real* text processing. But then I wouldn't >use Perl either. For system-maintenance type problems, Ruby is better >than Perl, because it is more readable, has a faster development time, >and is more fun. What is real text processing? Natural language recognition? Perl is not a good fit. Data cleaning and loading? Perl is widely used and does very well. True story. I have a friend who I helped speed a Perl program up for a while ago. He was processing 40 GB of data at a shot. He wound up bound on disk IO. BTW I am not a sysadmin. As for readability, development time, and fun, nothing beats having a good wheel already built for you. That happens more often for Perl than any other scripting language today. It is not a permanent advantage, but there are real benefits in using a language which has other people doing the same stuff you want to. (OTOH if you always choose languages based on popularity, you will get to experience some real grief.) [...] > > I am very familiar with what Ilya has done. ... > > > > > ... But the APIs that he produces often are grotesque, and his code > > is often virtually impossible for anyone else to understand or > > review... > >Perhaps because he is using a write-only language. It is clear to me that you have not read the flame wars in question. With a recent version of Perl look in 'perldoc perlre' for documentation on how you are supposed to use (?> ... ). Yes, it can fix exponential failures and make them linear. But you need to know an awful lot to know that the feature exists, let alone know when it would be helpful. This is a random and not particularly bad example. (The bad examples were the ones that caused the flame wars. He was criticized for producing extensions that were only useful for write-only code.) Treat the RE engine as a way of recognizing tokens and write real code, and you won't get into the problem in the first place. (Then again had Friedl taken that approach from the start he wouldn't have wound up writing a very nice book.) It hasn't been optimized yet, but Parse::RecDescent is an excellent illustration of how you can use this approach. For the record, I suspect that Ruby's support for things like iterators may make it much more convenient than Perl for this kind of approach. The issue that REs are not particularly well suited to complex parsing problems is inherent in REs, and not specific to this or that language. Friedl's RE would be insane to work with in any language, not just Perl. > > > > However this comes with the disadvantage that with every type comes > > > > more syntax. > > > > > >You got it, Ben. Randall "Nice-book-pity-about-the-language" Schwartz > > > > How would you feel if that was directed at you? Please > > stop and think about what it would mean if Randal made the > > decision he made in the early 90's and decided to turn his > > pedagogical talents to promoting a promising young scripting > > langauge. Today he has a reputation. That matters. > >I would laugh if it was directed at me. My comment was meant >humourously and I don't care about the reputation of people who can't >laugh at themselves. What I am *really* sick and tired of is >Perl-People preaching on comp.lang.ruby. For eaxample: I WILL YELL IF >I WANT TO. (remember?). I made a mistake in that case. I apologized. BTW out of curiosity when was the last time you laughed at yourself? (For me it was this morning.) Attempted humor doesn't always translate to writing very well. (For the record I saw Randal get bitten by this the day before yesterday.) > > I guarantee you that having Ruby get glowing recommendations > > from Dave and Andy is a large part of why so many people are > > willing to take a second look at it. I should know, I am one > > of them. > >When somebody guarantees me something, I always wonder why they find >it necessary to make that extra assurance. Are the other things they >say *not* trustworthy. In this case the reason for my statement was a form of emphasis. The right question is therefore to ask why I thought that that point was worth emphasizing. > > >asked what we want to do with Ruby. *I* think Ruby is going to blow > > >Python AND Perl out of the water, though it might take a while re the > > >latter. Why? In Python's case, because its just better (faster, > > >cleaner, sensible licence, no Guido). > >He asked for an *opinion*, and he got it. Actually I got it. Or at least I was the person you were replying to when you gave the opinion. > > And now anyone who likes Guido just got POed as well. > >I like Guido (as well as I can like someone I have never met). I >would have liked Python too, but it has a bad licence, which is >Guido's fault. Was that clear from what you wrote? > > you start by ticking someone off, things usually go downhill > > fast. > >As I recall, one of your first posts to this group was a public >flogging of a regular poster, because he YELLED. That ticked *me* >off. I can tell you are ticked off. Which is why this is my last post in this thread. It is already a flamewar. But note that after I misread that situation, I admitted to having made a mistake, I apologized, and as far as I know the apology was accepted. > > BTW if you make big promises, you had better be prepared to > > meet them. If you say "blow away", a fan of what you promise > > is history will become very dubious. Unless they (already > > biased against) think that it is really ready to blow away the > > competition, they will discount anything you have to say. > > > >I didn't promise anything, Ben. I said I "think" Ruby will blow >Python and Perl out of the water. I didn't say it would happen today. >What I find amusing, is that Pythoneers are saying Perl should beware >of Ruby, and Perl-People are saying Python is going to get the shaft. >For once they *nearly* agree. Sorry, I am imprecise in saying "promise". But you did say "blow away" and the response after that is sadly predictable. > > In Perl's case, because in the > > >real world Perl is used to write spaghetti code, and structured > > >spaghetti code (the Ruby way) is better than unstructured spaghetti > > >code (the Perl way). > > > > Oh really? Amateur attempts at OO design are no fun to work > > with. They quickly get as bad as the worst procedural designs. > > What is worse is that the grandiose mistakes that result have > > performance problems. Implement that in a language which has > > not yet sorted out performance kinks, and you have a recipe for > > disaster. > >You have a serious performance fixation, Ben. Have you tried >switching to a faster machine? There is a difference between caring about good algorithms and caring about optimizing every detail. I care about the scalability of the algorithms used in basic parts of my system. Why? Because I don't like being surprised by learning about issues when I move to a production environment and the system unexpectedly falls over. But a factor of 5 performance difference isn't a problem if it is obvious from the start. You may be amused by this. The same friend who used to toss around 40 GB of data at a shot? For a new project they just spent a million on hardware to handle the terabytes of data that they need to manipulate. Sometimes getting a machine that is faster still is easier said than done! (Yes, his team is still quite pleased with the development time, performance, and overall maintainability of Perl.) > > The worst Perl is the result of people who don't know how to > > program, don't want to learn, but want cool results. > >What, you mean like Ilya's unreadable APIs? No, like the target audience for most of the Perl-CGI books. If Ruby becomes as popular as Perl is today, I guarantee that their work won't be any prettier in Ruby than it is in Perl. >In anticipation of the next SERMON, Last one in this thread. I promise. Sincerely, Ben _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com