Splitter quiz / survey

Robert Fraser fraserofthenight at gmail.com
Tue Apr 28 05:05:05 PDT 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

For quick, simple, write-once scripts, I still haven't found anything 
that beats Perl. I've completely forgotten shell script syntax just 
because of how powerful & simple Perl is for these tasks (I refuse to 
use Ruby because implicit variable declarations means typos = bugs and I 
make a lot of typos... apparently Python is also a good scripting 
language; maybe I'll give it a try some day).

If your code is longer than 50 lines and/or needs to be maintained in 
the future, Perl becomes a lot more questionable. But Perl hate seems to 
go along with goto hate, Vista hate, emo hate, etc. as bandwagon-jumping.



More information about the Digitalmars-d mailing list