An interview with Larry Wall (LinuxVoice)

Posted Jul 23, 2015 17:51 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: An interview with Larry Wall (LinuxVoice) by dvdeug
Parent article: An interview with Larry Wall (LinuxVoice)

Not really. With Python the type choices are static and you can be sure that your program prints "0.0" instead of "0" for all inputs.

An interview with Larry Wall (LinuxVoice)

Posted Jul 23, 2015 22:36 UTC (Thu) by dvdeug (guest, #10998) [Link] (48 responses)

$ python
Python 2.7.10 (default, Jul 1 2015, 10:54:53)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 0
>>> b = 0
>>> a + b
0
>>> a = 0.0
>>> a + b
0.0

I don't see how this is any different from what you're talking about with Perl. The type choices aren't static; they depend on the input types.

An interview with Larry Wall (LinuxVoice)

Posted Jul 23, 2015 22:51 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (47 responses)

I don't see how this is any different from what you're talking about with Perl. The type choices aren't static; they depend on the input types.
Python variables are typed. Not so with Perl. So:

 cat script.pl
 $a=<STDIN>;
 $b=<STDIN>;
 print $a+$b;

 echo -e "1\n2" | perl script.pl
 3
 echo -e "1.1\n2" | perl script.pl
 3.1
 echo -e "aa\n2" | perl script.pl
 2

Now let's try that with Python:

$ cat script.py
 import sys
 a = sys.stdin.readline().strip()
 b = sys.stdin.readline().strip()
 print a+b

$ echo -e "1\n2" | python script.py
 12
$ echo -e "1.1\n2" | python script.py
 1.12
$ echo -e "aa\n2" | python script.py
 aa2

Everything is _predictable_. If you want your input to be treated as floats - you need to spell it out explicitly:

$ cat script.py
 import sys
 a = float(sys.stdin.readline().strip())
 b = float(sys.stdin.readline().strip())
 print a+b

$ echo -e "1\n2" | python script.py
 3.0
$ echo -e "1.1\n2" | python script.py
 3.1
$ echo -e "aa\n2" | python script.py
 Traceback (most recent call last):
   File "script.py", line 2, in <module>
     a = float(sys.stdin.readline().strip())
   ValueError: could not convert string to float: aa

The Perl's way is simply madness incarnate, and instead of fixing it, they are making it even more complicated with lots of potential for mischief.

An interview with Larry Wall (LinuxVoice)

Posted Jul 23, 2015 23:42 UTC (Thu) by dvdeug (guest, #10998) [Link] (7 responses)

"Python variables are typed. Not so with Perl."

I don't know what you meant by that; it is not true for the two obvious meanings. Untyped could mean that variables at compile time don't have defined types, as is true in both Python and Perl, or it could mean that values stored in variables don't have types at runtime or compile time, which is true for assembly languages and BLISS, but by no means Python and Perl.

Yes, Perl implicitly converts strings to either integers or floats before feeding it to the "+" operator, whereas Python doesn't. Python is hardly predictable, though; if your function takes two arguments and adds them, it could be adding integers or floats or any thing that overloads "+".

The big difference I see is the silent conversion of strings, and I suspect that's part of a bigger pattern of silent conversions in Perl that Python does have. But if you're dealing with just numbers, I don't see the Python model as being all that different from the Perl model.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 6:18 UTC (Fri) by raiph (guest, #89283) [Link]

> Untyped could mean that variables at compile time don't have defined types, as is true in both Python and Perl

In Perl 6, variables are a kind of container. Containers in Perl 6 have a container type. For example, by default, an `@array` variable has an `Array` container type:

my @foo;
say @foo.WHAT; # (Array)

Container types have an 'of' type, the type of the things contained in the container. So one might have an `Array of Int`.

my Int @bar;
say @bar.WHAT # (Array[Int])

> or it could mean that values stored in variables don't have types at runtime or compile time

Values have a static type in Perl 6.

say 42.WHAT # (Int)

Binding of values to containers can have additional dynamic constraints, used to select or reject arguments based on their run-time value not just their compile time type.

subset NameOfFileThatExists of Str where *.IO.e;
multi sub bar (NameOfFileThatExists $name) { ... }
multi sub bar ($doesntexist) { ... }
bar("foo")

"file".IO.e returns True if "file" exists in the current directory. So the bar("foo") call will dispatch to the first bar if "foo" exists and to the second bar if not.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 8:26 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> I don't know what you meant by that; it is not true for the two obvious meanings. Untyped could mean that variables at compile time don't have defined types, as is true in both Python and Perl, or it could mean that values stored in variables don't have types at runtime or compile time, which is true for assembly languages and BLISS, but by no means Python and Perl.
There's a small but crucial difference - Python does not do any guessing when you read a variable from an external source. And there's no heuristics for incompatible types - you simply get errors.

Actually, I got bitten by it today. As if on cue, someone used "==" to compare numeric values in Perl, and it even worked fine. That is, until someone started using fractional values as an input.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 8:50 UTC (Fri) by dvdeug (guest, #10998) [Link] (4 responses)

Perl did not guess their format when it read them in; it read them in as strings. You implicitly told Perl to convert them to numbers when you used a numeric operator on them; if you were concerned that you knew exactly what type they would be converted to, you could have converted them yourself. There are of course heuristics for incompatible types in Python, as I demonstrated by doing a + b with a floating point and b an integer; the only question is how incompatible and in what ways.

If you want to argue that strings should not silently convert to numbers, that's an argument. It seems far away from any discussion of rational numbers in Perl 6.

"use warnings" would tell you if you use "==" on strings. There's shared responsibility when you screw up by using a questionable feature in a language that the system you use has warnings on.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 9:34 UTC (Fri) by rsidd (subscriber, #2582) [Link] (1 responses)

If you want to argue that strings should not silently convert to numbers, that's an argument. It seems far away from any discussion of rational numbers in Perl 6.

Floats should not silently convert to rationals. And apparently this doesn't even require an operation. Merely writing "3.14159" makes perl6 treat it as 314159/100000. It's hard to imagine that this has security implications, though. Just needless complexity and inefficiency.

What happens when interfacing with a C library (say GSL)? Are these "rationals" then converted into floats before calling? And are the return values converted back to "rationals"?

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 19:19 UTC (Fri) by raiph (guest, #89283) [Link]

> Floats should not silently convert to rationals.

I can't imagine any language doing that. If your comment is aimed at Perl (5 or 6) then I think this is another manifestation of overall confusion about decimal fractions.

https://en.wikipedia.org/wiki/Decimal#Decimal_fractions

> Merely writing "3.14159" makes perl6 treat it as 314159/100000.

Just for emphasis: https://en.wikipedia.org/wiki/Decimal#Decimal_fractions

Hopefully you'll spend a few seconds reading this wikipedia link and you'll go "ahhh". :)

> What happens when interfacing with a C library (say GSL)?

One uses explicit typing in the signature (the list of parameters) of the Perl 6 functions that call the C functions. For example:

sub add(int32, int32) returns int32 is native("libcalculator") { * }

means that one must call the `add` function with two native 32 bit ints.

See http://doc.perl6.org/language/nativecall#Passing_and_Retu... for some more details.

> Are these "rationals" then converted into floats before calling?

They can be. It's controlled by explicit types and explicit type coercions in the signature. For example:

sub foo(Num(Rat), Num) ...

would be callable with:

foo(13/17, 26e3)

> And are the return values converted back to "rationals"?

Rakudo does not currently support signature based coercion of the return value; I don't know whether there's a plan to one day support that.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 20:43 UTC (Fri) by raiph (guest, #89283) [Link] (1 responses)

> Perl did not guess their format when it read them in; it read them in as strings.

Perl 6 lets users directly specify input types for command line args:

perl6 -e 'sub MAIN (Int $int, Rat $rat, $string) { .print and "\t".print and .WHAT.say for $int, $rat, $string }' 42 2 Foo

Usage:
-e '...' <int> <rat> <string>

perl6 -e 'sub MAIN (Int $int, Rat $rat, $string) { .say and .WHAT.say for $int, $rat, $string }' 42 2/10 Foo

42
(Int+{orig-string[Str]})
2/10
(Rat+{orig-string[Str]})
Foo
(Str)

Perl 6 displays an automatically generated usage message until you pass arguments that correspond to the specified types.

When you do, it stores the typed values and the original string values so you can use either as appropriate to your needs.

The design docs suggest a similar mechanism is supposed to be applicable to input other than command line args but Rakudo doesn't support that yet afaik.

> You implicitly told Perl to convert them to numbers when you used a numeric operator on them

A nit: I'd say that treating operands of the `+` operator as numbers is explicit, not implicit.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 22:36 UTC (Fri) by raiph (guest, #89283) [Link]

> A nit: I'd say that treating operands of the `+` operator as numbers is explicit, not implicit.

And, if I did, I'd be wrong.

https://en.wikipedia.org/wiki/Type_conversion

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 0:26 UTC (Fri) by mchapman (subscriber, #66589) [Link] (2 responses)

> Everything is _predictable_.

You're making a false comparison there. It would be equally predictable in your Perl code had it used string concatenation instead.

I don't see a big difference between what Perl and Python are doing here. In both cases, the programmer has to know what kinds of values they are working with. With Python that's encoded in the value's type; with Perl that's encoded in the value itself. But either way, if you're taking in a string from the outside world and want to use it in your program you still need to *validate* that string -- in Perl you might use Scalar::Util::looks_like_number. Once validated, the way that value's type is encoded seems to be largely irrelevant.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 8:21 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> You're making a false comparison there. It would be equally predictable in your Perl code had it used string concatenation instead.
Who said that I want concatenation? I simply want a behavior that doesn't depend on the exact details of input (which very well might be malicious).

> I don't see a big difference between what Perl and Python are doing here. In both cases, the programmer has to know what kinds of values they are working with. With Python that's encoded in the value's type; with Perl that's encoded in the value itself.
There's a fundamental difference here - with Perl6's braindead number treatment, $a + $b can mean DIFFERENT things for different numbers.

Really.

> Scalar::Util::looks_like_number.
Which number? Rational, float, integer, bigint?

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 11:46 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> Who said that I want concatenation?

Your Python code asked for it. It seems reasonable to expect that if you're comparing two code snippets you wanted them to do roughly the same thing.

> There's a fundamental difference here - with Perl6's braindead number treatment, $a + $b can mean DIFFERENT things for different numbers.

When does it not mean "add them together and produce a result that is the closest representable value to the answer"?

I have only passing familiarity with Perl 6, but I would be totally surprised if this were ever not the case.

But in Perl 5, whether a particular scalar should be treated as a number or a string depends only on the operator or builtin doing the interpretation. The + operator, for instance, interprets whatever you give it as a number.

There are rules as to how this interpretation is done, and those rules are consistently applied. It seems that you think those rules aren't legitimate because they are based on the value, rather than some "type" associated with that value. If that's actually the case, then I'm afraid no explanation is likely to satisfy you. That's simply how Perl works.

> Which number? Rational, float, integer, bigint?

Again, I refer to Perl 5 only.

Scalar::Util::looks_like_number returns a true value iff Perl thinks the scalar "looks like a number". It's really just as simple as that. "Looks like a number" is quite well-defined by Perl. It has nothing to do with "types", because Perl doesn't have types in that sense.

In practice, something that "looks like a number" can be used as if it actually were an integer or a float, assuming Perl actually had such things.

Why does it not matter whether it's an integer or a float? Simple: that only matters when you use the value. The integer-ness or float-ness of the value is not intrinsic to the value itself. If you use it in an operation that demands a float, it will act like a float. If you use it in an operation that demands an integer, it will act like an integer. Same for strings and booleans. The value isn't any of these, but it will happily act like one if you ask it to.

I really hope this explanation makes sense to you, even if you don't happen to like it. I'm out of ways to explain it!

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 0:29 UTC (Fri) by mrons (subscriber, #1751) [Link] (9 responses)

I don't see your point here. The perl code is predictable.

You used the + operator so in "$a+$b" $a and $b are to be treated as numbers.

If you wanted $a and $b to be treated as strings, you would use "$a . $b"

If the python code, when I look at "a+b", I have to examine the rest of the code to determine what "a+b" means (addition or concatenation).

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 8:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

> I don't see your point here. The perl code is predictable.
It's not.

> You used the + operator so in "$a+$b" $a and $b are to be treated as numbers.
Which numbers? Rationals, floats, doubles, integers, bigints?

And the answer, of course, is ANY OF THEM (depending on the Moon's current phase and Mars's relative position to it).

> If you wanted $a and $b to be treated as strings, you would use "$a . $b"
BTW, the fact that "+" happily works with strings without any errors is another braindead idea.

An interview with Larry Wall (LinuxVoice)

Posted Jul 26, 2015 16:17 UTC (Sun) by flussence (guest, #85566) [Link] (7 responses)

> BTW, the fact that "+" happily works with strings without any errors is another braindead idea.

Perl 5 has errors for that. You can enable them by typing "-w" on the command line. They're off by default; little things like that are why code from 20 years ago still runs correctly in it unmodified.

I'd say any language where I can't be sure of the return type of "a + b" at a glance is more brain damaged.

An interview with Larry Wall (LinuxVoice)

Posted Jul 26, 2015 18:57 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> I'd say any language where I can't be sure of the return type of "a + b" at a glance is more brain damaged.
Ah, so you do agree that not being able to tell what comes out of "a+b" is braindamaged. Like not being able to tell whether it's float, rational or bigint.

An interview with Larry Wall (LinuxVoice)

Posted Jul 26, 2015 20:06 UTC (Sun) by dvdeug (guest, #10998) [Link] (1 responses)

In Python, "a + b" could return literally any type, any value. All it takes is the appropriate "def __add__ (a, b): return value" in some class somewhere. That being "brain damaged" is an opinion I'm not going to get into, but it's not different between Perl and Python.

An interview with Larry Wall (LinuxVoice)

Posted Jul 26, 2015 23:02 UTC (Sun) by anselm (subscriber, #2796) [Link]

In Python, "a + b" could return literally any type, any value. All it takes is the appropriate "def __add__ (a, b): return value" in some class somewhere.

That applies to Perl, too – see “perldoc overload”.

An interview with Larry Wall (LinuxVoice)

Posted Jul 27, 2015 0:03 UTC (Mon) by mchapman (subscriber, #66589) [Link] (1 responses)

> Like not being able to tell whether it's float, rational or bigint.

Perl guarantees it's a scalar. If the result is an integer, the scalar will "look like" an integer. If the result is a floating-point value, the scalar will "look like" an integer.

"Looks like" in Perl is as strong a guarantee as "has a type of" in Python or some other languages. I would like to think you are merely unwilling to acknowledge this idea, not incapable of it. Either way though, I don't think there's anything more I have to say on the matter.

An interview with Larry Wall (LinuxVoice)

Posted Jul 27, 2015 0:06 UTC (Mon) by mchapman (subscriber, #66589) [Link]

> ... the scalar will "look like" an integer.

And obviously that should be "... floating-point value".

An interview with Larry Wall (LinuxVoice)

Posted Jul 27, 2015 17:08 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

> Like not being able to tell whether it's float, rational or bigint.

You're almost getting it now, yes. Don't you just hate it when mathematical operators are commutative and return *numbers*? How dare they.

Maybe I should have used a more extreme example: "(a + b) * a / b". Does that return a number, a string, or a runtime error?

An interview with Larry Wall (LinuxVoice)

Posted Jul 27, 2015 17:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

>Don't you just hate it when mathematical operators are commutative and return *numbers*?
WHICH numbers? They behave differently.

> Maybe I should have used a more extreme example: "(a + b) * a / b". Does that return a number, a string, or a runtime error?
In Python it's either a floating number or a runtime error (barring bizarre operator overloads).

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 9:26 UTC (Fri) by rschroev (subscriber, #4164) [Link]

Python variables are typed.

Maybe close enough for the discussion, but not exactly right. For the sake of correctness: Python variables (names really) aren't typed; Python values are.

See e.g. Python Objects for an explanation how Python objects work.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 11:00 UTC (Fri) by raiph (guest, #89283) [Link] (24 responses)

> Python variables are typed.

Python variables are not typed.

> Not so with Perl.

Perl 6 variables are typed.

--------

A Perl 6 equivalent of your examples:

echo -e "1\n2" | perl6 -e 'say get() + get()'
3
echo -e "1.1\n2" | perl6 -e 'say get() + get()'
3.1
echo -e "aa\n2" | perl6 -e 'say get() + get()'
Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏aa' (indicated by ⏏)
in block <unit> at -e:1

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 11:14 UTC (Fri) by rsidd (subscriber, #2582) [Link] (16 responses)

Cyberax's point was the implicit conversion of strings to numbers, which occurs via the "+" operator. Apparently what has changed in perl6 is that the "+" operator no longer works on strings. On the other hand, if you use "~" the same input gets treated as strings. The implicit conversion is not only for values from stdin either, it could be any string. So you have
---
$ perl6 -e 'say "2" ~ "2" '
22
$ perl6 -e 'say "2" + "2"'
4
---

Why is this a good thing? Why isn't it telling me that I can't use the "+" operator on strings?

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 11:48 UTC (Fri) by mchapman (subscriber, #66589) [Link] (14 responses)

> Why is this a good thing? Why isn't it telling me that I can't use the "+" operator on strings?

Why should it? You asked for numeric addition; you got numeric addition. Why would you want it not do what you asked for?

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 12:03 UTC (Fri) by rsidd (subscriber, #2582) [Link] (9 responses)

Because it may be a bug? Oversmartness is bad whether it's pwrl or MS Excel. When I try to add strings the compiler/interpreter should tell me and not silently change the type! There is a reason programs in Haskell tend to run correctly the first time.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 12:28 UTC (Fri) by mchapman (subscriber, #66589) [Link] (1 responses)

> Because it may be a bug?

It could be, yes. All code can be wrong.

I'm sure Perl 6 has a way to say "test that $a and $b are both Ints, throw an exception if they're not, otherwise add them together and, if the result can be stored in an Int, return that result, else throw an exception". You'll probably find it's a few more characters than + though.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 22:19 UTC (Fri) by raiph (guest, #89283) [Link]

Oh, I'm sure there are lots of ways. We're talking about Perl here. :)

The first thing I came up with:

($a,$b) ~~ :(Int, Int) or fail; $a + $b;

The `:(...)` bit is a literal signature, exactly like the ones that appear in function definitions. The `~~` "smartmatch" operator, with these operands, does a trial bind of the argument list on its left with the signature on its right.

I skipped testing the result because an Int can store arbitrarily large integers, and if all of RAM was consumed by a truly vast integer, an exception would (should) be raised by lower levels of the stack.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 21:21 UTC (Fri) by dvdeug (guest, #10998) [Link] (6 responses)

As the old quip goes "If you want Haskell, you know where to find it."* It really seems out of place in a subthread comparing Python and Perl.

* I found that frustrating in the early 90s, as C was widely available and PL/I was not.

An interview with Larry Wall (LinuxVoice)

Posted Jul 25, 2015 4:12 UTC (Sat) by rsidd (subscriber, #2582) [Link] (5 responses)

Python is heavily influenced by Haskell (indentation and list-comprehensions are two obvious examples). So it's not irrelevant.

An interview with Larry Wall (LinuxVoice)

Posted Jul 25, 2015 5:02 UTC (Sat) by dvdeug (guest, #10998) [Link] (4 responses)

Haskell's first release was in 1990; Python was created in 1990 and released in 1991. So it doesn't seem likely that indentation or any other early feature was influenced by Haskell. The type system, in particular, is very unHaskell. In these features, Perl and Python differ pretty marginally.

An interview with Larry Wall (LinuxVoice)

Posted Jul 25, 2015 11:56 UTC (Sat) by anselm (subscriber, #2796) [Link] (3 responses)

It's pretty safe to say that Python's use of indentation for structure was not a Haskell influence. This is fairly obvious considering that the ABC programming language, which Guido van Rossum worked on at CWI before starting Python, also used indentation for structure. ABC had been around for more than a decade before Python was released.

List comprehensions, OTOH, were only added to Python way later, namely with version 2.0, which was released in 2000. It would not be entirely unreasonable to consider them influenced by Haskell.

As far as the type systems of Perl and Python are concerned, I think there are considerable differences. The observation that Perl doesn't really differentiate between numbers and strings, calling them “scalars”, while in Python strings are a special case of a (“non-scalar”) container type that also includes tuples and lists would be one's first clue that the type systems of Perl and Python are not really very similar at all.

An interview with Larry Wall (LinuxVoice)

Posted Jul 25, 2015 12:37 UTC (Sat) by dvdeug (guest, #10998) [Link] (2 responses)

List comprehensions are listed as being derived from Haskell by one of the sources linked from Wikipedia. It's not that surprising a claim.

"Considerable" is in the eye of the beholder. When compared to Haskell, they look quite similar, both dynamic systems with heavy OO mixture and no type inference.

An interview with Larry Wall (LinuxVoice)

Posted Jul 26, 2015 3:19 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

> no type inference

Maybe I'm just not parsing your statement properly, but Haskell does all kinds of type inference…

An interview with Larry Wall (LinuxVoice)

Posted Jul 26, 2015 18:47 UTC (Sun) by nix (subscriber, #2304) [Link]

Let's expand that sentence:

When compared to Haskell, Perl and Python look quite similar, both dynamic systems with heavy OO mixture and no type inference.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 15:59 UTC (Fri) by anselm (subscriber, #2796) [Link] (3 responses)

The problem is really that, as far as the “+” operator in Perl (5, at least – I haven't looked at Perl 6) is concerned, "123foobar" or for that matter "bazquux" are bona-fide numbers and therefore perfectly eligible to be added numerically. This tends to throw people off at times when instead they expect their compiler or interpreter to complain about a type mismatch.

Having said that, in Perl you wouldn't expect “+” to do string concatenation because that operator is called “.”. Now as far as the “.” operator in Perl 5 is concerned, 123 and 3.1415 are bona-fide strings and therefore perfectly eligible to be concatenated.

I teach Perl classes (among other subjects) for a living and in my considered opinion it is not a simple language to teach. Perl's idiosyncratic approach to evaluating expressions is something that many people find difficult to get to grips with, and previous experience with saner languages doesn't really seem to help a lot. It's not that what Perl does is illogical – it does have a certain twisted logic to it –, it's just that it's strange. Also, to really appreciate Perl you need to know C, the shell, sed, and awk, and few people nowadays do (at least the ones who end up in my classes generally don't). These days I prefer teaching Python because for all its shortcomings it is much easier to explain to people.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 23:40 UTC (Fri) by raiph (guest, #89283) [Link] (2 responses)

> [treating 123apples as a number] tends to throw people off at times when instead they expect their compiler or interpreter to complain about a type mismatch.

Fwiw, Perl 6 no longer accepts "baz" as a number, insisting that a string must start with decimal digits if it's to successfully coerce to a number.

There's a saying on #perl6 that every DWIM ("Do What I Mean") has a corresponding WAT. One has to weigh the supposedly positive value of DWIMs against the negative value of their WAT(s).

I hear that, in your opinion, the WAT is not worth the DWIM, especially when it comes time to teach the language.

I'm curious if you can see and thus express any significant value to the DWIM even while it's not enough to counter the WAT?

> I teach Perl classes (among other subjects) for a living and in my considered opinion it is not a simple language to teach.

I'm curious what your student mix is between non-programmers learning programming by learning Perl and programmers in other languages learning Perl.

There are a bunch of programming teachers in the Perl community and I've watched their input help shape Perl 6, which was in part about cleaning up the language and making easy things easier. Perhaps you yourself contributed.

The upshot is that one can get a whole lot done with truly trivial code like:

say lines

> Also, to really appreciate Perl you need to know C, the shell, sed, and awk

Fwiw I don't think that applies to Perl 6.

An interview with Larry Wall (LinuxVoice)

Posted Jul 25, 2015 0:15 UTC (Sat) by anselm (subscriber, #2796) [Link] (1 responses)

I'm curious what your student mix is between non-programmers learning programming by learning Perl and programmers in other languages learning Perl.

Most of the people I've taught Perl to over the years were programmers with experience in other languages, ranging from Visual BASIC to things like C++ or Java. These people have the advantage that they already know about things like variables, conditionals, and loops. Stuff like $foo[1] vs. @foo[1] tends to confuse them, as does scalar context vs. list context in general. As I said, this stuff has its own twisted logic behind it, but from a language-learner POV it wasn't the smartest idea to design the language that way.

say lines

I'm getting the distinct impression that Perl 6 should not have been called Perl. If it ever actually comes around it will create lots of confusion among our customers because they will have to figure out whether they want us to teach Perl 5 or Perl 6.

In any case, demand for Perl classes hereabouts has dwindled to near-zero anyway. I'm teaching way more Python these days than Perl, and I can't even say I'm sorry. I was a Perl programmer in the late 1980s when we were waiting for the first (pink) Camel book to come out, and have followed the language for a very long time – including, e.g., consulting with O'Reilly on the German translation of the Perl 5 version of Programming Perl – but I don't use Perl for new projects anymore. Not if the code will take more than one screenful of lines, anyway.

An interview with Larry Wall (LinuxVoice)

Posted Jul 25, 2015 3:55 UTC (Sat) by raiph (guest, #89283) [Link]

> $foo[1] vs. @foo[1] tends to confuse them

Yeah. That's gone in Perl 6:

my @foo = 0,1,2,3; say @foo[1];
1

> scalar context vs. list context

Yeah. Context is still very much a thing in Perl 6.

> I'm getting the distinct impression that Perl 6 should not have been called Perl.

Right. I can see it being renamed sometime in the next 5 years, with the leading candidate new name being Camelia. But Larry has refused to even consider that prior to getting a 6.0.0 shipped (which is currently scheduled for this Christmas).

> If it ever actually comes around it will create lots of confusion among our customers because they will have to figure out whether they want us to teach Perl 5 or Perl 6.

I'm sure it's going to put in enough of an appearance globally to at least cause confusion. :)

> In any case, demand for Perl classes hereabouts has dwindled to near-zero anyway.

Where's here?

> I'm teaching way more Python these days than Perl, and I can't even say I'm sorry.

Sure. I like the Perl 5 community, and love Perl 6, but when I've eased newbies into scripting in the last few years I've started with Python, not Perl.

> I don't use Perl for new projects anymore. Not if the code will take more than one screenful of lines, anyway.

I think the same is true of a lot of folk.

The Perl 6 design is clearly aiming at programming-in-the-large just as much as it is scripting. But the only semi-serious test of its characteristics in that regard that I'm aware of is the compiler toolchain. So it seems like the jury is going to still be out for at least another few years on that.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 21:52 UTC (Fri) by raiph (guest, #89283) [Link]

> Apparently what has changed in perl6 is that the "+" operator no longer works on strings.

Sorry, my previous comment may have been confusing. The default Perl 6 number parsing now rejects a string that does not start with a decimal number.

> $ perl6 -e 'say "2" ~ "2" '
> 22
> $ perl6 -e 'say "2" + "2"'
> 4

> Why is this a good thing?

There are several things I can do with your question. I can consider it a simple, well-formed question and process it that way. I can consider it potentially dangerous, in part or whole, and process it on my own terms, picking out what's non-dangerous about the question and deal with that bit. Or I could just reject it as not something I am willing to process.

For subjective input, Python tends toward the third option, to keep itself and its users sane in their world. Perl tends towards the middle, to keep itself and its users sane in theirs.

> Why isn't it telling me that I can't use the "+" operator on strings?

Well, first, because you can. :)

If you don't want that you can stop it in a given lexical scope:

multi sub infix:<+> (Str, Any) { fail "nope" }
say "2" + 4 # dies with "nope" message

One of the design assumptions in Perl 6 is that companies, teams and individual developers, will want to tighten or loosen strictness to suit their own view of what's dangerous, what's ill formed. Perl 6 makes it simple to bundle such policies in to single `use` statements that apply lexically. And these can be added to the ecosystem so that those with a similar philosophical mindset for a particular use-case can easily follow the same policies.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 11:26 UTC (Fri) by rsidd (subscriber, #2582) [Link] (6 responses)

> Python variables are not typed.

They're typed. The following is an example of how it should work.

>>> a = "2"
>>> type(a)
<type 'str'>
>>> from fractions import Fraction as Fr
>>> a = Fr(3,4)
>>> type(a)
<class 'fractions.Fraction'>
>>> b = 2.5
>>> type(b)
<type 'float'>
>>> c = a*b
>>> print c
1.875
>>> type(c)
<type 'float'>
>>> d = Fr(4,5)
>>> e = a*d
>>> type(e)
<class 'fractions.Fraction'>
>>> print e
3/5

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 11:55 UTC (Fri) by mchapman (subscriber, #66589) [Link] (5 responses)

> They're typed.

No, they're not. Your code is printing out the types of the *values* inside those variables.

Python quite happily lets you do:

>>> a = 4
>>> a = "forty two"

If these Python variables were typed, then the second assignment would throw an exception. It doesn't.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 12:11 UTC (Fri) by rsidd (subscriber, #2582) [Link] (4 responses)

You're changing the binding: the new a is different from the old a. You can do that in any language, perl, C, even haskell. You're going to tell me haskell variables aren't typed?

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 12:24 UTC (Fri) by mchapman (subscriber, #66589) [Link] (2 responses)

> You're changing the binding: the new a is different from the old a.

OK, this just sounds like a problem of nomenclature. When I think of "variable", I think of "the symbol typed by the programmer", not "the value to which that symbol is currently referring".

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 16:00 UTC (Fri) by peter-b (guest, #66996) [Link] (1 responses)

Well, to be perfectly pedantic, there are three things involved here:

1. The symbol
2. The slot bound to the symbol
3. The value stored in the slot

Most programming languages attach type annotations to (2) or (3).

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 16:15 UTC (Fri) by anselm (subscriber, #2796) [Link]

As far as Python is concerned, it is counterproductive to think of variables in terms of “slots” that can have “values” stored in them because that isn't really how the language works. Names in Python are really more like sticky labels attached to objects. If you stick your label on a new object, the type of the previous object you stuck it on doesn't matter, but as long as the label sticks to the same object, the type of that object determines what you get to do with it. Also, objects can have more than one label sticking to them.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 21:46 UTC (Fri) by dvdeug (guest, #10998) [Link]

In C, if you run across

r_t funct (a_t a, b_t b) {return a + b;}

a, b and the return value all have specific types known at compile time and invariant at runtime. On the other hand, you can pass values of arbitrary type to

def add (a, b): return a + b

and a and b and the return value have no types at compile time, and can have a number of different types during the runtime of the program. There's a big difference there.

And it seems weird to say that Python variables are typed in this sense; it's like bragging that Python supports lowercase characters, except that way more programming language (implementations) have had problems with lowercase characters then have not had typed variables in this sense. As far as my memory will reach, only BLISS of all the non-assembly languages has not had types attached to their values either at compile or runtime.