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

41–50 of 127 posts

Re: Perl and Undecidability (2008)

#41

Post by eru »

c0m0 wrote: post #11
c0m0 wrote: post #5

For the people out there that's not so into CS, and does not understands it's implications. It basically means you could write a perl program that could cause an infinite loop in the interpreter (or compiler). This I would presume independant of the actual implementation of the compiler and intrepreter as that would only mean this is a bug report for the specific implementation, and not a problem with the language de…

Actually the problem has more implications, as it's an effect of parsing the code. Any IDE:s that have advanced features that rely on parsing and analysis of the code can be caught in an infinite loop and stop responding. The sad part is, in the general case it's impossible for the parser (or any other process overviewing it) to decide if it's actually caught in an infinite loop or not, that's why they call it undeci…

In theory, yes. Of course in practice, it's not so bad: they can run the parser in a different thread, they can put hard limits on how long they run, etc.

(The hard limit is how C++ gets parsed, I think. Since parsing C++ is also undecidable thanks to weird interactions with template metaprogramming.)

Re: Perl and Undecidability (2008)

#42

Post by jasode »

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…

The terseness isn't the variable name, it's the notation of the type:

  @foo
... is more compact than C#...

  ArrayList foo = new ArrayList();  // C# v2
  var foo = new ArrayList();  // C# v3
And Perl

  %foo
... is more compact than C++:

  auto foo = std:map;

Re: Perl and Undecidability (2008)

#43

Post by [deleted] »

eesmith wrote: post #36
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…

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.

[deleted]

Re: Perl and Undecidability (2008)

#44

Post by dagw »

eesmith wrote: post #36
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…

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.

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)

Re: Perl and Undecidability (2008)

#45

Post by kbp »

jasode wrote: post #42
kbp wrote: post #40

Earlier quoted context omitted.

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

The terseness isn't the variable name , it's the notation of the type : @foo ... is more compact than C#... ArrayList foo = new ArrayList(); // C# v2 var foo = new ArrayList(); // C# v3 And Perl %foo ... is more compact than C++: auto foo = std:map ;

But when you talk about Perl stagnating and losing out to other languages, the languages it lost out to were Python and Ruby, which don't require any type notation. It also lost out to PHP, which has sigils, but they don't carry as much information: $foo just means foo is a variable. Perl didn't lose out to C++ and C#; they were never really competing in the same domain.

In Perl, you write:

    my @list = (1, 2, 3);
Whereas in Perl's popular successors, Python and Ruby, you write:

    list = [1, 2, 3]
Saying the former lost out because the @ makes it unreadably terse is nonsense.

Re: Perl and Undecidability (2008)

#46

Post by kbp »

jasode wrote: post #39
Ultimatt wrote: post #34

Earlier quoted context omitted.

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

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

Perl is not competing with C++; they're entirely different languages with entirely different usecases. Comparing it to Python is reasonable; comparing it to C++ is silly.

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

Newer C++ versions are more akin to newer Perl 5 versions like 5.26 (May 2017), 5.24 (May 2016) etc. Perl 6 is a new language using some of the same ideas; comparing Perl 5 and Perl 6 is like comparing C++ and C#, not C++ and C++17.

Re: Perl and Undecidability (2008)

#47

Post by jasode »

kbp wrote: post #46
jasode wrote: post #39

Earlier quoted context omitted.

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

> 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. Perl is not competing with C++; they're entirely different languages with entirely different usecases. Comparing it to Python is reasonable; comparing it to C++ is silly. > Also, updates to C++ via C++14 and C++17 were discussions that…

>Perl is not competing with C++; they're entirely different languages with entirely different usecases.

Yes, I understand that C++ does not compete with Perl. My point is the rejuvenation stories, not the runtime or use case differences.

I use a utility every day called ExifTool[1] that's 100% Perl source code or very close to it. However, ExifTool does not keep Perl at the top of mind the way Tensorflow brings Python relevancy to a new generation of programmers.

[1] https://www.sno.phy.queensu.ca/~phil/exiftool/

Re: Perl and Undecidability (2008)

#48

Post by bshimmin »

jwilk wrote: post #30
virgilp wrote: post #27

Earlier quoted context omitted.

> TIMTOWTDIBSCINABTE That's an apt motto for perl. One doesn't even need to know what it means.

There's more than one way to do it, but sometimes consistency is not a bad thing either.

Has anyone been able to do this for PHP's T_PAAMAYIM_NEKUDOTAYIM yet? (I know it's not an acronym, but I wish it were.)

Re: Perl and Undecidability (2008)

#49

Post by kbp »

jasode wrote: post #47
kbp wrote: post #46

Earlier quoted context omitted.

> 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. Perl is not competing with C++; they're entirely different languages with entirely different usecases. Comparing it to Python is reasonable; comparing it to C++ is silly. > Also, updates to C++ via C++14 and C++17 were discussions that…

>Perl is not competing with C++; they're entirely different languages with entirely different usecases. Yes, I understand that C++ does not compete with Perl. My point is the rejuvenation stories, not the runtime or use case differences. I use a utility every day called ExifTool[1] that's 100% Perl source code or very close to it. However, ExifTool does not keep Perl at the top of mind the way Tensorflow brings Pytho…

> Yes, I understand that C++ does not compete with Perl. My point is the rejuvenation stories

Well, the way C++ had new versions released in 2017 and 2014, Perl 5 had new versions released in 2017 and 2016; what stagnation are you demonstrating? You said "updates to C++ via C++14 and C++17 were discussions that turned into reality"; and the same thing happened with updates to Perl 5 (which is the language "Perl" is usually shorthand for). Perl 6 is an entirely different language, it, along with languages like Ruby, compares to Perl 5 the same way C# and Rust compare to C++.

Post reply on HN