Live data from Hacker News

Interview with Larry Wall

developers.slashdot.org

41–50 of 93 posts

Re: Interview with Larry Wall

#41
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…

I have been using Perl for the last 3.5 years (for work). Before that I used Python for 8 years. For the vast majority of things Python is better. Perl programmers tend to say that the language is more powerful and allow for shorter programs, but in my experience, when writing the same program in Perl and Python, the later is more concise. There are some Perl features that save you keystrokes, for example, autovivification, but in the long run those are a lot of trouble. Also, it's really hard to learn to use Perl properly, it's full of inconsistencies and antipatterns, it's so easy to write bad code with it. Python is much simpler, consistent and with less corner cases. Python features (e.g. iteration protocol) seem more elegant to me. Perl features feel really hacky, they work, but they're rarely orthogonal and usually have surprising side effects.

One aspect where Perl still kickass is for writing shell scripts. Running commands, interacting with the filesystem and other tools is so easy. Once you know Perl, you rarely use bash, sed, grep or awk.

Re: Interview with Larry Wall

#42
post #27

Earlier quoted context omitted.

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.

yeah but there was no stable Perl 6 in 2012. Perhaps `dead on arrival` would have been better said than `too late`.

Re: Interview with Larry Wall

#44

Earlier quoted context omitted.

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.

Eventually wasm will provide GC.

Edit: It's on the roadmap just after MVP so I wouldn't say it's that far. Also based on the latest talks from Luke at City Hall(I can't find the link) the access to DOM could arrive even sooner than the GC. My point is that wasm is worth investing it because it's the future. Once language X compiles to wasm and perl compiles to JS you can see a double digits performance difference. I don't need to tell you which language looks more appealing. WASM has nothing to do with applets/flash etc. It was already clarified in various posts.

Re: Interview with Larry Wall

#45
post #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 co…

I find hard to think of a single positive thing of contexts in Perl. For me, this is one of the worst aspects of the language (along with references) because is really confusing and it doesn't provide any benefit at all, i.e. there is nothing that you can do with contexts that you can't do in a better way without them.

Re: Interview with Larry Wall

#46
post #40
post #29

Earlier quoted context omitted.

> 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 co…

OK thanks for the answer. I agree that this context sensitivity is probably the most Perl-ish part of Perl. I just read over the Camel book section on this, and it says: "This is the most important section in this chapter. In fact it's the most important section in the entire book." "Not only that, but you can't make any general rules to apply what you know about some expressions to others. Each expression can make u…

FWIW, I've found that this quote:

"Not only that, but you can't make any general rules to apply what you know about some expressions to others."

has been greatly improved in Perl 6 over Perl 5. That is, the very rules of the parser feel more concrete and the degree of composability between interlocking syntactical constructs has far fewer rough edges. The explanations for the edge cases, when you do come across them, tend to feel more "justifiable" to me as well, in the sense that Perl 5 justifications can and will often be implementation oriented where Perl 6 justifications will tend to come from the language design itself. (Where implementation demands in excuse in Perl 6, it tends to be of the NYI variety).

So the fear of 'mostly correct' is not an issue in Perl 6, in my experience. FWIW, I've also written a lot of Perl 5 code at this point and I've found 'mostly correct' to be absolutely fine in practice, if a bit of a WTF in a few cases going on (edit: going in).

"Each expression can make up its own rules."

While at the same time as becoming more predictable in the manner I describe above, Perl 6 also pushes this to the absolute limit by making it LITERALLY true. For Perl 5, this sentence is pretty true in spirit, if a little bit of a fib practically. The language just didn't have the design that would allow it to, say, produce a real AST. Things like source filters were attempted early on in the language cycle and were already considered harmful by the time I started Perl in 1998.

In Perl 6, every expression can easily make up its own rules, but you don't do it in some oddball one-liner. Instead you have an operator (that is, "a subroutine with a funny name") defined somewhere in scope using the same definition mechanism as every native operator in the language. You get absolute guarantees for behavior on your own operators -- anything core can do, you can do. And it's (edit: core is) always there as a reference to guide you while writing your own operators.

But then again, maybe you actually just don't define that many custom operators. The syntax is terse and expressive enough that I don't find myself doing it very often.

I think in the long run, Perl 6 has everything you need -- and if you don't like the way it looks, it has everything you need to change that, too. And your code wouldn't be transpiled as we do in JavaScript today. It would instead be parsed by the same grammar engine that parses Perl 6 itself.

Re: Interview with Larry Wall

#47
"Which large companies are still using Perl in production? I can name Booking.com, but do you know any others?" - it's worth mentioning DuckDuckGo of course, which is quite young and chosen Perl as a way to go.

Re: Interview with Larry Wall

#48
post #38
post #37

Earlier quoted context omitted.

Although I don't think of Python and Java as that similar, I do see what Larry is getting at. Python encourages "There should be one-- and preferably only one --obvious way to do it", which is very nice for institutions where multiple programmers have to work with the same code. The power that comes from "more than one way to do it" in Perl is great for an individual programmer that wants to create his own custom too…

Yeah I see what he's getting at in the sense that Python is more regular and compositional, while Perl is more personal and "poetic" (if I'm to be charitable, I don't really like that quality in my code). But "Python has always considered itself institution-centric" is patently FALSE... as I said, if you were using Python 10+ years ago, when Perl was more popular, you would find that statement very surprising. Paul G…

I will agree with you that Python didn't consciously consider itself institution-centric, but it has valued institution-friendly goals such as readability and maintainability.

Re: Interview with Larry Wall

#49
post #48
post #38

Earlier quoted context omitted.

Yeah I see what he's getting at in the sense that Python is more regular and compositional, while Perl is more personal and "poetic" (if I'm to be charitable, I don't really like that quality in my code). But "Python has always considered itself institution-centric" is patently FALSE... as I said, if you were using Python 10+ years ago, when Perl was more popular, you would find that statement very surprising. Paul G…

I will agree with you that Python didn't consciously consider itself institution-centric, but it has valued institution-friendly goals such as readability and maintainability.

My problem is that I don't consider those institution-centric goals... I consider them to be essentials for developing good software quickly.

I've written many open source Python projects in the thousands of lines, and one of them was 30K lines. Right now, I'm actually going back to some 4 year old Python code I wrote by myself, outside of any institution. I don't see how you could NOT value readability and maintainability in this context.

But yes, I get what he's saying. He's just saying it in a wrong-headed way. As if writing readable code is actually a burden or a cost. It's not if you value your own time properly.

Re: Interview with Larry Wall

#50
post #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.

> everyone's sentiment in the Perl community right now

Definitely not 'everyone'. And I strongly suspect it's not even 'most'.

There has been a relatively small but very vocal group with this point of view.

Post reply on HN