The XP Nodelet informs me that I've been a member of the Monastery 10 years as of today, but it feels quite melancholy in the wake of the most recent Tiobe Index. Perl was ranked as the 9th most popular language in January 2013, but has fallen to 13th one year later.
A look at their long term history reveals that perl has fallen from an average ranking of 4 when I first entered the Monastery, to an average of tenth now, and my own experience has confirmed this: most of the work I do in perl these days is prototyping for fuller development in other languages.
What saddens me most is that I have learned a lot about software development from perl as a language, and as a community, and now it's beginning to feel that this world has increasingly little relevance for those who live outside of it.
Re: A Melancholy Monkday
by moritz (Cardinal) on Jan 19, 2014 at 10:20 UTC
|
It saddens me too.
It also saddens me that large parts of the community are still in denial
about the downwards trend. Yes, I know that the TIOBE methodology sucks (I've
said so myself), but business people still make decisions based on those
numbers.
Moreover there are other, less contestable comparative metrics by which Perl is
losing, like module count and
job
counts (yes, that's from 2008, I know; but newer comparisons I've seen but
don't remember the URLs of right now mostly confirm the trend). Also,
github has
numbers that place Perl at no. 12, which is disturbingly close to what TIOBE
says.
Some people use the argument that goes like this: those comparisons are
relative, and the programming language "game" is not zero-sum. The total
number of programmers is increasing, so even if Perl is losing in terms of
relative numbers, it is (or might be) gaining in terms of total numbers. That
argument is somewhat correct (and again, I've used it myself in the past), but
I still think that it is a rather weak argument for defending the status
quo.
Maybe I'm hanging out with the wrong Perl 5 people, but many parts of the Perl
5 community don't feel all that vibrant, and when I try to answer a Perl
question with code that is far from best practises, I try to search for a
tutorial that explains how to do it better (use strict; use warnings; use DBI
placeholders; use lexical file handles etc.) and most of the results that come
up are crap (outdated, or don't get the essential points across). Finding Perl
programmers for $work is very hard, and so on.
Even if you ("you" meaning the casual reader, not the OP here) are not
convinced, please ask yourself one question: If we want to improve things,
what's the best starting point? Admitting that there might be a problem, or
insisting that everything is fine?
Assuming for a moment that you are with me, and not with the denial camp,
the next step is asking "why?".
I think there are several reasons. One is that Perl isn't new and shiny
anymore. Sadly there's not much we can change here.
Another reason is that there has been a lack of killer applications written
in Perl in the past year, or people simply don't talk about that stuff is
written in Perl. I have hopes that http://www.builtinperl.com/ changes the
publicity situation a bit for the better, and personally I'm excited about
Duck Duck Go and the
Lacuna Expanse.
But there is a very important reason that is easy to overlook if, like me,
you love Perl: There are parts of the language that are plain crap. Not having
subroutine signatures is plainly embarrassing. Having to bless objects
yourself is embarrassing. The fact that say reverse 'foo' doesn't
reverse the string (even though reverse is the recommended way to
reverse a string) is just wrong. There are lots of other WTFs in the language
that I won't go into; that's a topic for a different Meditation, if there is
sufficient interest. But any experienced Perl programmer has come across a lot
of them.
Perl people often react with denial to these problems as well. The standard
response is "But we have Moose" or $WhateverCoolModule. Well, Modules
are a great tool for tasks like speaking HTTP, but to be an accepted patch for
a missing language feature, it needs to be very widely adopted. Moose
probably comes closest to that in the OO world, but when you take a look at
the three big web frameworks, you'll see that only Catalyst uses it
(and some of the core contributors regret it), Dancer doesn't, and
Mojolicious uses its own OO implementation.
The situation is even worse in the realm of subroutine signatures; there's
a myriad of modules out there, most of them using source filters (and yes,
Devel::Declare still shares the downsides of source filters),
most of them force you to write a different keyword than sub (which
trips up any static analyzers, linters etc.) and none of them seems to be a
clear winner.
So, we need evolution and/or revolution. In the core, not just in modules.
Since I invest my free time in revolution, it is not my
place to comment on how evolution should be done. I just observe that it's
vital.
All other efforts depend on that, in the end; writing good tutorials
depends on having a consistent, understandable thing to explain. Having fun
using the language depends on not having to re-implement OO (or relearning the
currently hip OO module), and so on.
And all efforts depend on admitting that there's something wrong in the
first place. Thank you, starX, for brining up the topic, even if it's an
unpleasant one.
| [reply] [d/l] [select] |
|
The fact that say reverse 'foo' doesn't reverse the string (even though reverse is the recommended way to reverse a string) is just wrong.
IMO the fact that you consider context to be a flaw rather than a strength is indicative of the reason why Perl5 has seen a decline in absolute popularity(*) over the past 10 years.
Instead of celebrating Perl's unique characteristics; explaining their utility and exploring their merits; highlighting and contrasting the effective productivity that results from having a language and language constructs that favour the concise and simple construction of algorithms for the common cases over the theoretical niceties of full orthogonality; the Perl community has become apologist for not being like every other language -- verbose, laborious and painstaking in putting the desires of the grammar theorists over and above the requirements for code development and the needs of the developers.
The pedants and purists have done far more damage to the prospects of Perl, than all of the discontinuities they perceive, put together.
If language is defined as a means of capturing and communicating complex ideas; then there is simply no need for a language -- computer or otherwise -- to comply with, nor be constrained by, any grammatically perfect set of definitions or rules.
Take any natural language. They all have their anomalies and discontinuities. They have homographs, and homophones, and heteronyms, and heterographs, and synonyms, and polysemes. They have ambiguities and contextualities and disorthoganalities. They are flexible and fluid and living, evolving entities. Indeed, it is the anomalies of natural languages that we human beings most delight in and celebrate.
When was the last time you saw one of those verbose and tortuous amalgamations, of boiler-plate phrases with prescribed meanings, studiously devoid of proscribed constructs, so beloved of the law-making and law-enforcing professions; win awards or plaudits for its construction?
In fact, it is exactly the opposite of those that we celebrate. Poetry and prose in all its diverse forms would be almost non-existent if it all had to comply with some set -- whichever set, assuming you could get agreement on a single set -- of formally defined rules of grammar.
What I see over the last 10 years is that instead of explaining, justifying, and indeed, celebrating that we use a language that favours capturing the semantic needs of the common case, with concise and efficient syntax; we've become collectively apologetic for the disorthoganalities that arise from the pragmatic favouring of utility and practicality, over academic nicety and theoretical purity.
Perl5 has its great strengths -- born of its unique qualities not despite them. And the way to reinvigorate Perl as a language and development environment is to embrace those strengths not deny them. To explain, teach and laud those unique qualities; and to build upon them whilst staying true to the original design philosophy of the language.
(*Absolute versus relative).
As the number of programmers grows -- especially through the creation of entirely new markets for software; eg. mobile/tablet/SmartTV/SmartDash apps -- the relative proportion of Perl programmers has fallen due to there being no viable Perl presence -- nor possibility for it -- in those market places. That's further weakened by the near absence of Perl in the cloud market place; mostly due to Google preferring Python to Perl.
I perceive that there is also a fall-off in the absolute number of Perl programmers. In part this is due to there having been some proportion of people using Perl that came to it because it was the in-thing at the time. They've since migrated away to RoR or PHP; then Objective-C or Java; and will shortly be looking to GO or Dart or whatever else they think will make up for their inabilities as programmers.
In part it is because Perl(5) reached a point where it was due for an upgrade; but despite the coming and going of many Christmases, that upgrade has never arrived. The result is that Perl5 first stagnated; then started a phase of trying to evolve through a) prosthetics: the rapid adoption of ill-designed and badly integrated stick-ons; and b) comb-overs, wigs and plastic surgery: cosmetic makeovers designed to flatter and conceal rather than modify the underlying nature of the beast.
Like sticking a side-car on a motor bike and calling it a car; or wrapping over a 40 year-old veedub chassis in a plastic facsimile of a GT40 and calling it a race car; both forms of 'evolution' are transparent failures.
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.
| [reply] |
|
IMO the fact that you consider context to be a flaw rather than a strength is indicative of the reason why Perl5 has seen a decline in absolute popularity(*) over the past 10 years.
I do not think that context is a flaw in Perl 5. I believe that reverse's context dependence in particular a flaw.
Perl's usual approach is to have different operators for different functionalities. + for numeric additions, . for concatenating strings. lt for string comparisons, < for numeric comparison. But reverse for list reversal and reverse for string reversal clearly breaks that pattern. Instead of coming up with a different name for one of the operations, it abuses context, even though it's perfectly reasonably to want to reverse a string and use it in list context.
Context is well and good, as long as we stick to the principles. reverse doesn't, and that surprises newbies regularly and seasoned perl programmers occasionally.
The same could be said the x operator (which does different operations based on the argument syntax, not based on name or context) or the bitwise operators.
| [reply] [d/l] [select] |
|
|
|
|
|
Not having subroutine signatures is plainly embarrassing.
Strangely enough, I've been programming in a variety of languages for over 30 years and this is the first time that I can remember coming across the term "subroutine signatures". But since moritz thinks they're crucially important it seemed only fair to find out what they are.
So, off I go to my default search engine and ask it about subroutine signatures. It turns out that they are just interfaces - essentially what would be described by a well-functioning prototype system. Presumably this precise term is used in some other branch of English which is why I haven't come across it before today.
However, the pertinent thing is that of the first 10 results (my arbitrary choice) returned by the search engine, fully 8 are specific to Perl (and one of the others is the wikipedia entry explaining the term). I was pleased to find that contrary to the doom and gloom in this thread and that perpetuated by the devotees of other languages more generally, Perl is actually at the forefront of discussions on some computational matters.
So let us not despair too much. For all those who would rally round and actively try to boost Perl's reputation, very good luck to you. The starting point is to my mind at least not so low as many might suggest.
| [reply] |
|
The more common term is "function signature" or "type signature", but since we call functions "subroutines" in Perl, it becomes "subroutine signature". No wonder you find Perl discussions when looking for mostly perl-specific nomenclature :-)
| [reply] |
|
Its strange that you talk so much at length about Perl 5 and not mention a word about Perl 6.
Nothing that Perl 5 can ever do will bring back those glory days. Mostly because many things that Perl 5 used to offer as USP are now available in other languages. The remaining ones don't really make that much of killer features.
Perl 6 was supposed to fix these very problems. Due to unfixable problems plaguing Perl 5. And we haven't seen anything from the Perl 6 project that could be considered worth replacing Perl 5.
A moment of introspection. Don't take this is as a the usual Perl 6 troll posts. But frankly speaking how much of band aid can possibly fix Perl 5.?It can keep Perl 5 alive for its existing user base. But there is no way you can compete with the newer breed of languages with routine 2 year release making small time syntax improvements.
Perl 6 has to also take it as seriously as Perl 5 does. Stop pedantic debates on production readiness and release something what rest of the world considers production ready.
| [reply] |
|
Its strange that you talk so much at length about Perl 5 and not mention a word about Perl 6.
I did mention it, albeit indirectly. Just look at where the "revolution" link takes you. That said, I've talked about Perl 6 here on perlmonks often enough that I assume most regulars here are familiar with stances. Or if not, it's easy for them to read my older ramblings on Perl 6.
Perl 6 was supposed to fix these very problems. Due to unfixable problems plaguing Perl 5. And we haven't seen anything from the Perl 6 project that could be considered worth replacing Perl 5.
Nothing from the Perl 6 project can, at the moment, be considered a worthy replacement for Perl 5 at every level. At individual levels (for example expressiveness, or concurrency (on the JVM backend at least)), Perl 6 and its current main implementation, Rakudo, are actually superior to Perl 5. There is still much work to do (much more than anybody imagined when the Perl 6 efforted started), but I'm still hopeful.
But there is no way you can compete with the newer breed of languages with routine 2 year release making small time syntax improvements.
... which is why I'm invested in the Perl 6 effort. I wish more people would realize that the long term health (and I'm talking about > 5 years here) of Perl depends on Perl 6. For all its maturity, Perl 5 simply can't move fast enough to be competitive with all the rest of the languages out there.
Stop pedantic debates on production readiness and release something what rest of the world considers production ready.
Telling volunteers what to do is never going to work. That said, you can be assured that I spend about 98% of my Perl 6 time actually improving stuff, and only 2% responding to troll.
| [reply] |
|
|
|
Re: A Melancholy Monkday
by atcroft (Abbot) on Jan 19, 2014 at 06:49 UTC
|
As long as perl is useful to and educational for you, who cares what someone else says about the popularity of the language you use? Seriously, since I joined this site, I have seen various threads of people bemoaning this same thing-that this report claims perl's demise, that that survey or index reports that perl is dead or on its way out. Saddening, maddening, yes. But really, why should they matter? Perl will continue for as long as it is useful or someone finds value in its use. If you are worried about your skill sets, then by all means try to pick up another language (or two, or more, if the urge hits you), and take to heart what each of them teaches you, but I would not sweat it too much just yet.
| [reply] |
|
Hi,
I'm following this "popularity discussion" here and elsewhere. I normally agree with the opinion that it's irreleavant want others say as long as the language is useful and actively maintained, which perl is.
But: Currently we are searching for a young employee. There is not one that has experience in Perl. But worse, the candidates are not really attracted by learning a language which seems to be old, outdated and unfancy. I can understand this. Arguing that the programming language is more or less irrelevant in the long term is difficult addressed to someone being at the start of his professional career and thinking about where to invest learning power into. It's definitly easier to convince someone knowing he can now learn a very attractive programming language.
Many many people are really surprised hearing that we use Perl as main programming language. From "what is this" to "uhhh, that still lives" you can hear everything, but really no "oh, what a mature, effective programming language with an unbelievable eco system".
So, I'm really not against all activities raising the popularity of Perl.
Best regards
McA
| [reply] |
|
We are searching for a young employee ...
Perhaps that is part of your problem. I want to find experience. Hire people who seem to have the knack for it, then take them under your wing and teach them what you do and how you do it here.
| [reply] |
|
I don't get it. I've had several young employees in the recent years, and though they didn't know any Perl, none had any reticence learning it to do the job; in fact, they all were quite happy to learn something new.
| [reply] |
|
But: Currently we are searching for a young employee. There is not one that has experience in Perl. But worse, the candidates are not really attracted by learning a language which seems to be old, outdated and unfancy.
Tell them: "Never call Perl old, outdated, and unfancy before you have worked with MUMPS." ;-)
Why are you explicitly looking for a young employee? No money for experienced employees?
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
As long as perl is useful to and educational for you, who cares what someone else says about the popularity of the language you use?
Everybody who cares about Perl should care. Public perception influences what programming languages are taught at universities, and what language new "from scratch" projects are written in. Both choices influence the talent pool and the number and quality of available modules and tools. So the past perception of Perl has shaped the status quo (about which you seem to be happy), and the current perception of Perl shapes the future of Perl.
| [reply] |
Re: A Melancholy Monkday
by FloydATC (Deacon) on Jan 19, 2014 at 20:16 UTC
|
Perl started out as a language for hacking together reports and automating system maintenance tasks. For a while, Perl was the go-to language for web development as well, and I think this is why it gained a lot of "mainstream popularity". Fast forward 20 years or so, and there's a whole lot of languages equally well suited for web development. (Some people would say better suited. Pff...) Some of those languages are well suited for other purposes too, and sometimes you can't do without them. (If "yum" was written in Perl I would never install Python. Ever.)
So, why are people choosing those other languages? Apart from there being a lot of choice out there, here's a few of the reasons I've heard from co-workers and friends:
- It's a hacker's language. The syntax is just strings of line noise gibberish that makes sense only to someone suffering from extensive marble loss. (This is obviously false, regular expressions actually make perfect sense. As do hashes of hashes of arrays of objects. Containing hashes.)
- Okay so it's possible to write readable Perl, but it's still hard to maintain. We had this one program... (Everyone's heard about this nightmare project with unmaintainable code that some ex-employee pulled out of his colon before he was convinced to pursue other career options.)
- Multithreading is a PITA. This one is hard to argue with. (Hashes are the backbone of Perl, making them work well with threads is an exercise in masochism. Compare and contrast with Java's ConcurrentHashMap. DBD::mysql, perhaps the most important module for some of us, isn't thread-safe so it must be carefully worked around if we are to try using threads.)
- It's a moving target. Beginners can choose between learning the obsolete Perl 5 syntax or the experimental, eternally unfinished Perl 6 syntax. (I have not yet bothered with Perl 6 myself...)
- There's no free IDE like Visual Studio or Eclipse. (I don't think I've ever heard of someone outside of the Perl community who knew that Padre existed. They only know about ActiveState.)
Fortunately, I have a team leader and a boss who really doesn't care what languages my use to solve problems in the team, as long as we get the job done well and on time.
Between the five of us, we do VBscript, PowerShell, Perl, PHP, Javascript, CMD batch scripting and BASH shell scripting. Plus some C/C++/C# and Java hacking if we have to. Back-ends we have to deal with include MySQL, PG, SQL Server and (occasionally) Oracle. Note that we don't even work with software development, it's all systems maintenance and troubleshooting.
The important thing for me is not if Perl is no.4 or no.14 on my team leader's list of preferred languages (because he stumbled across such a list on the interwebs). What matters to me is that I'm still allowed to use Perl for tasks where it makes sense to do so. Such as reporting and automating systems maintenance.
-- FloydATC
Time flies when you don't know what you're doing
| [reply] |
Re: A Melancholy Monkday
by chromatic (Archbishop) on Jan 19, 2014 at 07:49 UTC
|
A look at their long term history reveals that...
... they've changed how and what they measure several times, so it's easy for honest empiricists to dismiss their chartjunk.
| [reply] |
|
Even that were true, they've changed it equally for everyone else. So that's a perfectly fair way of measuring things, at least in comparison if not absolutely.
Languages never truly die, but their usage drops slowly to a point no one wants to do any work worth doing in that anymore.
| [reply] |
|
| [reply] |
Re: A Melancholy Monkday
by xunker (Beadle) on Jan 19, 2014 at 22:40 UTC
|
I hit this post by accident, but it struck a chord with me. My user info says I've been a registered user here since late 2000.. of course I haven't posted anything here for about ten years. Perl was my first "adult" language, where I was writing code meant to be used by other people, not just myself. I later on (2002-2007) created a ridiculously popular web site from Perl -- about 9 mil pageloads/day.
But I've left perl since then. Why?
I got really frustrated at the lack of progress in both the language and the culture of those who used the language. It wasn't just the perpetual treadmill of Perl 6, it was the complacency of the community around the lack of change. At the time I felt that there was no drive for us to re-evaluate established patterns, we were quite happy to keep using the same approaches as before and that there was no will to explore alternatives. I didn't want to spend the rest of my career doing what felt like maintenance programming.
That may well have changed since then (it was 7 years ago), but that was my reason and I believe others felt the same. I don't hate perl.
How would Perl need to change to get me to come back? I don't know. I suppose, like any language wanting to grow mindshare, it would need to offer a way for me to do things I'm already doing but in a better way.
| [reply] |
|
| [reply] |
Re: A Melancholy Monkday
by tangent (Parson) on Jan 19, 2014 at 22:29 UTC
|
One big problem Perl has at the moment is simply a lack of presence. For example, web APIs are a big thing right now, and the companies that provide them offer implementations in many different languages, however, 9 times out of 10 Perl is not even mentioned. But when you look at the implementations in other languages you see that many have been contributed, i.e. not written by the company who provide the API but by individuals taking the time to write a version in their favourite language.
So I think one thing that we can all do is to to make a concerted effort to fix this situation (perhaps it could even become a Perlmonks project). If each one of us committed to seeking out an API that lacked a Perl version, and then contributing one, would that make a difference?
Up until recently I would not have thought that I was at a level to do this kind of thing but I have just adapted a fairly complicated application written in PHP and was surprised by how easy it was, even though I have no PHP experience. So I hereby offer myself up to this project.
Talking and debating is great but we need to get out there and do stuff.
(PS: I'm sure I've come across this suggestion before but I can't remember where)
| [reply] |
Re: A Melancholy Monkday
by Lady_Aleena (Priest) on Jan 21, 2014 at 08:08 UTC
|
One way to increase its popularity is to nab people before they find other languages. Create Twitter, Facebook, Tumblr, etc accounts and start talking about something else to get people's attention, then when you feel you have enough, start talking about perl. On Twitter I have a vast array of follower "groups", and one day I may use one or more of those groups to promote perl through things like apps for their mobile devices about the reason those in that group followed me. Most of my followers don't even know how to write markup for webpages, but I might nab a person or three who might want to know how I did such a nifty thing. If I can get just one person interested in perl, I did my job at promoting it.
Leave the sanctuary of the Monastery and preach the good word. ;)
.oO(I used to have a module named Nifty.)
ps. I was nabbed into perl before learning other languages were out there. In this case, I am happy to be nabbed.
No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!
Lady Aleena
| [reply] |
Re: A Melancholy Monkday
by pvaldes (Chaplain) on Jan 19, 2014 at 23:14 UTC
|
Perl was ranked as the 9th most popular language in January 2013, but has fallen to 13th one year later.
It is important to note that we changed the TIOBE index algorithm at the end of 2013. The two major changes are: 1. now much more search engines contribute to the TIOBE index. 2. in the past the sum of the ratings of the top 50 languages was 100%, now the sum of all languages is 100%. As a result most top languages dropped about 0.5% (www.tiobe.com)
| [reply] |
Re: A Melancholy Monkday
by kbrannen (Beadle) on Jan 21, 2014 at 20:01 UTC
|
Others have pointed in in various ways that to help Perl's popularity, it needs to get people's attention to be used. It needs to have a way to solve people's problems better. I don't know how to do that completely, as it will require many different approaches, but I can think of 1 way.
Going back to the more popular days, I'd love to see it used more in web programming. Javascript has taken over the browser, and frankly, I don't like that (because I don't like Javascript). Why can't we have:
<script type='text/perl'> ...perl code... </script>
Yeah, there are all kinds of hurdles to overcome with that, starting with:
- adoption by all the major browsers so it could be used
- removing a few parts of CORE for security reasons (e.g. system and family)
- probably need to add a few things, or else pull a few modules in automatically (e.g. CGI, Ajax, etc)
- and probably many more...
But if we could do that, we might see a nice revival of Perl ... not to mention I could use a better language when I have to do client-side work. :)
Kevin | [reply] [d/l] |
|
It has always baffled me why JavaScript, of all languages that could have “won the war” (on that particular battlefield), turned out to be the one that did so ... and that it did so essentially by-default. It is a perfectly egregious language, devoid of strong-typing and many other things, which is why whenever possible I use one of the newer “cross-platform” languages (specifically: haXe ...), which can generate JavaScript as one of its several so-called “targets.” (The image on that front-page really says it all.)
Somehow, though, I just don’t see Perl having its proper place in a scenario like the one you describe, Kevin. It’s just not what I think of Perl as being “for.” So it’s like using a wrench to drive a nail ... we’ve all done it, and maybe we have a few bandages to show for it, but it’s just not the scenario where this language was meant to shine, and where it does shine. All of us need to rip-apart text files, to build elaborate data-structures and forget about ’em, to use regular expressions and high-performance hash tables, and ... to use CPAN.
CPAN, really, is where it’s all at, anyway. The perl executable on my machine is tiny; the php executable (which compiles everything in at build-time) is many megabytes in size. Yet the composite content of CPAN, inclusive of its many dynamically-loaded modules, is larger still ... if, when, and as-needed. (And, to make useful use of Perl on a client, you’d have to install these same big things ... Perl would be very uncomfortable there, and it wouldn’t really out-shine the neighbors.)
A “popularity contest,” even if the statistical methods used are sensible and really appropriate to the occasion (vs. the simple selling of magazines ...), is for the most part just a measure of fashion, and/or of what subjects a harried business school or college figures can be stuffed into a degree-program that will sell. When you have many tons of freight to move, and someone paying you to move it, you need ... a locomotive.
“Programming languages: always learn another one. Just because.”
| [reply] |
Re: A Melancholy Monkday
by sundialsvc4 (Abbot) on Jan 21, 2014 at 00:16 UTC
|
The exact same thing is true of every system that has ever been built in any language: (1) the value of the system is not measured by the “popularity of” the language that it was originally written in, and (2) it will never be rewritten in something else.
Sure, lots of entirely-new projects get started each year, in a situation where there absolutely is a free-choice about what language to use. But I can count the number of those that I have encountered in thirty-plus years on one hand. Nearly all of the time, the work to be done is an extension or an enhancement to an existing (legacy) system. Or, it is an addition to an inventory that already contains hundreds of existing, installed, in-service applications. There is no free-choice here: a company will not sustain the business risk of arbitrarily choosing a new language-platform just because someone says that it is “–er.”
Today’s “sexy world” is strictly a mobile-app one. Schools are churning-out programmers who know how to use the (almost ...) only(!) languages that can be used today for mobile development. Perl does not show up on that radar at all. This should be of no surprise to anyone.
Instead of trying to set your course based on “popularity contests,” choose versatility. Constantly make it your business to learn, or at least to seriously learn about, new programming languages ... never stop doing that. You will learn, not only about what else is going on in our world, but different ways of thinking about the application of computers to problems. Every language, and Perl is certainly no exception, champions not only a particular set of tools, but a particular approach and mind-set. To use a tool effectively, you will think differently. (Or, in the case of Java, you will turn your mind off altogether....) ;-)
| [reply] |
|
|