I recently turned down a job that involved revamping and tailoring a piece of work I did some years ago for a new end client. The reason I turned it down is because whilst the original used Perl; that was not acceptable for the revamp which had to be done in Python.

I don't like Python. Every time I've used it, it feels like a poor substitute.

Kinda like listening to an Elvis impersonator or a Beetles tribute band. It/they completely miss the point of what makes the original great. They go to great lengths to copy the superficial things; accents, cloths, hairstyles, even mannerisms and facial ticks; but completely fail when it comes to the important stuff; the music. They may sing and play all the notes in the correct order and key. They may even fairly accurately emulate the sound and tone and feel of one particular performance of each song they play. But listen to 3 live performances of any given track by the original artist and you'll notice that they are all quite different. Different in ways that are mostly too subtle for me as a non-musician to describe well; but you're never in doubt they are they. Each performance is unique and valuable for its uniqueness; and for originality; and because it shows the skill and growth of the artist.

The tribute bands meanwhile are condemned to only emulate, because the moment they add some originality to the performance; they fail to be a tribute any more and become karioki.

And that's how it feels when I use Python. Like a tribute band that opted to break out of the mould and add its own stamp on the original. Along the way of adding its unique contributions, it lost something, and many somethings that made the original so good. So usable.

For example, take regex. Like most every post Perl language, Python has "Perl-compatible" regex. Except of course, it isn't! It may be able to do pretty much everything that the Perl regex engine can do; but the way it does it is anything but compatible. It's not just that the regex features and syntax -- recursive regex; non-greediness; look-ahead/behind; embedded code et. al. -- but also the way the regex is used -- method call style versus top-level operators -- and the way they are (or not) integrated into the language.

Ie. The way perl re's operate upon $_ by default; the way substitutions can be both applied and tested in a single statement; the difference in operation between scalar and list context; that global captures can be returned en-mass or one at a time.

And that's just one language feature where a raft of subtle and not-so-subtle differences make Python a piss poor substitute for Perl. And there are many others.

Maybe if I'd come to Python first; I wouldn't always be comparing and noticing its awkardness; but that ship has long since sailed.

Turning down the work was no big loss in the scheme of things; it wasn't worth a great deal.

But it was an interesting piece of work -- the only type I take on these days -- that I would have enjoyed doing. Kind of an extension to a piece of work I did 6 or 7 years ago, though for a different ultimate user and purpose. The friend I did that original work for was adapting it and selling it on to a new client for a new purpose, and gave me first refusal on the new stuff. However, whilst the original was done as a C library that used Perl for the workflow glue and file handling; the new version will reuse the C library with some additions and use Python for the glue. And my friend tells me that this is the trend.

Not only because some client are specifying Python; but also because most of the other guys he farms work out to, are not just preferring Python, but positively anti-Perl. Not it seems because they have any particular aversion to Perl itself, but because they see it as an evolutionary dead end.

Not extinct; nor even yet on the critical list; but still vulnerable, bordering on endangered. In desperate need of a forward looking positive plan indicating where it is going and why. They are mostly young, and are unwilling to expend the energies and time acquiring skills in a language for which they see little demand and no clear evolutionary path.

The responses (and the lack thereof) to this thread/question pretty much sum up how I feel about the subject.

I don't need Perl to evolve and have a future. It continues to work well for those things I use it for as is. 5.10 satisfies my needs of Perl.

Most of what has come in p5 since has been either too buggy, or trivial, or too transient for me to have bothered to add it to my core lexicon. Most of what I use from 5.10 still works fine in all the later builds when they are the target. And the few things that don't -- usually because of the short-sightedness or sheer bloody-mindedness of the developers -- I've developed workarounds that I apply after the fact to code developed in my preferred environment. Which is fine for me, given my low development rate at the twilight of my career; but developing code to work despite the best efforts of the core maintenance team; is no way for those at start of theirs to go on.

And p6? It's interesting, but unproven. And possibly, unimplementable.

And in the time it has taken to get to the point where it is now -- which rumour has it is that it'll do about 90% of what P5 does; and about 30% of the P6 unique stuff; but with a performance that makes your 3.6GHz i7 look like a 400MHz Pentium 4 -- most of the then, big players in IT have disappeared; whilst many of the biggest players in the industry today have gone from startups to huge, mature companies that are now running, controlling and otherwise influencing much of it. Many millionaires (and billionaires ) have been made; careers forged; entire new branches of the industry have been born, evolved and come to maturity.

Too late for the mature P5 programmer; and too little, too nebulous, too radical and too slow to evolve for those starting out. It is seen as neither the successor to Perl5, nor sufficiently revolutionary to make it worth the learning curve, uncertainty and risk going forward.

So what future do I see for Perl? A slow, painful, but inevitable decline, first to obscurity, nicheness; and then extinction.

I won't affect me, so I'm all right Jack; but I do so hate the vision.

What future would I have liked for Perl?

• Perl5 with knobs on; and minus a few warts.
• Greater maintainability (of perl itself); a cleaned up codebase that encouraged experimentation and change, rather than fighting it tooth and nail.
• Greater performance; through a root and branch clean-up, rafactoring; re-writing of the core rather than ad-hoc optimisations.
• Greater extensibility; through loadable (domain specific) parsers.
• Greater concurrency; by refactoring using modern coding styles -- reentrant functions; removal of God-objects, global variable and static allocations - to allow threading to be integrated at the core.

But then, most of that is what most of those involved in the Grand Inquisition that started the Perl6 bandwagon were hoping for.

Unfortunately, despite the apparent democracy of the start; the Grand Inquisition turned into the Grand Vision. But the Vision was only seen by a few; and only seen in full by one; and along the way many of those that had seen a part of the Vision had Crises of Faith, and were excommunicated, and fell by the wayside. And whilst there has been a steady recruitment of new disciples to the cause; few have been party to the full Vision; and fewer still have been able to keep their faith for more than a short time.

And the rest is history.

I won't be giving up using Perl; but as far as its future is concerned. I've stopped looking.

And going by the lack of reaction to this thread; so have most others.

paraphrase:


“I am not a pessimist.
Just a well informed optimist.”
[download]



Also note that cinema has not superseded theater and television has not superseded cinema nor theater.
L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

I don't like Python. Every time I've used it, it feels like a poor substitute.

You only feel Python is a poor substitute if you have used Perl before, else Python is new language to learn which can get you a job. The problem is many people who come to Python are generally from the C/C++/Java line, and find themselves at home with a syntax where the only difference is the indentation.

What are the compelling reason for them to use Perl anyway?

Python has "Perl-compatible" regex. Except of course, it isn't!

In this era where bulk of the work there is, is to write application around a data base, or take inputs from a data end point(Through web forms). The chances and the very opportunities of you using some great kung fu over data are in short supply.

but that ship has long since sailed.

and

Too late for the mature P5 programmer; and too little, too nebulous, too radical and too slow to evolve for those starting out.

I'm not sure where I read this, but I guess it was on HN. The problem with a lot of older programmers is, we don't exactly have X years of experience. We have one year of experience in a legacy technology for X years. Rigidity is not a nice thing to have, move on. And there is always the next ship.

• Many smart peoples are still doing cool stuffs with Perl: one among other is PSGI. It is in nuce a possible rebirth of Perl as web language. There are also young ones between them. If they put their passion on Perl is reasonable they continue in such way. As the brain is getting older is more difficult to switch prospective and jump on another charriot.


• Even if i have no direct experience (because i'm a ten finger software house) the modern OOrientation of Moose and all the heard, made Perl newly suitable for large projects maintained by big group


• A philosofical consideration. Perl is a humanistic programming language. It not aims to fit the businness, it aims to fit the programmer. Things are getting everyday more complex and specialized, architectures are now a mess of layers of sofwares and hardwares where you need a storage admin, a network engineer, a bunch of various sysadmins AND two or more tech support services for the softwares you put in the field. Languages too are specializing a lot: i have seen big group of Java programmers working for months and using a lot of hardware to produce a simple (uh.. and bugged too) web interface. In such panorama people with cross experience are valuable like diamonds. This is an implicit limit of the 'develop by specialization' that is almost written in the DNA of the human being. Perl is the incarnation of the cross over programming or a humanistic example if you prefeere. I think you do not need examples. In the humanistic stance of Perl i see a lot future.


• That said, we had not to forget what people love (despite the market). Many peoples here around (me too even with no such big contribution, for the moment..) love Perl a lot: they release, port and enhance Perl every here and then. Take apart Perl6 for a moment: how many different releases of Perl have you used? i work a lot on windows systems.. oh i have Strawberry and i have it portable too.

The future is not what it used to be.
[download]

Well, in the very long term, no programming language has a future.

In the next ten to twenty years, I expect Perl 5 to continue to be widely used; there is just too much mission critical software already written in it for it to disappear overnight. Because of this, maintaining backward compatibility, as Perl 5 has largely done, is vital, IMHO. In contrast, I felt that Python 3/Ruby 1.9 broke backward compatibility without a good enough reason. Based on random anecdotes from workmates, having Moose in the Perl core should help continue the Perl 5 renaissance.

Out of curiosity, I compared Perl's TIOBE index from three years ago:

Dec  Dec                            Delta
2011 2010  Language       Rating   Dec 2010
 1    1    Java           17.561%   -0.44%
 2    2    C              17.057%   +0.98%
 3    3    C++             8.252%   -0.76%
 4    5    C#              8.205%   +1.52%
 5    8    Objective-C     6.805%   +3.56%
 6    4    PHP             6.001%   -1.51%
 7    7    (Visual) Basic  4.757%   -0.36%
 8    6    Python          3.492%   -2.99%
 9    9    Perl            2.472%   +0.14%
10   12    JavaScript      2.199%   +0.69%
11   11    Ruby            1.494%   -0.29%
[download]

Oct  Oct                            Delta
2014 2013  Language       Rating   Oct 2013
 1    1    C              17.655%   +0.41%
 2    2    Java           13.506%   -2.60%
 3    3    Objective-C    10.096%   +1.10%
 4    4    C++             4.868%   -3.80%
 5    6    C#              4.748%   -0.97%
 6    7    Basic           3.507%   -1.31%
 7    5    PHP             2.942%   -3.15%
 8    8    Python          2.333%   -0.77%
 9   12    Perl            2.116%   +0.51%
12   10    JavaScript      1.771%   -0.27%
16   13    Ruby            1.128%   -0.12%
17   81    Dart            1.119%   +1.03%
[download]

See also:

• Why do people say 'Perl' is dead?!?!
• Perl is sinking (TIOBE): all time low for Perl
• IEEE Spectrum Language Popularity (see Perl as mobile language).
• IEEE Spectrum: Design, Methods and Data Sources

Also see also:

• Don't compare percentages
toby döt ink

To be fair, TIOBE is an awful way of determining actual usage. It's "methodology" is to search for +"<language> programming". Is Transact-SQL really used by nearly as many people (as of the latest index) as Perl or Python?

Here's some oddities (from Google currently, at least):


• +"c programming" +"objective-c"
  
• +"basic programming" +"perl"
  
• +"c coding" vs +"python coding" vs +"perl coding"
  
• +"java coder" vs +"ruby coder"
  
• +"java programmer" vs +"c programmer" vs +"python programmer" vs +"perl programmer" vs +"objective-c programmer"
  
• +"transact-sql programming" +"2014" vs +"transact-sql programming" vs +"perl programming" +"2014" vs +"perl programming" vs +"cobol programming" +"2014" vs "cobol programming"

  ...and the madness of +"basic programming" +"perl" +"2014" vs +"basic programming" +"perl" vs +"basic programming" +"2014"

  -T.

The funniest joke in the above is the ascendance of C, a language around since 1970. It was considered "old" when I was in college (1980). I've never written C professionally, except for a simple demo program I did for a job interview. I should look; I don't recall seeing many C programming jobs advertised.

1 Peter 4:10

Perl seems to be outperforming Python

I don't see that in either table you posted.
لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

From Dec 2010 to Oct 2014, Python fell massively, from 6.482 down to 2.333. In contrast, Perl went from 2.332 to 2.116. That is, Perl "outperformed" Python over the past four years by falling only 10%, rather than 178%. Now, if that rate of change continues...

Having said that, I was saddened that all four of my favorite languages (Perl, Python, Ruby, C++) fell during the past four years (I was not saddened that PHP suffered an even bigger fall than Python :). Most of the popular languages fell, with only C and Objective-C improving.

Although I am not really convinced about the TIOBE index measure, and have never been, I am quite happy that Perl made it back to the top ten in 2014, where it was not last year. This does not sound as a dead language, does it?

Well, in the very long term, no programming language has a future.

That is just a philosophical argument, on the very long term nothing has a future, not even the universe. When people talk of a future is always the next immediate few years.

Hi BrowserUK,

I'm not a programmer, just a storage guy on a look out for some automation and have already done some using Perl. So if whatever I say here sounds shallow or stupid, kindly pardon me.

Before I tried Perl, I tried Python. It was comparatively easier to learn. But, whenever I had to add some extra checks or functionality, I had to keep indenting. Which I don't like. Perl is not like that. It just lets me do my job. If I need to add something, it's comparatively easier in Perl.

I really like Perl, but I don't understand when people seem to have a puzzled look on their face when they see me using it. In fact, just today, while I was trying to automate some menial monitoring/health checks using Perl, my friend told me that I should focus on some other language because Perl is not being used much now a days. He hasn't written any scripts, he was just saying what "he keeps hearing from everyone". Which is something that is really sad.

In my opinion (based on very limited knowledge), Future of Perl is to a very insignificant, but equally definite extent being impacted by such folks who just keep thinking for some reason that Perl is stagnant. But Perl 5.20 was released pretty recently!! So how can it be stagnant?? :)

Funny thing was, though my friend said that, I could kind of see that he respected the fact that I am able to write something in Perl. Because Perl is considered as a more complex skill set than Python (His words, not mine. I am still Learning Perl and have no knowledge or ability to determine the said "complexity").

So while Perl is considered a stagnant language by a few people out there, it's also considered more complex skill. :)

I just saw your post and felt an urge to express what I felt and what I just heard today. Hope I don't end up ruffling some feathers here.

Your anecdote reminds me of something that happened to me at work just a few days ago. A "data scientist" -- young guy, very hip -- saw over my shoulder that I was working on some Perl, and he quipped with a smirk, "Oh, you're a Perl guy? I'll try not to hold that against you."

My immediate thought was, "Oh, you're a douchebag? I'll try not to hold that against you!"

Point is, Perl has a uniformly bad reputation among whole generations of programmers. Although a few of us know better, it's still a reality which will be changed neither by Awesome New Version!!1! nor by version number manipulexyacculation.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

"Oh, you're a Perl guy? I'll try not to hold that against you."

A while back on the PDL mailing list, Karl Glazebrook proposed that the collective noun for a gathering of python programmers be a "smug".
It occurred to me that python programmers might, in response, assert that the collective noun for a group of perl5 programmers is a "cemetery".

Any thoughts on the collective noun for a group of perl6 programmers ? ... an "hallucination" perhaps ?

;-)

Cheers,
Rob

Two reponses:

1. I think that your impressions and conclusions; along with those of your Pythonite friend are right on the money.
2. Perl 5.20 is still Perl 5.something; and Perl 5.something is still Perl 5; and that's been around forever.

   Like the 2012 Audi TT RS+ revision of the 2006 TT Mk.2 was seen by many as a stop gap to the 2014 Mk.3; and sold in very limited numbers despite delivering extra power, performance and economy; Perl 5.anything will always be seen by the many as an interim stop gap. Currently to nowhere.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Additional Point(s):

I came back to this page after reading the answers to the question I had posted earlier about learning perl. In a matter of minutes, so many folks responded with their helpful suggestions!!. This matters. It might not matter to the folks here who are full time programmers and are by far much more knowledgeable than I could ever be. Because I've never been "hooted off" here. It does matter. This community is really truly helpful and when a programming language has such a helpful community around, it just has to have a future. Because it deserves it.

To me, Perl is to scripting what Vim is to text editing. It's got the power of a surgical scalpel. And that's just one of the blades of this amazing swiss army knife of a language. I also think that as long as there is a need for a powerful language that can slice and dice text and has amazing modules for everything, Perl will be around.

It's also the "advertising" factor that counts. While Fabric (a python module for SSH connectivity and such) is so passionately spoken about, Net::SSH2 and the ilk get no love. I really don't get it. They both do allmost the same thing. Still, Fabric is thought of as being "this amazing thing" whereas Net::SSH2 is not.

Boy, I wrote too much in there.

Ultimately I think all programming languages, like spoken languages, will turn out to have a limited shelf life. Even the mighty C will eventually fall, or at least evolve into something almost as unrecognizable to today's C programmers as Beowulf is to today's English speakers. (C will just take a lot longer than most other programming languages.)

Perl 5 seems pretty healthy for the time being though.

When Perl 5 does eventually die, I hope that it's because it was eaten by Perl 6. Perl 6 will never be a matter of a simple upgrade - it's an entirely different programming language. If it ever gets itself into a position where it can eat Perl 5, that will be a Good Thing, because it will mean that it can probably also eat Ruby, Python, and most other dynamic and high-level programming languages. If all those programming languages get eaten by Perl 6, that will be a Good Thing for programmers, as Perl 6 (the language) is pretty awesome, even if Perl 6 (the implementations) are not quite there yet.

Did you answer "Yes" to my first question? OK. Release to CPAN. Report bugs. Fork projects. Spread knowledge.

Did you answer "Yes" to my first question?

Yes. With caveats. I would be more than willing to expend some, or even a lot, of my time contributing to giving Perl a future.

OK. Release to CPAN. Report bugs. Fork projects. Spread knowledge.

All completely pointless. Just business as usual. More of the same.

• Release to CPAN.

  Even if you doubled the number of modules on CPAN overnight, it wouldn't just have no positive affect; it would have negative affect.

  How do other languages get by with so few modules available?

  By ensuring that there is one module for each purpose, that incorporates the best knowledge, coders and APIs for that purpose. If a dispute about the best way forward arises, fork the module, implement both, get them out there and see which proves best in use. Then ditch the other one.

  Keep the pool small; concentrate the skills and efforts on that few. Where choice is required, place the choice within the module not between them. That way, when someone goes looking for something, they don't have 20 similar modules to try and choose between.

  It requires a more mature approach to the task of managing libraries: deferring to others; collaborating; making mature decisions to throw your own code away and collaborate with others in pursuit of a common goal; rather than endless taking your ball and running away to fork Yet Another XYZ module.

• Report bugs.

  I've reported bugs. Lots of them. But unless I can also have some influence over how they get fixed, it is a completely thankless task. First they get closed as "user error". If you persist enough, they may eventually get reopened. And then, if you're lucky, 10 years later they may get a 'fix', which doesn't solve the original problem; but rather make a feature of the bug and changes things such that it not only doesn't fix the overall problem; it irreparably breaks the workarounds for that original problem.

  The problem is, there is no consultation. The first you know about anything is notification that the bug has been closed in the latest release; with no chance to argue with the efficacy of that 'fix', without starting the whole process over again.

• Fork projects.

  Pointless. Taking your ball and running home never solved any problem. 90% of forks never see light of day; 95% never usurp the original.

  That's millions of hours of wasted time and effort by volunteers that helps no-one and just breeds ill will and resentment.

• Spread knowledge.

  To whom? Old hands are already committed to their paths. New minds will rarely be influenced by words. They'll follow the crowd; because that's the percentage play. It needs something new; something demonstrable and dramatic and usable by the many, today to grab attention.

The caveats:

1. I have to believe that what I am expending my time on, will achieve that goal.

   Pretty much anything less than a full fork of the code base, that ditched the existing revision history and all the out-of-date OS support and huge swaths of other historical gunk wouldn't interest me.

2. The future being aimed for has sufficient support from enough others, and significant others, in the community to allow it to be seen and announced as a community goal.

   The bottom line here is that unless it garnered the support and active involvement of at least some of the more active and less entrenched guys from p5p; there is no point in starting it.

3. The time frame for the goal has to be such that it can be reasonably predicted to be achievable before it is too late.

   I know many would say that it is already too late; but I think that if the right goal was chosen, and it could be achieved with 2 to 3 years, I would be prepared to try and help.

What should that goal be? I have my ideas; but it would be pointless to lay them out; my ideas would be a magnet for wide-spread, cursory dismissal.

It would require widespread and public consultation -- no hidden enclaves behind closed doors by small groups of yesterdays in-crowd -- and wide(ish) agreement by a sufficiently capable and influential group of proven contributors and if not totally new blood; at least enough occasional contributors and (perhaps) returning disillusioned, to give a core of willing people to make it happen.

And *ALL* of them would have to have an equal voice in the discussion of what gets done and why; even if not in the final decisions.

And it would have to happen fast. And that means no high horses, entrenched positions, or appeals to higher, prior (historical) authority.

It's not going to happen; but it could with sufficient good will.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

How do other languages get by with so few modules available?

Which ones do you mean?
لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

all the out-of-date OS support and huge swaths of other historical gunk

Unfortunately in relative terms, that accounts for mostly nothing.

99% of the complexity of the perl interpreter/compiler/runtime is due to its initial design. A clear example of premature and abusive optimization... maybe it made sense twenty years ago but nowadays it is just a heavy burden stopping perl 5 development in anything but trivial matters, and specially in getting new blood into it.

Anybody wanting to advance perl 5 seriously, should consider starting from scratch!

What OS support would you get rid of?

Daisuke Maki (lesstrat) wrote this piece about widening the audience for YAPC's, and thereby for perl.

What Do You Want Your YAPC To Be?

I thought that also interesting because I find such tech conferences often a bit too narrowly focused. (PostgreSQL conferences could improve themselves in this way too; I'm sure there are many more examples.)

PERL IS DEAD!!!

Am I doing it right? :P

NO!!!!! MORE EXCLAMATION MARKS!!!!!!!! AND BOLDFACE!!!!!!!!!!!!

That's the answer!

Rather than tilt against the windmill of getting "Perl 6" renamed to remove the "dead end" sign from Perl 5's future, just rename the "not going to Perl 6" fork of Perl 5... to "Ded".

- tye        

"Perl is not dead, it just smells funny." (freely adapted from Frank Zappa (1940-1993))

«The Crux of the Biscuit is the Apostrophe»

Most of all, I think that it makes no sense to say that you are a “professional <<language_name here>> programmer.”   You are a professional programmer, period.   Perhaps, if you are “only two years in,” you have not yet been obliged to dive into many other language systems ... outside of University, that is ... but that day will swiftly come, and then it will come again and again, until you no longer think about it much.   It simply becomes something that you do.   It becomes something that you know with certainty that you can do, and, yes, it is a market advantage.

One thing that you’ll see is that pretty much all of these language-systems are far more similar than different.   (And, on top of this, there are other systems that are truly different, such as Prolog.)   As the gamut of languages that you have “seriously used” continues to expand, it does become easier.

And BTW ... this is one characteristic of this business that I have always enjoyed.   Language-design, and the principles of “how to make a piece of silicon do what you want it to do” in general, have always been topics of particular interest to me, and the opportunity to learn “yet another one” is something that I look forward to.   (I guess all those years of reading BYTE Magazine ... an APL interpreter in flowchart form ... Robert Tinney’s Pascal’s Triangle cover and all of that ... rubbed off on me somehow.)   I don’t just do it because somebody else told me that I had to, nor necessarily paid me to do it.   To me, the topic is both challenging and intellectually intriguing, and it’s cool if you can make a living at something that is also, in part, your hobby.

The only thing I can say for certain is that Perl has a future with me. I like it, therefor I use it. It works. Good things go away when they are no longer good. I think that in and of itself determines that Perl will be around for quite a while....

The only thing I can say for certain is that Perl has a future with me. I like it, therefor I use it. It works.

My position exactly. But like me, you must be in the position of mostly choosing what you use. That puts you in a very small minority of coders. Most get told what they have to use; and it isn't Perl.

And it isn't going to be unless something changes. And nothing is going to change unless we, the existing Perl community decide it will.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Programming languages are like locomotives:   you don’t admire them for their looks.   You don’t get rid of them because they’re now “last year’s model.”   You use them to haul revenue freight.   Perl hauls a lot of digital freight in this world.   Millions of lines of battle-hardened source code, developed over the course of years and performing critical business functions, will continue to be in service for decades ... and the languages they were written in will remain in service for that purpose.

Languages are dirt-cheap.  (We really don’t need another one ...)   The software that they’ve been used to construct is:   “Priceless.™”

Paraphrase: You don't need to write new code; just 'maintain' your old stuff to see your career out. Or "F*ck you Jack, I'm all right!"

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Now that’s a most peculiar “paraphrase,” good sir!   And you yourself know it to be a lot of bilge, so there.   (You’ve got plenty of industry experience.)

Software takes a fairly huge amount of money to get right, but it costs next-to-nothing thereafter to keep it that way.   Sometimes people make the serious error of rewriting an application that works, in a “new and improved” language, only to discover ... the hard way ... that three things were true:

1. They didn’t actually know all of the things that the original application did, nor exactly how it did them.
2. That they seriously under-scoped and under-estimated the project, and failed to identify all of its subtle interactions with other parts of the business.
3. That, when the du$$t finally $ettled, what they’d come up really wasn’t “–er” than the system it replaced ... or, as the case may be, failed to replace.

If you have a system in Perl-5 that right now is doing exactly what you need it to do, there is little cost and little business risk in keeping it that way.   Whereas, if you set out to replace it or even to move it to a different language platform (or version), both the costs and the risks go sky-high.   You’d better have a rock-solid business case for that.

These “popularity contest” polls merely explore what programmers say they would prefer to use, when embarking on a new project, all things being equal.   As such, they’re really not worth much at all.   Call it “maintaining what you’ve got” if you want to, and decry it if you want to, but that is most of what any production shop actually does.   As you know.

Hi,

Just thought of this so writing it now. Like stated earlier, I tried Python first and then went back to Perl. Mainly because it allows me to add to my scripts easily than Python. I don't start with Flowcharts of how my script will work. I just write a small script and test it, then add some error checks and functionality and try to make it as generalized as possible. Perl allows me to do that. So typically, my scripts would begin with all the data and code in the same .pl file, about 15-20 lines in all, and then I keep adding little by little and it grows to about 300 lines, and by this time, the input data is separated into a file and the actual script is in a different file, and it's doing everything from, say checking if the supplied input has exactly 8 hex characters, and if the configuration file is where it is expected or not, and if the mail server is up or not, and so on and so forth.

I don't know about the future of Perl for large projects, simply because I have never worked on a large software project and given my nature of job, I don't think I'll ever be, but:

When it comes to cli based automation, that can extract text, filter it out and email it, or put stuff in an excel and create charts, Perl shines. Rather, it outshines and out performs Python, especially when it comes to using Regular Expressions to mangle and slice and dice text based output, which is 90% requirement of my job. My opinion is based on my limited use of both Perl and Python

Perl lets me do something like (my $i = 0; $i < 10; $i += 1.25), which I really badly needed at that time, and still do, because I just have to loop over things that way to get my job done.

It has ternary operators, which is something that I really like and was not available in Python back when I tried it out. As Perl is not white space sensitive, I can do nested Ternary loops and still nicely comment it and space it out so that it doesn't appear cryptic.

Strawberry Perl Portable is another plus point. I can install all the modules I need, then just copy the folder onto a server and have my scripts using the perl executable from that folder. No need to touch the pre installed Perl on the Servers.

These points might seem trivial, but they do matter for me. I'm sure there are a lot of folks out there like me and that's the reason why Perl will have a future for sure as folks like myself need it.

All,

IMHO: Perl will only be dead when you can't move Perl to a new hardware or software platform.

Even if all development were to stop tomorrow, as long as I can take a tar backup of my favorite Perl release and compile on a new server, Perl will live.

If you count the value of Perl by how many programmers are *working* on different projects, and then calculate how productive they are at getting real work out the door, then Perl is probably in the top 5 in use.

I always generated a lot of "working" code in whatever language I was using, but with Perl, I've increased my productive many times over other languages I've worked with. YMMV.

"C" was good, but "Perl" is GREAT!!!

Regards...Ed

…then Perl is probably in the top 5 in use.

I agree with this guess. I see many job ads that list Perl in the small print after the headliners Java, C, SQL, Sysadmin, QA, Python, etc. Jobs that headline Perl are rarely followed but much else besides PHP or the occasional big data or VOIP package.

And to comment on the overall thread a bit more seriously than I did initially: Perl is doing better today reputation-wise than it was in 2005–2010 by my anecdotal experiences and the problem never had anything at all to do with Perl 6 as I have heard it. Also: MOP may come to the core, Perl 5 is faster, less buggy, and better with Unicode than all the high level interpreted languages, and depending on how you see a thing Perl has the best OO and the richest web and ORM frameworks. PSGI has normalized, unified, and revived the language that stormed the early web. These are things that keep languages alive. PHP sure isn’t surviving on its great reputation. I work primarily in Perl and have had two “greenfield” projects with it in the last five years (and JS of course being web stuff) at a Fortune 20 company. So :P

This reminds me of a recent interesting blog post

It might be better with Unicode, but actually the last time I wanted to use it I had to go elsewhere due to its lack of support for Unicode filenames under Windows. Maybe the situation is better now, but I'm not talking about a distant past. Directory operations and Unicode

I don't know what's the status now, nor do I give a flying rat's ass about what the heck is the situation under various flavours of Unix, but why would I use something if I can't even get it to open files?

Jenda
Enoch was right!
Enjoy the last years of Rome.

I think one of the big problems in Perl's future is one of the same ones people have been battling for years. Perl is meant to make the easy things easy and the hard things possible. However, one of the hard things about Perl that could be easier is grasping the language and documentation.

I refer you to syntax of Data::Dump and the associated thread as an example. In particular the words "The reason I remain confused is perlop" in Re^2: syntax of Data::Dump and "Sometimes the perl interpreter is too clever for me." in Re^4: syntax of Data::Dump are particularly telling. What is the cost of outputting data formatted as the language documentation asks for it to be input? What's the cost of accepting the input in a consistent fashion? Why is it normal to cite paragraph two (out of three) of footnote seven (out of eight, most of them multiple paragraphs long)?

A sharp blade cuts best, and Perl as the Swiss army chainsaw has a lot of sharp blades. However, a tool as old as Perl should be worn smooth about the handle which holds those blades together. The saying about a craftsman not blaming his tools assumes that a craftsman can choose and improve those implements. Lots of things about Perl have been improved over time, but there are still these odd gotchas people find surprising. A powerful tool can always be dangerous, but one should be able to be wary of the cutting edge and count on the handle.

The rule of least astonishment (principle of least surprise) usually makes allowances for audience type. Perl has a different core design than lots of languages, and it's okay to surprise a bit with context and such. However, when programmers are surprised by things on a pretty regular basis by little bits of things not part of the language design like the above example, that's bad.

Python is ugly (my opinion), Ruby is slow, and Java is wordy. Perl's weakness is that it's sometimes hard to predict without specific experience around that part of the language. We have a great community that provides support, which is a good thing because apparently we really need it. We need it to impart those nuggets of knowledge to the long-term apprentices who have chosen to follow the not so smooth path to Perl mastery.

Perl's future I think is less fraught with competition from Ruby and Python than people assume. I see competition from Go, D, Rust, and Lua from below now that systems and embedded languages are getting friendlier. I see Scala, Clojure, and Java coming in from the side. PHP and Hack will continue to follow behind, picking off the stragglers. Julia and R may grab a bit, too. The most interesting of these to watch I find to be Go, Rust, and D. Their goals seem to be very much aligned with the goals of Perl6, but they are delivering production tools.

Your post seems to imply that the problem is the language itself. I don't see it that way; and a recent study, probably the most comprehensive of its type ever, seems to support that.

People and companies don't pick (or not pick) programming languages based upon syntax or features. They are picked on the basis of perceptions; and perceptions are influenced by a huge variety of factors; of which syntax is well down the order.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I don't discount at all that perception is the main problem. I think Perl is a wonderful language overall myself. The perceptions of it being complex, deep, broad, and somewhat arcane start somewhere, though. They are also reinforced when people come to the language and have such issues as did WoodyWeaver.

Should the rough spots be enough to keep people away from Perl? No, I don't think so. However, the rough spots do little to discourage the negative perceptions of incantations via line noise. Smaller, more regular, and more orthogonal languages are less susceptible to these perceptions and to some extent to these realities. One of the ways for Perl to really answer critics is to overcome the perceptions, not allow things that reinforce them when someone ventures past the anti-Perl hype.

Go, Rust, and D are all low(ish) level languages designed to be used in situations where C/C++ would normally be used. In what way are their goals aligned with the goals of Perl6 (a very high level language) ?

Perl6 like Perl5 is a high-level language that is able to reach down to low-level things like bit strings and fine-grained control over system calls. With XS and the the FFI C is part of the Perl5 language. Perl6 has a much improved FFI. One of the goals of Perl6 is to have compilation and as far as I remember that includes JIT, precompilation, partial precompilation, separate compilation, and optimizations. Perl6 supports optional static typing for faster and safer programs.

Go, Rust, and D on the other hand are systems languages but are not so low-level as C. They are all growing toward higher-level concepts but retaining as much compilation speed and runtime speed as they can.

Go for example has goroutines, maps, slices, a continue for loops, support for imaginary and complex numbers, labelled goto, methods, a return of possibly multiple values, panics, channels, and more. It compiles quickly for fast development iterations. It has regular expressions in its standard library (although they aren't as integrated into the language as in Perl). Strings, although immutable, are a separate type from characters and aren't just bare character arrays.

Rust has vectors that support push and pop. It has variable interpolation. It has traits and dynamic dispatch. You can pass closures. Its match is closer to Perl's smartmatch than to a C switch. The 'if' block is an expression rather than a statement, so it can return a value to a 'let'. This is a great generalization of something like the ternary operator or Puppet's setcode() or Puppet's case statement. It supports channels for communication. There are both references and pointers. Rust's regex library supports iterating over capture groups, supports named and numbered captures, supports character classes, and more.

D's regex library is part of the standard library. It supports matches, splits, replaces, etc. D has associative arrays built into the language. It has mixins, operator overloading, contracts, attributes, traits, exceptions, and try/catch/finally/throw.

Go and D are garbage collected. What I've mentioned just scratches the surface. That I've mentioned a feature for one of the three doesn't mean it doesn't exist in the other two. Some of the features in these languages actually borrow from Perl, Python, and Ruby in syntax or inspiration.

There's a lot of growing downward from higher-level languages these days. Perl has always been at the forefront of allowing one to reach down into the system a bit. There's a lot of growing upward from some of these newer low-level languages, too. As people look at object-oriented, perhaps compiled or JIT compiled, modular languages with strong standard libraries and the ability to prototype and iterate quickly I see Rust, D, and Go as a niche just adjacent to Perl6, Clojure, and perhaps Lua.

Issac Asimov opined in the preface to "Asimov's Guide to Shakespeare" that the English language has changed little since that time simply because we wish to read The Bard in the original. I think that Perl 5 will be with us for a long time for the same reason. It really is that good of a tool.

Moose is providing a bridge to Perl 6 but at the price of feeling "heavy" as it were. Moo is advancing Perl 5 while still being "perlish". Perl 5 will be viable and even grow for quite some time thanks to that.

When I asked my friend about Moose/Mouse/Moo etc., he said: "If people want object orientation, they use Java or C++; that isn't what they want Perl for.", and I agree.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Then we should agree to disagree.

You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

What's the reasoning behind that point of view?

If they want object orientation they should not be using Java or C++. I'm inclined to say they should not be using C++ unless they have a huge codebase already in any case.

Jenda
Enoch was right!
Enjoy the last years of Rome.

Will in next 10 years

- Perl still have a vibrant community?
- the industry still have a lot of Perl-code to maintain?
- the industry use Perl for green-field projects?
- be a good investment for aspiring coders?

And my answers would be yes, yes, no and no.

I would say:

• Perl hasn't had a vibrant community for the last 3 or even 5 years.

  The last time it felt vibrant to me was when the PUGS project was running.

• In the last 10 years there have been 5 major shifts in the software/IT ecosystem:
  • The first was truly large-scale web serving.
  • The second was hadoop.
  • The third multi-core hardware.
  • The fourth was the smartphone/tablet ecosystem.
  • The fifth is the cloud.

  Perl has no presence in any of these technologies; and each of them supplants or marginalises technologies where Perl did have a presence. In each case, where there were existing Perl projects, they have been replaced entirely by completely new code in other languages.

  Not (necessarily) because the new language was better then Perl; but because Perl simply wasn't available.

  Any existing Perl code does not need maintenance, because it is just gone.In what few small niches it still persists; it won't last for long. Certainly not 10 years; maybe 5.

• Agreed.
• Agreed.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

You seem to have a very strict definition of "vibrant".

The way I look at it:

- Perl is still maintained
- CPAN still grows
- sites like this still exist
- books about Perl are still written
- conferences are regularly held


For my rather modest requirements that is "vibrant" - and I expect that to continue for some time...

And there is still Perl-code around that I expect will still last for a long time, simply because rewriting that would mean reverse-engineering a lot of very old and poorly documented code which nobody wants to do. But true - those are only some niches.

So yes - depressingly the "future" seems to be rather bleak...

my expression is this - all new software mostly scripted with python - KDE GUI stuff (kig etc) or editors (e.g. notepad++ or sublime or whatever), the further we go the less perl support is.

python gained much momentum, and - I join the opinion - that damage bringed into community by perl6 in its current state is huge and continuing.

Perl5 is much better than python, but python is better maintained - e.g. look at Qt support - python have latest Qt5, perl have NONE...

now the good news:

• the situation is not likely to become worse than now, it is mostly stabilised.
• And you can often use Inline::Python, for
  • either utilising forgotten CPAN library (so you can use Qt from Perl using python support)
  • or just to reuse new library that is available only for python

Fortunately Inline::Python is in a great shape now, and sponsored by grant.

I only miss one thing - http://pypi.python.org/pypi/PythonPerl/0.9 - which is abandoned and not available at their site - maybe Stefan Seifert (author of Inline::Python) will help me with this?
if so - nothing to worry about, the future is bright, :)

that damage bringed into community by perl6 in its current state is huge and continuing.

This is nonsense and I’m tired of seeing it here without the slightest supporting logic or evidence.

Perl5 was zooming up to a dead end 15 years ago; there was a ton of infighting, apathy, unwillingness to look outside, big gaps between releases, and attitude of if you won’t do it my way I’m taking my commit bit and going home. Perl6 shook that up, broke things loose, and got a lot of new persons interested in Perl5 and moving it forward. The Perl5 renaissance that began c 2004 might have never happened without the Perl6 efforts. Moose, MOP, Moo, Mouse, and the advances that have arguably made Perl5 a superior OO language to Python and Ruby and Java only came in because of Perl6 discussions and dreams.

Moose, MOP, Moo, Mouse, and the advances that have arguably made Perl5 a superior OO language to Python and Ruby and Java

I'd like to see that argument!

I'm not against it; I'd just like to see:

1. the benefits of Moose/Mop/et al. laid out;
2. a comparison with the OO in those other languages.

My perception of Moose is that it is an expensive getter/setter generator. My perception of MOP is that is provides for introspection -- that has few if any legitimate uses.

I'd like to be persuaded that I'm wrong.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Sorry to be putting it this bluntly, but I haven't seen a bigger self congratulatory crowd than the Perl community in my whole life.

Programming tools and technologies, come and go in cycles of trends. Over the past years I've worked on numerous Perl projects, many of them had an explicitly goal of moving away from Perl at the earliest. In fact nearly every Perl project I've worked on has been a migration project. No one is doing serious work in Perl.

And Perl has missed many boats, We were not there where Application servers were all the rage, when Python started spreading like wildfire in the scientific computing community, when web frameworks were the talk of the years, when asynchronous programming frameworks peaked, and now when Big data is all over the place. All we have done and doing is merely playing a catch up game with the rest. This is not going to fly anywhere in the larger programming community. Shops that are already using Perl may continue to support existing applications, but it makes no sense for them to start new Perl projects.

We were there in the early parts of the web, when people thought writing a Perl script was better than writing a shell script. And all we've done from there there is live in an assumption that, that is all we ever need

We have a language where no new big changes can happen, We are not going to get sub routine signatures, no try/catch, never a class key word, never get all the OO goodies default out of the bag, We are never going to move out of XS, we are going to keep the wheels running. But no one has any reason to use this for doing anything new or serious.

Perl isn't even in the list of languages which kids these days have heard of. Because when they were in college, Perl is what their seniors two decades back used. Managers by and large, either don't have a high opinion of Perl or given absolute low support for it among team mates, don't even count it as a viable alternate these days. You can convince them to use it for some small time automation, or some other unix work, but they are not going to allow you to use it do serious work.

Perl 6.0.0 can change all that. But we are waiting indefinitely to see some light at the end of the tunnel. There is no telling when we can see a usable Perl 6 to do some serious work. And any one who asks for a date, is immediately labelled a troll for requesting a time bound closure to this project. For nearly all practical purposes Perl 6 is a bit a like 'Pursuit of happiness', the whole story is always how awesome the future is going to be, which never comes to arrive.

Based on all this, I guess if all you want is to make a living and are willing to develop deep expertise in some language I guess JVM languages are the way to go, Java, Scala with some Python.

The saddest part about this thread, is the acceptance.

We, the perl community simply don't see any mechanism by which we can change what we all see is happening.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Some of us already basically watch it from outside. Apart from a few fixes to my modules I did not write any Perl for ... years and while there are things that nag me about C# (yes, regexp support) I'm pretty much gone.

And no, I do not thing a complete, functional, tested and reasonably performant Perl6 finished and released next month would change any of that. Neither for me, nor for the rest of the world. Not only is the language years overdue, it had morphed into something ugly, overcomplicated and messy.

Jenda
Enoch was right!
Enjoy the last years of Rome.

Yes, change the version number.

Perl 7 = Reborn

The ten-year project to refactor Perl's internals to allow these big changes should have started in 2000. Instead, we got a cartoon butterfly.

We are not going to get sub routine signatures

Unless we got them: Experimental Subroutine signatures.
لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

The docs say:

WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl.

... which doesn't exactly inspire confidence ;)

We have a language where no new big changes can happen, We are not going to get sub routine signatures, no try/catch, never a class key word, never get all the OO goodies default out of the bag, We are never going to move out of XS

We'll never even get strict and warnings by default, or UTF-8 ...

What does it matter what the default is? Besides the default, at least for strict and warnings, does make sense. In one-liners and in scripts that have five lines, they would be just a nuisance and in longer script a

use strict;
use warnings;
no warnings 'uninitialized';
[download]

are just an unimportant and ignorable part of the boilerplate.

Jenda
Enoch was right!
Enjoy the last years of Rome.

I do think perl does have a future, but it currently rests in very narrow verticals.

Myself, I use it mostly for administrative tasks, though I have written other things (desktop and command line stuff for $work) in it as well. I find that perl is much easier to get things done on the machine with than bash/ksh/csh/flavor-of-the-decade-sh. Many sysadmins I know use perl extensively to get things done. I've almost completely foregone sh in lieu of perl.

That said, I do think that there are some things that could improve traction outside of the narrow verticals:

• Threading. While there are facilities for it, using them seems very onerous. I'm not sure if that's my lack of experience talking (I could see threading being onerous nearly anywhere) or if use threads; is just painful. I seem to recall a meditation recently that expressed much gnashing of teeth concerning the state of p5 threading, but I also seem to recall that it was mostly performance, not usability related.
• OOP. Moose/Moo/Mouse/M.next seems to be attempting to address this, but I do feel it needs to be baked in a bit better, if not by default. That said, I haven't even messed with the current options yet, as I usually just use hashes to get stuff done. Further up in this thread there have been statements to the effect of "no one who uses perl regularly would use it anyway", which I disagree with. I could easily see good OOP being useful to Mojolicious and Dancer projects to name a couple of things off the top of my head.
• Saner defaults. As mentioned above: Strict and Warnings should probably be on by default, but I also know that will break lots of existing code and will wreak havoc with one liners. I'm not sure how to address this in a logical manner. Perhaps something like use bootstrap;, but that's not really an improvement.
• Fix subroutines to accept parameters. While my ($foo, $bar, $bat) = @_ is usable, it reduces the readability of the code to someone who is unfamiliar with the language. It's my understanding that there's some stuff in 5.20 that may address this in a fashion.

All of the above said, in my narrow vertical I typically use perl for (administrative tasks), cluster management software is getting more and more useable. Salt is a REALLY REALLY powerful tool that's very usable. I don't think it has the capabilities of replacing perl outright for me, but it's making once hugely difficult stuff (multi-machine deployment and management) significantly easier. As these tools get more powerful, I do think that perl becomes far more niche, but I don't think it'll hit "dead" for quite some time.

A while back I ran into a video (maybe a TED talk?) regarding The Machine. I have to wonder what impact a fundamental shift in hardware would have on any language(s). It has been a while and I have not gone back and re-examined this, but assuming a fundamental advance in hardware, is there much of a future for anything we know?

It depends on "how much future" one includes in their definition of future of course. My point is that it may not be the nature of a given language itself that determines it's demise, but instead it could be that computer languages as a whole might simply become irrelevant because the listener might evolve beyond the core concept of what we call a language.

So, enough SciFi for the moment I guess.... having a Asimov/Hienlein moment... ...It happens....

I have to wonder what impact a fundamental shift in hardware would have on any language(s). It has been a while and I have not gone back and re-examined this, but assuming a fundamental advance in hardware, is there much of a future for anything we know?

Hardware advances tend to be transparent to languages, the OS hides them behind established device/file paradigms.

Memristors are just memory. The fact that it's persistent will be managed by the OS rather then languages.

Silicon photonics speed up memory and device access, but is otherwise transparent to languages.

Even where hardware advances can be usefully utilised at the language level -- virtual memory; threading -- it tends to be years if not decades before support filters into languages.

Hardware supported virtual memory has been around forever; but at the language level we still pretend that we have a single, linear memory space where the stack and heap occupy the same space despite the fact that in reality they occupy different chunks of physical ram.

Threading is ubiquitous in hardware now, and available to many languages; but no-one has yet really found the sweet spot for how to encapsulate them; hence we have either raw low-level; or some, mostly inappropriate, metaphor for them.

Basically, I don't think hardware really affects languages. There will always be a C/C++ compiler; and most other compilers and interpreters are built on top of that.

Maybe someone will come up with a radically different architecture; but I see no signs of it yet.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Your comments about hardware, and virtual memory in particular, reminded me of this good talk by Gary Bernhardt:

The Birth & Death of JavaScript

If you haven't seen it and have a few minutes to spare, it's enjoyable and maybe even a little thought provoking about whether hardware virtual memory is a good use of resources going forward.

And as for a radically different architecture, the Mill CPU has a great series of talks on video devoted to its development. It doesn't challenge your point about languages transparently supporting underlying system variations. But it will provide a very different target for compilers and JIT's which may favor some languages over others.

Thanks for that BrowserUK. Those points are informative to me, and seem to be on the money.

Clearly the example I used is a poor one for having tried to make the point I was attempting to make. (My lack of depth of knowledge in the arena). Perhaps our understanding of language is driving our innovation in hardware instead of the reverse. I wonder what might happen if the reverse was approached more aggressively. Maybe that is what is happening at a certain level in the fields of bio-mimicry and maybe even in quantum computing.

At any rate, I think you are right; hardware does not affect languages at this point in time, but I don't doubt that it will in the future. I find it hard to believe that all machine languages by nature have to operate at the basic level in one of two states. I think the success thus far has limited the innovation.

I have gone way off track relative to the original post and suspect I better stop. Thanks for the interesting meditation.

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is simply an inconvenient fact

wjw

By the way found this today: http://fosdem.org/2015/schedule/event/get_ready_to_party/

Now that Perl 6 is going to see a production release in 2015, which is a barely 2 months away. We can be fairly confident that within an year a lot of current day troubles will be gone!

Like the link says, Time to party!

Time to party!

Like it's 1999?

I'm not a fan of 'pre-announcements'; teasers and the like. Hell! Even the fanbois are getting bored with those.

Even what little supporting description there is, is divisive: "outlasted the naysayers".

The majority of those categorised and denigrated as naysayers; were previously enthusiasts and even contributors, worn down and turned off by the endless premature hyperbole; constant bickering; repeated reboots; never-ending next Christmases. Not to mention that "even its designers said it was impossible."

Will I read/watch the event? Sure. Will I watch it live? Depends if there are any reruns showing of "Star Trek Into Darkness" or "Matrix Revolutions" showing on catchup that day.

But I will watch/read it. Eventually. But my expectations will be very low.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I may be wrong, but I have the feeling that we are getting really near this time to have a real Perl 6, possibly not yet really full-fledged, but pretty close, the performance improvement has been quite massive over the last year, Perl 6 seems to be able to use existing Perl 5 modules (including XS or Inline C modules, it seems).

It seems to me that that Perl 6 development is really getting into another dimension this time. What I have used so far in my Perl 6 experiments was still not entirely satisfactory, but there has been a very clear improvement. I haven't made any detailed study, but it seems to me that programs are running at almost satisfactory speed (compared to Perl 5), just compiling is still quite slow. If my impression is right, I would not care too much, a few seconds lost on compilation time don't matter for me when I work on GB-long files.

What? Perl6 released next year? When was this first announced? 2006?

Isn't this the reason of Perl decline? People read an announcement like this, hold their breath ... and turn blue and eventually start to smell.

Jenda
The knight that says nay.

So this is from the link

But mostly how a bunch of stubbornly fun-loving people outlasted the naysayers to accomplish the extraordinary task of implementing a language that was so ambitious, even its designers said it was impossible.

How can anybody even afford to miss a deadline after writing something like this? After all they have to prove a point to 'the naysayers'. So I guess we should all take this well that this time its for real!

Prepare to be delightfully surprised.

Actually at this point, any thing with Perl 6 would hardly surprise me(us?)

Speakers: Larry Wall

All the more reason to take this seriously

That's a lot of Apocalypti to write in two months.

I don't see how you can capture a wide audience without embracing OOP. That is what is being taught at Colleges, that is what people know, and that is what they want given the large and growing amount of OO programmers. Believe all the languages used to develop Mobile apps are OO, also.

(Shrug ...)   College curriculums evolve along with everything else, trying their best to “keep current.”   However, the gamut of “what people know” is considerably broader than that.   Believe it or not, there are plenty of people out there who, like me, routinely and during the course of every day “shift gears” between all kinds of programming paradigms that are ... and, that are not ... today taught as dogma in universities.   One moment we might be writing OOP, and later on in the same day we might not.   All in a day’s work ... you pick up a wrench, then a screwdriver, then a ...

All that being said, this is not a compelling motive, either for “the death of the Perl language” nor for any sort of dramatic re-purposing of what it is today.   Perl, like all other languages, is a tool.   It’s not a fashion-statement.   It’s not merely something that might be used in some future project:   it’s the implementation language of literally thousands of applications, some many years old now, that are responsible for billions of dollars’ worth of mission-critical work and the jobs that go with them.   (As well as “writing brand-new stuff.”)   As a professional-grade language system, it needs no introduction and no defense.   Therefore, any talk of its “future,” or of its “demise,” truly are moot.   Such things are “academic arguments.”   Meanwhile, Perl is one of the perhaps many languages that people use, all in a day’s work, to pay for their kid’s college educations.   :-D

So somewhere between: "obscurity, nicheness" and "extinction". How sad.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Actually, a lot of people [erroneously] ascribe “the perceived deficiencies of a deployed system” to some deficiency of “the (whatever it is ...) programming language that was originally used to implement it.”   And... they perceive that “the solution to their problem” is “to rewrite it in <<insert_language_here>> ... And-d-d-d-d... they delude themselves into supposing that this step is anything less than:   “utterly and completely rewriting it.”   From Scratch.

They seem to have no trouble attaching “business risk equals zero” to such a hair-brained scheme . . .

Well, here’s a very-comparable (I think ...) real-world analogy:

False Syllogism #1:

• “This (“fifteen-story, full of offices and people”) building Sucks™.   (Premise.   Given.)
• This building is made of Wood.
• Therefore, the reason why this building Sucks™ is because it is Made of Wood™.

False Syllogism #2:

• If this building were not Made of Wood™, then it would not Suck™.
• Concrete™ is not Made of Wood.™
• Therefore, if this building were Made of Concrete™, it would not Suck.™

False Syllogism #3:

• The costs (and risks) of replacing a (“fifteen-story, full of offices and people”) Building Made of Wood™, with an equivalent Building Made of Concrete™, are negligible.
• Concrete™ is categorically-better than Wood.™
• Therefore, we should start immediately.

If we were talking about “an actual building,” then your damned-fool plans would never get off the ground.   The building-inspectors would stop you, if no one else did.   They would know perfectly-well that the only connection between a wooden structure and a concrete structure is that the before- and after-structures would coincidentally occupy the same real-estate lot, and they would prohibit you to think otherwise.   However, the computer-programming industry is ... at this point in time, at least ... “un-regulated and un-professionalized.”   Thus, at this point in time, “anything goes.”   Million-dollar mistakes like this one, therefore, happen all the time, because the folks that “pour the bits” imagine that they have nothing at all to learn from the folks that “pour the concrete.”   (Or, for that matter, that “erect the wood.”)

Maybe this particular project was built in a place where wood construction never would have been suitable.   (In the real-construction trades, such plans would never have been approved.)   But most likely, someone simply wants change for change’s own sake.   And, with no third-party voice of reason to check him, he sets sail.   Straight into:   “the same old rocks.”

Blah!

All of which is completely and utterly irrelevant to this thread. Which isn't about any given project written in Perl; or even all projects written in Perl. No one, except you, has made the slightest mention of anything that relates to replacing anything with anything.

Nor about the pros & cons of one language over another.

The subject -- it's just up there in case you've forgotten -- is: The future of Perl?

Other than your first post which amounted "I don't care cos I don't need Perl to evolve, -- which, in part, mirrors my own position; the difference being that I think it a shame to see my favorite language slip into obscurity even if it doesn't much affect me personally -- the rest of your blather is just irrelevant-to-the-discussion, scatter-shot straw-men, that you set up so you could knock them down. And you've even failed dismally to do that in any sort of a convincing way.

Your analogies suck; your syllogism are made up; and your conclusions are illogical. And it's all irrelevant to the thread.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I suspect that many people today are caught off-guard by a language that has no real notion of “compile time [error checking],” and that strives to be very permissive ... to DWIM.   There are both several different ways to say the same thing, and several idioms that look similar but that don’t do the same thing.   Unless you use strict; use warnings; you don’t get notified of errors that other languages would reject outright.   It’s certainly not as amorphous as JavaScript, but it can be off-putting.   If you came from a language with strong typing, and with a “there’s one way to do it] syntax, you will find yourself without the crutches things you are accustomed to leaning on.   You’ll write something, see that it compiles and even runs, and assume erroneously that this means it’s correct and that it’s doing what you wanted.   Then, you feel like you just got smacked in the face with a skillet.

But, quite honestly, I think that just about every programming tool out there has more-or-less the same kinks ... just, different kinks.