LWN: Comments on "An interview with Larry Wall (LinuxVoice)"

An interview with Larry Wall (LinuxVoice)

flussence — Thu, 31 Dec 2020 15:07:33 +0000

Writing it as 0.00001234e0 also works. Spelling out exponents feels odd at first, but it turns out the same trick works in C.

An interview with Larry Wall (LinuxVoice)

raiph — Mon, 28 Dec 2020 19:59:14 +0000

2020 update of my own comment. One can now write type conversions like so:

my Num() $bar = 0.00001234

which will store a float in $bar by converting the rational 0.00001234.

An interview with Larry Wall (LinuxVoice)

dvdeug — Tue, 28 Jul 2015 09:06:54 +0000

As long as you're writing 1.61803398, I don't see any justification for saying "If I wanted a fraction I'd write a fraction." A float is a fraction with a numerator between 0 and 2^24 and denominator of 2^24, times a power of 2. 1.61803398 looks a lot more like a decimal fraction then a floating point number. Maybe an explicit exponent, like 1.61803398E0, would make it clear that you wanted a float.

It's a trade-off of speed for less user surprise, and for a language with as little stress on raw speed as Perl, that's usually a good trade off. Accuracy is probably a wash; I bet there's a lot of times where you get back the exact best answer you could get with rationals where floats are less then precise, especially for less experienced users who aren't thinking in terms of IEEE754. I don't know Perl or Perl 6, but I assume if you want floats, you can explicitly demand them.

An interview with Larry Wall (LinuxVoice)

Cyberax — Mon, 27 Jul 2015 17:13:51 +0000

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

flussence — Mon, 27 Jul 2015 17:08:45 +0000

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

mchapman — Mon, 27 Jul 2015 00:06:57 +0000

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

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

An interview with Larry Wall (LinuxVoice)

mchapman — Mon, 27 Jul 2015 00:03:43 +0000

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

anselm — Sun, 26 Jul 2015 23:02:10 +0000

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)

dvdeug — Sun, 26 Jul 2015 20:06:47 +0000

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)

Cyberax — Sun, 26 Jul 2015 18:57:24 +0000

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

nix — Sun, 26 Jul 2015 18:47:34 +0000

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)

flussence — Sun, 26 Jul 2015 16:17:50 +0000

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

flussence — Sun, 26 Jul 2015 15:56:33 +0000

I get a strong impression you aren't even reading what you're arguing against, never mind who said it.

An interview with Larry Wall (LinuxVoice)

mathstuf — Sun, 26 Jul 2015 03:19:40 +0000

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

dvdeug — Sat, 25 Jul 2015 12:37:37 +0000

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)

anselm — Sat, 25 Jul 2015 11:56:49 +0000

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)

dvdeug — Sat, 25 Jul 2015 05:02:18 +0000

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)

rsidd — Sat, 25 Jul 2015 04:12:16 +0000

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)

raiph — Sat, 25 Jul 2015 03:55:01 +0000

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

anselm — Sat, 25 Jul 2015 00:15:16 +0000

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)

raiph — Fri, 24 Jul 2015 23:40:29 +0000

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

raiph — Fri, 24 Jul 2015 22:36:39 +0000

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

raiph — Fri, 24 Jul 2015 22:19:19 +0000

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)

raiph — Fri, 24 Jul 2015 21:52:29 +0000

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

dvdeug — Fri, 24 Jul 2015 21:46:36 +0000

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.

An interview with Larry Wall (LinuxVoice)

dvdeug — Fri, 24 Jul 2015 21:21:26 +0000

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)

raiph — Fri, 24 Jul 2015 20:43:36 +0000

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

raiph — Fri, 24 Jul 2015 19:19:02 +0000

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

raiph — Fri, 24 Jul 2015 18:58:05 +0000

What's the simplest way to get that fixed width code display? Are you having to use HTML mode to get it?

An interview with Larry Wall (LinuxVoice)

anselm — Fri, 24 Jul 2015 16:15:29 +0000

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)

peter-b — Fri, 24 Jul 2015 16:00:46 +0000

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)

anselm — Fri, 24 Jul 2015 15:59:56 +0000

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)

mchapman — Fri, 24 Jul 2015 12:28:05 +0000

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

mchapman — Fri, 24 Jul 2015 12:24:31 +0000

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

rsidd — Fri, 24 Jul 2015 12:11:05 +0000

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)

rsidd — Fri, 24 Jul 2015 12:03:56 +0000

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)

mchapman — Fri, 24 Jul 2015 11:55:43 +0000

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

mchapman — Fri, 24 Jul 2015 11:48:30 +0000

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

mchapman — Fri, 24 Jul 2015 11:46:33 +0000

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

rsidd — Fri, 24 Jul 2015 11:26:26 +0000

> 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