Great conversation here. Glad that people are willing to engage in it thoughtfully. (Many thanks to Alias for the conversation starter.)
@educated_foo [perl.org]: 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.
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
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 [delicious.com]. Let's see where it goes.
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 mess
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.
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 t
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.
"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 hi
It's about communicating clearly (Score:1)
Great conversation here. Glad that people are willing to engage in it thoughtfully. (Many thanks to Alias for the conversation starter.)
@educated_foo [perl.org]: 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.
Keeping technology simple since 2003
Reply to This
Re: (Score:1)
> 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
The known unknowns, the unknown unknowns, ... (Score:1)
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
Re: (Score:1)
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.
I think the process has begun [delicious.com]. Let's see where it goes.
Keeping technology simple since 2003
Re: (Score:1)
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 mess
Re: (Score:1)
361 problems Perl 6 addresses (non-exhaustive list) [perl.org]
Re: (Score:1)
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: (Score:1)
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 t
A lovely slogan... (Score:1)
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: (Score:1)
> 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: (Score:1)
http://www.macruby.org/ [macruby.org]
Keeping technology simple since 2003