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" syntax rendered it basically unreadable, without adding much useful functionality. The layers of syntax options forced teamwork-driven Perl (I wrote about 10k lines of it) to pay close attention to coding standards, closer than more consistent languages, just to not step on each other or have fights.
Then along came Python and Ruby, which shared most of the benefits of Perl (scripting, mostly), but added very clean, elegant OO syntax. Everyone who actually cared about writing decent OO scripts switched. Plus Python had much better math libs, and Ruby soon had Rails.
And Perl 6? Fourteen years and nothing to show for it, and it'll have to be backwards compatible to all the things violently wrong with Perl 5. There's no use case that isn't already covered by Python and Ruby. Unless some new technology comes along and Perl jumps in firstest with mostest (like Ruby did with Rails), no one will really care.
The average age of Perl programmers has been increasing by about one year per year since 2002 or so. I don't see that changing anytime soon.
... 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 fix the things that are wrong with Perl 5.
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.
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.
There are also some features that were eventually removed from Perl5, but not really. For example setting $[ was removed (it was a pretty stupid idea), but if you try to use it Perl loads the module arybase which re-implements that feature. (removing it simplified the internals)
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)
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.
* 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 supported with LuaJIT and is many applications (World of Warcraft, Photoshop Lightroom, Facebooks AI platform, etc.)
* VB.Net: many stick with VB 6, many switched to web development
* VBA.Net: everyone still use VBA 6/7 in various Office applications
* ASP.Net: many stuck with ASP coded in VBS/JS, many switched to similar platforms e.g. PHP
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
Now that I think about it, not even that big projects, teams of 10 or so devs, getting bogged down in language issues that Python simply didn't have (and no one even wished for tool support for, the was no need!)
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 programming was king to 1995 and the applets craze to 1999 when I was still regularly having conversations with people about the benefits of Java vs Perl to 2001 when you were actively hurting your career by not learning Java (not least because it seemed like the only people hiring were doing enterprise Java with horrible things like EJB and CMP/BMP).
Why did Java beat Perl? Well, there's a lot to that -- but at least part of it has to do with that fact that Java was simpler and didn't have nearly as many tricks up its sleeves (also known as the write-only problem). This is similar to the argument people today make when picking Go over other options like Scala. I also don't think it hurt that Java came out of Sun, which on the one hand was extremely influential because they sold the hardware everyone with money used, but on the other wasn't influential at all because they were "big iron" to the web's "why would I buy a Sparcstation when I can just put a PC under my desk?"
Fundamentally, though, Java was very successful at becoming the language you wrote code in if you wanted to be taken seriously as a software engineer building web applications and you didn't already have 5+ years of C++ experience. Perl programmers didn't get the same respect, and so Perl died.
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.
I don't know how it looks now, but if you login into the likes of HP-UX, Aix, Solaris and so on, usually only Perl is available.
This is what made me learn Perl, back when I was mostly into Python (.com days).
On people picking up Go over other options, well that's because people never learn and we are bound to propel shitty languages ad-nauseam.
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.
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 popular.
They refused to do a PHP version until it was too late. Someone else translated our code into PHP, then rewrote it a few times before releasing it. Over just a year or two, our marketshare plummeted, and now the UBB is a distant memory. We couldn't deliver a competing product.
Even if perl hadn't lost the deployability battle, the perl 6 fiasco was what let python and company eat away at the mindshare that wasn't concerned with just web applications.
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...
Those were the days.
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.
At least there are people maintaining Perl 5 at this point.
I can't help but think that we'll eventually be seeing "Why Python3 Didn't Win". Perl and Python both foolishly abdicated the throne. While shots are fired, I think Python3 could still recover with more compromises from its 'leadership'.
And why would you need to fork Python 3 to support Python 2 codebases?
Yes.
At a Perl conference in October last year Stefan Seifert decided it was time for him to have a go at something Perl 6 related. He had never written Perl 6 code before, let alone participated in the project, but within 24 hours he had Perl 6 calling Perl 5 calling Python[1].
That was just a few months ago. Now the Inline::Perl5 module[2] allows folk to use Perl 5 modules, even ones that do C level guts poking in to the Perl 5 interpreter, and to pass data back and forth, do callbacks back and forth, handle exceptions raised by Perl 5 in Perl 6 and vice-versa, use Perl 6 to call methods on Perl 5 objects and vice-versa, and use Perl 6 to subclass Perl 5 classes. Thus he's been able to, for example, create apps in Perl 6 using a leading Perl 5 web framework called Catalyst.[3] He's also having fun with calling Python libs from Perl 6.[4]
There's a lot more going on related to interop between Perl 6 and Perl 5, and more generally between Perl 6 and other languages, but the above is obviously a biggie.
> Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time
As is hopefully clear, with Inline::Perl5 there's no need to convert.
(Some folk will still want to rewrite some Perl 5 code in to Perl 6, and there are fledgling tools to assist, but they aren't necessary, just a nice option to have.)
[1] https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVM...
[2] https://github.com/niner/Inline-Perl5
[3] http://www.reddit.com/r/perl6/comments/2k6ii8/nines_apw_talk...
[4] http://www.reddit.com/r/perl6/comments/2n27el/perl6_20141121...
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 migrate. The answer for Python3's adoption was always something new. It reads like the list of reasons for invading Iraq.
Originally (and today's) overly optimistic EOL for Python2, then automated code conversion utilities, then porting all the major libraries, then 'six' type libraries to allow an ugly PythonX middle ground, then adding 3.x-only new features as a carrot, now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either.
All that said, and I think this is the best-case scenario: Python3 will survive and eventually thrive. It will just be a shadow of Python's former glory.
Is that -really- worth forcing unicode handling? For Zeus' sake, I wouldn't think so. This coming from someone who agrees with the change in theory.
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.
I've come to realize years after that Perl is simply difficult to learn, lots of little things to memorize. Its community took pride in language arcana. Things that are now simple in other languages are unbelievably difficult in Perl, like "hashes of arrays of hashes" and things like that.
On top of that, it's also difficult to read. No wonder Perl is losing, and to me the faster the world is cleanup from that, the better.
If you read Ovid's Beginning Perl, or chromatic's Modern Perl, you'll find they managed to explain the concepts very easily.
You have to evolve to survive. If you don't don't you may stay alive for a while. But you will die slowly.
> The implications for a programming language are difficult to prove conclusively, but simple to explain: an ecosystem focused more on maintaining existing projects than creating new projects will be less attractive for new projects.
Ruby/Rails provides an interesting example here. The ruby and rails community ecosystem (the author is right it's about "ecosystem" more than the language) -- has, in general, done it's best to focus as much as possible on innovation over stability. That is, has tried to choose focus on creating new projects over support for existing projects.
Much to the frustration of some in the ruby ecosystem with existing projects to support.
(Rails, of course, from one perspective is an existing project; from another is a framework, which has generally over it's history cared more about new projects that will be created with Rails than existing projects built on Rails that need to be supported).
Of course, there still are existing projects, and there are still developers participating in the ecosystem who need to support those existing projects. So you can only go so far.
What has this done for ruby/rails ecosystem? Hard to say. Overall it's been successful, but it still can't make the ecosystem as greenfield as a true greenfield ecosystem, which is perhaps why some are leaving ruby/rails for greener pastures -- more than any qualities of ruby as a language, it's just the opportunity to be in a greenfield ecosystem that is attractive, perhaps.
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.
This is no longer strictly true. On Friday, the "let's remove all the deprecated stuff" RFC was passed. Anything that causes an E_DEPRECATED in 5.6 will now be a fatal in 7. For example, ext/ereg and ext/mysql are no longer included, and have been shipped off to PECL. Shouldn't be a problem for anyone that doesn't compile their own, really. A few php.ini settings are also now removed, which will fatal on startup.
It'll be safe to say that if your code runs fine under 5.6 with error_reporting set to -1, then you'll probably run under 7 without too much trouble.
And that's exactly how deprecation is supposed to work! No massive changes, only incremental changes, and even those incremental changes come with at least a couple of years of grace period.
Not completely, ext/mysql does not output E_DEPRECATED. Although I guess installing a compatibility library is probably not all that much trouble.
Those will migrate to Julia, Go, or something else.
I used Python a lot in the last decade (2000 - 2004) for automatation and little applications.
Nowadays my choice would be OCaml for the same type of tasks.
EDIT: typo, automatic => automatation
The appeal of a scripting language is that "automatation and little applications" do not take a lot of friction to write, I'd say OCaml is less suited in this regard.
This might stem the tide for a while... Then we have pyston which maintains C api compatibility.
When I converted a perl script to python and saved 50% LOC I didn't know which version of which I was using. Am only vaguely aware of the Python 2.x vs. 3 issues. Never was aware of Perl 5 vs. 6.
When Python and Ruby fade, I look forward to the hand wringing about how version whatever didn't get pushed out fast enough. But that won't be the reason.
This is the way I see it. Perl5 is still being actively developed, perl6 is coming along nicely, cpan more awesome than ever, and there's still work for a perl dev.
If everyone was using the same language, then we'd all suffer because no one would be getting the new ideas.
Competition keeps things healthy.
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!
Allison Randal wrote on the death of Perl a while back and had some observations worth nothing to understand how it fell: http://allisonrandal.com/2013/03/31/mythbusters-why-i-still-...
I really liked working with Modern Perl, but rarely do anymore mostly since "nobody uses Perl" kills any suggestion even when it might be the right tool for the job. Ruby has become Perl 6 for me.
while I don't do anything with it today, I do know Perl/6 would be in contention for my 'deserted island' language of choice.
yet another dph
Python? Very popular. Solid language. Probably at some point more adopted than Perl, but not so much so that I can say it "won", partially because of how this list goes on.
Ruby? Same.
PHP? Maybe in the web space but not in general.
Javascript? Even in light of Node, this is still a marginal language out of the browser, especially considered over the past 15 years.
Lua? No.
Perl may not have "won" but it has hardly "lost", and now IMHO the sun is just beginning to set on this entire catagory of 1990s-style dynamic scripting language and there probably will be no further "winner" in this space.
http://programming.tudorconstantin.com/2015/01/perl-already-...
That's a strong statement. Are you quite sure those are the only two possibilities?
> 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 branding needs to change? It's not like the Perl 5.x line is not being maintained. Since Perl 5.10, there were some significant improvements, with consistent point releases coming out.
I think you might mean "unknown" rather than "moribund", but just in case: no it wasn't, it was quite successful, RAA wasn't CPAN but was quite rich, there were steady improvements to the language and the community outside japan was growing (i.e. most of the european ruby user groups started before ruby on rails). It was just growing slowly, rather than skyrocketing.
- 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 such a way that converters like 2to3 can do the conversion for you. I'm aware of no such tools or capabilities between Perl 5.x and Perl 6.
- Python3 isn't as ambitious as Perl 6 is/was.
Edit: As to point #2, I recall that there may have existed (maybe it still does?) some project to use Perl 6's "reprogram the grammar" capabilities to turn Perl 6 into Perl 5. I'm not sure how I really feel about that though. There was also a time when there was some buzz around Parrot VM[1] that was associated with Perl 6 (I don't know if it was some official partnership or just some announcement of Perl 6 support in Parrot).
Heck, apart from few - even those which are not supporting Py3k now have alternative package in PyPi. So it's positive sign.
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.
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.
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.
I feel Perl does not deserve to be mentioned in a hero's tale. There's been too much rankling and nincompoopery out of perl's characters given the size of that community. Far, FAR too much griping. Perl is a bummer, and that is why it did not win.
My philosophy is: live the life of a champion - overcome and be a shining light for others. Your war stories should be mostly glorious victories, no matter how mundane the battles or battlefields were.
