Re: Is Perl 6 too late? (an aside)
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)
*Paul
--- Larry Wall [EMAIL PROTECTED] wrote:
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.)
Larry
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
Re: Is Perl 6 too late?
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. :)
Larry
Re: Is Perl 6 too late?
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
Re: Is Perl 6 too late?
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. 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. 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. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
On 14 May 2007, at 11:51, Thomas Wittek wrote: 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. How did you know which reserved words and operators were going to be introduced in the future so you could avoid them all? -- Andy Armstrong, hexten.net
Re: Is Perl 6 too late?
chromatic wrote: 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. Oh, some someone must agree that word characters might be the better choice. As I wrote Moritz, I could only find the replacements for __PACKAGE__ and alike. Additionally it would be very nice to group them in packages. 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). As I partially wrote Moritz, I a) don't think that it's the case very often. you have to write the sigil a thousand times where it wouldn't be useful for only 1 case where you'd have a name conflict. b) even if there would be a conflict, it might be considered bad style to use identical identifiers (besides the sigil) for different things (vars/objects/subs/operators/...). I would also like semicolons to be optional. When (smart) people talk about Python's whitespace problem, they don't mean *horizontal* whitespace. I'm not much into Python. But as at least Ruby, Python, JavaScript, Groovy and Lua (which all are relatively young languages) don't force you to write semicolons. So semicolons don't seem to be the best invention since sliced bread. There should be extra-syntax for the rare cases (multiline) and not for the common ones. 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! And it should be. I really like the expressive power of most of the operators. Especially the new zip/junction/reduce/smart-match ones. But I don't like doing implicit type casting with operators. It's even discouraged in Perl5 as we have a warning for that. So maybe it'd be a good idea to completely drop it. People not only want code that _is_ sexy, but they also want it to _look_ sexy. At least almost everyone to whom I said, that I do most work in Perl, responded with some sentence containing the word ugly or unreadable. To get away from that image, it's neccessary to do some radical changes I think. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Andy Armstrong schrieb: On 14 May 2007, at 11:51, Thomas Wittek wrote: 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. How did you know which reserved words and operators were going to be introduced in the future so you could avoid them all? How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. know? They didn't. If there is a new release, you always have to check if your code still runs. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
On 14 May 2007, at 12:31, Thomas Wittek wrote: How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. know? They didn't. If there is a new release, you always have to check if your code still runs. I think that may be the point I'm making. -- Andy Armstrong, hexten.net
Re: Is Perl 6 too late?
herbert breunung schrieb: please make a decision for you to program in a language [..] [..] try python. [..] Oh, just because I think that they've some smart design decisions? Why not steal them? BTW: Why do so much people say go away if you don't like it instead of being open for ideas and discussing them from a neutral point of view? -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
I'm so tired of hearing how unreadable Perl is. It's specious. But if so many people think it... Uh-uh. Instinctive reactions can be both universal and incorrect...and I think that's what this is. At least, among those who have even bothered to look into Perl instead of just repeating FUD. As for the rest, nothing we do to P6 will overcome the default Perl sucks reaction from such bigots. Better to make it a powerful language with a compelling functional reason to use it; if we succeed, we can maybe start to win back some mindshare and undo the rep damage caused by the cgi explosion. On 5/14/07, Thomas Wittek [EMAIL PROTECTED] wrote: herbert breunung schrieb: please make a decision for you to program in a language [..] [..] try python. [..] Oh, just because I think that they've some smart design decisions? Why not steal them? BTW: Why do so much people say go away if you don't like it instead of being open for ideas and discussing them from a neutral point of view? -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED] -- Mark J. Reed [EMAIL PROTECTED]
Re: Is Perl 6 too late?
herbert breunung schrieb: please make a decision for you to program in a language [..] [..] try python. [..] Oh, just because I think that they've some smart design decisions? Why not steal them? BTW: Why do so much people say go away if you don't like it instead of being open for ideas and discussing them from a neutral point of view? you ignore what i wrote. im glad if you stay and keep on ask important questions but please recognise that there are some core decisions that define the language called perl, and when we change them its no longer perl. so please dont feel offended to me its a matter of logic and practibality. and to me it maybe sometime usefull dont write as much ; but keep out sigils i definitly dont like because it became much harder readable to me and the whole subject of twigils and siginiture sigils goes down the toilet whenn we throw that one away. so i hope you understand me now better all best herbert _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066
Re: Is Perl 6 too late?
Andy Armstrong schrieb: On 14 May 2007, at 12:31, Thomas Wittek wrote: How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. know? They didn't. If there is a new release, you always have to check if your code still runs. I think that may be the point I'm making. Your point is that you don't have one? Do you believe, that new keywords are the only cause of breaking backwards compatibility? I don't think so. So you rely on testing your code anyway. Sigils won't save you from that. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
On Mon, May 14, 2007 at 02:36:10PM +0200, Thomas Wittek wrote: Andy Armstrong schrieb: On 14 May 2007, at 12:31, Thomas Wittek wrote: How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. know? They didn't. If there is a new release, you always have to check if your code still runs. I think that may be the point I'm making. Your point is that you don't have one? Do you believe, that new keywords are the only cause of breaking backwards compatibility? I don't think so. So you rely on testing your code anyway. Sigils won't save you from that. Back in the 90's I was with a company that had a 20K line perl program. We would provide a copy of perl as part of the program suite, so that we could control which version was being used for our software and when it was upgraded while still allowing the customer to have their own version of perl that they could upgrade on their own schedule. Before any perl upgrade was built into our suite, we would of course test it extensivily to ensure that all of the code was still compatible. Until the perl4-perl5 change, there was never any problem - Larry is a wizard at adding totally new concepts and features in a way that just happens to include all of the old usage bits as a special case that falls magically out of the new, enhanced, more coherent whole. But there is no way that this would have been possible without the distinction between named operators and variables provided by sigils. Removing the sigil on a function call (it used to always be written sub(args...)) did, I think, lead to the difficulty in perl5 where it became difficult to add new keyword operators to the language - because they could conflict with subroutine names in existing code. Needless to say, that level of dependable upgradability without requiring code rewrites was considered to e a huge benefit of using perl for our company. (For the record, we delayed converting from perl4 to perl5 for many years, woried about the possibility of subtle problems arising from the massive changes that had been made to the language. When I finally tried it out, there were only a few changes that really affected us. I had the code converted in about two weeks, although we then ran it in parallel with the old code for about two months before accepting that nothing tricky had snuck in.) --
Re: Is Perl 6 too late?
On Monday 14 May 2007 04:28:15 Thomas Wittek wrote: 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). As I partially wrote Moritz, I a) don't think that it's the case very often. you have to write the sigil a thousand times where it wouldn't be useful for only 1 case where you'd have a name conflict. b) even if there would be a conflict, it might be considered bad style to use identical identifiers (besides the sigil) for different things (vars/objects/subs/operators/...). theproblemlinguisticallyspeakingisthatsometimespunctuationishighlyimportant\ fromareadabilitystandpointyoumaynotliketheuseofspacescommasdashesupper\ casinghyphensandperiodsbutitmakesatremendousdifferencetoreadabilitywhether\ youlikeitornotasitmaybebadstyleifyoudontputspacesbetweentwowordsandtheresult\ lookslikeawordthatsomeonemaydefineinthefuture There *are* a few linguists involved in Perl. So semicolons don't seem to be the best invention since sliced bread. There should be extra-syntax for the rare cases (multiline) and not for the common ones. Somehow English seems to get by with periods at the ends of statements, though almost no one pronounces them. But I don't like doing implicit type casting with operators. It's even discouraged in Perl5 as we have a warning for that. So maybe it'd be a good idea to completely drop it. I can't really see that changing DWIM to DWTWM is anything but a step backwards in Perlishness. People not only want code that _is_ sexy, but they also want it to _look_ sexy. At least almost everyone to whom I said, that I do most work in Perl, responded with some sentence containing the word ugly or unreadable. To get away from that image, it's neccessary to do some radical changes I think. I agree. You need less ignorant colleagues. I'm not sure Perl 6 can fix that. By the way, I'm still waiting to meet your cadre of Dylan hackers. -- c
Re: Is Perl 6 too late?
On Monday 14 May 2007 04:35:19 Thomas Wittek wrote: BTW: Why do so much people say go away if you don't like it instead of being open for ideas and discussing them from a neutral point of view? Perhaps you're not a native English speaker, but running into the room and saying Perl 6 doesn't have a compelling vision, Everyone thinks Perl is ugly, and Python and Ruby are doing things better than Perl 6 is *not* the way to start a friendly and neutral discussion, as if a sane, calm, neutral discussion of programming language designs and tradeoffs were possible. -- c
Re: Is Perl 6 too late?
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. In fact it makes the code easier to read. At least to me. The other day I had a lot of work to do with matlab code, and it just sucked. No variables where declared, and therefore I had no type information. I didn't knew if arguments passed to functions were arrays/matrices or scalars, and sigils would have helped very much. And don't say but a good IDE.. - I didn't have one. No language should depend on its IDE's syntax hilighting. I would also like semicolons to be optional. Most people don't ;-). Oh, really? Source? :) I paraphrased Larry Wall. Iirc it was everybody wants the semicolon or something - correct me if I'm wrong. I think they were invented to allow easier parsing and not easier coding. I think the p6 grammar is so complex that you couldn't do it without a statement terminator, be it a semicolon or a newline. And we know that you prefer the newline, I (and it seems, many other) do prefer semicolons. E.g. in JavaScript, Python, Ruby and Groovy they are optional or even don't exist. most languages don't allow you to call a function without parentheses. if you have foo bar without a statement termination, you can't know if thats foo(bar()), or foo() bar() whereas if you force the parentheses, it is unambigous anyway. Which explains why languages with simpler syntax can well live without the semicolon. 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. because, as was pointed out earlier, huge changes a) delay implementation significantly and b) change the character of the language too heavily. We want Perl 6 to be Perl still. 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. Most of these issues have been discussed in one way or another, either on p6l or on use.perl.org. If you really want the arguments, you'll find most of them. 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. Right. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Is Perl 6 too late?
Moritz Lenz wrote: Thomas Wittek wrote: Moritz Lenz schrieb: I would also like semicolons to be optional. Most people don't ;-). Oh, really? Source? :) I paraphrased Larry Wall. Iirc it was everybody wants the semicolon or something - correct me if I'm wrong. sorry, masak++ pointed out that it was wrong indeed. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Is Perl 6 too late?
On Mon, 14 May 2007 12:51:53 +0200 Thomas Wittek [EMAIL PROTECTED] wrote: Reason? I still haven't seen a good justification for sigils. This may not qualify as a good justification, but it is one I've discussed with others and rings true for many. Take a look at actual code written in other languages and you'll find many variable names that end in things like _ary, _array, _dict, _list, etc. to denote the type of container it is. Why? Because 'foo' doesn't tell you what it is, so programmers compensate with 'foo_dict' or 'foo_array' so they don't have to constantly go looking for the definition. With Perl you get that plainly visible with one single character at the beginning of the variable name. You can differentiate what it is easily, in a consistent way, with only one character. Personally, I love sigils for this reason alone. 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. Much like your argument about naming variables after reserved words, I see naming an array, scalar, and a sub the same to be bad style. - Frank Wiles [EMAIL PROTECTED] http://www.wiles.org -
Re: Is Perl 6 too late?
On 5/14/07, John Macdonald [EMAIL PROTECTED] wrote: Removing the sigil on a function call (it used to always be written sub(args...)) did, I think, lead to the difficulty in perl5 where it became difficult to add new keyword operators to the language - because they could conflict with subroutine names in existing code. Actually I think I never understood this issue. We claim that having the sigils saves us from stepping on our future feet by making sure keywords of the language are always different from any variable we might create. The fact that function don't need a sigil any more and it is even AFAIK discouraged to be used makes *this* argument mute. Thought this thread might not be the best place to ask this I'd be glad to read some explanation about this. regards Gabor
Re: Is Perl 6 too late?
OK! Be concrete ! :-) ( Hart wie Beton !)
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.
[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
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.
Tibor
Re: Is Perl 6 too late?
On Mon, May 14, 2007 at 20:41:35 +0300, Gabor Szabo wrote: On 5/14/07, John Macdonald [EMAIL PROTECTED] wrote: Removing the sigil on a function call (it used to always be written sub(args...)) did, I think, lead to the difficulty in perl5 where it became difficult to add new keyword operators to the language - because they could conflict with subroutine names in existing code. Actually I think I never understood this issue. We claim that having the sigils saves us from stepping on our future feet by making sure keywords of the language are always different from any variable we might create. The fact that function don't need a sigil any more and it is even AFAIK discouraged to be used makes *this* argument mute. Thought this thread might not be the best place to ask this I'd be glad to read some explanation about this. 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. -ryan (sorry, I deleted your message by mistake, I'm attempting to fake up a reply)
Re: Is Perl 6 too late?
Thomas Wittek skribis 2007-05-14 0:42 (+0200): excessive use of special characters (/\W/). This seems to be I don't like regexes. Ignoring for now that Perl 6 regexes will be more verbose and thus easier to read for someone without much prior exposure to them, what would you suggest as an alternative to regex matching? One of the common alternatives is to iterate over a list of characters, possibly using an index. Would you say that a screen page full of such code is easier to read and maintain than a single regex on a single line? Many languages have regexes, even the cleanest among them. And they're all as messy as Perl's. They're often more verbose on the outside, which can result in something like foo.match(/foo/) instead of foo =~ /foo/, but the /foo/ part is most important here. If you don't recognise what that is, it doesn't matter if .match or =~ was used. Many languages have regexes, but Perl was probably the first to apply them heavily in normal programming. And nowadays, they're so ubiquitous that it's hard to find a language without Perl-ish or Perl compatible regexes. Why do you think this is? I think it's kind of funny that indeed exactly the most cryptic part of Perl's syntax is copied to so just about every modern programming language, while at the same time Perl is constantly criticized for using special characters so much. No, special characters aren't a problem. They are the fundament of a very powerful and expressive syntax. Just don't try to understand a screen full of them all at once -- realise that in another language, the first three lines would sometimes already fill the same screen, and adjust your reading speed. On the other hand, the overall structure of a program is often more obvious, exactly because so much more fits in one screenful. In Perl it is often not needed to refactor something to many tiny subroutines with verbose identifiers, just for legibility. One thing stays true, though: Perl is very hard to read for someone who doesn't know Perl well enough. But that's practically true for almost language, be it Python or Japanese. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Is Perl 6 too late?
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.)
Larry
Re: Is Perl 6 too late?
Frank Wiles schrieb: Take a look at actual code written in other languages and you'll find many variable names that end in things like _ary, _array, _dict, _list, etc. Actually I've not seen that often. Where I've seen it frequently is in Visual Basic and Delphi/Pascal. I hated it too. But I think that the name of an identifier (noun/verb, single/plural, the meaning of the word) already gives enough context to understand what type it is. And every use of it (assigning and reading) additionally makes it clear. So _for me_ there is no need for an additional hint for the type. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
chromatic wrote: theproblemlinguisticallyspeakingisthatsometimes [snipped] I can't remember that I said that you shouldn't separate your expressions (by punctation/whitspaces), $.but! (*adding$ %*characters _+that^# $might) @#not_ !#be() !necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier to read and to type (in addition it was a torture to type that). So semicolons don't seem to be the best invention since sliced bread. There should be extra-syntax for the rare cases (multiline) and not for the common ones. Somehow English seems to get by with periods at the ends of statements, though almost no one pronounces them. Oh, I thought Perl was a programming language. My fault. Apples and oranges. Most modern scripting languages don't need the semicolons. I think there's no plausible reason for them. I agree. You need less ignorant colleagues. I'm not sure Perl 6 can fix that. I don't think that it's a point of ignorance. Especially as they (and enough other people on the web) only seem to be ignorant regarding Perl. Strange, huh? By the way, I'm still waiting to meet your cadre of Dylan hackers. I never claimed to have some. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
At 11:43 -0700 5/14/07, Larry Wall wrote: In other words, the sigil is consistently a noun marker in Perl 6, even when a sigil is used on a verb. It would seem to me that a preprocessor, written in perl of course, could easily respond to DIMENSION noun AS double statements or whatever you like by adding the appropriate sigl every the noun appears without it. As for too late I do have a problem. I started with perl 4 or so as MacPerl with Apple's MPW as a shell. Now, at age 72, I do worry that perl 6 may be too late for me. It's been two years since I got to the point of using the * sigl in perl 5 and I still have a lot to learn about that. FORTRAN forever. -- Applescript syntax is like English spelling: Roughly, though not thoroughly, thought through.
Sigils by example (was: Re: Is Perl 6 too late?)
Thomas Wittek skribis 2007-05-14 22:20 (+0200): But I think that the name of an identifier (noun/verb, single/plural, the meaning of the word) already gives enough context to understand what type it is. So is user_id a variable or a type? How about substring or document? Is new a function, or a variable? How about old? Is is_valid a function that determines whether something is valid, or a variable holding the result of this test? When you have update(delete_random), where both update and delete_random are functions, does this pass the function delete_random to update, or does it first delete something, and then pass the resulting value to update? Don't forget that one of the important decisions in Perl was that we don't always like to use parentheses, because that clutters code (and you don't want that!!). Given HTML Element, is HTML the type and Element the variable of that type, or is Element the type, and HTML the variable (for example, to hold the html element object)? Is pid a variable you used yourself, for example as the return value from fork, or does pid give you the pid of your current process? And if the latter, is that by calling the pid function, or because pid is a variable? Doesn't count input look wrong to you? It should, because count is a hash! By the way, what would input be? And how on earth would you write object.foo(), where foo is a variable holding a reference to a method, not the name of the method, if you had no sigils? ... ... ... ... ... | So is user_id a variable or a type? How about substring or | document? The Perl Way: $user_id is a variable, $substring is a variable, $document is a variable. user_id is not a variable, substring is not a variable, document is not a variable. | Is new a function, or a variable? How about old? The Perl Way: $new is a variable, $old is a variable. new is not a variable, old is not a variable. | Is is_valid a function that determines whether something is valid, or | a variable holding the result of this test? The Perl Way: $is_valid is a variable. is_valid is not a variable. | When you have update(delete_random), where both update and | delete_random are functions, does this pass the function delete_random | to update, or does it first delete something, and then pass the | resulting value to update? The Perl 6 Way: update(delete_random) passes the function delete_random to update. update(delete_random) calls the function delete_random, and passes whatever it returned to update. | Given HTML Element, is HTML the type and Element the variable of that | type, or is Element the type, and HTML the variable (for example, to | hold the html element object)? The Perl 6 Way: HTML $Element is a variable of the type HTML. $HTML Element is a syntax error caught early by the compiler. (And that's really great if your native language makes you think the other way around than the programming language wants you to.) | Is pid a variable you used yourself, for example as the return value | from fork, or does pid give you the pid of your current process? | And if the latter, is that by calling the pid function, or because | pid is a variable? The Perl Way: $pid is a variable that you set yourself. pid is not a variable. $*PID is a variable, that represents the pid of your current process. | Doesn't count input look wrong to you? It should, because count is a | hash! By the way, what would input be? The Perl Way: %count $input (or %count input) looks wrong, error caught even before compile time, programmer time and energy conserved. | And how on earth would you write object.foo(), where foo is a variable | holding a reference to a method, not the name of the method, if you had | no sigils? The Perl Way: $object.foo() calls the method called foo. $object.$foo() calls the method that is in the variable $foo. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Thomas Wittek skribis 2007-05-14 22:31 (+0200): $.but! (*adding$ %*characters _+that^# $might) @#not_ !#be() !necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier Those characters are meaningless. The many symbols in Perl 6 have very distinct meanings, which makes them very powerful tools! Oh, I thought Perl was a programming language. My fault. Apples and oranges. There is a reason that C programmers don't throw away their source code after compiling it. While in some companies, writing software is indeed a unidirectional process, most companies that wish to survive have to maintain what they wrote, and then you also have to read it. Programming languages and spoken languages are both read by human beings, so they should still be easily parsed by these creatures. Most modern scripting languages don't need the semicolons. I think there's no plausible reason for them. They typically have a line continuation character instead of a semicolon, though. However, like the previous sentence, and this one too, actually, sometimes there is a line break in between. Again, written language can be a nice example, because if we had line \ continuation characters in here, it would suddenly look a lot \ different. Did you, while reading this, pause, just before different? -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Sigils by example (was: Re: Is Perl 6 too late?)
Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and ''? I ask
because I've seen a lot of object-based code that has said stuff like
'$container{$key}'; it seems that there's an assumption that $foo can
be used as a list, a hash, or even a routine if the object that it's
tied to has list-, hash-, or routine-like behavior: i.e., it no longer
seems to be a scalar variable, but rather a variable. Whereas
'@', '%', and '' still seem to promise list, hash, and routine
functionality, respectively. In short, there no longer appears to be
a sigil that says I give my solemn promise that the contents herein
will be scalar.
--
Jonathan Dataweaver Lang
Re: Sigils by example (was: Re: Is Perl 6 too late?)
On 5/14/07, Jonathan Lang [EMAIL PROTECTED] wrote:
Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and ''? I ask
because I've seen a lot of object-based code that has said stuff like
'$container{$key}';
Well, $container{$key} is how you access elements of %container in
Perl5; in Perl6 that's %container{$key}. But in object-based P5 code,
you'd be much more likely to see $container-{$key}, where $container
contains a reference to a hash. I believe in P6 you could write that
either as $container.{$key}, $container{$key} (where the . is implied
since $container{$key} can't refer to %container anymore), or
%$container{$key}.
If I understand your point, however, it is that the availability of
references, which are scalars, has essentially removed the
scalar/array/hash/sub distinction, since you can store references to
any of those things in a $var. Further, in order to dereference such
references, you need something beyond the sigil anyway, which takes
its place as a type disambiguator.
You aren't the only person who feels this way; there was a proposal
back in the RFC process to remove sigils in favor of everything is a
scalar, dereference as needed. I was in that camp myself. But Larry
rejected that proposal, defending the utility of sigils, and I have
been swayed by the arguments, which I'm not going to repeat because I
can't say it as well, but I do advise you to go read - it was either
Apoc1 or Apoc2, I think.
Anyway, one of the things I like about the Perl6 design is that it
essentially restores sigils to their pre-Perl5 importance via
automatic referencing and dereferencing according to context. This
effectively removes the everything's a scalar anyway argument since
you can toss references around without making everything a $var. (I
dunno how many times I have tried to declare and initialize a hash
with my %hash = { ... }, which initializes the hash to have a single
element whose key is the hash reference provided and whose value is
undef... but in P6 that does the right thing.)
--
Mark J. Reed [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Thomas Wittek wrote:
chromatic wrote:
theproblemlinguisticallyspeakingisthatsometimes [snipped]
I can't remember that I said that you shouldn't separate your
expressions (by punctation/whitspaces),
$.but! (*adding$ %*characters _+that^# $might) @#not_ !#be()
!necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier
to read and to type (in addition it was a torture to type that).
Forgive chromatic. Part of joining @Larry is undergoing a painful
initiation process, which tends to inspire zealotry.
The point, though, is that there are three ways of handling the whole
part of speech issue. One is with a dictionary (reserved words): in
this method, every word is assigned a part of speech, usually with a
default. Any use of the word FOR must be a loop, any use of INT
must be a typedef, etc.
Another is with context (and predeclaration). In this method, the
surrounding context can be used to infer the part of speech of a word,
with some sort of confirmation for 'new' words (user-defined variables,
functions, etc.). Most present-day compiled languages use this one,
although they frequently rely on the reserved words approach, too, for
some words.
Finally, the approach Larry has chosen is to explicitly mark the part of
speech. Perl up to version 5 used an approach that attempted to
correlate the marker with the part of speech associated with the
surrounding context: foo(@array) vs. foo($array[0])
This approach was criticized for providing relatively little value over
the context+lookup approach. If the sigil has to correspond to the
context, then only in rare cases (ambiguous context) is the sigil adding
much value.
The new approach (@array[0]) ties the sigil to the declaration, serving
to distinguish name collisions and of course to autovivify variables
correctly.
Ultimately, it comes down to value added, and culture/custom. Perl has
always used sigils, so perl should continue to use sigils. That's a
legitimate stand, in the absence of compelling arguments to the
contrary. It let's perl be perl.
As far as value goes, let's call the C/C++ approach the nul approach,
since by default there is no sigil in front of words. (And I'm
considering * and to be sigils, rather than operators.)
The nul approach reduces typing. It relies on context to identify the
part of speech, occasionally forces some look-ahead (a name followed by
'(' is an invocation instead of a reference) and can't handle multiply
typed (@foo vs. foo vs. $foo vs. %foo) names.
The perl approach increases typing, by something less than 1 character
per identifier. (This is a real cost, that Larry continues to elect to
bear.) The p5 version imposed some disambiguation burden on the parser,
since $foo[0] involved @foo, not $foo. Perl *can* handle *some* multiply
typed names. There is a difference between $foo and @foo, but not
between my Cat $foo and my Dog $foo.
In addition, however, there is the whole *foo thing. Adding the sigil
has encouraged people to think in weird ways, 'tied' variables and
typeglobs not least among them. I don't know if a 'perl' that used the
nul approach would ever have had those features. (Sapir-Whorf lives!)
The perl approach, then, opts to pay a significant penalty (0.9+
characters per variable) to allow access to the cool extra features that
few other languages use, and none so compactly.
A similar trade-off exists with the statement terminating semicolon. In
this case, it involves the number of statements per line:
A language that terminates statements can ignore whitespace, allowing
multiple statements per line and statements that span multiple lines.
A language that associates line termination with statement termination
must pay a separate cost (continuation marker) for a statement to span
multiple lines. It will not, in general, support multiple statements per
line. (Though it could make the terminator optional and then inject
terminators between colinear statements.)
The vast majority of languages have opted to terminate statements. Perl
is among them. Probably the best argument is that encountering a
semicolon (or full stop, in COBOL) is a positive indicator rather than a
negative one. I see a semicolon. I know the statement is over. as
opposed to I don't see a continuation marker, so it's likely that the
statement is over, although it could be tabbed way off to the right or
something.
Also, there's the increasing size of words to consider. While $a = $b +
$c is a great example of why line termination is not needed, the trend
is for variable and function names, not to mention object and method
dereferences, to grow longer.
From
http://www.oreillynet.com/pub/a/javascript/2003/03/18/movabletype.html I
get:
|MT::Template::Context-add_tag(HelloWorld = sub { return 'Hello World.'; } );|
The MT::...add_tag method name alone is 30 characters. Jam a few long
identifiers together and you're writing a lot of multi-line
Re: Is Perl 6 too late?
Juerd Waalboer schrieb: Thomas Wittek skribis 2007-05-14 0:42 (+0200): excessive use of special characters (/\W/). This seems to be I don't like regexes. Ignoring for now that Perl 6 regexes will be more verbose and thus easier to read for someone without much prior exposure to them, what would you suggest as an alternative to regex matching? Not ignoring that will nullify your argument. Regexps/rules are great, and I never said anything differing. If the syntax gets more readable without any cost (in which I belive) its even better. Now do s/Regexps\/rules are/Perl is/ on the last sentence. On the other hand, the overall structure of a program is often more obvious, exactly because so much more fits in one screenful. My suggestions won't have an impact on the expressiveness of Perl. So in many cases you might have even less characters on your screen. Of course some special character sequences would be replaced by word character sequences, but that won't fill your screen by a magnitude. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Sigils by example (was: Re: Is Perl 6 too late?)
Jonathan Lang skribis 2007-05-14 14:52 (-0700):
Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and ''?
It's useful code self documentation, but not very important, in my
opinion.
If you have sigils, it makes sense to have different sigils for
different things, because that allows very nice shorthands (remember how
this thread was originally more or less about avoiding clutter?) like:
sub foo (@bar, $baz) { ... }
And of course, different behaviour in list context:
my @quux = (@foo, @bar); # These arrays foo and bar flatten
my @quux = ($foo, $bar); # These arrays foo and bar do not
That's a subtle yet very useful distinction.
But this is just very handy, not important.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Austin Hastings: A similar trade-off exists with the statement terminating semicolon. In this case, it involves the number of statements per line: A language that terminates statements can ignore whitespace, allowing multiple statements per line and statements that span multiple lines. Still possible with optional semicolons (as you say later): a = 1 b = \ 2 c = 3; d = 4 The vast majority of languages have opted to terminate statements. Most of the younger scripting languages didn't. Probably the best argument is that encountering a semicolon (or full stop, in COBOL) is a positive indicator rather than a negative one. I see a semicolon. I know the statement is over. as opposed to I don't see a continuation marker, so it's likely that the statement is over, although it could be tabbed way off to the right or something. Your semicolon could also be tabbed way off, so you can't be sure there either. I see no semicolon, so it's likely that the statement continues on the next line. So line termination doesn't gain a punctuation character No problem I think. and causes the ends of lines to be uncertain. It's exactly as certain as with semicolon termination. See above. It does reduce typing, for the small crowd of people that wouldn't just use them anyway because they use them in every other language. I think the lack of value here outweights the savings of one character per line. But even if the advantage of line termination is low (some characters saved, some people might say it looks cleaner), I cannot see any advantage of semicolon termination. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Thomas Wittek skribis 2007-05-15 1:03 (+0200): On the other hand, the overall structure of a program is often more obvious, exactly because so much more fits in one screenful. My suggestions won't have an impact on the expressiveness of Perl. Not so. Consider /@foo/, which is an alternation of all the elements of @foo. That's not just interpolation, it's something very smart, and even without seeing the context that this regex is in, I know how to read this. I don't have to scroll back up to find out that foo was once assigned an array. So in many cases you might have even less characters on your screen. Less characters isn't always better. Often it's worse, sometimes it's better. It appears to me a hell of a job to find out when it's what, and I think Larry figured it out quite well. Of course some special character sequences would be replaced by word character sequences, but that won't fill your screen by a magnitude. Of course. Every symbol can be substituted for a word comma but that doesn apostrophe t automatically make code easier to read period I think a language needs a good balance between symbols and letters comma and for a programming language comma I think alternating between the two is close to a perfect balance comma whereas in human languages once, every $few (words) is.probablybetter; period -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Sigils by example (was: Re: Is Perl 6 too late?)
Mark J. Reed wrote:
Jonathan Lang wrote:
Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and ''? I ask
because I've seen a lot of object-based code that has said stuff like
'$container{$key}';
Well, $container{$key} is how you access elements of %container in
Perl5; in Perl6 that's %container{$key}. But in object-based P5 code,
you'd be much more likely to see $container-{$key}, where $container
contains a reference to a hash.
True; but not at all what I was referring to.
I believe in P6 you could write that
either as $container.{$key}, $container{$key} (where the . is implied
since $container{$key} can't refer to %container anymore), or
%$container{$key}.
_This_ is closer to what I'm referring to. As I understand it, Hash
is a role that provides (among other things) postcircumfix:{ }. So
any object that does Hash should be able to call the above method.
And unless I've missed something, there's nothing in perl 6 that
insists that an object that does Hash must be assigned to a variable
that uses the '%' sigil; the '$' sigil seems to work equally well.
i.e., I've seen code to the effect of:
class Foo does Hash { ... }
my $obj is Foo;
$objkey = 5;
say $objkey;
In short, it appears that there's nothing keeping you from assigning
hash-like or list-like objects to scalar variables.
And this is without bringing references into the picture.
You aren't the only person who feels this way; there was a proposal
back in the RFC process to remove sigils in favor of everything is a
scalar, dereference as needed. I was in that camp myself. But Larry
rejected that proposal, defending the utility of sigils, and I have
been swayed by the arguments, which I'm not going to repeat because I
can't say it as well, but I do advise you to go read - it was either
Apoc1 or Apoc2, I think.
I have never been in that camp. In fact, I tend to see the points I
raise above as a bug, not a feature.
Perhaps the relationship between sigils and roles will be addressed in
the as-yet unwritten S14 (or whichever spec is supposed to address
tied variables)?
--
Jonathan Dataweaver Lang
Re: Is Perl 6 too late?
On 5/14/07, Thomas Wittek [EMAIL PROTECTED] 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. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Is Perl 6 too late?
OK! Be concrete ! :-) ( Hart wie Beton !)
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.
[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
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.
Tibor
Re: Is Perl 6 too late?
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).
The same opinion goes for all loops, except the
do { statement } ( { while, until } );
variety.
/rant
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.
-Garrett
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. digressing 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]
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?
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?
On Thursday 03 May 2007 03:06:43 Andrew Shitov wrote: What is nedded is a very simple step: Contributors. -- c
