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

111–120 of 127 posts

Re: Perl and Undecidability (2008)

#111

Post by daotoad »

carlmr wrote: post #35
dmytrish wrote: post #31

Earlier quoted context omitted.

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.

Perl is essentially a pigdin or creole language composed of C, shell, awk, sed and POSIX concepts with bits of Lisp thrown in.

If you know Unix, you will already know about 80% of perl. If you know Perl well, you already know a lot of Unix concepts.

Perl is a pain to learn if you don't have a solid Unix background. However, IME, if you acknowledge the sources Perl draws from, look at how they're integrated, and spend some time learning the underlying technical culture, it actually simplifies the learning process.

Interestingly enough, it's also easier to learn a natural language if you spend some time learning the underlying culture.

Re: Perl and Undecidability (2008)

#112

Post by [deleted] »

rcthompson wrote: post #72
c0m0 wrote: post #67

Earlier quoted context omitted.

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.

[deleted]

Re: Perl and Undecidability (2008)

#113

Post by cutler »

It's almost 2 years since Perl 6 was released and it's still dog slow at what Perl 5 was famous for - string parsing with regular expressions. A 19Mb Apache log file on my 2010 quad core Mac takes Perl 6 21 secs. to search for lines containing 15-character words compared with Ruby: 4secs, Perl 5: 2.4 secs. and PHP7: 0.8 secs. We keeping hearing how the optimisations are coming but I haven't seen any significant improvements in string parsing since Perl 6 was released in December 2015. How can you market the advantages of a new version of a language when it can't even match its predecessor?

Re: Perl and Undecidability (2008)

#114

Post by [deleted] »

ionforce wrote: post #103
psergeant wrote: post #3

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.

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

[deleted]

Re: Perl and Undecidability (2008)

#115

Post by psergeant »

ionforce wrote: post #103
psergeant wrote: post #3

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.

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

https://perl.careers/

Re: Perl and Undecidability (2008)

#116

Post by kbp »

deathanatos wrote: post #75
arnsholt wrote: post #29

Earlier quoted context omitted.

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

> Is it? (I honestly have no idea about Lisp.)

In Lisp you can modify the read table at run time, so you can do whatever you want. The functions the reader calls when it comes across '(', ')', ' ', and every other character are all completely customisable.

Re: Perl and Undecidability (2008)

#117

Post by zbentley »

Diederich wrote: post #108
zbentley wrote: post #77

Earlier quoted context omitted.

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.

Read the rest of my post. If you don't agree, that's fine.

Re: Perl and Undecidability (2008)

#119

Post by Ultimatt »

ionforce wrote: post #118
lmm wrote: post #106

Earlier quoted context omitted.

No idea. Picked it up from general conversation.

You're not using it correctly. You don't throw shade /on something/, you throw shade /at someone/.

In British English at least to cast shade on is a perfectly common idiom.

Re: Perl and Undecidability (2008)

#120

Post by Ultimatt »

cutler wrote: post #113

It's almost 2 years since Perl 6 was released and it's still dog slow at what Perl 5 was famous for - string parsing with regular expressions. A 19Mb Apache log file on my 2010 quad core Mac takes Perl 6 21 secs. to search for lines containing 15-character words compared with Ruby: 4secs, Perl 5: 2.4 secs. and PHP7: 0.8 secs. We keeping hearing how the optimisations are coming but I haven't seen any significant impro…

Because its faster at OO than Perl 5 and has a tonne of other builtins that make it easier to write algorithmically performant code. Not to mention its trivial to write parallel code. I dont think there have been any optimisations in the regex engine in the time you're discussing. The raw IO however has seen huge improvement, especially if you state you arent using unicode and don't want grapheme normalisation. In 2011 just my tests took 35s to execute. Now that's 1s and startup time is 2/3 of that. Something like CSV parsing or even log parsing where you split instead of regex is competitive. Last I checked faster than Ruby but slower than C. But yeah you do still have to work around the slow bits, or be explicit with what you want like ascii IO.
Post reply on HN