> And to attract contributors, you have to have a convincing vision. right
please make a decision for you to program in a language that has fame or one that you like most. as moritz said the special variables are now better sorted and some changes you write about are too far from perls basic principles, i thank that would not be perl anymore. but even for demands like yours it is thought as 2 or 3 lisp-style macros could turn perl6 into something your seems to want. except that one with type recognition of course which i cant think of how to make this work with an macro. but hey since parrot also will read python you would not run too far if you try python. i think you could only win if you try it. maybe youll find problems with python you didnt thought abd be than better informed of or found your favoured programming lang. best herbert > I'm only a distant observer of the Perl6 design process, so I might not > be in the position to criticize Perl6. > On the other hand, a distant view might be insightful. > This is not intended to be a provocation. > But I also think that there is a great opportunity to make _big_ changes > to Perl to be even more competitive. > But maybe Perl6 is probably too far defined to encounter big changes in > some critical aspects. > > As Ruby and Python are getting more and more attraction [1][2] I think > they do something right, that Perl doesn't. > What I think where both (especially Python) do better is in readable code. > > What makes Perl hard to read is the excessive use of special characters > (/\W/). > In my opinion, reducing the use of those characters would make Perl a > lot easier to read and also easier to write. > Global variables with cryptic names, that no beginner can make any sense > of by reading it. And after not working with "$<" for some months I > can't remember it either, although I've got quite some Perl experience. > > Additionally I'm not a friend of sigils: Typing them is relatively > painful, for reading there is no advantage if you use an editor with > decent syntax highlighting and the code looks more cryptic. The answer > in Perl6 are twigils, great... One step backwards in my optinion. > Most programming languages > /C(++|#)?|Java(Script)?|Python|Ruby|Groovy/... don't need them. The only > obvious advantage of using sigils is variable interpolation in strings. > But that could easily be done only in strings without the need to put a > $ in front of each and every variable name in the rest of the code. > > I would also like semicolons to be optional. There are far more cases of > single line statements than multiline statements. So you would save > quite some characters, when the semicolon would be optional and you > could concatenate multiline statements with e.g. a backslash. > > Some say that there are too much operators in Perl(6). I partially > agree. I don't like the implicit type casting forced by the operators > (== int / eq string). That's harder to learn and remember. Harder to > read also. > I really like the Python way of doing it: Set the variables type on the > assignment and remember it. The (fewer) operators now work according to > the type of the operands. No implicit (and error prone) type casting. > That way seems to be the best compromise of easiness and type safety. > > I could continue on that, but I've already written too much... > > [1] http://radar.oreilly.com/archives/2007/05/state_of_the_co_6.html > [2] http://www.google.com/trends?q=perl%2C+python+-snake%2C+ruby > > </digressing> > > People not only want code that _is_ sexy, but they also want it to > _look_ sexy. > > -- > Thomas Wittek > http://gedankenkonstrukt.de/ > Jabber: [EMAIL PROTECTED] > ______________________________________________________________________ XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club! Jetzt gratis testen! http://produkte.web.de/club/?mc=021130
