Live data from Hacker News

Perl and Undecidability (2008)

jeffreykegler.com

31–40 of 127 posts

Re: Perl and Undecidability (2008)

#31

You know there was that recent Stackoverflow analysis that concluded that Perl was the most disliked programming language? It got me to thinking about how Perl managed to become quite so profoundly disliked, and I remembered these papers and thought that maybe things like this are the reason.

Perl has a lot of crappy language design decisions (which make it "fun" and a tire fire waiting to happen in any large-ish codebase):

- interpretation of a variable (is it a list, a number, a string, a hash?) depends on the context in which it's used, and the context depends on, um, its context;

- pervasive global state (`$_` and friends);

- you can mess with compile-time operations, patch the language on the fly, e.g. during module imports;

- autovivification: a single read by key from a hash is enough to actually create this key; variables are a number and a string at once, but the number will not be computed until you need this variable in number context. Reading a non-existing key in a hash as a hash actually creates a new subhash.

- ties: you can override access to any variable by your methods;

- the built-in data structures are special, there is no sane way to emulate and extend them (but, as usual, for sure there are insane ways);

- the built-in `sort` takes a code block (not a closure with parameters), that has magic variables `$a` and `$b` appearing out of thin air. It looks like a closure, but it's not.

- features are often added in a convoluted way. E.g. there was a (now deprecated) feature that allowed `push` and `shift` to take a reference to a hash instead of a hash directly. How was it implemented internally? Basically by backpatching the error condition when the existing `push`/`shift` choked on a reference.

- the language design principle is "Do What I Mean" (where the "I" part varies). It's ironic that a language built "for human communication" by a linguist (what could possibly go wrong?) is harder to read and to reason about that programming languages built around logic.

On the other hand, if your business brings enough income to pay good developers with strong discipline, you can still have a big codebase in Perl and sustain it for years: it's better to have a terrible language and good engineers than bad engineers and a good language.

Re: Perl and Undecidability (2008)

#32

C++ is also undecidable, by the way: http://blog.reverberate.org/2013/08/parsing-c-is-literally-u... Perl was a great language design lab experiment. They gave people 20 ways to do any simple thing, and then Matz and Guido looked to see which ways became popular and designed great languages that allow only those ways and maybe 1-2 more that are highly frowned upon. I'm almost as glad Perl exists as I am that I never…

Going off on a tangent: I dislike standard sluggification algorithms; they’re far too fond of throwing away useful parts of the title, like small words in some or turning C++ into just c in almost all cases. parsing-c-is-literally-undecidable would be so much better as parsing-c++-is-literally-undecidable (but note that Amazon S3’s HTTP server has a broken implementation of + in file names that they refuse to fix; with that exception, using + in the URL is perfectly safe everywhere I know of) or even parsing-cpp-is-literally-undecidable (you might choose this manually) or parsing-c-plus-plus-is-literally-undecidable (a sluggifier might produce this).

Re: Perl and Undecidability (2008)

#33

You know there was that recent Stackoverflow analysis that concluded that Perl was the most disliked programming language? It got me to thinking about how Perl managed to become quite so profoundly disliked, and I remembered these papers and thought that maybe things like this are the reason.

Perl being a dead and disliked language has become a meme. But the community is still very much alive and a lot of cool stuff is being built with Modern Perl. http://mojolicious.org

Re: Perl and Undecidability (2008)

#34
post #25

Earlier quoted context omitted.

Point 2 is kind of nonsense. The ecosystem is incredibly big and keeps up with most things. Name something then search here https://metacpan.org/ The main missing stuff is anyone marketing heavily their libraries and there being communities around them etc. Like probably no one knows what PDL is, even though it was around long before numpy+scipy etc. Before data science trended in the mind of hipster VCs and coders.…

>ecosystem is incredibly big I wasn't talking about the size of cpan because it's not relevant to my point. I was talking about Perl not being at the forefront of everyone's minds and being used as a 1st-class environment as computing entered new domains. E.g. instead of Sun or Microsoft taking an existing language like Perl and giving it a canonical IDE to let programmers write data entry GUI applications, they crea…

Ok then your definition is corporate ecosystem then? Perl in general is hardly the stuff of scaled soft eng. in a mega corp. It wasn't designed for that, but to empower an individual to be highly productive quickly. With that in mind the ecosystem is super healthy, even by your definition. I'm more shocked Python has managed to bridge that gap, but so did Pascal at one point so I guess designed to be a teaching language wins out!

Re: Perl and Undecidability (2008)

#35

You know there was that recent Stackoverflow analysis that concluded that Perl was the most disliked programming language? It got me to thinking about how Perl managed to become quite so profoundly disliked, and I remembered these papers and thought that maybe things like this are the reason.

Perl has a lot of crappy language design decisions (which make it "fun" and a tire fire waiting to happen in any large-ish codebase): - interpretation of a variable (is it a list, a number, a string, a hash?) depends on the context in which it's used, and the context depends on, um, its context; - pervasive global state (`$_` and friends); - you can mess with compile-time operations, patch the language on the fly, e.…

>It's ironic that a language built "for human communication" by a linguist (what could possibly go wrong?) is harder to read and to reason about that programming languages built around logic.

It's not like having a fascination with weird language quirks makes you have good taste in languages. Especially because weird quirks are the end of usability.

Re: Perl and Undecidability (2008)

#36

C++ is also undecidable, by the way: http://blog.reverberate.org/2013/08/parsing-c-is-literally-u... Perl was a great language design lab experiment. They gave people 20 ways to do any simple thing, and then Matz and Guido looked to see which ways became popular and designed great languages that allow only those ways and maybe 1-2 more that are highly frowned upon. I'm almost as glad Perl exists as I am that I never…

I don't think the language design influence of Perl on Python was as strong as you imply. (Not that there's no influence.)

Certainly the influence on Ruby was larger.

Also, I seem to recall the Perl5 object model was influenced by Python.

Re: Perl and Undecidability (2008)

#37
post #7

Earlier quoted context omitted.

Perl is disliked because it has a very shallow learning curve to do badly, and a high learning curve to do well. Therefore, lots of people see a lot of bad code, but also people don’t understand a lot of good code.

Its the main reason any language is hated. JavaScript now is less hated because the tooling got there and people were educated at university to program in it well. PHP and Ruby are on the list of disliked on the SO analysis. Which is basically nonsense for modern versions of both languages. I really wish these stats would state "Perl 5" too, as Perl 6 is really modern in semantics and syntax and is nice to code in.

I agree that Perl 6 is the first readable version of Perl. It might actually be considered a nice language. Yet all the tools that are newly rewritten by our Perl guys are in Perl 5 because that's what they know.

Re: Perl and Undecidability (2008)

#38
[not trying to hijack the discussion, but I think a meta-discussion is in order based on comments I've seen on this article]

The article is about whether or not you can actually parse Perl without running Perl to parse itself. One of the benefits/drawbacks to Perl is that it lets you run the interpreter at compile time, thus resulting in the possibility of an infinite loop preventing compilation. Which makes some people unhappy.

Oddly enough, this reminds me of the whole strongly/weakly typed discussion, with people weighing in and asserting one position or another, without really adequately comprehending the opposing position.

The meta-discussion here repeats almost every other discussion of Perl I see on HN and elsewhere. First there is a claim of death, either in the past, or present. Then there are claims that death was by sigil, line noise, etc. Further, additional claims are that other tools have taken over its space.

The data used as evidence are StackOverflow analyses, or Tiobe scores, or, insert additional popular, and often self-selected, data sets. You have to make specific assumptions about some of the data presented to be able to accept it, such that each community has about the same rate of people searching for answers on SO, or other places. Or that the searches will have relevant terms in the in each case.

This is a stretch to put it mildly. If I google for DBIx::Simple, and this search is caught by one of these filters, will it show up in Perl or not? I can't actually answer this. I have to refer to what the collectors of the data say on their own methodology [1][2]. I am not saying that there are not secular changes throughout the industry, or that various observed gross trends are "wrong". What I am saying is be careful reading into these analyses too strongly, as they may not be measuring what you think they are measuring.

In many cases, over the last 20 years or so, I've seen folks pushing Python happily talking up why they left or abhor Perl, usually saying/quoting things they've heard. From my own experience, Perl 4 and onward, much of what they complain about was Perl 4 or before. Likely before many of them started programming. That is speculation on my part, but it does appear to fit what I've observed.

If I extend this out to operating systems, I have people tell me how horrible Linux is and how much better anything-other-than-linux is than it on a very regular basis. They like to list (what they perceive to be) the faults, quote SO and other random websites as examples, and often make pronouncements not backed up by objective fact ... in many cases contradicted by objective fact.

We as a society of technologists seem to like our tools to the point where we feel that we can and should break into tribes with tags of honor around our necks, and nasty comments about alternative tools, and users of said tools. I've personally heard many an anecdote and critique of various tools from otherwise smart technologists that were, at best, badly misinformed, and at worst ... not simply disingenuous, but dishonest.

Look, it is great you like your tools, your operating system, your language. It does not mean that you are "better" or "smarter" than someone else because you use such things. And yes, I've had professional discussions as recently as last week on exactly this issue. Which is insane.

Maybe I've spent too many years on the business side, as I look at all of these things as tools to accomplish a goal, and as engineers, our jobs are to select the right combination of tools to a) minimize effort, b) maximize the possibility of success, c) enable debugging, observability, supportability.

No single tool, OS, editor (yes, I went there) has this. Moreover, if you need to bash what someone else is using simply for self gratification, then there are deeper issues afoot than simply a technological consideration.

Finally, I've been a user of Perl, and contributor to (CPAN) for more 20 years. Rumors of its demise, are greatly exaggerated. It is not my be-all/end-all language ... I am comfortable and competent in 5-6 at any one time, and can easily work in Python, C, Julia, Node, etc. w/o major issue (though with google nearby for things I don't have on the tip of my memory).

I don't use Perl for machine learning (though I could). I don't use it for numerics (though, again, I could). I don't use node for either of these. You pick the right tool for the right job. And you need to keep an open mind throughout the process on what the right tool is.

If you feel a need to bash on others choices, it might be worth reflecting why you think this course of action actually adds any light to a discussion. From what I've seen, it only adds heat.

[1] http://blog.codeeval.com/codeevalblog/2016/2/2/most-popular-...

[2] https://stackoverflow.blog/2017/05/09/introducing-stack-over...

[edit: fixed ref spacing]

Re: Perl and Undecidability (2008)

#39
post #25

Earlier quoted context omitted.

>ecosystem is incredibly big I wasn't talking about the size of cpan because it's not relevant to my point. I was talking about Perl not being at the forefront of everyone's minds and being used as a 1st-class environment as computing entered new domains. E.g. instead of Sun or Microsoft taking an existing language like Perl and giving it a canonical IDE to let programmers write data entry GUI applications, they crea…

Ok then your definition is corporate ecosystem then? Perl in general is hardly the stuff of scaled soft eng. in a mega corp. It wasn't designed for that, but to empower an individual to be highly productive quickly. With that in mind the ecosystem is super healthy, even by your definition. I'm more shocked Python has managed to bridge that gap, but so did Pascal at one point so I guess designed to be a teaching langu…

>It wasn't designed for that,

And I'm not "penalizing" Perl for that.

>I'm more shocked Python has managed to bridge that gap,

That's more to my point. Old languages like C++ and Python keep getting rejuvenated as 1st class drivers of innovation but Perl (the language -- not the cpan) keep getting ignored.

I was surprised when Google chose Python as one of the 1st class languages for its new Tensorflow instead of a new language like Julia. I do understand why they chose Python but nevertheless was surprised.

Same for C++. It gets rejuvenated in things like graphics programming (NVIDIA's CUDA SDK is C++ not Perl). And when Bitcoin showed up in 2009, it's canonical client was C++ not Perl. Also, updates to C++ via C++14 and C++17 were discussions that turned into reality whereas Perl 6's long development became a running joke about vaporware.

Perl5 and Perl6 don't really have any new stories like that where it gets rejuvenated. Therefore, it keeps dropping off everyone's radar as "legacy".

Whether Perl programmers are highly productive with Perl isn't really the issue.

Re: Perl and Undecidability (2008)

#40
post #8

You know there was that recent Stackoverflow analysis that concluded that Perl was the most disliked programming language? It got me to thinking about how Perl managed to become quite so profoundly disliked, and I remembered these papers and thought that maybe things like this are the reason.

>how Perl managed to become quite so profoundly disliked I'm guessing the reasons are actually more conspicuous than computer science concepts of "undecidability" since most working programmers don't read academic papers to judge whether they like/disklike a programming language. The conspicuous reasons seem to be a combination of: 1) PERL's usage of sigils.[1] One the one hand, it makes code compact and terse . On t…

> 1) PERL's usage of sigils.[1] One the one hand, it makes code compact and terse

Sigils have nothing to do with Perl's terseness; actually, they make code very slightly (one character per variable) more verbose. In Perl 5, $foo is a scalar, @foo is a list, %foo is a hash, etc. $foo[0] is the first element of the list @foo; it gets a $ because the element being accessed is a scalar. This is in contrast to most languages where variables are referred to like 'foo' and that's that.

Post reply on HN