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

71–80 of 187 posts

Re: Why Perl Didn't Win

#71

Post by _paulc »

beat wrote: post #20

You know what rocked? Perl 4. I started on Perl 4 in the mid-1990s. It was fantastic! I started replacing thousand-line C programs with hundred-line Perl programs that were more robust and worked better, and replacing shell scripts made of awkward sed/awk pipelines with neat, tight Perl. Arrays and hashes as first class data structures? Marvelous! Then Perl 5 ruined it all. The ridiculous, bloated "object oriented" s…

Absolutely right - Perl 4 had a clear niche (text processing, UNIX system scripting etc) and did this very well. Perl 5 added so much cruft and ugly syntax on top of this in an attempt to try to become more 'general purpose' that it lost its focus. At this point it became easier to switch to Python for 'real' programming.

There are still a lot of problems in the Perl 4 space and to be honest I wish that distributions shipped with a supported version of 4.036.

Re: Why Perl Didn't Win

#72

Post by nailer »

nostrademons wrote: post #28
BuckRogers wrote: post #12

Earlier quoted context omitted.

It is a different departure, and it isn't a 1:1 comparison. That's true. But Python3 is an obvious failure and no one is admitting it, yet. I've seen claims from the core dev team about how Python3 is doing well because it has more downloads from Python.org, which is so stupid I won't even address it. A comparison of PyPI download statistics says it all. Python3 migration had many ridiculous ways of pushing people to…

FWIW, I just founded a new startup and we're using Python3. No major problems so far, and I find it much more pleasant to work with than Python2.5-2.7 (which I used in my last startup, and at Google). Dictionary comprehensions are great, keyword-only arguments have been necessary in a couple cases, Unicode's not a total mess, I like how the standard library naming & packaging has been cleaned up, and I suspect I'll l…

Man I remember when Splunk were the innovative disrupters. Now they're the ones who won't update their library for the current version of Python.

Re: Why Perl Didn't Win

#73

Post by proveanegative »

beat wrote: post #20

You know what rocked? Perl 4. I started on Perl 4 in the mid-1990s. It was fantastic! I started replacing thousand-line C programs with hundred-line Perl programs that were more robust and worked better, and replacing shell scripts made of awkward sed/awk pipelines with neat, tight Perl. Arrays and hashes as first class data structures? Marvelous! Then Perl 5 ruined it all. The ridiculous, bloated "object oriented" s…

Is there an actively maintained fork of Perl 4 (or earlier) somewhere? Sounds like there should be.

Re: Why Perl Didn't Win

#74

Post by simcop2387 »

silvestrov wrote: post #47
riffraff wrote: post #40

Earlier quoted context omitted.

> The perl developers greatly underestimated the importance of syntactic sugar and familiarity. I don't think that's the case. The problem is that the generation of tools that have stuff in common with perl (awk, sed, shell) are completely unfamiliar to programmers which started programming in the last 15 years, compared to those that started 30 years ago.

Look at how much boilerplate code you need in Perl 5 to create a class versus C++/Java's simple class MyClass { } You need to assign to a variable named @ISA, you need to return 1; at the bottom of the file. And 'public' members have to be listed in the EXPORT variable. It is really funny that Perl 5 OO need more boilerplate code than Java!

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'; This will setup any accessors and also handle initializing them in the constructor that's created for you by default.

Re: Why Perl Didn't Win

#75

Post by acqq »

toyg wrote: post #65
tonyedgecombe wrote: post #52

Earlier quoted context omitted.

What can we learn from this? That we shouldn't attempt major changes that aren't backwards compatible?

> we shouldn't attempt major changes that aren't backwards compatible? I think is more about practicality. Incompatible releases are a huge hassle for users; the payout should be equally huge to make it worth the effort of porting. As the post says, a language should try to be the best choice for new projects: easier and more powerful than other choices, delivering better results with less effort. An incompatible rel…

And compatibility was big reason why Windows 95 was a success.

Re: Why Perl Didn't Win

#76

Post by conradfr »

drac wrote: post #13
riobard wrote: post #7

Anyone feeling that Python 3 is gonna do the same to Python as Perl 6 did to Perl?

it feels more like Python 3 is similar to the transition between PHP 4 and 5. Painful, sure but ultimately not a deterrent to language adoption. I'm sad about this, I loved programming Perl a decade ago but the last side project I wrote in Perl was all the way back in 2010.

I would think that the PHP4 -> PHP5 (relative) slow transition was more about hosting support than developer's adoption. Because of of the extreme (and often infuriating) stance on backward compatibility migrations were not that difficult : http://php.net/manual/en/migration5.incompatible.php

It was mostly new things, not different things. I don't even remember the new object model being that hard to pick from the PHP4 one. I think lots of developers got more stuck on the 5.2 -> 5.3 transition.

Isn't Python 2/3 more about libraries and compatibility than hosting ? My personal anecdote is that it deferred me way too long to learn the language seriously. I didn't want to waste time learning an old version but too much things were on it, especially Django and Flask (being mainly a webdev).

PHP7 vs Hack could mirror that though.

Re: Why Perl Didn't Win

#77

Post by chrisdone »

perlgeek wrote: post #45
beat wrote: post #20

You know what rocked? Perl 4. I started on Perl 4 in the mid-1990s. It was fantastic! I started replacing thousand-line C programs with hundred-line Perl programs that were more robust and worked better, and replacing shell scripts made of awkward sed/awk pipelines with neat, tight Perl. Arrays and hashes as first class data structures? Marvelous! Then Perl 5 ruined it all. The ridiculous, bloated "object oriented" s…

> And Perl 6? Fourteen years and nothing to show for it ... except a nearly feature-complete [1] compiler [2] and an impressive test suite [3] [1] http://perl6.org/compilers/features [2] http://rakudo.org/ [3] https://github.com/perl6/roast/ > and it'll have to be backwards compatible to all the things violently wrong with Perl 5 Not at all. The whole point about Perl 6 is that it breaks backwards compatibility to fi…

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

Re: Why Perl Didn't Win

#78

Post by maxerickson »

tonyedgecombe wrote: post #52
frik wrote: post #36

Earlier quoted context omitted.

It seems so. * Perl 6: almost everyone is on Perl 5, or switched to another language * Python 3: many libraries and devs will stick with Python 2, several devs switched to Go * PHP 6: unicode rewrite never released, new features backported to 5.3+, several books were published in advance with PHP 6 in the title, next release will be named PHP 7 to avoid confusion * Lua 5.2+: half of the community stuck with 5.1 as su…

What can we learn from this? That we shouldn't attempt major changes that aren't backwards compatible?

Breaking backwards compatibility is a more apt description of that list than major rewrite.

Part of the lesson from Python 3 is that large numbers of people will only spend 3 years deciding whether a 5 year plan to make a major change to a 20 year old language succeeded or not.

Re: Why Perl Didn't Win

#79

Post by mrottenkolber »

simcop2387 wrote: post #74
silvestrov wrote: post #47

Earlier quoted context omitted.

Look at how much boilerplate code you need in Perl 5 to create a class versus C++/Java's simple class MyClass { } You need to assign to a variable named @ISA, you need to return 1; at the bottom of the file. And 'public' members have to be listed in the EXPORT variable. It is really funny that Perl 5 OO need more boilerplate code than Java!

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.

Re: Why Perl Didn't Win

#80

Post by ceronman »

frik wrote: post #36
aytekin wrote: post #33

Earlier quoted context omitted.

Big rewrites = death

It seems so. * Perl 6: almost everyone is on Perl 5, or switched to another language * Python 3: many libraries and devs will stick with Python 2, several devs switched to Go * PHP 6: unicode rewrite never released, new features backported to 5.3+, several books were published in advance with PHP 6 in the title, next release will be named PHP 7 to avoid confusion * Lua 5.2+: half of the community stuck with 5.1 as su…

> The opposite: > * Node.js: it seems many consider the io.js fork based on up-to-date v8 js engine with ES6 support (nodejs 0.11/12 branch fork) and may leave the old nodejs 0.10.x behind

It seems too soon to tell what's going to happen with io.js. It was released just a few days ago.

Post reply on HN