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

71–80 of 127 posts

Re: Perl and Undecidability (2008)

#71

Post by jasode »

kbp wrote: post #69
jasode wrote: post #66

Earlier quoted context omitted.

>Saying the former lost out because the @ makes it unreadably terse is nonsense. Well, that's not what I claimed. I also wasn't really focused on "@%$" specifically but you had brought it up so went with it. (I get this weird feeling that I'm discussing with someone who's emotionally invested in Perl and he feels like I'm bashing Perl. Please let's us both stop this and make sure we're talking about Perl in a detache…

> I also wasn't really focused on "@%$" specifically but you had brought it up My involvement in this conversation started with quoting you saying that one of the major reasons for Perl becoming disliked was "PERL's usage of sigils.[1] One the one hand, it makes code compact and terse". Perl's use of sigils has nothing to do with terseness, and since Perl lost its mindshare to Ruby and Python which to the tiny extent…

>, I don't think that's a valid point about Perl's trajectory.

Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. I feel you have my comments mixed up with someone else.

>'' are not used as sigils in Perl.

I agree and I didn't say they were.

That's 3 cases of nitpicking something I actually didn't claim. I can only assume this over-interpretation of things I didn't write is a result of some underlying irritation that I caused. Let's just stop. Peace.

Re: Perl and Undecidability (2008)

#72

Post by rcthompson »

c0m0 wrote: post #67
knome wrote: post #20

Earlier quoted context omitted.

perl works fine, and you aren't going to unexpected trigger an infinite loop due to some bug in the language definition. What you can't do is tell how to parse a piece of perl without running the program. http://www.perlmonks.org/?node_id=663393 These are an expounding upon this link. In most languages, you can at least tell what things are. This is a function. That's a variable. In perl, there are constructs whose p…

If you can't in general parse a piece of perl without "running the program" as you yourself mentioned then I'm pretty sure that parsing it can definitely trigger infinite loops as perl language is definitely turing complete during run time. So your statement is a contradiction.

The comment said you won't cause an infinite loop during parsing due to a bug in the language definition, not that you can't do so at all. Perl lets you run arbitrary code during parsing, so of course it's possible to run an infinite loop while parsing. But you can only do that by actually writing an infinite loop in your code, not by writing something that confuses the parser into looping forever.

Re: Perl and Undecidability (2008)

#73

Post by kbp »

jasode wrote: post #71
kbp wrote: post #69

Earlier quoted context omitted.

> I also wasn't really focused on "@%$" specifically but you had brought it up My involvement in this conversation started with quoting you saying that one of the major reasons for Perl becoming disliked was "PERL's usage of sigils.[1] One the one hand, it makes code compact and terse". Perl's use of sigils has nothing to do with terseness, and since Perl lost its mindshare to Ruby and Python which to the tiny extent…

>, I don't think that's a valid point about Perl's trajectory. Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. I feel you have my comments mixed up with someone else. >' ' are not used as sigils in Perl. I agree and I didn't say they were. That's 3 cases of nitpicking something I actually didn't claim. I can only assume this over-interpretation of things I didn't write is a…

> Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine.

Well, if you just weren't considering Python and Ruby, then aren't they counter-examples to your point? They're terser than Perl in that regard; if that's a major reason people moved away from Perl, then why did so many of them move to those languages?

> I agree and I didn't say they were.

Then why did you bring them up in a discussion about sigils?

Re: Perl and Undecidability (2008)

#75

Post by deathanatos »

arnsholt wrote: post #29
jwilk wrote: post #10

It's worse than that. You can't parse Perl without running arbitrary Perl code: https://www.perlmonks.org/?node_id=663504

So? It's not that uncommon for highly dynamic languages to do this. Lisp macros for example depend on being able to run arbitrary code at compile-time.

Is it? (I honestly have no idea about Lisp.) It isn't just about being able to do stuff at compile time: In Perl's case, as I understand it, you can't determine if a string of text is a valid (in the sense of generating an AST!) Perl program without executing it. This precludes things like reliable syntax highlighting.

Languages can include meta-programming/macro facilities without effecting whether or not the parser can do its job; I am fairly certain that Rust's macros are an example of this. Python, as a more dynamic language, also includes metaprogramming facilities (metaclasses, decorators) but IIRC, can still be parsed without needing to simulate a Turing machine.

Re: Perl and Undecidability (2008)

#76

Post by zbentley »

ceronman wrote: post #6
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 a very practical language. But this practicality has been achieved by building features on top of bad design. The result is a big, complex and quirky language. To make this worse, the community decided to "fix" this re designing the whole language from scratch. They created Perl 6 which has a much better design, but it's incompatible. The community now it's broken in two and the future doesn't look that good.

I think the word "big" above is often overlooked when discussing Perl (5). For a scripting language, there are an incredibly huge number of core language features. Even compared to something like Ruby or a lisp-like language with a true templating/macro system. It's easily up there with c++ in terms of "number of (sometimes crazy) things you can do with the core language/distribution out of the box".

And that's not even a statement about how many ways there are to the same/similar things things; these features all are intended to facilitate different stuff. I think it is the biggest language I've ever programmed in, fighting for top spot with C++.

I think core-language-feature counts are something it's better to have in moderation. JavaScript of ~2010 was far too small a language, so it had crazy library/cargo-cult utility bloat. Lisp is somewhat similar: it's elegance in its small size and simplicity, but that results in a lot of beginners (re)writing a lot of unnecessary code. Perl and C++ have too many core-language features; everything else is somewhere in the middle.

...and all that is without even getting into some of the insane language extensions you can find in third-party libraries. There's an on-after-module-load hook someone wrote that's implemented in terms of a syntax extension to the language, that isn't quite an operator or a statement. There's a coroutine library which is written mostly inside to the fatal-killsignal core dump handler I think (or something similar). And the list goes on.

Re: Perl and Undecidability (2008)

#77

Post by zbentley »

Ultimatt wrote: post #14
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…

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 third-party tools that weren't written with each other in mind", I'm talking "I have a request handler that once, an hour ago had to load and call a function in a given module, and is now issuing cryptic errors on all requests of a certain type because they happen to call a function in a different, totally unrelated module that worked before".

This is largely because of the sheer volume of weird global state inspections/mutations you can do in Perl--or I guess it's more accurate to say that Perl has a conveition of it being "OK" to heavily and frequently inspect and mutate global state. You can monkey patch in many languages, and sometimes it's even encouraged (Ruby), but only in Perl is it not uncommon to see monkeypatch removal or seriously altering replacement of core functionality. I've had modules hackily unload other already modules because the loaded modules' names matched a buggy load-time regex. I've had packages clobber text handling or encoding routines in other packages at compile time, or only after calling a certain function a certain way. I've had modules change the behavior of the core signal handling APIs so that any code that talked to them . . . didn't actually handle signals. And those are just the pithy examples that fit in a single sentence.

Now granted, this isn't a criticism of Perl-the-language but more of (depending on how you choose to interpret it) library authors who don't prioritize or even consider interoperability with other tools, or of Perl-the-community's conventions regarding when it's OK to go mess around in globally-stateful guts of code you don't control. You could also just as easily say that it's a symptom of the big, multipurpose monolith I had to maintain--which is valid, but other not-designed-for-huge-projects languages don't, in my experience, have problems quite this bad when they're forced to scale.

My goal isn't to cast blame, but to point out that CPAN is incredibly bloody far from a high-quality, stable, or usable code repository for certain very common use cases.

Re: Perl and Undecidability (2008)

#78

Post by zbentley »

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

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

Utter and unabashed tangential pedantry: Perl should not be all-caps. The PERL "acronym" is actually a backronym (or "retronym" if you like): https://docstore.mik.ua/orelly/perl3/lperl/ch01_02.htm

Re: Perl and Undecidability (2008)

#79

Post by kazinator »

zbentley wrote: post #76
ceronman wrote: post #6

Earlier quoted context omitted.

Perl is a very practical language. But this practicality has been achieved by building features on top of bad design. The result is a big, complex and quirky language. To make this worse, the community decided to "fix" this re designing the whole language from scratch. They created Perl 6 which has a much better design, but it's incompatible. The community now it's broken in two and the future doesn't look that good.

I think the word "big" above is often overlooked when discussing Perl (5). For a scripting language, there are an incredibly huge number of core language features. Even compared to something like Ruby or a lisp-like language with a true templating/macro system. It's easily up there with c++ in terms of "number of (sometimes crazy) things you can do with the core language/distribution out of the box". And that's not e…

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

In the end, it's better to have a big, "batteries included" language. For one thing, it is all released at once. No separate versioning for one hundred different packages. The regression test suite for the language can cover that functionality which would otherwise be in packages. No nonsense of releasing a new version of the language and then relying on field reports about broken packages.

Re: Perl and Undecidability (2008)

#80

Post by kazinator »

SonOfLilit wrote: post #26

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…

Lisp is also undecidable simply because the body of a (defmacro ...) form can do anything, including getting into a loop and not terminating.

Programming in general is undecidable even if the compiling of the language isn't. Whether or not a program gets to the executable stage may be decidable in some language, but whether that program terminates and calculates the correct result isn't. (So what good is the first order decidability, at the end of the day.)

In practice, building everyday, run of the mill programs terminates in a reasonable time. The undecidability means that the time isn't guaranteed; we must be prepared to wait arbitrarily long for a compilation, and to forcibly terminate it it we feel that it seems like it won't complete. And when we do that, we have no proof that it wouldn't have completed. But, so what; if a file that should take seconds to compile takes 15 minutes (i.e. that particular case is decidable), we still regard that as a problem. Why on Earth is it taking 15 minutes? Either something is wrong, or we have to adjust our expectation for that file.

Post reply on HN