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

61–70 of 127 posts

Re: Perl and Undecidability (2008)

#61

Post by eru »

knome wrote: post #55
eru wrote: post #41

Earlier quoted context omitted.

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

Yes, templates are turing complete. https://github.com/knome/metabrainfuck/blob/master/bf.cpp Does attempting to autocomplete such a template cause issues for IDEs? I used emacs when writing it, so I've never tested such a thing.

For simpler languages you can implement logic in the editor / IDE for things like precise autocomplete and parsing.

For C++ even precise syntax colouring would be undecidable---and just hard to get the logic right. There are two ways out: (1) implement an approximation and the occasional impression, (2) ask the compiler for help. I think the llvm project helps with the latter.

(What does emacs have to do with things? Or do you mean you are using emacs without any special support for C++? With the right modes you can turn your emacs (or vim etc) into basically a fully fledged IDE.)

Re: Perl and Undecidability (2008)

#62

Post by Ultimatt »

carlmr wrote: post #37
Ultimatt wrote: post #7

Earlier quoted context omitted.

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 .

Well not just what they know, but what all their existing stuff is written in. Makes sense too. The two Perls aren't really that compatible, far worse than migrating Python 2 to 3 and companies struggled with that manoeuvre. You can run and call each language from the other, with some in memory wrangling between https://github.com/niner/Inline-Perl5 But the same is true for Python and Java objects.

Re: Perl and Undecidability (2008)

#63

Post by Ultimatt »

rurban wrote: post #18
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…

It's more caused by the toxic climate amongst it's maintainers, paired with technical and management incompetence. When Larry Wall was still the lead a lot of progress was made, but then it reversed course in the last 20 years. Every single competent developer left or was booted, and not a single of the many designed features for Perl6 were properly implemented in perl5. Perl5 is now purely a religion, with the heres…

Given this commentary, its probably worth highlighting you're the developer of an entire fork of the perl codebase... Rather than the average user.

Re: Perl and Undecidability (2008)

#64

Post by pwdisswordfish »

dozzie wrote: post #21
pwdisswordfish wrote: post #13

Earlier quoted context omitted.

http://www.perlmonks.org/?node_id=663504 Site's not ready for 21st century.

Indeed it's not ready. It loads and reacts to clicks too fast and doesn't use two megabytes of JavaScript.

https://i.imgur.com/ImKOkpH.png https://i.imgur.com/ih1mK80.png

I guess it's time to love JavaScript, because with 2mb bundles it keeps people with literally no clue like you from not being my colleagues.

Re: Perl and Undecidability (2008)

#65

Post by dotandimet »

bshimmin wrote: post #48
jwilk wrote: post #30

Earlier quoted context omitted.

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

PAAMAYIM_NEKUDOTAYIM isn't an acronym, it's Hebrew for "two dots twice", ie, :: (double colon)

I think the two Israeli guys who wrote the first PHP runtime used it either as a private joke or because they couldn't think of how it's called in English.

Re: Perl and Undecidability (2008)

#66

Post by jasode »

kbp wrote: post #45
jasode wrote: post #42

Earlier quoted context omitted.

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); Wher…

>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 detached manner.)

Yes, strlen("my @list = (1, 2, 3)") is greater than strlen("list = [1, 2, 3]"). I wasn't talking about that. I was talking about things like strlen("@") A realistic scenario where perceptions of "@" and "Arraylist" is compared would be a C# programmer working on an ASP.NET website or Javascript programmer working on Nodejs and then the company needs him to go fix an old website that was written in Perl ~15 years ago. The old Perl programmer left and C# programmer is stuck looking at Perl's "line noise". That irritated C# programmer then fills the Stackoverflow survey expressing his "dislike" of Perl. The C# and Javascript looked "readable" but Perl syntax such as "" looked like gibberish.

Re: Perl and Undecidability (2008)

#67

Post by c0m0 »

knome wrote: post #20
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…

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.

Re: Perl and Undecidability (2008)

#68

Post by hoytech »

dmytrish wrote: post #31
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 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.…

Most of these design decisions are very useful and pragmatic, and not everyone regards them as "crappy".

Additionally, there are several misleading statements in your post. I expect you are aware of the following but just for the record:

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

Perl uses dynamic scoping (https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynam...) when setting $_ and friends. For example:

    $ perl -E '$_ = "A"; say; say for ("B", "C"); say;'
    A
    B
    C
    A
For me, dynamic scoping (and, relatedly, RAII) is sorely missed in languages that don't have it. (Although I do agree about $a/$b in sort -- that's a language wart, but not too bad in practice)

> - autovivification: a single read by key from a hash is enough to actually create this key;

Not true:

    $ perl -MData::Dumper -e 'my $h = {}; $h->{a}; print Dumper($h)'
    $VAR1 = {};
You need to read it as a hash or array reference for it to autovivify:

    $ perl -MData::Dumper -e 'my $h = {}; $h->{a}->{b}; print Dumper($h)'
    $VAR1 = {
              'a' => {}
            };
Autovivification is another feature that I miss in languages that lack it.

Your points about the perl5 implementation are definitely accurate, although I suspect a lot of language implementations have their own dirty laundry as well. :)

Re: Perl and Undecidability (2008)

#69

Post by kbp »

jasode wrote: post #66
kbp wrote: post #45

Earlier quoted context omitted.

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); Wher…

>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 that sigils contribute to terseness/verbosity are more terse, I don't think that's a valid point about Perl's trajectory.

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

I don't even know Perl, I'm just critiquing your logic.

> Perl syntax such as ""

'' are not used as sigils in Perl.

Re: Perl and Undecidability (2008)

#70

Post by masukomi »

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…

ruby did not go the python way and have only have a couple ways to solve a problem. There may not be quite as many ways to solve something as perl allows but it's still allows for a lot of options.
Post reply on HN