Live data from Hacker News

Interview with Larry Wall

developers.slashdot.org

21–30 of 93 posts

Re: Interview with Larry Wall

#21
post #20
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

JS as target will always be slower and bigger(as payload) than WASM as target so my point is that JS as compilation target is no longer relevant once WASM is supported(i.e. most likely by the end of the year). It makes little sense to start a javascript backend now unless you are looking for very short term benefits.

Re: Interview with Larry Wall

#22

Earlier quoted context omitted.

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

On top of that, I know actual companies that specialize in doing this for bigger companies. The companies want to move something from form, database, file, or whatever to another. Or merge several with some analysis into a new one. You'd think this would be automated or a simple job for one, on-site programmer.

Instead, these firms get paid big money to do that on a regular basis for the same companies. Mind-blowing.

Re: Interview with Larry Wall

#23
post #13

Earlier quoted context omitted.

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

rakudobrew worked fine, thanks.

Re: Interview with Larry Wall

#24

Earlier quoted context omitted.

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.

On top of that, I know actual companies that specialize in doing this for bigger companies. The companies want to move something from form, database, file, or whatever to another. Or merge several with some analysis into a new one. You'd think this would be automated or a simple job for one, on-site programmer. Instead, these firms get paid big money to do that on a regular basis for the same companies. Mind-blowing.

You would think, but it does take some upfront thinking about how to get data cleanly out of one system and into another. Most developers don't really care about that part so you pay big bucks later. If your report writers are struggling getting collection-style reports (e.g. "give me all open contracts"), expect to pay through the nose.

Re: Interview with Larry Wall

#25
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

And sometimes you find out data file Z is itself a Perl script :)

Re: Interview with Larry Wall

#26
"Perl has always considered itself primarily a programmer-centric language, while Python has always considered itself to be more institution-centric. So in a sense it's a bit dumbed down, much like Java. You'll note both of those languages make their greatest appeal to managers. :-) "

Huh? I was using Python when Perl was more popular, and this seems completely fabricated. He's trying to lump Python in with Java, which is bizarre because those 2 camps have pretty big philosophical differences.

I think that the main reason that Python became more popular because it has both clearer syntax and clearer semantics than Perl. It is compact AND readable -- not just compact. The data structures in Python also behave more like those you would see in a CS textbook.

I'm working on my own language, and I just read over the Camel Book ("Learning Perl"). Honestly I don't see much in there that I want to borrow, except maybe for ~= automatically introducing variables. What else is good about Perl, which is

    1) not in Python/Ruby/JavaScript (like hash tables)
    2) overly terse/clever?
(Honest question)

Perl's regex syntax seems to be it's biggest influence and legacy, with Python/Ruby/Java/PCRE all adopting its syntax.

And -e in Perl is also useful -- Python/Ruby/etc. aren't really good for one liners like Perl. This provides a nice gateway into the language.

But a lot of other features were rightly ignored by other languages IMO.

Also, with regard to the previous sentence, I actually consider Python OO kind of weak, but it's definitely better than Perl's AFAICT.

Re: Interview with Larry Wall

#27
post #20

Earlier quoted context omitted.

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

JS as target will always be slower and bigger(as payload) than WASM as target so my point is that JS as compilation target is no longer relevant once WASM is supported(i.e. most likely by the end of the year). It makes little sense to start a javascript backend now unless you are looking for very short term benefits.

The github repo for rakudo-js dates to September 2012. You're correct, but it looks like this effort has been in development for longer than WASM has been around.

Re: Interview with Larry Wall

#28
post #20

Earlier quoted context omitted.

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

JS as target will always be slower and bigger(as payload) than WASM as target so my point is that JS as compilation target is no longer relevant once WASM is supported(i.e. most likely by the end of the year). It makes little sense to start a javascript backend now unless you are looking for very short term benefits.

It's JavaScript that's a much smaller and faster payload if you need garbage collection. There's talk of putting a generic garbage collector into WASM but that's still well into the future. WASM also doesn't have direct access to the DOM - right now it's more like Flash or Java applets than it is JavaScript.

Re: Interview with Larry Wall

#29
post #26

"Perl has always considered itself primarily a programmer-centric language, while Python has always considered itself to be more institution-centric. So in a sense it's a bit dumbed down, much like Java. You'll note both of those languages make their greatest appeal to managers. :-) " Huh? I was using Python when Perl was more popular, and this seems completely fabricated. He's trying to lump Python in with Java, whi…

> What else is good about Perl, which is 1) not in Python/Ruby/JavaScript or 2) overly terse/clever? (Honest question)

Scalar/list/hash context. It makes zero sense and the syntax seems to change randomly… until you understand it. Then contexts make a great deal of sense.

Also, having dealt with a good deal of Python, I'm inclined to lump it in with Java too—less verbose and dynamically typed, but still focused on code that's superficially easy to read or understand. There's a big difference between being able to read a function or class definition (whatever the hell it means to ‘read’ code; I don't even know anymore) and understand where that falls in the big scheme of things. Python and Java read from the bottom-up; individual methods make sense but then you have to piece everything together. Perl, APL, and Lisp-family read from the top-down. You start with some abstractions and idioms and work your way down to individual functions, which may be hard to grok but what matters is what they do, not how. Perl makes writing those really, really fast, and allows building abstractions easily.

Re: Interview with Larry Wall

#30
post #5

I wish the language the best, but I find it a bit confusing to call it Perl 6. It is basically a new language, something different than Perl (5).

That's basically everyone's sentiment in the Perl community right now. Perl6 is a nice language (I mean, I'm not a huge fan, but it's not bad either) but it's a language that has some Perl influences but is definitely not Perl. It's like if Ruby was called Smalltalk 2.
Post reply on HN