On 5/14/07, Thomas Wittek <m...@gedankenkonstrukt.de> wrote:
> Moritz Lenz schrieb: > >> 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.
> Even if it's "only" ugly: To what advantage? I don't think ugliness is a > good characteristic of a programming language.
Some people consider mathematics ugly too, but expressivity for mathematicians is valued more over general readability. So too in perl. (This is related to "learn once, use often")
>> Additionally I'm not a friend of sigils:
> > Then you shouldn't program in perl. Really.
> Reason? I still haven't seen a good justification for sigils.
Whether you like it or not, sigils are a part of Perl's personality that aren't going away any time soon. If you don't like them, then you shouldn't use perl. All those people claiming that Perl 6 isn't Perl would be on the money if Perl 6 didn't have sigils.
To allow arrays and scalars and subs to have the same name (besides the
> sigil) although they have different content? No good idea I think. > I also can't remember that I ever named a variable like a "reserved > word" or operator. And even if I could, I'd consider it to be bad style.
I think of it more like hungarian notation. The sigils enable a default set of expectations. "Oh, I see an @, so this thing must be an array". Perl 6 has changed the meaning behind the notation ever so slightly, but the utility is still there.
>On the other hand, unless this steps on something, I could suggest >dropping the @ and % anyway, so we have $array and $hash, and then >we could instead use the @ and % sigils as a prefix to indicate in >that case that we want them to copy by value. For example:
> my $foo = [23, 434, 6]; > my $bar; > $bar = $foo; # copy by reference > @$bar = @$foo; # copy by value
>Actually, I think that would be a vast improvement, as we could then >use the @ prefix with any collection type as short-hand to say that >= is copy by value.
As a follow-up or clarification of what I just said, here is a proposal ...
Variables of all types have $ sigils.
The semantics of $foo = $bar are unchanged; usually $foo and $bar point to the same container after the assignment, afaik.
Prefixing a @ or % before a variable name indicates a syntactic short-hand for something concerning the variable.
On declaration, saying @$foo means the same as "Array $foo", and saying %$foo means the same as "Hash $foo", or some such. This works for my|our|has etc as well as parameter declarations. This is instead of declaring @foo or %foo.
On use in an expression, @$foo = @$bar indicates we want a copy by value or clone or shallow copy or whatever, and $foo and $bar point to different containers after the assignment; the semantics are like the current @foo = @bar.
Similarly, use eg @@$foo rather than @@foo as appropriate.
With these changes, I see it making Perl more consistent in appropriate ways, and easier to use, and huffmanizing isn't worse.
Also, it means we can free up the @ and % rare ASCII symbols for other purposes in some situations.
I could also argue that the conception of @ meaning plural vs $ singular isn't really an absolute, since any value can be treated as either being a collection or being atomic under different circumstances.
> 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/).
(/\W/) It is in Ruby the same. In Python re.search('\W',foo). Is it really nicer ?
> 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.
In Perl6: $*UID (see S02.pod)
> 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.
Perl is a language with sigils. We must see it more penetrating ! The advantages of sigils in Perl are overall, by item access in structures, by the flexibility of subroutine calls, interpolation , global variables, .... Perl wants separate variables from other language structures . Perl without sigils is not Perl more. Perl6 in this regards is really to late for you :-)
> 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.
Operators are only another format ( nice ) of functions.
> 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...
"use warnings" is helping you !
And you can always make explicit type conversion. That does mean explicit :-) . But you must type something more. The only builtin implicit type casting in Perl is this numeric / string conversion and it is fairly obvious and absolutely not error-prone.
These reports are fairly special. These are not about popularity of a programming language , but how many books O'Reilly sold, and how many were googled. What about is not clear. Maybe waiting for Perl6 ? In place of contributing? Searching for redemption ?
> People not only want code that _is_ sexy, but they also want it to > _look_ sexy.
Sex is oftentimes perversion ;-) Well, natural selection. Survives the fittest idea , not necessarily the sexiest look.
Thomas Wittek wrote: > Moritz Lenz schrieb: >>> 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.
> Even if it's "only" ugly: To what advantage? I don't think ugliness is a > good characteristic of a programming language.
>>> 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.
> I hope so. I could only find the counterparts for __PACKAGE__ etc. in > S02. I didn't find the one for e.g. $<.
>>> Additionally I'm not a friend of sigils:
>> Then you shouldn't program in perl. Really.
> Reason? I still haven't seen a good justification for sigils. > To allow arrays and scalars and subs to have the same name (besides the > sigil) although they have different content? No good idea I think. > I also can't remember that I ever named a variable like a "reserved > word" or operator. And even if I could, I'd consider it to be bad style.
No one mentioned that if it wasn't for sigils, many strings would be increased, length-wise, to do operator concatentation. If it wasn't for that then simple string insertions couldn't be used.
Plus sigils are a defacto form of representing variables in other languages, like Unix scripting and PHP. I'd rather read a data item [scalar, { associative, 1-D } array, list, class object ] and have a good idea of what the target data type is. References is the only data type ones that introduces some sort of mystery to this mix, IMO.
>>> I would also like semicolons to be optional.
>> Most people don't ;-).
> Oh, really? Source? :) > I think they were invented to allow easier parsing and not easier coding. > E.g. in JavaScript, Python, Ruby and Groovy they are optional or even > don't exist. As I said, there are much more cases where you wouldn't > need them but have to write them than vice versa. > Optional semicolons save keystrokes, eye pain and stupid syntactic > errors. And if you still like them, you could just use them, which is > the definition of "optional".
Almost all mainstream languages do it though, and it serves as nice visual breaks in source. I honestly hate lack of semi-colons, with the exception of shell scripts, all of which I produce that are less than 150 lines long.
Then again I don't do more than 2 sets of statements in a given line for shell scripts either, and I don't so the same with Perl.
<rant>
The only thing I hate about Perl with required formatting is the silly braces. If it's one line and separated by visible whitespace, why is the only option available to me the
statement_1 if(statement_2);
or
statement_1 unless(statement_2);
syntax? Seems less readable than:
if(statement_2) statement_1
or
unless(statement_2) statement_1
The only legitimacy for the first set of formats would be if in fact you were reading off the logic statement in a left-to-right language. But then again many languages don't follow that convention (Japanese, Korean, etc etc for instance).
>>> 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.
> Oh, if I didn't like Perl, why should I care about posting my ideas here? > Perl has stolen the largest part of the language from other languages. > Why not do so again by adopting good ideas.
>> Don't get me wrong, there's nothing bad in writing some critics, but >> yours is impossible to realize in Perl 6
> Admittedly I'm much too late and I didn't expect applause for my critics > -- but at least I hoped to get a discussion based on arguments.
> > and therefore are it's hard to call it constructive.
> Unfortunately I already thought this. Even if everyone agreed that > sigils (or forced semicolons, or tons of operators, ...) are more bad > than good (and this seems like persuading the pope to allow homosexual > muslims to marry with priests) the design process is probably too far to > introduce such dramatic changes. > Sadly.
Yes, probably about as likely as Neo-Nazi's getting married to Haccidic Jewish people with Satanic priests presiding.
On Mon, May 14, 2007 at 10:48:34PM -0700, Garrett Cooper wrote:
: No one mentioned that if it wasn't for sigils, many strings would be : increased, length-wise, to do operator concatentation. If it wasn't for : that then simple string insertions couldn't be used.
Well, except you can interpolate in Perl 6 with bare closures, so
say "answer = {foo}"
wouldn't be so bad.
: The only thing I hate about Perl with required formatting is the silly : braces. If it's one line and separated by visible whitespace, why is the : only option available to me the : : statement_1 if(statement_2); : : or : : statement_1 unless(statement_2); : : syntax? Seems less readable than: : : if(statement_2) : statement_1 : : or : : unless(statement_2) : statement_1
That has been a not-infrequent complaint about Perl from people coming from a C-ish background. However, what we discovered with the Perl 6 design was that it was not, in fact, the braces that were silly, but the parentheses. The braces consistently represent a closure in Perl 6, even in control constructs, which are not special-cased as in C and Perl 5. But by taking that approach we can get rid of the parens that are doing only syntactic work without carrying any semantic weight. So Perl 6 ends up with the one-liner:
if statement_2 { statement_1 }
and that's no more characters than your parentesized version.
Now you might think that the curlies are still useless there, but the fact that it's a closure means you can capture the value of the control condition if you like. This would be rare with an if, but with other control flow structures it's quite common. In particular this very common construct:
for 1..100 -> $i { say $i }
Since -> is just a built-in way of writing an anonymous sub with arguments, there's no need to invent special syntax for loop variables!
And when you say
for 1..100 { say $_ }
you're still logically calling an anonymous sub with a single parameter called $_. I freely admit that the use of braces in C and Perl 5 is silly, but the braces in Perl 6 are about as far from silly as you can get.
: The only legitimacy for the first set of formats would be if in fact you : were reading off the logic statement in a left-to-right language. But : then again many languages don't follow that convention (Japanese, : Korean, etc etc for instance).
Oddly, the statement modifier is borrowed directly from English.
: The same opinion goes for all loops, except the : : do { statement } ( { while, until } ); : : variety.
That particular construct comprises several additional cans of worms. :)
As a follow-up to this thread, I discussed the matter on #perl6 with Larry today (before the thread on mutable arguments), and I learned that one of my main concerns, of inconsistency between different collection types, is not valid.
1. Not just Array, but also Seq can typically bind to both @ and $.
2. Not just Hash, but also [Mapping,Set,Bag,Pair,etc] can bind to both % and $.
So its not just Array and Hash with the extra sigils, while everything else has only the $.
I now recommended that the Synopsis be updated to explicitly clarify such as these details, to make things less ambiguous for future readers, and they don't make the same mis-assumptions that I did about the limited scope of @ and % use.
That is, the Synopsis should explicitly state which are all the built-in types that could typically bind to each of the sigils (and everything can bind to $).
Larry thought that perhaps S02 would be the place for it.
In conclusion, I retract my previous suggestion of just using $ where we used to use @ and %.
It's a valid aside to note that, while people know what singular and plural are, few people use or even refer much to the Greek use of a special intermediary (the dual) when there were exectly two of something...but the basic mindest of dichotomy is a fundament of the language. (c.f. the men/de construct so basic to the language).
Perl is like that. There are a lot of little corner cases that are distinctly Perl, things unlikely to be seen elsewhere, and sometimes hardly ever even used in Perl.... but the mindset that is Perl is a beautiful thing, and that's still there.
Besides, if you don't get the aesthetics of the Schwartzian Transform, then you should probably be using python or java anyway, hm?
Let's let Perl be Perl. It's a new Perl, but it's still a pearl. =o)
> On Mon, May 14, 2007 at 02:21:47PM -0400, Ryan Richter wrote: > : In Perl 6, the & sigil is used to distinguish between > : > : foo bar > : > : which calls bar and passes the return value to foo, and > : > : foo &bar > : > : which passes bar as a Code object to foo.
> In other words, the sigil is consistently a noun marker in Perl 6, > even when a sigil is used on a verb. In Perl 6, where sigils > distinguish nouns not only from verbs, but also from adjectives (if > you count types as adjectival). With a glance you can tell which > are the nouns and which are the types here:
> multi CatDog sub make_catdog (Cat $cat, Dog $dog) {...} > multi CatDog sub make_catdog (Cat Dog $catdog) {...}
> While Gabor is correct that in Perl 5 removing the sigils from verbs > made some verbal collisions happen that otherwise wouldn't have, in > Perl 6 we've mostly fixed that by essentially getting rid of most > reserved words, and making even the builtin functions participate > as normal multis and methods. For that reason, and because verbs > linguistically tend to be disambiguated by the nouns fed to them as > argements, verbs don't need to be conjugated nearly as badly as nouns > need to be declined. A lot of nouns typically don't have arguments > to disambiguate them with, at least until you start subscripting > them, > and we don't do multiple dispatch on subscripts.
> As for the original complaint, we long ago decided to ignore people > who > are prejudiced against languages that mark nouns. Greek wouldn't be > Greek if you couldn't decline your nouns. (In my estimation, it's > the conjugated verbs that make Greek so difficult to learn, really. > On the other hand, once you learn them they're very expressive in > tense and aspect. It's all tradeoffs.)
