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

61–70 of 187 posts

Re: Why Perl Didn't Win

#61

Post by ugexe »

duskwuff wrote: post #38
pyre wrote: post #6

Earlier quoted context omitted.

While you may end up being right, Perl6 is a much larger departure from Perl5 (than Python3 is from Python2). 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)?

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

Respectively: https://github.com/rakudo-p5/v5

While not quite the same as what was asked, it's clear that 'not at all' is not an informed answer

Re: Why Perl Didn't Win

#62

Post by cturner »

ugexe wrote: post #60
CodeWriter23 wrote: post #39

Earlier quoted context omitted.

I started calling it out as vaporware around the Holidays 2001. I would be shouted down by certain zealots who would tell me code (pre-Alpha quality) was available for use right now. At least there are people maintaining Perl 5 at this point.

There are commits to Rakudo, a Perl 6 compiler, every day. It's also scheduled to be production ready by the end of 2015.

You might be right. But I have been reading forum posts to this effect for fifteen years, and eventually eveyone switches off. Even if you are right, would you trust your career focus to a software community who had got it this wrong for that long? I am looking forward to checking out a future perl 6 but part of that is now duke nukem forever curiosity - what on earth could be in it that kept those smart people at it for that long?

Re: Why Perl Didn't Win

#63

Post by biomimic »

gaius wrote: post #53
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…

Indeed. While personally I think Tcl is a better language than either, professionally I jumped straight from Perl 4 to Python, bypassing Perl 5 altogether. The combination of needing rigid standards to make a codebase maintainable in big projects, with the dynamic nature of the language meaning that tool support for it was scarce, was a double whammy. Now that I think about it, not even that big projects, teams of 10…

Tcl is Fantastic.

Re: Why Perl Didn't Win

#64

Post by biomimic »

gaius wrote: post #55
lacker wrote: post #29

If there was no Ruby, I suspect Perl would still be popular. At one point the scripting language holy wars were "Perl vs Python". That turned into "Ruby vs Python". Similar philosophy, lots of better stuff in Ruby.

Online yes - but a hell of a lot of Tcl was being written too, by people who just couldn't be bothered posting about it.

Tcl was and still is undiscovered gold.

Re: Why Perl Didn't Win

#65

Post by toyg »

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?

> 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 release starts from a position where it requires more effort, so it must deliver much better results in much less time or it will be discarded on practical ground (and all the while having the same feel and strengths as previous releases - you can't make Go, call it Python 4 and expect people will love it). That's very difficult to deliver.

Re: Why Perl Didn't Win

#66

Post by cturner »

riobard wrote: post #7

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

No. Python3 delivers concrete improvements on accepted problems with python2. Just the async io and encoding improvements with python 3 justify it. It continues the design spirit that drew devs to python.

When a loved platform stops evolving, as python2 has, there is this lovely period when it continues to be awesome, while requiring you to learn nothing new. Python is here now. But come the day that my new Linux distro links to 3 over 2, I will get organised to move.

Re: Why Perl Didn't Win

#67

Post by inDigiNeous »

Oh man, I remember hating to program Perl. With Perl, there wasn't just one way to do things, but there were 10, and all of those involved different combinations of @{} $[] [#] '%' characters put in seemingly random order and changing completely the context on which they operated, with the logic only clear to those who somehow understood the connection between these symbols and their meaning.

Maybe it didn't win because the language syntax was just a mess, and same variables just in different contexts could mean like 3 different things depending on what way you pass them, what you you return them and what kind of random character is in front of them.

Don't take this personally, just ranting out my feelings for the Perl programming language, and glad that it isn't one of the things I have to know anymore! Good riddance!

Re: Why Perl Didn't Win

#68

Post by chhantyal »

pyre wrote: post #10
riobard wrote: post #7

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

As someone who has been both a Perl and a Python programmer, I don't feel like Python3 is going to kill Python. Why? - Python3 currently exists, and there is a large push to get the majority of the "big" packages to support it (many of which do currently support Python 2.x and Python3). - It's possible for a Python package to support both Python 2.x and Python3 at the same time or to program the Python 2.x version in…

Indeed, big libraries supporting Python 3 is rapidly growing http://py3readiness.org

Heck, apart from few - even those which are not supporting Py3k now have alternative package in PyPi. So it's positive sign.

Re: Why Perl Didn't Win

#69

Post by klibertp »

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!

What? I'm not a PERL programmer - I used it a bit before it grew OO features, roughly at the same time I used Turbo Pascal, so really long ago. Yet, in these examples: http://stackoverflow.com/questions/1037312/how-do-i-create-a... I see no boilerplate you speak of. If you look at this http://stackoverflow.com/questions/1037312/how-do-i-create-a... answer you'll see comparison to C++, which isn't exactly in the favour of the latter in terms of conciseness.

And then, even if it was true and you really needed to "add public methods to EXPORT variable" that's no different than modern JavaScript, right? That's how modules work in JS. Having to "return" something at the end of a module is a requirement in Lua, too - again, it's just how the module system works.

Anyway, I don't know PERL, but knowing many other languages I find your claims suspicious. It reads as if you were a recent Java convert who tries to rationalize his decision to leave PERL or something like that.

Re: Why Perl Didn't Win

#70

Post by nailer »

sulam wrote: post #14

Speaking as someone who lived through this period during the formative years of my programming career, the author has completely missed the most influential language of the time and, in my mind at least, the number reason why Perl lost. Yes, I'm talking about Java. It's easy to hate now, but Java back then replaced all the server-side Perl programming that I did in the space of about 3 years, from 1994 where CGI prog…

Ditto on the Sys Admin side with Python - Perl had modules for everything, but the inbuilt punctuation variables mixed with regexs for everything and the flexibility Perl offered led to a perception that nobody could maintain anybody else's stuff.

Sys admins were still about getting shit done quickly at scale, and Python slowly began to replace Perl. Python 2 had string methods built in, Red Hat switched everything to Python, tool.s like LXML started coming out right when we all had to munge XML all day and suddenly that was it.

Post reply on HN