Re: Is Perl 6 too late?
On Sunday 13 May 2007 15:42:30 Thomas Wittek wrote: > What makes Perl hard to read is the excessive use of special characters > (/\W/). It also makes Mandarin and other ideographic languages impossible to read. As evidence I admit that, though I am very smart, *I* can't read them. (Try to ignore the billion-plus people who can.) > 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. Most of those have gone away. > Additionally I'm not a friend of sigils: I'm not a friend of potential conflicts between built-in operators and my identifier names (and especially the conflicts between scalar, aggregate, type, and function names). > 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. When (smart) people talk about Python's whitespace problem, they don't mean *horizontal* whitespace. > Some say that there are too much operators in Perl(6). I partially > agree. That's like saying there are too many function calls in Scheme. Perl's an operator-oriented language! > People not only want code that _is_ sexy, but they also want it to > _look_ sexy. You'll have to find me more than a handful of Dylan hackers to start to convince me of that! -- c
Re: Is Perl 6 too late?
Thomas Wittek wrote: > chromatic schrieb: >> On Thursday 03 May 2007 03:06:43 Andrew Shitov wrote: >>> What is nedded is a very simple step: >> Contributors. > > And to attract contributors, you have to have a convincing vision. > I'm not sure, if the (current) Perl6 specs are convincing enough to > attract the developers out there. I think they are ;-) > But I also think that there is a great opportunity to make _big_ changes > to Perl to be even more competitive. I don't think that there is space for the changes you are implying in the following paragraphs. Small changes are acceptable, of course. > But maybe Perl6 is probably too far defined to encounter big changes in > some critical aspects. Right ;-) > 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/). I disagree: The make it look ugly, but not hard to read. > 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. Well, most of them are gone or renamed to more readable ones in p6. > Additionally I'm not a friend of sigils: Then you shouldn't program in perl. Really. > I would also like semicolons to be optional. Most people don't ;-). > 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. Well, if you like the python way, feel free to code in python. Perhaps some day it will be possible to mix them: use python; # Write python code here Don't get me wrong, there's nothing bad in writing some critics, but yours is impossible to realize in Perl 6, and therefore are it's hard to call it constructive. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Is Perl 6 too late?
chromatic schrieb: > On Thursday 03 May 2007 03:06:43 Andrew Shitov wrote: >> What is nedded is a very simple step: > Contributors. And to attract contributors, you have to have a convincing vision. I'm not sure, if the (current) Perl6 specs are convincing enough to attract the developers out there. Sure there are a lot of great ideas. But imho Perl6 still has quite some deficiencies, that are criticized very often for Perl5. 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 People not only want code that _is_ sexy, but they also want it to _look_ sexy. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
