An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
Posted Jul 24, 2015 11:48 UTC (Fri) by mchapman (subscriber, #66589)In reply to: An interview with Larry Wall (LinuxVoice) by rsidd
Parent article: An interview with Larry Wall (LinuxVoice)
Why should it? You asked for numeric addition; you got numeric addition. Why would you want it not do what you asked for?
Posted Jul 24, 2015 12:03 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (9 responses)
Posted Jul 24, 2015 12:28 UTC (Fri)
by mchapman (subscriber, #66589)
[Link] (1 responses)
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.
Posted Jul 24, 2015 22:19 UTC (Fri)
by raiph (guest, #89283)
[Link]
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.
Posted Jul 24, 2015 21:21 UTC (Fri)
by dvdeug (guest, #10998)
[Link] (6 responses)
* I found that frustrating in the early 90s, as C was widely available and PL/I was not.
Posted Jul 25, 2015 4:12 UTC (Sat)
by rsidd (subscriber, #2582)
[Link] (5 responses)
Posted Jul 25, 2015 5:02 UTC (Sat)
by dvdeug (guest, #10998)
[Link] (4 responses)
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.
Posted Jul 25, 2015 12:37 UTC (Sat)
by dvdeug (guest, #10998)
[Link] (2 responses)
"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.
Posted Jul 26, 2015 3:19 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Maybe I'm just not parsing your statement properly, but Haskell does all kinds of type inference…
Posted Jul 26, 2015 18:47 UTC (Sun)
by nix (subscriber, #2304)
[Link]
When compared to Haskell, Perl and Python look quite similar, both dynamic systems with heavy OO mixture and no type inference.
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.
Posted Jul 24, 2015 23:40 UTC (Fri)
by raiph (guest, #89283)
[Link] (2 responses)
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.
Posted Jul 25, 2015 0:15 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (1 responses)
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.
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.
Posted Jul 25, 2015 3:55 UTC (Sat)
by raiph (guest, #89283)
[Link]
Yeah. That's gone in Perl 6:
my @foo = 0,1,2,3; say @foo[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)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
An interview with Larry Wall (LinuxVoice)
I'm curious what your student mix is between non-programmers learning programming by learning Perl and programmers in other languages learning Perl.
say lines
An interview with Larry Wall (LinuxVoice)
1