Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Perl Didn't Win

outspeaking.com

Post reply on HN
Print view View original

171–180 of 187 posts

Re: Why Perl Didn't Win

#171

Post by duskwuff »

ptx wrote: post #152
duskwuff wrote: post #136

Earlier quoted context omitted.

If you seriously think that Perl5 is less suitable for text processing than Perl4 was, I suspect you haven't actually used the language in a while... it's still perfectly good for that. Perhaps even better, since 5.8 added extensive support for Unicode (without requiring explicit conversions and breaking everything like Python 3 did).

From a quick skimming through the docs[0], Perl 5.8's Unicode support sounds a lot like Python 2's except that the default encoding is latin1 instead of ASCII - i.e. unlike the Python 3 way of explicitly decoding binary data into Unicode text at the point where it's read (where presumably the encoding of the data is known), it will defer the decoding until the data is used (at some completely unrelated point in the p…

The documentation you're looking at is quite old; I'd recommend looking at the current version for a better view. (The implementation is largely the same; the documentation has just improved quite a bit since then.)

http://perldoc.perl.org/perluniintro.html

Anyways, Perl5's Unicode support is quite different from Python's.

Specifically, it doesn't have distinct "Unicode string" and "byte string" types; instead, it has a single unified string type. These strings may be internally stored as Latin1 or UTF-8, depending on how they were created, but they behave identically for almost[1] all purposes, and there are easy ways to force Perl to convert between the formats. It's still possible to create a nonsensical string if you do something silly like append Unicode characters to a string containing raw UTF-8 data, but that's not something the language can entirely protect you from.

[1]: The only exceptions I'm aware of are functions which explicitly operate on the utf8 status, like utf8::is_utf8(), and bitwise operations like &|^ and vec().

Re: Why Perl Didn't Win

#172

Post by b2gills »

ptx wrote: post #152
duskwuff wrote: post #136

Earlier quoted context omitted.

If you seriously think that Perl5 is less suitable for text processing than Perl4 was, I suspect you haven't actually used the language in a while... it's still perfectly good for that. Perhaps even better, since 5.8 added extensive support for Unicode (without requiring explicit conversions and breaking everything like Python 3 did).

From a quick skimming through the docs[0], Perl 5.8's Unicode support sounds a lot like Python 2's except that the default encoding is latin1 instead of ASCII - i.e. unlike the Python 3 way of explicitly decoding binary data into Unicode text at the point where it's read (where presumably the encoding of the data is known), it will defer the decoding until the data is used (at some completely unrelated point in the p…

Why are you pointing to the unicode entry doc in an ancient version of Perl?

Also according to perlunifaq the minumum version you should be using is 5.8.1 which the documents for 5.8.0 would of course not mention.

Really if you want good unicode handling you should probably use 5.16.0 or later. If you want the latest version of Unicode there are ways of changing which version of Unicode Perl is compiled with, but it is easier to just use the latest version of Perl, which is 5.20.

http://perldoc.perl.org/perluniintro.html http://perldoc.perl.org/perlunitut.html http://perldoc.perl.org/perlunifaq.html http://perldoc.perl.org/perlunicode.html

p.s. I noticed in the Python talk you linked that no one knew that the pile of poo symbol is in there because the japanese characters for luck and poo are very similar. ( I am unable to find a link to where I first read this ) The Japanese are also responsible for why we call them emoji (e means image, and moji means character. ) http://www.fastcompany.com/3037803/the-oral-history-of-the-p...

Re: Why Perl Didn't Win

#173

Post by duskwuff »

raiph wrote: post #139
duskwuff wrote: post #38

Earlier quoted context omitted.

> Can one even use CPAN with Perl6? Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time (like all of the PyPI packages that support both Python2 and Python3)? Respectively: Not at all, and not without major contortions. The languages have diverged a lot ; even basic tasks like defining a function are not the same.

> Not at all [can one use CPAN] You are mistaken. See my nearby comment about Inline::Perl5. > not without major contortions [can one convert]. One doesn't need to convert (due to Inline::Perl5). That said there can be valid reasons (eg having fun and learning Perl 6) to want to convert existing Perl 5 code to a Perl 6 equivalent anyway. While some partial P5-to-P6 conversion tools already exist[1] (and I'd be surpri…

Perl5.18 has some limited support for Perl6-style function signatures, but it's still considered "experimental" and requires a pragma to enable. I don't consider that to really be part of the language yet; real-world Perl5 function definitions end up looking like this, at best:

    sub foo {
        my ($foo, @bar) = @_;
        ...
    }
I'm not sure if that's valid syntax in Perl6 or not, but either way it's certainly not idiomatic.

Re: Why Perl Didn't Win

#174

Post by bmn_ »

mrottenkolber wrote: post #79
simcop2387 wrote: post #74

Earlier quoted context omitted.

A small correction there, you aren't making them public by putting them in EXPORT. What you're doing is actually using another module to munge the namespace that used your class. In fact by default all functions defined in a package that is used as a class are public by default. And here's the boiler plate for more modern perl: package MyClass; use Moose; 1; You can define properties of the class using has 'property'…

Why do you need to return 1 though? That seems pretty ridiculous.

Because that's how [require](http://p3rl.org/require) works:

> to indicate successful execution of any initialization code

Other dynamic languages have problems with "half"-loaded code. This mechanism is a defense against that.

Re: Why Perl Didn't Win

#175

Post by bmn_ »

duskwuff wrote: post #173
raiph wrote: post #139

Earlier quoted context omitted.

> Not at all [can one use CPAN] You are mistaken. See my nearby comment about Inline::Perl5. > not without major contortions [can one convert]. One doesn't need to convert (due to Inline::Perl5). That said there can be valid reasons (eg having fun and learning Perl 6) to want to convert existing Perl 5 code to a Perl 6 equivalent anyway. While some partial P5-to-P6 conversion tools already exist[1] (and I'd be surpri…

Perl5.18 has some limited support for Perl6-style function signatures, but it's still considered "experimental" and requires a pragma to enable. I don't consider that to really be part of the language yet; real-world Perl5 function definitions end up looking like this, at best: sub foo { my ($foo, @bar) = @_; ... } I'm not sure if that's valid syntax in Perl6 or not, but either way it's certainly not idiomatic.

Too many people arguing about about function signatures are under the impression that this needs to be part of the core language. Turns out, it doesn't: Perl is flexible enough to have its syntax amended.

As a practical programmer, I have enjoyed signatures and run-time type checking for years, provided by libraries. Even now, these libraries are more featureful than core signatures.

Re: Why Perl Didn't Win

#176

Post by bmn_ »

pyre wrote: post #2

It's no wonder there are issues with Perl 5 to 6 transition they went from: > They're going to merge Perl 5.12 and Perl 6 in "mid-2001" to: > There's a Perl 5.8 on the way in 2002. ^_~ That said, I think that anyone doing serious Perl 5.x work has long since abandoned the idea that Perl 6 has anything to do with Perl 5.x other than sharing the "Perl" name and Larry Wall. Maybe this is confusing to "outsiders" and the…

The branding will not change, for BDFL reasons. The best all we can do is coming to grips with Perl 6 not being a successor, but a sibling.

Re: Why Perl Didn't Win

#177

Post by jjn1056 »

Not sure what 'winning is'... I've had a great career in Perl so far and every company I've worked at has been a startup using Perl (not old legacy code). So that's like almost 20 years and every year someone says, "Perl is dead", etc. And every year I just have a blast programming Perl. I've met a ton of great people and I enjoy contributing to open source. So I would say quite complaining about something you personally don't like and get on with doing something useful.

Re: Why Perl Didn't Win

#178

Post by jjn1056 »

mrottenkolber wrote: post #79
simcop2387 wrote: post #74

Earlier quoted context omitted.

A small correction there, you aren't making them public by putting them in EXPORT. What you're doing is actually using another module to munge the namespace that used your class. In fact by default all functions defined in a package that is used as a class are public by default. And here's the boiler plate for more modern perl: package MyClass; use Moose; 1; You can define properties of the class using has 'property'…

Why do you need to return 1 though? That seems pretty ridiculous.

It has uses. Sometimes you can also use it to write code that runs like a script if called in script mode (what some people are calling a modulino. If you really hate it there's a number of packages on CPAN to make it disappear.

Also new versions of Perl allow you to define a package scope and skip the '1;' Most Perl programmers don't use this yet since the benefit is very small and the cost is losing some back compatibility. Maybe in a few years it will be more common:

package MyApp::Web { ... }

Like a lot of things in Perl it has a use that might not be immediately evident. Its also possible a more elegant solution could have been found as well. Generally when I write real code I never notice it (the 1; is drowned out by docs and real code.

Re: Why Perl Didn't Win

#180

Post by kbenson »

raiph wrote: post #144
chrisdone wrote: post #77

Earlier quoted context omitted.

> The whole point about Perl 6 is that it breaks backwards compatibility I think this is is a contributor to why Perl 6 will never amount to anything. That boat has sailed. Python 3 broke backwards compatibility and to my knowledge everybody is still using Python 2. Python has a lot of energy right now, so that might save it, or it might go the way of Perl when the next cool language comes out and everybody jumps shi…

One way to look at things is that Perl 6 breaks backwards compatibility with Perl 5. Another is that Perl 6 has well designed language interop and evolution features that make it so easy to nicely use code and libs from other languages that backwards compatibility becomes irrelevant. The big problem with Perl 6 has been that the implementation has trailed the ambitions of the design. But that's changing due to pieces…

Well, not quite irrelevant. Just because language interop is easy doesn't make the fact that there doesn't exist the interop for a library you need. That said, it's also a good chance to get good sane default implementations in first. On of the problems with CPAN is finding the best of the multiple modules available that fit the need.
Post reply on HN