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

121–127 of 127 posts

Re: Perl and Undecidability (2008)

#121

Post by Ultimatt »

zbentley wrote: post #117
Diederich wrote: post #108

Earlier quoted context omitted.

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

I agree there is a lot of dross on CPAN. I've also lived the frustration of seeing two kinds of exception handler TryCatch vs Try::Tiny in the same subdir of a codebase. The issue is really that a lot of basic modern functionality requires CPAN, and the core of Perl 5 is small and mostly not super helpful. Something akin to Moose in core as the new standard way to do OO would have been a good plan 10 years ago.

Re: Perl and Undecidability (2008)

#122

Post by SonOfLilit »

masukomi wrote: post #70
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.

In python there are also lots of ways to do things, but usually only one obvious one. The same, I think, goes for Ruby.

Re: Perl and Undecidability (2008)

#123

Post by Diederich »

zbentley wrote: post #117
Diederich wrote: post #108

Earlier quoted context omitted.

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

I read your post carefully, and I even agree with parts of it. There are major modules/module families that don't work together.

However, that's light-years from the claim that I quoted.

There are a lot of different ways of doing the same things in Perl the language and in the CPAN ecosystem. That's a strength and weakness. But in my experience, the authors of most of the modules care very deeply about doing things in a sustainable way.

Re: Perl and Undecidability (2008)

#124

Post by cutler »

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

Faster OO but dog slow regexes? This is Perl, right? The Practical Extraction and Reporting Language where extraction is largely the work of regular expressions and, now, grammars. OO languages are a dime a dozen so how can OO be Perl 6's main priority?

Re: Perl and Undecidability (2008)

#126

Post by b2gills »

cutler wrote: post #124
Ultimatt wrote: post #120

Earlier quoted context omitted.

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

Faster OO but dog slow regexes? This is Perl, right? The Practical Extraction and Reporting Language where extraction is largely the work of regular expressions and, now, grammars. OO languages are a dime a dozen so how can OO be Perl 6's main priority?

To be fair Perl 6 returns structured data from regexes, whereas Perl 5 returns flat data. That has huge implications on how different the regex sub-languages gets parsed. It also has a significantly different syntax, and integrates more into the rest of the language. Basically it had to be created from scratch, so that would mean that it couldn't benefit from the already existing optimizations of the Perl 5 regex engine.

Perl 6 is also a mostly unpaid volunteer effort. So everybody gets to choose what they work on, and very few people are brave enough to work on that aspect of the compiler.

Also I would say that the main priority of Perl 6 is to integrate many ideas from many languages and bring them together in such a way that it seems as if all of these ideas always belonged together.

The reason why the object system sees more optimizations is because everything is, or can be seen as, an object. A big improvement there, can for example make regexes faster.

Re: Perl and Undecidability (2008)

#127

Post by carlmr »

daotoad wrote: post #111
carlmr wrote: post #35

Earlier quoted context omitted.

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

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

That mixing and matching seems exactly like the quirks a linguist would pick up that lower usability (at least for the general user, Unix users are kind of used to being thrown in the deep end of the usability pool).

Post reply on HN