If one thing stands out from recent discussions on The Perl Renaissance (the whole set of modern/enlightened/marketing blog posts) it's that we don't properly recognise that we are so unskilled at promotion that we don't know what we don't know about the subject.
We throw around words like "Modern" and "Enlightened" and "Directory of Marketing" because they are the best we can do, because we don't know how to name things well.
We discuss the competition for mindshare as if our users are an Economist's mythical "Rational Consumer" and only care about release schedules, and we grasp at ideas like paying people to take a role, with no grounding for knowing if that type of role is what is needed.
I'm just as bad, but I at least try to remember how little I know about most thing. My websites are either ultra-minimalist, intentionally devoid of style, or aim for the simpler is better look (which is about the best I can do when I don't have a real designer to draw source material from).
Perhaps I'm fortunate to have spent some time working for one of the world's best design companies (or more specifically, the Australian "Amnesia Solutions" office before they were bought and aggregated into the larger entity). At the time I didn't even have enough knowledge about design to recognise that they were good, I've only come to realise that years later.
But, I can say that I've spent enough time working side by side with "real designers" and promotion people that I've gained at least the knowledge of how truly bad I am at design and promotion.
This isn't a problem that we (the mirror ball crew) can solve ourself, and the sooner we acknowledge that the better. I certain have nothing much to say on the subject, other than to say how little I know about the subject.
Like other giant Open Problems, often the solution is not to try to solve the problem at all. Especially when you can't throw money at the problem.
Often the solution is to acknowledge you have a problem, build a suitable collaborative space for solving the problem, be inviting to outsiders or fringe members of the community that have the knowledge you need, and then do the best you can within the collaborative space to partly solve the problem until you can recruit even better people.
And at each step, you (as the community leader with no domain knowledge) deal with the tools to make sure that the output of every hour of work from the People Who Know is captured, reused and recycled.
That the work for the community is held by the community, so when your rare and valued knowledge giants run out of the time to help you and move on, you can safely stand on their shoulders.
This is pretty much the exact process that was used to solve the Perl on Windows Problem, and it's the approach that is being used to solve the Perl IDE Problem.
So I propose the following. If your blog is not stunningly beautiful, you don't get a say in how we solve our PR issues. If you don't have a blog, or engage in other forms of promotional work, you don't get a say.
You don't contribute to the solution in any useful way, so you don't count.
What you can do though, is run infrastructure. Even if the web people left for PHP, Perl still holds on to it's core community of sysadmins.
The existence of the DOZENS of websites, mirror networks, databases, automated testing infrastructure, analysis sites, forums and search engines is testament to our ability to build and run infrastructure better than most of our competitors.
So lets stop this bumbling conversation and do what we do best. Lets build and run the infrastructure so that the real people able to solve the problem. So people like Phillip Smith (and others with competant design skills) can have the support they need to solve these issues with as little process overheads as possible. of effort.
I'm happy to step up and put my server where my mouth is.
As a starting point, I'll be creating a new sub-repository off of http://svn.ali.as/ specifically for the collective storage of design materials, should you be generous enough to donate any.
My little repository management tool is simple enough that it should serve as a useful basis for design-type people to run it themselves (even if it's ugly, but I'm willing to work on that and it is templatable...).
If anyone has design material they would like to contribute, just say the word and I'll set up an account for you. I'm happy to take any contributions you wish to give.
File formats for commercial tools are welcome. The design world is still largely run on commercial tools and we need to be willing to deal with and accept that.
When someone comes along with something better than my infrastructure (I'm fully aware svn is not entirely ideal for large amounts of binary data) I'll happily stand aside and let that better thing be the place to store material.
Update: As my first contribution to making Perl better looking, the Padre team has chosen the Blue Morpho Butterfly as it's logo, and I've added the initial 16 x 16 pixel application icon for it.
Re:Where can you find good designers?
gabor on 2009-07-28T03:12:43
I think I better write down my idea.Take one of the web sites related to the Perl community and send out a call to the Open Source Web Designers to create a design for it. Hopefully you get several suggestions. You pick one. You go.
You get a nice custom made site.
The designer gets a site that is (or will be) seen by many people and is linked to his site promoting him/her.We can start with the the one.
We throw around words like "Modern" and "Enlightened" and "Directory of Marketing" because they are the best we can do, because we don't know how to name things well.
IMHO, "we" throw around these terms because they have positive connotations with no denotations -- i.e. they are standard marketing claptrap. If you have a specific idea for how you want Perl to change, you christen it "Good Perl" or something, then repeat that term endlessly. One of these days, after I decide what I want Perl to become, I'll get around to releasing "Cool Perl" and/or "Sexy Perl."
This is pure bullshit. Perl took over from C and SH back in the day because it let people sling around text files with minimal effort. And Ruby on Rails is handing Perl its own ass now because it lets people script up a shiny-looking web page with minimal effort (also because DHH knows how to use hair gel...). If you want to "market" Perl, first use it to solve your own problems, then package up your code in a way that others can use it.
Re:IMHO...
chromatic on 2009-07-28T03:53:04
[They] are standard marketing claptrap.
I don't speak for any "we" but the editorial we, but I like the term "Modern Perl" because I like pointing to well-written code which takes advantage of the CPAN and community idioms and features added to Perl in the past decade to solve problems elegantly and maintainably and having a concise, memorable term to use to distinguish it from bad code poorly thrown together with no sense of design, little understanding of Perl's strengths and weaknesses, and no intent for long-term maintainability.
I find that that distinction between the two codebases exists and is much easier to discuss if it has a name. (The pattern movement has known this for most of Perl 5's lifespan.) I don't particularly care what other people use as a name, whether Enlightened or Modern or Maintainable or Good or whatever. I just want it to have a name.
Re:IMHO...
Alias on 2009-07-28T03:56:09
Ignoring the marketing claptrap comments, my only criticism of "Englightened" and "Modern" are that as an adjective they aren't self-evident.
Modern Bride Magazine? OK, I can see what that might be, even though I'm not a bride.
Modern Perl? Without knowing Perl already, it's not something that says much.
Re:IMHO...
chromatic on 2009-07-28T05:00:02
Without knowing Perl already, it's not something that says much.
I'm not sure any adjective would be self-evident to people unfamiliar with Perl. I suppose we could characterize them by Perl 5 release version number, but that has obvious flaws. We could use "circa 1999" or "circa 2004" to describe the code, but that's clunky.
"Modern" and "enlightened" and "Renaissance" all connote visible differences between eras. That's an interesting convergence around a narrative metaphor: effective and elegant Perl 5 programming in 2009 is different in concrete ways from Perl 5 programming in 1999. That seems like a useful (and verifiable!) fact to consider during naming.
There may be more effective adjectives. If something better comes along, I'll use it.
I favor the "contemporary" definition for "modern", by the way.
Re:IMHO...
educated_foo on 2009-07-28T04:02:55
I don't particularly care what other people use as a name, whether Enlightened or Modern or Maintainable or Good or whatever.
Try "chromatic's," or "strict and warnings and Moose," or (I guess) "rakudo." My point, which seems to have sadly been lost, is that "meaningless-positive-adjective Perl" is standard marketing bullshit, and implicitly assumes that your audience is a pack of semi-morons. It's no better than "Enterprise Perl Bean Solutions." Please don't do that.
Re:IMHO...
jmm on 2009-07-28T13:19:35
I don't see it as "meaningless-positive-adjective" perl, so much as "memorable-succinct-suggestive-adjective" perl.
A "name" has to serve a lot of purposes. If it is too long and unmemorable (strict and warnings and Moose Perl) it is not a name but a description. The name does *not* have to be the description, it just has to be suggestive enough that, once someone learns the description the name will an easy to remember tag that quickly reminds them of the description. It also is a bug advantage if the name is catchy/interesting enough that someone seeing it for the first time is inspired to investigate and find out what it means (which might mean learning some history to know why the name is suggestive - such as why "modern" perl is different from "traditional" perl).
For example, "Extreme Programming" meant absolutely nothing to me when it was just a name. After reading about it and the various components, it made an excellent label to identify what I had learned (even though very little in it seems extreme to me - but then I was never too fond of the more traditional methodologies against which it might seem extreme).
Just because you can have marketing speak infested things that have no content does not mean that all marketing speak is bad. Used with care and in moderation, it can be very powerful and enhance the technical content immensely.Re:IMHO...
educated_foo on 2009-07-28T18:23:32
The name does *not* have to be the description, it just has to be suggestive enough that, once someone learns the description the name will an easy to remember tag that quickly reminds them of the description.
Agreed. But to retain some credibility, the name should be both descriptive and value-neutral. "Extreme Programming" and "Waterfall Programming" both succeed because they describe the relevant processes without claiming that they are either good or bad. "Perl" and "Linux" do as well, to some extent, because they are just random words that are easy to Google. In contrast, "modern" and "enlightened" are singularly lousy choices: they have generic positive connotations, but no real meaning. For example, if we were still "enlightenment thinkers" and "modern philosophers," we would be using Newtonian physics in our arguments about how the Mind controls the Body through the pituitary gland.
Re:IMHO...
Alias on 2009-07-28T04:16:53
> I don't speak for any "we" but the editorial
He means the words (plural), not the people
Re:IMHO...
slanning on 2009-07-28T20:30:09
One of these days, after I decide what I want Perl to become, I'll get around to releasing "Cool Perl" and/or "Sexy Perl."Maybe pudge can do the jingle. Something inspired by the late and inexplicably great Michael Jackson.
Re:IMHO...
educated_foo on 2009-07-28T21:09:17
The win would be epic: Ayn Rand meets Garth Brooks through an ambi-sexual filter...
For the explanation see excerpts.
Re:Design != Marketing
zby on 2009-07-28T09:29:21
Yeah - marketing is a broader term than advertising. It is not only about communicating - it is also defining the audience - i.e. finding the market for the product, finding out where it can be the most useful.
So lets stop this bumbling conversation and do what we do best.
No. How's that for a clear-cut response?
If you don't want to participate in understanding the perception issue, or if you think this has no value, or if you think you already know the answers, that's OK. I realize plenty of people have one (or more) of those opinions. You don't have to help if you don't want to, but please don't tell others not to try.
Re:Except ...
Alias on 2009-07-28T13:12:33
> If you don't want to participate in understanding the perception issue.
Whether I want to participate or not is irrelevant. When Gabor started Padre he didn't say "I want to participate in making an great IDE". He simply wanted a great IDE, and he knew that to achieve that he needed to recruit people better than him at producing what he wanted.
Go watch his talk. His attitude there is what has made him such a good project leader for Padre.
http://yapc.tv/2008/ye/lt/lt2-07-gabor-padre/
What he is doing there is not what we are doing with regards to this issue. We're trying to solve problems we know very little about, without looking to find the people that do know how to solve our kind of problem.
> or if you think this has no value
Quite the opposite, I think this has the potential for negative value. To have a bunch of people who know very little prattling on about what to do and distracting everyone.
> or if you think you already know the answers
I believe the entire point of my post was that nobody in the conversation so far has the answers.
> please don't tell others not to try
I'm telling them to help find the people with the skills we need to fix the problem (and help THEM) ather than try to fix the problems without the skills.
Re:Except ...
Ovid on 2009-07-28T13:44:22
OK, now I better understand what you're saying. However, what I'm saying is that we need information and we're the domain experts in the problems we're trying to solve. I also have said several times that we're not qualified to do the actual research. We're qualified to figure out our own goals and contribute expert knowledge on what we might need to make those goals happen. I thought I made that clear a few times, particularly when I wrote:
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?
I've done enough research into this to know that it's unlikely that we can do this ourselves, but we certainly need to be involved in the process.
You wrote:
I believe the entire point of my post was that nobody in the conversation so far has the answers.
I know that. I've made that clear, over and over again, that we don't know the answers and we don't even properly understand the questions. When people say "we just need to evangelize X" or "we need more Perl programmers", that's going entirely against what I'm trying to do. I don't want to make a wild guess. I want to:
- Clearly define a goal
- Understand what information we need to assist us in achieving that goal
- Find experts in gathering and interpreting that information
- Profit! (or not)
It's obvious that I've not made this clear in my blog posts. I think I need to make another
:/
By the way, I realize that my answer might have sounded harsh, even with the smiley. I really, really value the things you've done for the Perl community (remember when people were telling you that you were wasting your time trying to parse Perl?). I just want to try a different approach. I concede that it might fail, but I promise not to take too much of the community down with me
Great conversation here. Glad that people are willing to engage in it thoughtfully. (Many thanks to Alias for the conversation starter.)
@educated_foo: The reality is that people are using Ruby, and Rails, for more than just scripting up "shiny-looking web page with minimal effort." (I'll concede the point about DHH's hair.) They're using it for all kinds of crazy stuff, like writing desktop applications and large-scale messaging services like Twitter. (All things that Perl can do equally well.)
Regardless, I think a major point is being missed in these arguments: the people making these "shiny-looking web pages" are doing the grassroots marketing for Ruby, and Rails, and so on, e.g.: "Hey, did you know that Yadda-yadda was built with programming-language-of-the-day?" "No kidding? I gotta try that..."
So that's point #1: "solve your own problems" isn't quite right. Grassroots marketing is helping other people solve their problems with your solution. Admittedly, I think that's what you're saying with "package up your code in a way that others can use it."
Point #2 is that most of the people using frameworks like RoR and Django have made the choice to learn them recently. FIve years ago, nobody I know was programming primarily in Python or Ruby. And it's not like there was a glut of Ruby and Python University graduates looking for frameworks; they all had to make a choice to learn something new.
So why did they choose these other languages and frameworks? Perhaps it was marketing "claptrap," perhaps it was hype and shiny Web sites. Those surely played a part. However, the other aspect is -- as we've all been talking about -- perception. Perceptions, and first impressions, of the language, its community, its resources and so on, all impact people's likelihood to take that first step into learning something new (or coming back).
I've heard it argued that the Perl community doesn't really want an avalanche of new people -- signal-to-noise and all that garbage. However, if we want to see those showcase sites, and applications, running Perl -- if we want the grassroots marketing that brings -- Perl must do a better job of communicating clearly about itself.
Communicating clearly is everything discussed above. It's the marketing "claptrap," it's the shiny-looking Web sites, and its a community that appears to openly want people to adopt this language, because it's the best damn language we've got.
Re:It's about communicating clearly
Alias on 2009-07-28T13:20:30
> I've heard it argued that the Perl community doesn't really want an avalanche of new people -- signal-to-noise and all that garbage.
Really? Who? Where? I'll go and smack them in the face.
> However, if we want to see those showcase sites, and applications, running Perl
And the scary thing is, we do run those sites.
IMDB, Amazon, Yahoo, DoubleClick, LiveJournal, The BBC, the... er... world's biggest... um... porn site (YouPorn).
> It's the marketing "claptrap," it's the shiny-looking Web sites...
Half our problem is, I suspect, we lack the knowledge to even understand the correct terms to describe what we think we need.
The question is, given a consistent lack of competence, and a desire to improve, what are the kinds of processes we need to go through to address it?
The known unknowns, the unknown unknowns, ...
ggoebel on 2009-07-28T17:33:32
I think we could use some good blogs on marketing and visual vs. functional design, etc. A website dedicated to grinding this particular ax would welcome. Articles in a well read online publication would be excellent. Ignorance can be cured.
Some of what needs to be done, may appear as simple window dressing. But a consistent style guide and resources for building Perl websites that would like to use it would be great.
There are a lot of unorganized efforts out there. Things like making it easier to install libraries and applications as a user with limited rights. And many module maintainers are rewriting their OO code making Moose the defacto standard.
This is fairly typical for open source projects. But Perl could definitely use some cat herding public health policy person(s) to help us all stay on top of best practices.
As a part-time Perl programmer, my Perl is a mismatch of old and new practices. With all the Perl resource scattered about, I never know where to go to find a rational discourse on current best practices and recommended libraries.
Alias, thank you for all your efforts. Dare I say, that I've heard Perl needs a pumpking...
Re:It's about communicating clearly
phillipadsmith on 2009-07-29T01:37:54
"And the scary thing is, we do run those sites."
Very underplayed by the Perl community, unfortunately. From Perl.org, which then links to the O'Reilly site, the "success stories" are five years old. There are other lists I've seen, but none are very comprehensive or compelling.
"The question is, given a consistent lack of competence, and a desire to improve, what are the kinds of processes we need to go through to address it?"
I think the process has begun. Let's see where it goes.
Re:It's about communicating clearly
educated_foo on 2009-07-28T19:20:19
Desktop applications? I haven't seen any yet (I don't count web apps), so can you point me in the right direction?AFAIK, Twitter is just a shiny web app that throws a lot of servers at a problem. Other than the web interface, it seems like the whole thing could be done with text files and a UDP server. Rails actually seems like a terrible fit for what Twitter is doing; it seems better suited for the simple, low-traffic web interfaces that most small businesses want than for a high-traffic buffered message queue.
Admittedly, I think that's what you're saying with "package up your code in a way that others can use it."
Exactly. UNIX, C, Perl 5, and Rails worked because they were first written to solve actual problems, then cleaned up so they could be used by others. I expect Perl 6 will fail because it's not directed at an actual problem ("keep Perl moving" and "make Perl clean" are too vague).
most of the people using frameworks like RoR and Django have made the choice to learn them recently.
Fads count for a lot in programming. Perl, Python, and Ruby are all roughly similar at a technical level (though Perl gets variable scoping right), so if I don't know any of them, then all else being equal, I'll choose the one most likely to make me look cool and/or get me a job. But immediate usefulness also counts: if one of them has a ready-made solution for my specific problem, then I'll probably choose that one. Perl seems to have done well 10 years ago for its text munging and CGI handling. I (thankfully) don't have to write web apps, but Ruby became popular because other programmers were forced to write them, and Rails made that less painful. I hope people don't lose sight of the fact that the most important goal of any programming tool is to be useful. You don't need to shine a diamond, and you can't shine a turd.
Re:It's about communicating clearly
chromatic on 2009-07-28T20:37:04
I expect Perl 6 will fail because it's not directed at an actual problem....
361 problems Perl 6 addresses (non-exhaustive list)
Re:It's about communicating clearly
educated_foo on 2009-07-28T21:05:33
Just to take one example, "the AUTOLOAD subroutine should be able to decline a request" may be a shortcoming of the Perl language, and may annoy some Perl programmers, but it's not a "problem" in the sense I intended. "I need to offer my company's widgets for sale on the web" is a problem. "I need to convert this UniProt file to FASTA" is a problem. If you design a programming language while thinking about programming languages, you get Scheme.
Re:It's about communicating clearly
chromatic on 2009-07-28T22:06:55
If you design a programming language while thinking about programming languages, you get Scheme.
That's a lovely slogan, but in the real world I suspect it's meaningless.
If you don't think about programming languages while you design a programming language, I wonder how you add features that are specific enough to address real design problems while general enough to allow people to use them to address problems that didn't exist while you were designing the language. I wonder how you balance elegance and the smallest set of primitives necessary to combine into sufficiently powerful abstractions. I wonder how you address learnability and mnemonics and chunking and linguistic principles of memorability, complexity hiding, Huffman encoding, allomorphism, familiarity, false cognates, and more.
Fortunately no programming language designer has to choose between the false dilemma of "Thinking solely about real-world business problems" or "Thinking solely about PL design". (I suspect if you asked Steele and Sussman about their design goals for Scheme you'd get a set of complementary and contradictory goals.)
A lovely slogan...
educated_foo on 2009-07-29T03:42:31
I missed a "solely" there: "If you design a programming language while thinking *solely* about programming languages, you get Scheme." If you look at the languages that endure, most were designed by smart people with specific problems to solve: John Backus wanted to TRANslate FORmulas to machine code, and created FORTRAN; Dennis Ritchie wanted to program his PDP-11 in something higher-level than assembly, and created C; etc.
Perl fit(s) into this tradition. Perl 6 hasn't quite figured it out yet.
Re:It's about communicating clearly
Alias on 2009-07-29T18:56:22
> If you design a programming language while thinking about programming languages, you get Scheme.
I believe the evidence would suggest you get something like Ada as well
:) Re:It's about communicating clearly
phillipadsmith on 2009-07-29T01:30:15
"Desktop applications? I haven't seen any yet (I don't count web apps), so can you point me in the right direction?"
"AFAIK, Twitter is just a shiny web app that throws a lot of servers at a problem. Other than the web interface, it seems like the whole thing could be done with text files and a UDP server. Rails actually seems like a terrible fit for what Twitter is doing; it seems better suited for the simple, low-traffic web interfaces that most small businesses want than for a high-traffic buffered message queue."
Agreed, and I bet they regret the decision. But, assuming that should have been obvious to the folks at Twitter, what was the initial thing that lead them in the direction of Ruby on Rails? (And, either way -- good or bad -- Twitter has done a lot to promote awareness of RoR.)
"Fads count for a lot in programming. Perl, Python, and Ruby are all roughly similar at a technical level (though Perl gets variable scoping right), so if I don't know any of them, then all else being equal, I'll choose the one most likely to make me look cool and/or get me a job."
Therein lies the Catch-22. if it's a cyclical thing, it's hip today, and gone tomorrow. Look at Javascript, however: as Piers Cawley points out, it was barely on people's horizon a few years ago and now it's the core of how many Web experiences are delivered. The future is unfolding right now, and I don't see any reason why a Perl renaissance isn't in the cards.
As much as I think a more a uniform style and message would be great for Perl, I also think that releasing and marketing an application that non-Perl people would find cool and useful could do as much to fix Perl's image problem as anything else.
After using this fictional application, a user might see that it is written in Perl and think "Hey, I didn't know that Perl can do that". They might then look at the source code and think, "Hey, this isn't the same ugly Perl that I remember from the mid 90s."
A good example of this for me was Rails. When Rails was released I didn't know much about Ruby, but that one project prompted me to look into the language. It wasn't the marketing coming out of the Ruby camp that inspired me so much as the cool things you could do with Rails and clear messaging on the Rail's website.
Re:Don't just market the language
ggoebel on 2009-07-28T22:47:14
I think you're hitting the nail on the head.
Everything else sets the stage... but without the killer app, we can't attract the magpies.
Then again, a killer app which attracts developers... won't be able to retain them if the support infrastructure is a maze of twisty passages all different
We need it all. And if somebody(s) can chart a course... then perhaps we can each scratch an itch that gets us there.
Re:Don't just market the language
revdiablo on 2009-07-28T23:05:51
More and more as I read through these discussions and debates, it makes me wonder how they can be resolved. I doubt all the players involved are going to start agreeing. Most projects have pretty clear leadership to resolve these kind of problems. Who's in that position for Perl?
If it's Larry, is he going to engage these issues or is it off his radar entirely?
Re:Don't just market the language
Alias on 2009-07-29T04:13:53
Larry is a language designer.
He's involved with things at the level of the language "surface".
He's said a number of times (in person, if not in print) that other people should deal with the packaging and repositories of modules.
Same thing extends to things like the marketing and presentation of Perl to the world. This is more the sort of thing that the TPF is for.
Re:Don't just market the language
revdiablo on 2009-07-29T14:22:11
I thought so, but who then? It seems there's no single person or even group who has a leadership role, which is why there's schizophrenia. I guess that's not necessarily a bad thing, but it's not exactly comforting when a bunch of the players appear to be at odds about which direction to take the project.
C'est la vie. No matter what happens, at least the code won't go up in a poof of smoke. =)
I agree that we do not, collectively, know about marketing. We need help here.
But the problem isn't entirely a marketing issue. There are real issues. Some of these have been identified, and are being worked. Some of these have been identified, and have been fixed. That is wonderful. I'm certain there's still more to identify and fix, and I suspect there are a number which have been identified, but have not been worked, apart from possibly getting put on someone's TODO list.
The more of those items we can take care of, the easier the marketing task will be, when we get competent help and can really address the marketing issues.
Of course, there's also the bad marketing that's currently going on. The stuff that I've seen most prominently is Perl Golf. A quick google search shows I'm preaching to the clergy here, so I'll shut up about that.
