A few years ago I interviewed with a big-name company that said perl is forbidden on their projects. The interview was with the engineering manager. and it seemed like he was driving that decision.
He said perl was too messy, too many ways to do things and no "set" way to do things, so you end up with incompatible chunks of code, and he hated the line noise. They said they use java instead. According to him, it had some strong typing built into it. I politely as I could told him that I worked on vhdl/ada for several years and strong typing can be a massive amount of work in and of itself. I don't know java so I don't know how "strong" it is. maybe perl 6's class convention will fix the "million ways to do classes and they're all incompatible" problem. I get a little tired of the line noise myself sometimes. I would really love to see named, type-checked, subroutine parameters, with default values of the unassigned ones. @_ is cute, and it can be cool to have the default paramter variable be as many paramteres as you want, unlike c++ where having an undefined number of parameters is a pain to work with, but sometimes @_ can be a pain to work with too. Maybe when perl 6 is official, it will remove some of the consistent complaints about perl from the discussion. Then again, there's also the "coolness" factor. Perl was cool when it was the glue that held the internet together. I assume java became cool when it became the defacto language for writing droid apps. Everyone wanted to write the next angry birds and make a million dollars, so that's good for recruitment purposes. Maybe perl5 or perl6 could figure out someway to make perl the "lottery" language again. If the next big app was written in perl and made some kid a chunk of money, that would help. We've been looking to hire an electrical engineer and I would like someone with strong perl. So far the interviewees have been either weak perl skills (I haven't written my own perl script, but I've looked at other people's scripts) or no perl at all. Since perl is lower priority compared to EE skills, we'll probably end up with someone with weak skills. So, my interview for a job a few years ago, and our current interviewing for someoen now, would seem to say that perl coders are aging and not getting replaced. Greg > Bill Ricker wrote: >> Three-part article by VM Brasseur @vmbrasseur >> "The Rising Costs of Aging Perlers" > > I guess this was worth writing down, but weren't we all aware that "the > practitioners of Perl are aging and not enough junior developers are > being created to sustain the language as a going concern?" Pretty much > any Perl-related metric you look at will tell you this. > > In part 2: > > ...it does not appear as though the Perl community is doing much to > correct this issue. As I detailed in my earlier post, in many cases > Perl's new programmer outreach appears fairly crummy if not virtually > non-existent. This needs to change before Perl starts to face a > cultural extinction. > > This gives the impression like the #1 problem with Perl is the lack of > outreach to new developers. > > Making sure new developers have a good experience is a useful way of > reducing the friction of getting developers from junior to intermediate, > and yes, if you do a really bad job at it, you'll turn some developers > away (a quantity I expect amounts to a rounding error), but you have to > look further up the marketing funnel to find the real problem. > Developers need a compelling reason to investigate the language in the > first place. That's not happening these days for both technical and > perceptual reasons. > > Two of the three prescribed solutions in part 3 actually address the > marketing problems, rather than the thesis from part 1, developer > outreach. One was "make cool stuff and talk about it." This is a great > idea, even if not novel. (The "Iron Man Blogging Challenge"[1] was one > attempt at that.) But it is less clear how to encourage it to happen, > other than simply spreading the word. > > The next suggestion is "Modernize our dilapidated online communities," > specifically mentioning PerlMonks. Sounds good, and I'm sure some of > that wouldn't hurt. But how do you make that happen? Who runs PerlMonks? > (Apparently it was "was recently assimilated by The Perl Foundation.") > It seems it is equally important to go to the new platforms where > developers hang out now, like Stack Overflow. (You can find a link to > the weekly "stackoverflow perl report"[2] in the Perl Weekly > newsletter[3].) > > The third and final suggestion is for The Perl Foundation (TPF) to fund > "training, outreach and community building." That's great, and if there > are sponsors and volunteers interested in pursuing that, fantastic, but > if I was allocating a limited budget of time and money to solving Perl's > diminishing relevance, there are higher priority, big picture issues to > be addressed. > > Maybe my assumptions are wrong, but I'd like to see the stats that show > that PHP, Python, and Ruby are still on growth trajectories because of > their superior new developer outreach. It's an important supporting > function, but it isn't why developers show up at your door. > > > As the effective figurehead of the Perl community, I feel only TPF is > in a position to make the sort of changes necessary to drag Perl back > into relevance and to allow it to grow and thrive, and these changes > are not predominantly technical in nature. > > I don't know if TPF is of the right structure to do the job. Perl needs > some strong leadership from someone who has a vision for a future of the > language, a strong desire to see it become relevant again, a willingness > to tick off the old-school developers who cling to the 1990s way of > doing things, and the persuasion skills to bring them on board. > > Who leads TPF? (You can answer that here[4].) I've been aware of the > people who have lead Perl releases, but I can't say TPF leadership has > been all that visible (I don't read P5P; maybe it is there). It's built > from layers of committees, that all report to another committee, known > as the board, which has a chairman, but it seems designed to diffuse > power. That's a good model if you want to keep cruising with the status > quo. Not so great if you need to make significant changes. > > I wonder if a structure modeled after Debian would work better. > > I'd like to see a Perl leader who either has or hires product management > expertise. They need to be able to examine Perl as a product, compare it > to the other languages operating in the same space, understand why users > are choosing them over Perl, and use that to inform a road map - whether > that be making Perl better at what those other languages do, or finding > a new killer application for Perl. (This approach was discussed years > ago on the Enlightened Perl marketing list.) > > Then there's the whole Perl 6 issue... I haven't read a fraction of > what's been said about the impact Perl 6 has had on the brand, so I'll > refrain from commenting, as it is likely to be redundant. > > -Tom > > 1. http://www.enlightenedperl.org/ironman.html > 2. http://bit.ly/1369hWo > 3. http://perlweekly.com/ > 4. http://www.perlfoundation.org/who_s_who > > -- > Tom Metro > Venture Logic, Newton, MA, USA > "Enterprise solutions through open source." > Professional Profile: http://tmetro.venturelogic.com/ > > _______________________________________________ > Boston-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/boston-pm > -- _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
