Ben Tilly writes: > I want to get some perspective on language design. Some of > my initial impressions are available at: > > http://pub13.ezboard.com/fiwetheytheoryandpracticeofprogramming.showMessage?topicID=286.topic > > (Hmmm...that essay might not do great things for Perl/Ruby > relations, but I think it raises an interesting point.) > Hi, In your essay, you write: > Programming languages often have some sort of type system. Some > languages (eg JavaScript) attempt to have both untyped operators and > untyped variables. This is a truly horrible idea. Languages which > want a minimal level of sanity _need to type one or the other_. Perl > types its operators, Ruby its variables. (Ruby, like Smalltalk, uses > dynamic runtime typing. If you try to access a method that isn't > there, you blow up. Everything is a method call.)" [my emphasis] What about Lisp? Values are what is typed in Lisp, not variables or operators. You *can* declare for efficiency, but you don't have to. Lisp has a type hierarchy where every object has more than one type. You also write you have a math background. So I'm surprised you don't mention Lisp. > The advantage of Perl's typing operators is that you do not usually > need to cast variables from one type to another. For the kind of text > extraction and processing that Perl often does this can be very > convenient. It is a MYTH that perl is competent for text processing. Does that get your goat, Ben? Well you don't have to take my word for it. Here is what one of the (ex) *perl 5 porters* had to say : "... the lack of a lot of key text-processing ingredients makes Perl solutions for many averagely complicated tasks either extremely slow, or not easier to maintain than solutions in other languages (and in some cases both)... My current conjecture on why people classify Perl as an agile text-handler (in addition to obvious traits of false advertisement) is that most of the problems to handle are more or less trivial ("system-maintenance"-type problems)." (you can check up on: http://www.perl.com/pub/2000/09/ilya.html) The author of the quote is Dr Ilya Zacharevich, who teaches math at Ohio state University. His work on Perl 5 includes operator-overloading, much of the regex-engine, the OS2 port, and the FreezeThaw, Devel::Peek, Math::Pari, and Term::Readline modules. > 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 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). 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). It doesn't *matter* what corporate America chooses, because the organisations that adopt Ruby are going to have an edge. Corporate America doesn't care about language quality, but it does care about the edge. Regards, Peter ;; Syntactic sugar causes cancer of the semicolon. -Alan Perlis