3 ms·

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 coeffici

by 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).

by Grue3 11y ago

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).