Important caveat before you read: please don't read this blog post as Ovid saying "don't evangelize Catalyst, don't write tutorials, etc." I'm not saying that. These things are important and we should continue them. I'm saying that we need a core team to get together to really understand the nature of the problem we face rather than relying on anecdotal evidence. Now on with the show.
Gábor wrote the following in his blog:
Yesterday I wrote Perception is Reality - we need a director of marketing. After a few hours I was caught on IRC by some people who said the main problem why companies are not picking Perl or why they are leaving Perl is that they cannot find good Perl programmers. As reaching programmers to learn perl is not the job for a marketing director hence we don't need a marketing person.
Gábor doesn't buy this argument and he's right not to because this reflects a very fundamental and common error of identifying the solution as the problem. The reasoning works like this: "companies aren't finding enough Perl programmers so we need to teach more programmers Perl." The error can be illustrated by a slight change to that: "companies aren't finding enough COBOL programmers so we need to teach more programmers COBOL."
The problem is identified as "not enough Perl programmers", but that's actually a component of the solution because it completely fails to address the problem of why we don't have enough Perl programmers. Since this error has been made, I really have to attribute a large part of that to myself because I've failed to communicate as effectively as I can, so I'll try to take another swing at it. Let's look at a few proposed solutions to what I'm calling P3 ("Perl Perception Problem") and see what new (or old) perceptions might result. To be fair, many of these "solutions" might very well reflect a perception of a different problem.
(Note: read the next paragraph carefully. I've been accused of trashing Perl and I expect that's because people are skimming what I write.)
Notice that I am not saying I agree with any of those hypothetical responses. Nor am I saying that those are the responses we'd receive. Further, all of those proposed solutions have merit, but the one (or ones) which will gain us the most bang for our buck are unknown. Heck, parts of the solution might be things we've not even considered yet.
One danger of proposing solutions without understanding the underlying problem is that we may come off as self-serving and we don't want to do that. To avoid it, one thing we must realize is that not all of our critics are wrong. Consider PHP. They mopped the floor with us on what many considered our home turf. They've obviously done something right. We might make vague claims of "technical superiority", but tell that to SmallTalk and Scheme developers. They also think they have "technical superiority", but superiority for what? If we don't understand the problem, we can't say what we're superior for! If our solutions are truly self-serving, they deserve to be ignored as there's a good chance we're solving the wrong problem. Just look at the RIAA. Many people involved with that really believe they're doing the right thing just as we're convinced they're not. It's easy to hear what one wants to hear.
In regards to understanding the problem, chromatic wrote:
I think we can both agree that marketing activities should reflect reality. That's why I base my conclusions [regarding the Perl 5 development process] on (and refer to) publicly accessible raw data, such as timelines, release dates, bug reports, patch submissions, commit logs, documentation, and mailing lists are all public information.
Relying on raw data is important and I'm happy chromatic is doing that, but few, if any of those sources really tell us why we have a problem (the mailing lists sound tempting, but we're really in an echo chamber). For example, let's say that you're consulting your access logs and you find many searches for the term "email". You might conclude that you have a support problem and people are looking for contact information. It might be spambot email harvesters. We're the BBC. We might have people thinking they can find celebrities email addresses online. The thing is, you can't know by just looking at raw data. You can only guess. If we can gather better information about P3, we still won't know the answer, but we can make better guesses.
To understand P3, we need to do research. Some people have mentioned the financial aspect and that's a worthwhile concern, but we don't necessarily have to spend money -- though we will need to spend time. I doubt many of us are experts in market research but maybe someone is and is willing to volunteer services? Maybe we can team up with another open-source group to facilitate this? Maybe we can find a university teaching marketing and propose an interesting research project and domain expertise? Do we have contacts for any of this? If we want to understand this problem, we can. We just need to be sufficiently creative and motivated to get to the bottom of it.
Dave Cross and I (and Rozallin Thompson, I believe) will be meeting in Lisbon at YAPC::EU 2009 to discuss this issue. I encourage others to join us. Let's tackle this beast once and for all. Our careers depend on it.
Dave Cross and I (and Rozallin Thompson, I believe) will be meeting in Lisbon at YAPC::EU 2009 to discuss this issue.
Do you mind if I join you as well?
Cheers, JJ
Re:Count me in
Ovid on 2009-07-27T10:55:55
Not at all! The more the merrier. Heck, even people disagreeing with me on P3 are quite welcome. I want plenty of opinions.
Dave Cross and I (and Rozallin Thompson, I believe)
Yep, I shall be there.
Re:See you there!
Ovid on 2009-07-27T11:01:39
Excellent
:)
One facet of market research (really, product marketing) is identifying the target customers and how well the product serves their needs.
I suspect one part of the echo chamber problem you describe is that few people seem to be explicit about who the customer might be and what they need. One facet of market research (really, product marketing) is identifying the target customer and how well the product serves their needs.
Perl has several "customers" to consider. A non-exhaustive list might include:
Other ideas?
Each will have different needs and Perl fits those needs differently. Any research that happens should consider a variety of customers and needs.
You mentioned PHP as an example. I think it got big because it made it easy for first-time developers to deploy on shared hosts. Or rather, mod_php did. Contrast that to mod_perl. Who was the customer for mod_php? Who was the customer for mod_perl? But imagine if there had been a mod_mason available before mod_php? Things might be different today.
-- dagolden
Re:Who is the customer?
Ovid on 2009-07-27T12:18:30
This is an excellent point and one I've been considering. In order to define the customer, we need to understand what we're trying to do. In other words, once we have a goal defined, we can better understand who are customers actually are and thus know who we need to potentially gather data from. My goal is this (and when we get a group together, perhaps this will change):
Allow Perl to reclaim its status as a respectable programming language for new projects.
If that goal is acceptable, then we can better understand our customers. If there's a lot of positive buzz around Perl ("hey, modern Perl is actually easy to read!"), then I expect that people learning new languages might come along for the ride, but I don't want my hunches to define things.
Thus, we need to figure out:
- Who gets to choose the programming languages for projects?
- What are they looking for?
- What languages are they choosing and why?
- Why didn't they choose Perl? (Many would be surprised if it turns out that our competition is actually Java/C# and not PHP/Python/Ruby, but how can we know?)
- Where are they getting their information?
Of course, this is only the tip of the iceberg, but the "who" is probably the customer I'm after.
Re:Who is the customer?
dagolden on 2009-07-27T13:35:52
Regarding "what we're trying to do", see my recent blog post: What do you want Perl 5 to be?
-- dagolden
Re:Who is the customer?
Alias on 2009-07-27T12:20:23
PHP won because you could edit your website in a website editor.
You could use all the tools you had already to learn the skills you didn't have and achieve the goal you want.
Dreamweaver clinched it for them, because now you had an editor that wouldn't break the code.
And most people, in my opinion, don't change technologies if the ones they already have can do the things they need.
Re:Who is the customer?
ruz on 2009-07-27T22:04:10
Check out http://www.denwer.ru/. It's in russian, but from download picture you'll get the idea. It has perl extension, however how much time will you spend looking for good perl hosting.
I've been talking to a lot of people about this recently, and I usually ask the question "Why do you care if Perl survives?". Most people say the same thing that you say at the end of your post: "Our careers depend on it."
I think that's a pretty poor reason to do anything, and certainly the worst of all the reasons to promote a programming language. If we're in a situation where we are merely trying to save jobs and keep Perlers employed, we're not doing the right thing.
Re:Your career isn't a good enough reason
Ovid on 2009-07-27T18:59:16
Ouch! You're perfectly correct. I was trying to come up with a vaguely punchy ending and dropped the ball. Thanks for calling me on that.
Re:Your career isn't a good enough reason
gabor on 2009-07-27T20:54:23
Interesting.
Why do you think it is not a good enough reason?I thought that the sentence Your career depends on it perfectly fits my situation and probably that of many others so I was wondering why do you think it is not an acceptable reason to invest in the future of Perl?
I am quite sure if I could not make a living any more using Perl I could switch to something else. It will certainly take many years to gain some reputation and I might even need to take a salary cut because of that but I would find my way. In that meaning my career does not depend on the well being of Perl at all.
On the other hand I would be very disappointed, For many years I might keep feeling that ouch, I could have done this in Perl a lot easier or that I would have enjoyed my time more.
I know it is just a programming language, but still some of us, including me, has certain emotional investment in it. I think otherwise we would not discuss this issue.
In that respect I certainly feel that my career depends on the well being of Perl.Maybe I am using the word depends a bit broadly here but if you think this is not a good reason to put in more energy, please explain why?
Re:Your career isn't a good enough reason
Ron Savage on 2009-07-27T22:46:50
Hi Folks
Because companies which hire me don't hire me to promote my career! Surely that's obvious.
They hire me because they have a code to be written, I'm available, and either they want Perl or (rarely) they let me choose Perl.
Again, for
/them/, my career does not come in to it. So, we need to promote Perl so more people automatically see Perl as the best language to provide a solution.
Cheers
Re:Your career isn't a good enough reason
Ovid on 2009-07-28T12:01:00
The reason why "your career isn't a good enough reason" can possibly be explained by again casting things in a slightly different light. Imagine if we saw this posting:
We need to better evangelize COBOL and convince more programmers to learn it because our careers depend on it!
The obvious reply is that this is a very self-serving statement which ignores the reality that COBOL is an antiquated language that needs to die. Companies are turning to older COBOL programmers because young people don't want to learn it. Until such time that we have so few COBOL programmers that companies are forced to switch, this language is going to stay around. However, it's not staying around because COBOL is a good language; it's staying around because companies are finding that their hands are tied. Thus, generating more COBOL programmers is merely going to plaster over the fact that a technically inferior language is hampering development all over the world.
In other words, we shouldn't be promoting Perl just for our careers. We need an ethical stance. If we firmly believe Perl to be a good choice (or can be again made to be a good choice, just as COBOL used to be a good choice), then that's OK. Careers for career's sake isn't good enough. However, as has been said many times before, it's tough convincing someone of the truth if their livelihood depends on lies
:) Re:Your career isn't a good enough reason
drhyde on 2009-07-28T12:58:37
Other people - and companies - might not care about my career, but I do. So I'd I thought career depended on perl then hell yes, "my career depends on it" is a damned good reason for *me* to care and to do something about it!Re:Your career isn't a good enough reason
brian_d_foy on 2009-07-28T15:06:38
You should take anything your career depends on and make your career not depend on it. If Perl disappearing meant that your career was over, then you either aren't a valuable employee or need to diversify your skills. You should never have only a single thing that makes you employable.
Knowledge of a particular programming language should be among the least of your skills. You should be valuable for your general knowledge of how things work, your experience in the problem domain, and your ability to solve problems with the tools you are given. If you don't have those skills, knowing Perl isn't very useful over the span of a career.
