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

51–60 of 93 posts

Re: Interview with Larry Wall

#51

Post by munificent »

chubot wrote: post #49
cicero wrote: post #48

Earlier quoted context omitted.

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

> Right now, I'm actually going back to some 4 year old Python code I wrote by myself, outside of any institution

I think by "institution", he mostly meant "group of people" as compared to a solo programmer.

Personally, I tend to prefer "institutional"-style languages because I have a pretty bad memory. Basically even my solo code is still the work of a group of people—me and all my past selves.

Re: Interview with Larry Wall

#52

Post by munificent »

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.

> Perl+OLE automating the processing of Excel and Word files.

There's a phrase you don't often find in a sentence containing "fun".

Re: Interview with Larry Wall

#53

Post by jlarocco »

chubot wrote: 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…

That whole section talking about Python seems like sour grapes, or making up excuses why Perl gave up so much mindshare to everything else.

Python and Ruby beat out Perl because they released new versions and responded to and kept up with changes in the software industry, while Perl stagnated for 15 years, making incremental point releases to Perl 5 while struggling with the boondoggle that is Perl 6.

Re: Interview with Larry Wall

#54

Post by rsync »

zenlot wrote: post #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.

Oh By[1], the universal shortener, runs solely on perl CGI.

We wouldn't have done it any other way.

[1] 0x.co

Re: Interview with Larry Wall

#55

Post by chubot »

munificent wrote: post #51
chubot wrote: post #49

Earlier quoted context omitted.

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

> Right now, I'm actually going back to some 4 year old Python code I wrote by myself, outside of any institution I think by "institution", he mostly meant "group of people" as compared to a solo programmer. Personally, I tend to prefer "institutional"-style languages because I have a pretty bad memory. Basically even my solo code is still the work of a group of people—me and all my past selves.

Right, 100% agree, but then we've just defined away "solo programmer".

If there are no solo programmers, then it doesn't make sense to design any part of a language for them :)

Re: Interview with Larry Wall

#56

Post by lloeki »

chubot wrote: post #40
PeCaN wrote: 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…

> In fact, a big part of learning Perl is actually learning how Larry thinks. Therefore, once you can think like Larry does, you know what Perl should do.

Haha, this reminds me of Ruby's Matz:

> The principle of least surprise means principle of least my surprise.

Re: Interview with Larry Wall

#57

Post by protomyth »

yeowMeng wrote: post #25
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

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

Yep. It is often much easier (see UNIX pipes) to break a problem down into steps that can be paused / restarted, not to mention just making the logic of each piece much simpler. I've seen where one class of data (e.g. transactions on contracts) are broken down into subclasses (e.g. commercial, individual) then processed by a different perl program to be recombined into one set that is finished by another perl script.

Its amazing how 5 very simple programs is easier to maintain code-wise and operations-wise than 1 big program sometimes.

Re: Interview with Larry Wall

#58

Post by rurban »

zenlot wrote: post #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.

cPanel does everything in perl

Re: Interview with Larry Wall

#59

Post by munificent »

chubot wrote: post #55
munificent wrote: post #51

Earlier quoted context omitted.

> Right now, I'm actually going back to some 4 year old Python code I wrote by myself, outside of any institution I think by "institution", he mostly meant "group of people" as compared to a solo programmer. Personally, I tend to prefer "institutional"-style languages because I have a pretty bad memory. Basically even my solo code is still the work of a group of people—me and all my past selves.

Right, 100% agree, but then we've just defined away "solo programmer". If there are no solo programmers, then it doesn't make sense to design any part of a language for them :)

I think there are "solo programmers", but they either:

1. Tend to have a pretty good memory for their own code so they are comfortable living in their own idiosyncratic world.

2. Don't maintain solo programs for a long time.

Even for group code, I think there is still room for languages that are more focused on "build your own mini-language, then write your program in it" as opposed to "there's one prescribed way to do it".

I think a lot of it comes down to ramp up time. When a new developer (or your future forgetful self) starts hacking on your program, how much time do you want them to spend before they are useful?

Languages like Python, Ruby, and Java try to minimize that by making all code in those languages roughly similar so it's easy to hop from one codebase to another.

Languages like CL and Perl place less of a premium on that. In return, the idea is that once you have ramped up, your overall velocity is higher. You basically have to learn a new language—the "language" that the program itself is written in—but once you have you now can express concepts in that program's domain more succinctly.

I don't think there's a right or wrong here, just different trade-offs to be made.

Post reply on HN