4 ms·

>any two valid identifiers may be joined with a single ' to form a longer identifier Oh no.

kstrauser 11y ago
It gets worse. "Hey, let's double down on weak typing!": http://examples.perl6.org/categories/cookbook/01strings/01-00introduction.html#Strings_as_numbers http://examples.perl6.org/categories/cookbook/01strings/01-0... print +"" ; # a num-ified empty string evaluates as 0 print "1" + 1 ; # 2 The opportunity for insidious bugs (for the benefit of not having to type 'int("1") + 1' those times when you really need to do that) is a terrible tradeoff, in my opinion. In before "but Python...!". Python is strongly typed. >>> "1" + 1 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot concatenate 'str' and 'int' objects >>> 1 + "1" Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str'
- sp332 11y ago
  print "1" + 1 ; # 2 This isn't new, is it? '+' is for addition, '.' is for concatenation.
  - kbenson 11y ago
    In Perl 5, yes. In Perl 6, ~ is for concatenation, '.' is for methods.
- kbenson 11y ago
  This is not weak typing. Perl (both 5 and 6) use operators to define type context. It's entirely unambiguous whether you want to add something or concatenate strings because they are different operators. "1" + "1" # 2 "1" . "1" # 11 (~ to concatenate in Perl 6) 1 + 1 # 2 1 . 1 # 11 When you perform a string operation on a numeric type, it stringifies the number, when you do a numeric operation on a string, it numerifies the string (and warns if it can't be cleanly done). This isn't a typing problem, this is a commenting on language without actually knowing how it works problem. But that's nothing new, people have been doing that to Perl for a long time now.
  - kstrauser 11y ago
    Ah, sorry. Despite having used Perl for years, I'd forgotten how much emphasis it puts on concepts that invoke a high cognitive load.
    - Dylan16807 11y ago
      There is nothing "high cognitive load" about having different operators for addition and concatenation. I think it's simpler.
      - ionforce 11y ago
        Who "adds two strings"? You're 1) converting the strings to ints 2) adding the ints. The possibility of confusion is the part that is already complex.
        nikatwork 11y ago
        > Who "adds two strings"? $timeText = $systemHours . ':' . $systemMinutes; vs $durationTimer = $userInputHours + 1; There ya go.
    - kbenson 11y ago
      On the contrary, I think there is a higher cognitive load in having to reason about the behavior that results from using the + operator between two types when their types may differ. e.g., the Wat talk[1]. To be clear, there is a cognitive load to both. One is based on keeping correct type of the variables you are using with the + operator, the other is knowing that numeric addition and string concatenation are not the same thing, and have different operators. Since string concatenation and numeric addition really aren't the same thing, and don't share the same properties, I prefer the different operators. 1: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
      - btilly 11y ago
        On the contrary, I think there is a higher cognitive load in having to reason about the behavior that results from using the + operator between two types when their types may differ. e.g., the Wat talk[1]. The simple fact that you run out of operators limits how many types can usefully exist. In Python you use + quite reasonably for integers, floats, strings, and arrays. By contrast raw Perl has equivalents only for numbers and strings, and is unable to distinguish between integers and floats. That is why Perl doesn't do exact arithmetic with large integers. But, you say, Perl allows you to use bigint? Well, yes. And that is internally implemented with the magic of overload. Using that you can have any number of types which overload + to do what they want, and you have all of the same issues as arose in the Wat talk. It took a long time for me to be convinced, but I am now convinced that typed variables and untyped operators (like Ruby and Python do) is strictly better in practice than untyped variables and typed operators (like Perl does by default). And as for the complexity, it is just something you have to live with. Want evidence? https://mitpress.mit.edu/sicp/full-text/sicp/book/node48.html https://mitpress.mit.edu/sicp/full-text/sicp/book/node48.htm... discussed this exact problem some 30 years ago. I do not believe that the intrinsic problem is being solved any better today than then.
- dragonwriter 11y ago
  Honestly, I think the Perl way is clearer than the Python way: Perl: unary + is "convert to number", binary + is "convert operands to numbers and add". This is clear and consistent. String concatenation uses a different operator completely. Python: binary + is string concatenation if the left operand is a string, and numeric addition if the left operator is a number. It fails at runtime if the right operator is inconsistent with the operation specified by the combination of the operator and the left operand.
- baudehlo 11y ago
  That's not weak typing. That's type coercion. You're thinking of JavaScript in this particular issue.

It gets worse. "Hey, let's double down on weak typing!": http://examples.perl6.org/categories/cookbook/01strings/01-00introduction.html#Strings_as_numbers http://examples.perl6.org/categories/cookbook/01strings/01-0... print +"" ; # a num-ified empty string evaluates as 0 print "1" + 1 ; # 2 The opportunity for insidious bugs (for the benefit of not having to type 'int("1") + 1' those times when you really need to do that) is a terrible tradeoff, in my opinion. In before "but Python...!". Python is strongly typed. >>> "1" + 1 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot concatenate 'str' and 'int' objects >>> 1 + "1" Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str'

sp332 11y ago
print "1" + 1 ; # 2 This isn't new, is it? '+' is for addition, '.' is for concatenation.
- kbenson 11y ago
  In Perl 5, yes. In Perl 6, ~ is for concatenation, '.' is for methods.
kbenson 11y ago
This is not weak typing. Perl (both 5 and 6) use operators to define type context. It's entirely unambiguous whether you want to add something or concatenate strings because they are different operators. "1" + "1" # 2 "1" . "1" # 11 (~ to concatenate in Perl 6) 1 + 1 # 2 1 . 1 # 11 When you perform a string operation on a numeric type, it stringifies the number, when you do a numeric operation on a string, it numerifies the string (and warns if it can't be cleanly done). This isn't a typing problem, this is a commenting on language without actually knowing how it works problem. But that's nothing new, people have been doing that to Perl for a long time now.
- kstrauser 11y ago
  Ah, sorry. Despite having used Perl for years, I'd forgotten how much emphasis it puts on concepts that invoke a high cognitive load.
  - Dylan16807 11y ago
    There is nothing "high cognitive load" about having different operators for addition and concatenation. I think it's simpler.
    - ionforce 11y ago
      Who "adds two strings"? You're 1) converting the strings to ints 2) adding the ints. The possibility of confusion is the part that is already complex.
      - nikatwork 11y ago
        > Who "adds two strings"? $timeText = $systemHours . ':' . $systemMinutes; vs $durationTimer = $userInputHours + 1; There ya go.
  - kbenson 11y ago
    On the contrary, I think there is a higher cognitive load in having to reason about the behavior that results from using the + operator between two types when their types may differ. e.g., the Wat talk[1]. To be clear, there is a cognitive load to both. One is based on keeping correct type of the variables you are using with the + operator, the other is knowing that numeric addition and string concatenation are not the same thing, and have different operators. Since string concatenation and numeric addition really aren't the same thing, and don't share the same properties, I prefer the different operators. 1: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
    - btilly 11y ago
      On the contrary, I think there is a higher cognitive load in having to reason about the behavior that results from using the + operator between two types when their types may differ. e.g., the Wat talk[1]. The simple fact that you run out of operators limits how many types can usefully exist. In Python you use + quite reasonably for integers, floats, strings, and arrays. By contrast raw Perl has equivalents only for numbers and strings, and is unable to distinguish between integers and floats. That is why Perl doesn't do exact arithmetic with large integers. But, you say, Perl allows you to use bigint? Well, yes. And that is internally implemented with the magic of overload. Using that you can have any number of types which overload + to do what they want, and you have all of the same issues as arose in the Wat talk. It took a long time for me to be convinced, but I am now convinced that typed variables and untyped operators (like Ruby and Python do) is strictly better in practice than untyped variables and typed operators (like Perl does by default). And as for the complexity, it is just something you have to live with. Want evidence? https://mitpress.mit.edu/sicp/full-text/sicp/book/node48.html https://mitpress.mit.edu/sicp/full-text/sicp/book/node48.htm... discussed this exact problem some 30 years ago. I do not believe that the intrinsic problem is being solved any better today than then.
dragonwriter 11y ago
Honestly, I think the Perl way is clearer than the Python way: Perl: unary + is "convert to number", binary + is "convert operands to numbers and add". This is clear and consistent. String concatenation uses a different operator completely. Python: binary + is string concatenation if the left operand is a string, and numeric addition if the left operator is a number. It fails at runtime if the right operator is inconsistent with the operation specified by the combination of the operator and the left operand.
baudehlo 11y ago
That's not weak typing. That's type coercion. You're thinking of JavaScript in this particular issue.