Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl and Undecidability (2008)

jeffreykegler.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: Perl and Undecidability (2008)

#101

Post by kazinator »

zbentley wrote: post #86
kazinator wrote: post #79

Earlier quoted context omitted.

> I think core-language-feature counts are something it's better to have in moderation. If an app needs something, it will either get it from there, or failing that, from add-on packages. That only matters for fitting into a small embedded system where you can perhaps get a smaller image if you just bundle the exact set of packages that are required. Due to inter-package dependencies, that plan can easily be foiled.…

I agree about batteries-included languages, but that applies more to library-type tools , IMO, than language features . A library-type tool is something like "I need to get an md5 hash; I hope a function to do that is included with the language distribution so I don't need to go find a library!". A language feature is something in response to questions like "How do I express that I'm calling a method on an object? Or…

> but that applies more to library-type tools, IMO, than language features.

I'm a Lisp person of many years, so my perception of this distinction has gradually atrophied, dried and fallen off. But even in this context, I would still rather have a larger language (more stuff which is Just There), even though more kinds of things can be add-on modules in Lisp than in something like Perl.

Re: Perl and Undecidability (2008)

#102

Post by ionforce »

lmm wrote: post #54
hpcjoe wrote: post #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 peo…

Some tools are appropriate for particular situations. Most are better off being entirely replaced. There are thousands of programming languages out there, while the ideal toolbox would contain dozens at most; our industry badly needs some pruning. We need to have these conversations, and they're not going to be easy precisely because we're emotionally attached to our tools, but frankly if you're really so detached as…

Where did you get the phrase "throwing shade on" from?

Re: Perl and Undecidability (2008)

#103

Post by ionforce »

psergeant wrote: post #3
grabcocque wrote: post #2

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

This is one of the most well-reason and true responses I've ever read about Perl.

Who are you?

Re: Perl and Undecidability (2008)

#104

Post by ionforce »

psergeant wrote: post #15
jasode wrote: post #8

Earlier quoted context omitted.

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

Why do you write it in all capitals?

I thought I was the only person who asked this.

Re: Perl and Undecidability (2008)

#105

Post by yellowapple »

jandrese wrote: post #95
esaym wrote: post #93

Perl is awesome. I bring in 90k+ a year making a living on perl while only working remotely ( and living in a small city where the avg household income is Honestly, the only reason python "won" was because google picked it up for internal use (and that was only because of the perl5/6 debacle since why pick perl5 since 6 would be coming out by next Christmas?) As far as "undecidable", its a feature and one of the reas…

IMHO, Perl was hurt more by its sigils than the protracted P6 development. There was a lot of revulsion to sprinkling your code liberally with $, @, and %. Many many comments about writing unreadable line noise when programming Perl. Python's genius was to force programmers to indent their code, making sure it had at least a modicum of structure.

I still don't understand that revulsion. Yeah, it looks "ugly", maybe (a valid but very subjective opinion), but it also makes it obvious that something is a variable and - specifically - whether that variable is singular or plural at a given moment.

The "Perl is indistinguishable from line noise" meme came about from folks equating JAPH-style Perl Golf one-liners with all of Perl. It had very little to do with the use of sigils specifically; such "line noise" is perfectly possible in Ruby and Python.

If anything specific to Perl contributed to the "Perl is line noise" meme, it's probably the fact that a bunch of special variables have names consisting of punctuation marks. Nothing stopping the programmer from doing a "use English;", though.

Re: Perl and Undecidability (2008)

#106

Post by lmm »

ionforce wrote: post #102
lmm wrote: post #54

Earlier quoted context omitted.

Some tools are appropriate for particular situations. Most are better off being entirely replaced. There are thousands of programming languages out there, while the ideal toolbox would contain dozens at most; our industry badly needs some pruning. We need to have these conversations, and they're not going to be easy precisely because we're emotionally attached to our tools, but frankly if you're really so detached as…

Where did you get the phrase "throwing shade on" from?

No idea. Picked it up from general conversation.

Re: Perl and Undecidability (2008)

#107

Post by dagw »

eesmith wrote: post #89
dagw wrote: post #44

Earlier quoted context omitted.

I don't think the language design influence of Perl on Python was as strong as you imply. I think the influence was mainly in Guido looking at Perl and realizing he wanted a language that didn't look like that. I'm pretty sure the Guido has said that ALGOL 68 and Pascal was probably the biggest positive outside influences (together with some in-house language called ABC that he was using at the time)

When you say "that didn't look like that", are you presenting a conjecture? There was only a few years between the first release of Perl and the start of Python. van Rossum's 1993 paper at http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=51C... explicitly lists C, ABC, Modula-3, Icon, C++, and Smalltalk as influences. The section "competitors or precursors" also includes Perl and Tcl. It does not appear these…

The statement about Perl came from an interview with him I read.

Re: Perl and Undecidability (2008)

#108

Post by Diederich »

zbentley wrote: post #77
Ultimatt wrote: post #14

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

The size of the CPAN is certainly impressive. However, past a certain point, a big, multipurpose, monolithic Perl codebase being worked on by a ton of different developers is going to have significant problems caused specifically by the use of different CPAN libraries: many, many quite common libs do not "play well" with each other in quite simple cases. And I'm not talking about "I'm trying to glue together two thir…

> CPAN is incredibly bloody far from a high-quality, stable, or usable code repository for certain very common use cases.

Citation needed.

Re: Perl and Undecidability (2008)

#109

Post by yellowapple »

oblio wrote: post #17
pjc50 wrote: post #12

Earlier quoted context omitted.

Perl used to have fans with meetups and so on. I've not heard of these for a long time. IMO three things killed Perl, leaving it as an unpopular legacy husk: - loss of ecosystem. The high points for Perl were CGI.pm and its use as a "super awk" by sysadmins. The first was obliterated by other ecosystems, better and worse: PHP, Rails, Node, Go, and so on. The second was obliterated by "servers are cattle not pets": pe…

> Python managed to avoid this level of community damage but has still split into two languages, Python 2 and Python 3. The fracture is very slowly healing. Outside of some huge corporate hold outs with a lot of Python 2 code (Google & co.), Python 3 will win out. Perl 6 vs Perl 5, on the other hand, I don't even know if you can call it a fracture. A new start would be more fitting.

It's definitely a new start, but both Perl 5 and Perl 6 each have various modules bridging the gap between the two. Yeah, they're definitely separate languages, but (at least in theory) they're very much interoperable.

I don't know much about the Python ecosystem, but my impression is that besides the 2to3 program there wasn't really much of an effort to make them work together.

Re: Perl and Undecidability (2008)

#110

Post by yellowapple »

dozzie wrote: post #23
pjc50 wrote: post #12

Earlier quoted context omitted.

Perl used to have fans with meetups and so on. I've not heard of these for a long time. IMO three things killed Perl, leaving it as an unpopular legacy husk: - loss of ecosystem. The high points for Perl were CGI.pm and its use as a "super awk" by sysadmins. The first was obliterated by other ecosystems, better and worse: PHP, Rails, Node, Go, and so on. The second was obliterated by "servers are cattle not pets": pe…

> IMO three things killed Perl, leaving it as an unpopular legacy husk [...] I don't really think it was any of these. There's much simpler mechanics at play here: Perl's competition (Python and Ruby) has about the same expressiveness, but is much easier to learn, so for a long time very few people have chosen Perl to learn. There was simply not enough young blood to replace old timers that were retiring, dying, or m…

I find that interesting, since of those three, Perl was the first language that really "clicked" for me (Ruby was almost that language, but it didn't start clicking until after I had learned Perl; Python still ain't really clicking, though it's gotten a bit better lately).
Post reply on HN