Why Perl Didn't Win • Hacker News Board

Re: Why Perl Didn't Win

#21

Post by nemo » Sun, Jan 18, 2015, 6:06 AM UTC

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…

There were two sides - PHP was eating a ton of share from Perl for people and businesses who just wanted to get some simple web thing going. Sun pulled out the "Java is Enterprise" card early and successfully marketed it as being a professional scalable web programming solution for enterprise class applications with a few targeted buzzwords for whatever market segment they were going for. Perl seemed like it was always looked at as an amateur tool (much as PHP/ASP generally were), while Java was taken seriously in "enterprise" spaces (largely due to Sun's success at marketing Java to businesses).

There's a wrinkle, too. Perl isn't just a web thing. It was (and is) still used in "enterprise" spaces for scripting on servers. It's still out there being used to create scripts rather than applications. In that space Ruby/Python are competing, but there's still plenty of sysadmins who use Perl since it works.

Re: Why Perl Didn't Win

#22

Post by silvestrov » Sun, Jan 18, 2015, 6:12 AM UTC

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…

The perl developers greatly underestimated the importance of syntactic sugar and familiarity. (Java was helped a lot by looking like C).

PHP was much more friendly towards new programmers than Perl 5, it was so much easier to make simple web pages. So it took over. It didn't matter that Perl 5 was more advanced.

(oh, you uploaded module to same dir and didn't remember to add something to @INC)

Re: Why Perl Didn't Win

#23

Post by kijin » Sun, Jan 18, 2015, 6:20 AM UTC

I don't think Perl will ever recover from the Perl 6 fiasco, and I'm worried for Python for the same reason.

PHP, on the other hand, handled the PHP 6 "failure" relatively gracefully. There was a bit of stagnation in the days of PHP 5.2 when the devs devoted too much energy to PHP 6 and not enough on improving the current version. But soon, PHP 6 was put on hold and some of its better parts began to be ported to PHP 5. Thanks to this decision, PHP has improved by leaps and bounds since 5.3. Also thanks to the lessons learned, nobody is particularly worried about any breaking changes in PHP for the foreseeable future. Everyone knows that any script that works in PHP 5.6 will probably work just fine in 7.0, so new projects continue to be written in PHP. This peace of mind is very important for languages that carry a lot of legacy baggage.

If there's anything for other languages to learn from PHP, it would be their graceful handling of PHP 6 -> 5.3~5.6. The syntax is still terrible, and the default behavior remains borderline insane, but PHP since 2009 has been an exemplar of how a widely used scripting language should handle new versions.

Re: Why Perl Didn't Win

#24

Post by BuckRogers » Sun, Jan 18, 2015, 6:21 AM UTC

bane wrote: post #16

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…

> Is that -really- worth forcing unicode handling? I dunno. I'm new to Python (version 2 so far) and I easily spend 25-50% of my coding time fighting with ascii/unicode issues in Python. I wish Python 2.x just did something smarter. Similar, but not quite as bad, is the need for me to put str() around non-string values in concatenation. Just f'ing doing it for me. I'll write a bunch of code, put together a message in…

The problem is that both support unicode and 2 vs 3 unicode handling are just two different ways to do it. Which places Python3 firmly in the 'technological churn' category, rather than true technical innovation.

I'd probably agree 3.x is more Pythonic in this regard, but I think it was an ill-advised move. Plenty of reasoning in my last response as to why.

Why not go ahead and use Python3, you may find it works for you. For me, there's a long tail of libraries that don't exist there, and frankly following the core dev teams' example- we should all act in our own best interests. I'm far more productive in 2.x.

I may eventually move to 3.x, but it will have to be based on its merits. Rather than dogma, salesmanship or propaganda. Today it isn't even close to 2.x and we're nearing 7 years since 3.0 was released.

Unlike most things in life such as updating some software package, the "latest version" of a programming language isn't always in your best interests. I think this is a hard mental barrier to break down, especially people coming into Python now.

But I would always recommend learning/using 2.x, not only is it easier to build cool things with it (the whole point), but you have to learn 2.x. You can avoid 3 entirely, without any issue whatsoever.

Re: Why Perl Didn't Win

#25

Post by pjungwir » Sun, Jan 18, 2015, 6:37 AM UTC

I'm curious if anyone really expected Perl 6 to arrive like the article describes ("The problem wasn't apparent in 2000."). I was just a junior programmer, and I loved 5.6, but from the beginning 6 sounded to me like it would be a wholly different language, probably never delivered, and certainly never adopted. Maybe I'm projecting, but I felt that was a broad sentiment back then. By 2001 I was writing Python half time or more, and even though I felt a great fondness for Perl while Python left me cold, it still felt like it delivered everything Perl 6 aspired to (if you could stand the lack of regex literals, grr.....). Once Ruby became popular we got all the good things of Perl without the aridity of Python, so there was even less reason to care. In the late '00s I took a few years off programming to do a degree in Classics, and I kept telling myself half-jokingly that if Perl 6 shipped I'd know I'd been away too long. When Parrot was released I figured I'd better get back in the game.

That's not to say Perl 6 wasn't needed. Among programming languages Perl was probably my first love, especially the linguistics tie-ins with $ @ % etc, but write-only was a real problem, and people were moving to Python on the one hand and Java on the other. Maybe PHP killed Perl for low-end cheap hosting, but for larger projects, among people who would never have considered PHP, it lost because picking it seemed irresponsible.

Re: Why Perl Didn't Win

#26

Post by nostrademons » Sun, Jan 18, 2015, 6:40 AM UTC

McGlockenshire wrote: post #5

This article is pretty much spot on. I lived through this era and experienced the downfall of perl web applications first hand. My employer produced an amazingly popular perl-based web application, using flat files for data storage because so few shared hosts had DBI and DBD::mysql installed. It's some gloriously horrible code. They did a ground-up rewrite and then hired me to maintain it, right as PHP was becoming p…

Man, I remember UBB. I worked in a dot-com run exclusively by teenagers in 2000, and UBB was the go-to solution for forums. I also remember spending a day writing a Perl CGI script to do polls, since the idea of SaaS or outsourcing widgets on your website was in the far future, and everyone knew that you had to have all the source code for your site in cgi-bin.

Those were the days.

Re: Why Perl Didn't Win

#27

Post by richardbrevig » Sun, Jan 18, 2015, 6:40 AM UTC

McGlockenshire wrote: post #5

This article is pretty much spot on. I lived through this era and experienced the downfall of perl web applications first hand. My employer produced an amazingly popular perl-based web application, using flat files for data storage because so few shared hosts had DBI and DBD::mysql installed. It's some gloriously horrible code. They did a ground-up rewrite and then hired me to maintain it, right as PHP was becoming p…

I remember the days of the UBB. Flat file databases, what memories. I also recall UBB getting hacked because the data separator was a pipe bar and the code didn't check for that on input. SQL injection before SQL. Maybe I dreamt that. Either way, I remember my time with flat file databases.

Re: Why Perl Didn't Win

#28

Post by nostrademons » Sun, Jan 18, 2015, 6:50 AM UTC

BuckRogers wrote: post #12

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)?

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 love asyncio when the time comes to use it. The only library we wanted which doesn't support it is Splunk, and that was Splunk's loss (we just switched to PaperTrail).

There's an awful lot of FUD and hate for Python3 on Hacker News, but I've found it's great for a green-field project. And folks with 500KLOC existing systems should know that their technology choices are basically locked in time to when they started the project, anyway.

Re: Why Perl Didn't Win

#29

Post by lacker » Sun, Jan 18, 2015, 6:52 AM UTC

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.

Re: Why Perl Didn't Win

#30

Post by McGlockenshire » Sun, Jan 18, 2015, 6:56 AM UTC

richardbrevig wrote: post #27

McGlockenshire wrote: post #5

This article is pretty much spot on. I lived through this era and experienced the downfall of perl web applications first hand. My employer produced an amazingly popular perl-based web application, using flat files for data storage because so few shared hosts had DBI and DBD::mysql installed. It's some gloriously horrible code. They did a ground-up rewrite and then hired me to maintain it, right as PHP was becoming p…

I remember the days of the UBB. Flat file databases, what memories. I also recall UBB getting hacked because the data separator was a pipe bar and the code didn't check for that on input. SQL injection before SQL. Maybe I dreamt that. Either way, I remember my time with flat file databases.

Yup, that was pretty bad. The resulting filtering ended up causing a lot of trouble for folks not using Windows-1252 or something in the ISO-8859 family, as it'd replace pipes in post bodies with the HTML numeric entity for the pipe in that charset. A similar incident is one of the things that got me hired - I was the only one to actually pick up a phone and call their office and talk to tech support about the sheer size of the possible bug.

The most fun security bug the previous major version had was a side effect of file naming. In order to prevent users from just downloading data files, every data file was given the .cgi extension and was always saved as 0777 because shared hosting sucks and nobody ever used suexec like they should.

The file format for user records is the login name on the first line, and the plaintext password on the second, email on the third. Someone figured out that #, ! and / weren't filtered in usernames. See where this is going yet? If the directory containing member records was available inside the document root, someone could perform trivial remote command execution.

The second most fun was people discovering XSS before it was called XSS. With some creative quoting, you could inject javascript into the markup.

I'm just thankful nobody figured out CSRF, I'd have hated to figure out how to deal with that way back then...