13 ms·

> Why not "if 5 < x < 100"? Sigils look awful. Because sigils tell you things. What if 'x' in your example is a list? Are you now checking the length of the li

> Why not "if 5 < x < 100"? Sigils look awful. Because sigils tell you things. What if 'x' in your example is a list? Are you now checking the length of the list rather than the value? Sounds like room for a security bug to me.

lmm 11y ago
> Because sigils tell you things. What if 'x' in your example is a list? Are you now checking the length of the list rather than the value? Sounds like room for a security bug to me. Only if your language is really awful. A good language shouldn't even let you run "5 < x" when x is a list, but even a mediocre one would surely at least make that error out at runtime rather than giving a nonsense answer.
- hahainternet 11y ago
  > Only if your language is really awful. A good language shouldn't even let you run "5 < x" when x is a list, but even a mediocre one would surely at least make that error out at runtime rather than giving a nonsense answer. It depends what you consider "Nonsense". Python for example has no reliable way to differentiate between a string and a list. Strings are iterable, but lists can't be compared with the < syntax for example. My point is simply that $x very clearly says (in Perl 6) "A single value called x" wheras @x is "A list of values called x". In python, "x" is indeterminate even at runtime. Oh, and you can declare barewords with \x for example, if you really want to, it is Perl after all.
  - DonHopkins 11y ago
    What version of Python can't differentiate between a string and a list, or compare lists? Python 2.7.10 (default, Jun 10 2015, 19:42:47) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> type([1]) <type 'list'> >>> type('1') <type 'str'> >>> type(1) == type('1') False >>> [1] < [2] True >>> [2] < [1] False >>> I consider it "Nonsense" to abuse overloaded context sensitive strings of punctuation with arbitrary rules of precedence and associativity, instead of English words correctly spelled out of letters that people can look up alphabetically in a reference manual and google for tutorials to find out what they mean.
    - hahainternet 11y ago
      Sorry I should have made things more clear. I am talking about in things like function signatures. Doing something like isinstance(x, str) is discouraged and considered non-pythonic, and recently hasattr() has also been talked about. However, both strings and lists can be iterated, so assuming that this will fail is incorrect: x = "Hello" for y in x: print("{} is {}".format(y, type(y))) I asked on IRC and ultimately the only answer I got was that the most pythonic way to do things was to name functions whatever_str and whatever_list. edit: I also should have said above "lists can't be compared with strings using <". I was trying to point out Python did things potentially correctly there, but I see now it's ambiguous.
      - DonHopkins 11y ago
        If it's so important to decorate variables with unique punctuation to visually distinguish between two particular kinds of many possible types, then why don't you also decorate function calls according to whether they return lists or scalars? How should you decorate functions that return different types depending on what context they're used in? http://perlmaven.com/wantarray http://perlmaven.com/wantarray If it's so important to visually distinguish the names of scalars and arrays, then shouldn't you also be able to distinguish a string from an int, like BASIC's a$ -vs- i%? So why just distinguish lists and scalars? Why not go all the way to Hungarian Punctuation and use Unicode and Emoji characters to uniquely decorate variables for every other possible built-in and user defined type? https://en.wikipedia.org/wiki/Hungarian_notation#Relation_to_sigils https://en.wikipedia.org/wiki/Hungarian_notation#Relation_to...
        hahainternet 11y ago
        You might be a little confused, I'm pretty sure that wantarray and the concept of functions caring about context is entirely gone in Perl 6. Now you are expected to return objects which 'do the right thing'. However, if you really want to do some of the other things you've listed they are possible to do. Perl 6's syntax can be augmented by the programs being executed. I'm honestly interested though, was I ultimately wrong above? Is there a smart way to define a function in python that can take both a single item and a list of items? In Perl 6 I'd just define a multi sub where the list form applies the single item sub for each item in the list.
- mollmerx 11y ago
  A "good" language might let you run "5 < x" when x is a list and return a list of booleans. This is what languages in the APL family do.
  - awwaiid 11y ago
    I think Perl 6 gets to claim some APL-ness :) . Though you do sometimes need to be explicit: my @x = 3,4,5,6; say "yep" if 5 < @x.any; # yep! (5 < @x.any).perl.say # output: any(Bool::False, Bool::False, Bool::False, Bool::True) (edit: forgot to add the full junction output)
    - mollmerx 11y ago
      Absolutely! Also, the inclusion of non-ASCII operators harkens back to APL. Mind mind isn't yet made up on whether I like this. I anticipate code being easier to read and harder to type. Given perl5's reputation in this regard, I'm optimistic I'll find it to be an improvement.
Grue3 11y ago
In other languages this is solved by naming variables appropriately. There would be no variable "x" because it's a bad name. It would be something like coefficient-of-friction which is clearly a scalar. Having to write a symbol to denote that it's a scalar is superfluous. This explains why Perl code looks so messy, by the way. The language itself encourages poor variable naming.
- hahainternet 11y ago
  Really? my %clients vs my @clients Do you name your variables client_list .. client_dictionary? No? Then sigils aren't superfluous.
  - slavik81 11y ago
    Well, yes. When I use a list, I name them clients. When I use a hash, I specify the key. For example, clientsById.
    - hahainternet 11y ago
      With a language like Perl 6, you can happily use simply @clients or %clients and if you define those correctly, you can explicitly detail the key too.
- kbenson 11y ago
  As long as you view Perl, whether 5 or 6, in the light of C and assume it should function like C, then there will be lots of little things that seem odd and pointless. When you accept that Perl implements some things that C has no concept of whatsoever, and uses them to it's advantage throughout the language, then many of these little things start to make sense. Specifically, Perl uses context to change behavior, and lists behave differently depending on context. This is really no different than how Lisp uses parenthesis in a different way than C, except that Lisp has the benefit of being more visually distinct so people that are familiar with C and C-like semantics don't immediately assume they know what's going on an why when they see Lisp constructs. Perl is different as well, but it often looks similar enough to cause people concern before they know what they are really looking at. As for this specific example, arrays evaluated in scalar context (as opposed to list context) return the number of elements in the array. There is no array length function or method, as it's superfluous. 0+@x is the number of items in @x, and 5 < @x tests whether @x has more than 5 items, since < imposes scalar context. There are many, many places in the language where context is used to simplify operations, this is just a very simplistic example, but it should illustrate why sigils are important, as they change how operations are evaluated. Put simply, it's not possible to make a coherent criticism of Perl's use of sigils without understanding context and how it's used within the language, and factoring the benefits and drawbacks of that into your criticism. To criticize without this knowledge is to do so from ignorance (in the literal sense, not as an insult).

lmm 11y ago

> Because sigils tell you things. What if 'x' in your example is a list? Are you now checking the length of the list rather than the value? Sounds like room for a security bug to me. Only if your language is really awful. A good language shouldn't even let you run "5 < x" when x is a list, but even a mediocre one would surely at least make that error out at runtime rather than giving a nonsense answer.

hahainternet 11y ago
> Only if your language is really awful. A good language shouldn't even let you run "5 < x" when x is a list, but even a mediocre one would surely at least make that error out at runtime rather than giving a nonsense answer. It depends what you consider "Nonsense". Python for example has no reliable way to differentiate between a string and a list. Strings are iterable, but lists can't be compared with the < syntax for example. My point is simply that $x very clearly says (in Perl 6) "A single value called x" wheras @x is "A list of values called x". In python, "x" is indeterminate even at runtime. Oh, and you can declare barewords with \x for example, if you really want to, it is Perl after all.
- DonHopkins 11y ago
  What version of Python can't differentiate between a string and a list, or compare lists? Python 2.7.10 (default, Jun 10 2015, 19:42:47) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> type([1]) <type 'list'> >>> type('1') <type 'str'> >>> type(1) == type('1') False >>> [1] < [2] True >>> [2] < [1] False >>> I consider it "Nonsense" to abuse overloaded context sensitive strings of punctuation with arbitrary rules of precedence and associativity, instead of English words correctly spelled out of letters that people can look up alphabetically in a reference manual and google for tutorials to find out what they mean.
  - hahainternet 11y ago
    Sorry I should have made things more clear. I am talking about in things like function signatures. Doing something like isinstance(x, str) is discouraged and considered non-pythonic, and recently hasattr() has also been talked about. However, both strings and lists can be iterated, so assuming that this will fail is incorrect: x = "Hello" for y in x: print("{} is {}".format(y, type(y))) I asked on IRC and ultimately the only answer I got was that the most pythonic way to do things was to name functions whatever_str and whatever_list. edit: I also should have said above "lists can't be compared with strings using <". I was trying to point out Python did things potentially correctly there, but I see now it's ambiguous.
    - DonHopkins 11y ago
      If it's so important to decorate variables with unique punctuation to visually distinguish between two particular kinds of many possible types, then why don't you also decorate function calls according to whether they return lists or scalars? How should you decorate functions that return different types depending on what context they're used in? http://perlmaven.com/wantarray http://perlmaven.com/wantarray If it's so important to visually distinguish the names of scalars and arrays, then shouldn't you also be able to distinguish a string from an int, like BASIC's a$ -vs- i%? So why just distinguish lists and scalars? Why not go all the way to Hungarian Punctuation and use Unicode and Emoji characters to uniquely decorate variables for every other possible built-in and user defined type? https://en.wikipedia.org/wiki/Hungarian_notation#Relation_to_sigils https://en.wikipedia.org/wiki/Hungarian_notation#Relation_to...
      - hahainternet 11y ago
        You might be a little confused, I'm pretty sure that wantarray and the concept of functions caring about context is entirely gone in Perl 6. Now you are expected to return objects which 'do the right thing'. However, if you really want to do some of the other things you've listed they are possible to do. Perl 6's syntax can be augmented by the programs being executed. I'm honestly interested though, was I ultimately wrong above? Is there a smart way to define a function in python that can take both a single item and a list of items? In Perl 6 I'd just define a multi sub where the list form applies the single item sub for each item in the list.
mollmerx 11y ago
A "good" language might let you run "5 < x" when x is a list and return a list of booleans. This is what languages in the APL family do.
- awwaiid 11y ago
  I think Perl 6 gets to claim some APL-ness :) . Though you do sometimes need to be explicit: my @x = 3,4,5,6; say "yep" if 5 < @x.any; # yep! (5 < @x.any).perl.say # output: any(Bool::False, Bool::False, Bool::False, Bool::True) (edit: forgot to add the full junction output)
  - mollmerx 11y ago
    Absolutely! Also, the inclusion of non-ASCII operators harkens back to APL. Mind mind isn't yet made up on whether I like this. I anticipate code being easier to read and harder to type. Given perl5's reputation in this regard, I'm optimistic I'll find it to be an improvement.

Grue3 11y ago

In other languages this is solved by naming variables appropriately. There would be no variable "x" because it's a bad name. It would be something like coefficient-of-friction which is clearly a scalar. Having to write a symbol to denote that it's a scalar is superfluous. This explains why Perl code looks so messy, by the way. The language itself encourages poor variable naming.

hahainternet 11y ago
Really? my %clients vs my @clients Do you name your variables client_list .. client_dictionary? No? Then sigils aren't superfluous.
- slavik81 11y ago
  Well, yes. When I use a list, I name them clients. When I use a hash, I specify the key. For example, clientsById.
  - hahainternet 11y ago
    With a language like Perl 6, you can happily use simply @clients or %clients and if you define those correctly, you can explicitly detail the key too.
kbenson 11y ago
As long as you view Perl, whether 5 or 6, in the light of C and assume it should function like C, then there will be lots of little things that seem odd and pointless. When you accept that Perl implements some things that C has no concept of whatsoever, and uses them to it's advantage throughout the language, then many of these little things start to make sense. Specifically, Perl uses context to change behavior, and lists behave differently depending on context. This is really no different than how Lisp uses parenthesis in a different way than C, except that Lisp has the benefit of being more visually distinct so people that are familiar with C and C-like semantics don't immediately assume they know what's going on an why when they see Lisp constructs. Perl is different as well, but it often looks similar enough to cause people concern before they know what they are really looking at. As for this specific example, arrays evaluated in scalar context (as opposed to list context) return the number of elements in the array. There is no array length function or method, as it's superfluous. 0+@x is the number of items in @x, and 5 < @x tests whether @x has more than 5 items, since < imposes scalar context. There are many, many places in the language where context is used to simplify operations, this is just a very simplistic example, but it should illustrate why sigils are important, as they change how operations are evaluated. Put simply, it's not possible to make a coherent criticism of Perl's use of sigils without understanding context and how it's used within the language, and factoring the benefits and drawbacks of that into your criticism. To criticize without this knowledge is to do so from ignorance (in the literal sense, not as an insult).