Live data from Hacker News

The Joy of Perl (1998)

salon.com

31–40 of 82 posts

Re: The Joy of Perl (1998)

#31
post #19

Used to spend a ton of time writing Perl (see username). Moved on to better designed languages. Which are not hard to find. There are a few big issues with Perl 5 but the biggest is easily the mess of references vs flat values. Python, Ruby, JavaScript and many other dynamic languages do not make the programmer think about whether you are going to pass a data structure like an array or hash as a reference or direct v…

"Python, Ruby, JavaScript and many other dynamic languages do not make the programmer think about whether you are going to pass a data structure like an array or hash as a reference or direct value. Perl does." If you don't think about these things in python, you're going to be scratching your head when you see something like this: >>> foo = ['a','b','c'] >>> bar = foo >>> bar[1] = 'z' >>> foo ['a', 'z', 'c']

No, it isn't the same. I'm no language lawyer, but this is my understanding of it.

In python, $foo is a reference. It might be a reference to a scalar value, or list, or hash, etc, but it is a reference. The code you wrote might cause confusion for people who don't understand the python model.

In perl, $foo might be a scalar value, or it might be a reference to a value of some kind. Perl has this exact same type of problem demonstrated by your python code, but in addition it has the problem of "is $foo a scalar value or a reference?"

Re: The Joy of Perl (1998)

#34

Earlier quoted context omitted.

Ruby definitely has its niche in web development mainly due to Rails, Jekyll and Sinatra. Quite a weird choice for other things. Pretty sure Homebrew on Mac uses it. It’s not the most performant of languages (although it’s definitely getting better).

Homebrew is the only thing I think Ruby is perfect for. It's just a DSL for describing how to fetch and build a program, like Makefiles but more convenient.

As the other reply to you said, agreed on the DSL-construction thing. I used a fair bit of Puppet a couple of years ago and that was very much Ruby through and through. What I really liked about it was how easy it was to jump from DSL for general use cases to Ruby for specialized libraries or system Facts.

Re: The Joy of Perl (1998)

#36

Earlier quoted context omitted.

"Python, Ruby, JavaScript and many other dynamic languages do not make the programmer think about whether you are going to pass a data structure like an array or hash as a reference or direct value. Perl does." If you don't think about these things in python, you're going to be scratching your head when you see something like this: >>> foo = ['a','b','c'] >>> bar = foo >>> bar[1] = 'z' >>> foo ['a', 'z', 'c']

No, it isn't the same. I'm no language lawyer, but this is my understanding of it. In python, $foo is a reference. It might be a reference to a scalar value, or list, or hash, etc, but it is a reference. The code you wrote might cause confusion for people who don't understand the python model. In perl, $foo might be a scalar value, or it might be a reference to a value of some kind. Perl has this exact same type of p…

I think OP's point was that even in Python you have to be conscious where your "storage" is--that you're sharing it.

Yes, the "Python" model (or Java, JavaScript) of referring to everything by reference is uniform and simple--except it still shares the issue of having to care if you add mutation into the mix. Due to its apparent smoothness it might even make it easier to run into that. In a sense Perl is honest here in saying I use local arrays via @ prefix and I know this array "lives here", like in the C/C++ world where you have to care about where the storage is so you don't pass references to stack objects etc.; in this world, when you take a reference, it's a heads-up that you may have to care about something. In Perl, unlike in C/C++, you don't have to care about memory safety, but you still, like in all imperative languages, you have to care about sharing of mutations. An explicit reference makes this explicit. If you return an array flat (without taking a reference) in Perl, it is being copied, and while that's slow, it is at least safe. It's an unclean solution for the issue, but in a sense it's at least pointing your head towards the issue.

The clean solution for this is functional programming. Lisp was first to use a uniform "everything is a reference, implicitly" model. But it also preferred a functional programming model where you don't mutate your data structures. Java and Python took the reference model but mixed it with an imperative data update model. Meh.

And I agree that I like the "just use references for everything implicitly" approach. But I also like to combine it with a functional one. And I ended up creating a project to achieve exactly that in Perl, and will shamelessly plug it here: https://metacpan.org/pod/FunctionalPerl (Code written in it co-exists with code that still uses non-reference variables, so feel free to argue that "now you have both worlds mixed", but for one it aims at existing Perl programmers who know how to deal with the non-reference model, and secondly functional programming matters most in the upper levels of an application; it's fine to use imperative code in inner loops / enclosed in an otherwise pure function, and it's fine to use array/hash variables there; FunctionalPerl comes in where you'd traditionally take a reference via `\`; so it's kind of a split between imperative and functional world now).

Re: The Joy of Perl (1998)

#37
post #19

Used to spend a ton of time writing Perl (see username). Moved on to better designed languages. Which are not hard to find. There are a few big issues with Perl 5 but the biggest is easily the mess of references vs flat values. Python, Ruby, JavaScript and many other dynamic languages do not make the programmer think about whether you are going to pass a data structure like an array or hash as a reference or direct v…

> join(‘,’,@{$foo->{‘bar’}}) Thank you for that example. I guess the equivalent in JavaScript is: foo.bar.join(',')

Correct. You can use libraries in Perl (autobox and a class offering "join") so you can write it in Perl as:

   $foo->{bar}->join(',')
I've done that in FunctionalPerl[1]:

  use FunctionalPerl ":autobox";
  my $foo= {bar=> ["hi", "there"]};
  is $foo->{bar}->join(','),
     'hi,there';
[1] https://metacpan.org/pod/FunctionalPerl

Re: The Joy of Perl (1998)

#38

I bet some younger HN readers are looking at this and wondering if the popularity off Perl at this point is primarily sentimental associations that older devs have with the early days of the Web when they could find artsy ways to explore a new emerging medium. It is. Very much so.

I disagree completely, but I'll accept that that's partly a matter of taste.

But the thing that shocks me most about how completely Perl has fallen out of fashion is that nowadays sysadmins will write a hundred-line bash script rather than a five-line Perl script because of the theory that Perl is hard to read.

Re: The Joy of Perl (1998)

#39
post #19

Used to spend a ton of time writing Perl (see username). Moved on to better designed languages. Which are not hard to find. There are a few big issues with Perl 5 but the biggest is easily the mess of references vs flat values. Python, Ruby, JavaScript and many other dynamic languages do not make the programmer think about whether you are going to pass a data structure like an array or hash as a reference or direct v…

"Python, Ruby, JavaScript and many other dynamic languages do not make the programmer think about whether you are going to pass a data structure like an array or hash as a reference or direct value. Perl does." If you don't think about these things in python, you're going to be scratching your head when you see something like this: >>> foo = ['a','b','c'] >>> bar = foo >>> bar[1] = 'z' >>> foo ['a', 'z', 'c']

It's incredibly confusing if you naively use a list as a default argument, e.g.

    def foo(some_list=[]):
        ...
        some_list.append(3)
        ...
Since the default is constructed when the function is evaluated, it's the same list, but only when the default is used.

Or the n00b's attempt to use lambdas:

    def list_of_lambdas(x):
        result = []
        for n in range(x):
            result.append(lambda m: n + m)
        return result

    for func in list_of_lambdas(3):
        print(func(3))

    5
    5
    5
(All the closures share the same "cell", meaning the same "n", which is 2 at the end of that loop. Worse, if you 'yield lambda ...', that example would look like it worked. So, yes, Python absolutely has references.)

Re: The Joy of Perl (1998)

#40
post #9

We use perl to power some web services that have been running a long time. It’s a work horse. I’m ok with it but it is hard to read, I think because there are so many ways to do everything. it takes a bit to get used to some of the syntax ($@~). I was told my perl was very c like during a review. It’s great for text manipulation though. I just remember Rasmus (of php) talking about how he always expected any language…

PHP rise is a lesson in systemic effects. linguistic wise it had nothing on perl, the module execution model was another 'less is more'. Crazy in retrospect.
Post reply on HN