On Mon, 27 Apr 2009, bearophile wrote: > Walter Bright: > > Expect, yes, but Andrei made a good point that (4) is not the most > > useful behavior. > > If your language acts in an intuitive and logic way, people need less time to > write programs, to debug then, and write less bugs in the first place. This > outweighs most other things. If you have to add a stripping it's not so bad. > > > > Since Perl has been very successful in its niche of string processing, I > > would give a lot a weight to its behavior for basic functions. > > Perl is now (correctly) dying because it looks like it was designed by an > army of crazy monkeys. It was acceptable years ago, when there was no better > alternative, but today it's better to look at other places for design ideas, > at Python, Clojure, C#4, Haskell, Scala, Chapel, F#, Ruby. > If you want to see a small design error that may be partially derived from > Perl you can see std.string of Phobos1, the chomp and chop functions. They > have too much similar names and they do to much similar things. So you often > need a manual to remember what does what. > I am not a compiler writer, but I am quite able to see what a mess Perl is. > Perl is nearly never a good place to copy language design ideas from. > > Bye, > bearophile
Actually, perl is a risky language to take _syntax_ from, but _semantics_ aren't nearly as dangerous. Obviously there's some semantics that are horrible (see it's OOP mechanisms), but parts of the rest are quite good. I grip and groan every time I find myself having to touch perl code, but it's rarely due to non-syntactical issues. Later, Brad
