Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with Larry Wall

developers.slashdot.org

Post reply on HN
Print view View original

11–20 of 93 posts

Re: Interview with Larry Wall

#11

Post by 0xdeadbeefbabe »

ianai wrote: post #9
yeowMeng wrote: post #3

My experience with Perl: We (a corporate shop) have a lot 'legacy' scripts in Perl. I am assigned to maintain such scripts as no one else wants that role. I discover, Perl is powerful. Every 'legacy' script I find can be trivially regression tested (These scripts always have the same pattern, take some input, produce some output). Managers want to move away from Perl. I want to move closer to Perl.

Do they even have a replacement in mind already?

Wouldn't they need a mind to put something in mind?

Re: Interview with Larry Wall

#12

Post by JadeNB »

a3n wrote: post #6

> my @values = [1 .. 20]; 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 > say @values[0,2,4 ... *]; 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Wall says this should print all the evens, but it prints all (this is in the perl6 repl).

Which version are you using? I happen to have 2016.04 installed:

    $ perl6 -v
    This is Rakudo version 2016.04 built on MoarVM version 2016.04
    implementing Perl 6.c.
and I see:

    > my @values = [ 1 .. 20 ];
    [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20]
    > say @values[0, 2, 4 ... *];
    (1 3 5 7 9 11 13 15 17 19)
(Of course it's the odd numbers, not the even numbers, but it just happens that the odd-valued entries are in the even-indexed positions in this list.)

Re: Interview with Larry Wall

#13

Post by a3n »

JadeNB wrote: post #12
a3n wrote: post #6

> my @values = [1 .. 20]; 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 > say @values[0,2,4 ... *]; 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Wall says this should print all the evens, but it prints all (this is in the perl6 repl).

Which version are you using? I happen to have 2016.04 installed: $ perl6 -v This is Rakudo version 2016.04 built on MoarVM version 2016.04 implementing Perl 6.c. and I see: > my @values = [ 1 .. 20 ]; [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20] > say @values[0, 2, 4 ... *]; (1 3 5 7 9 11 13 15 17 19) (Of course it's the odd numbers, not the even numbers, but it just happens that the odd-valued entries are in…

  perl6 --version
  This is perl6 version 2013.12 built on parrot 5.9.0 revision 0
Installed from the Mint/Ubuntu/... repository. Wow, that's really old.

Is there anything like Python's Anaconda, but for Perl6?

Re: Interview with Larry Wall

#14

Post by liveoneggs »

a3n wrote: post #13
JadeNB wrote: post #12

Earlier quoted context omitted.

Which version are you using? I happen to have 2016.04 installed: $ perl6 -v This is Rakudo version 2016.04 built on MoarVM version 2016.04 implementing Perl 6.c. and I see: > my @values = [ 1 .. 20 ]; [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20] > say @values[0, 2, 4 ... *]; (1 3 5 7 9 11 13 15 17 19) (Of course it's the odd numbers, not the even numbers, but it just happens that the odd-valued entries are in…

perl6 --version This is perl6 version 2013.12 built on parrot 5.9.0 revision 0 Installed from the Mint/Ubuntu/... repository. Wow, that's really old. Is there anything like Python's Anaconda, but for Perl6?

try rakudobrew or just building it yourself from rakudostar

Re: Interview with Larry Wall

#15

Post by Bromskloss »

protomyth wrote: post #7
yeowMeng wrote: post #3

My experience with Perl: We (a corporate shop) have a lot 'legacy' scripts in Perl. I am assigned to maintain such scripts as no one else wants that role. I discover, Perl is powerful. Every 'legacy' script I find can be trivially regression tested (These scripts always have the same pattern, take some input, produce some output). Managers want to move away from Perl. I want to move closer to Perl.

The sad thing is about 90% of normal back-end computing at enterprises is take data source A,B,C,etc and generate data file Z. Cobol lives because it could do that well. Perl did that amazingly well[1]. Its really trivial to write easy to maintain code that does that in a very standard (across programs) way. 1) Data Munging with Perl was a pretty good book for it

> Cobol lives because it could do that well.

Can't every language do that well?

Re: Interview with Larry Wall

#16

Post by protomyth »

Bromskloss wrote: post #15
protomyth wrote: post #7

Earlier quoted context omitted.

The sad thing is about 90% of normal back-end computing at enterprises is take data source A,B,C,etc and generate data file Z. Cobol lives because it could do that well. Perl did that amazingly well[1]. Its really trivial to write easy to maintain code that does that in a very standard (across programs) way. 1) Data Munging with Perl was a pretty good book for it

> Cobol lives because it could do that well. Can't every language do that well?

Amazingly enough, not really. Quite a few don't do it at all without some really good library support. Its not really that "sexy" of a problem and often ignored by people developing languages for interactive situations.

Re: Interview with Larry Wall

#17

Post by protomyth »

digi_owl wrote: post #10
protomyth wrote: post #7

Earlier quoted context omitted.

The sad thing is about 90% of normal back-end computing at enterprises is take data source A,B,C,etc and generate data file Z. Cobol lives because it could do that well. Perl did that amazingly well[1]. Its really trivial to write easy to maintain code that does that in a very standard (across programs) way. 1) Data Munging with Perl was a pretty good book for it

Work is receive input, mangle input, send output once you generalize it enough. but the devil will definitely be in the details.

Oh yeah, the details are the problem. Worse, its a technical problem and a people issue for some kinds of output. Report Writing has all of the problems of graphic design and date munging with none of the rewards. Lord help you if the friggin DBA & Application Developers built the database or other data sources for transactional processing and didn't provide any help (e.g. summary tables, other data source) for batch (set) processing.

I now follow a simple law when setting up a data source: If I need attribute X from an item then I better have a way to find all items with attribute X in a hurry.

Re: Interview with Larry Wall

#18

Post by niftich »

forinti wrote: post #2

>Why isn't PERL more windows friendly? Really? I've had tons of fun with Perl+OLE automating the processing of Excel and Word files.

Same; I've always had more problems with Python on Windows, rather than Perl.

With Perl 5, both ActiveState's and Strawberry Perl just worked, whereas Python can't even print to the console [1] without workarounds or an extra library that's not installed by default.

[1] http://stackoverflow.com/questions/5419/python-unicode-and-t...

Re: Interview with Larry Wall

#19

Post by AnimalMuppet »

Some gems:

> It turns out if you accept the 90% of each paradigm that is practical, and reject the 10% that puritanically rejects other paradigms, you can get a pretty decent general-purpose language out of it

> But there's a long history of people confusing "general-purpose" with "Turing-complete".

Yeah. Things that are formally equivalent are not (usually) equally easy.

Re: Interview with Larry Wall

#20

Post by niftich »

themihai wrote: post #4

Isn't quite late for a JS backend given that we have WASM now?

In an IRC chat [1] on 2016-04-15, pmurias, the lead developer of rakudo-js [2] said:

> Perl 6 -> wasm won't be happening any time soon

> for now wasm is just bytecode asm.js

> if we really wanted to compile to it we would have to use enscripten and run MoarVM on top of wasm

[1] https://irclog.perlgeek.de/perl6/2016-04-15/text

[2] https://github.com/pmurias/rakudo-js

Post reply on HN