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.
This is again "Dogs are uncool because Hitler liked dogs." It would be
great if we all steered our rhetoric off this fallacy (and generally
arguments originating from and eliciting emotional response).
Perl tried many things and broke many rules. Along the way it also found
many nuggets and inspirational bits for other languages.
Speaking of split in particular, I find Python's behavior for split
inferior to that of Perl and undesirable for Phobos. The semantics of
splitting depends on the contents of the splitter, so if you split by a
non-literal, it's difficult to count on the result of the splitting. If
I'm changing the behavior for Phobos' splitter, I'm doing so because I
found a reason to, not because Hitler liked dogs.
Andrei
