This was more a rhetorical question.
My point is:
Perl's character is to try to comply to the needs of many target groups at the same time.
But this attracts criticism for mangling syntax from different domains.
There is
- Perl the scripting language, with special variables, one-liners, golfing, $_ ,
- Perl the modular language packages, CPAN,
- Perl the OO language, with Moose, M* ...
- Perl the functional language with anonymous subs, map/grep and closures
- ...
At the moment we get beaten at most battle fields by more specialized languages,
because their users get confused by all the other features.
Our marketing strategy should be to fill these gaps ...
Perl could be a great interactive shell language (something Python could never do)
with the possibility to expand short scripts to full scale applications (something where Bash sucks).
... to be continued.
| [reply] |
I apologize for cherry-picking on that post, and for re-ordering the quotes.
Lanx: Perl could be a great interactive shell language ... with the possibility to expand short scripts to full scale applications ....
....which is pretty close to why I love Perl.
Lanx: Our marketing strategy should be to fill these gaps ...
Ouch. I've heard statements like this many times and it always makes me wince. I see some flaws here.
It isn't at all clear who "our" is in this statement. Whose responsibility is it, in a horde of volunteers, to have a "marketing strategy"? We have several candidates for "our" to deal with. I'll comment on three: There are the developers who create Perl, and there are the people who write Perl applications to solve their problems ("Perl is the language to get your job done." Does that ring a bell?), and there are those who just use Perl applications to solve their problems. You won't see the third group a lot on Perl conferences nor on Perlmonks, because often they don't give a damn about the programming language which has been used in an application as long as it creates value for them, but I might get to them later.
On recent Perl conferences I've occasionally heard a statement like "We did this because of ... why not?". Of course, "Why not" as a motivation is absolutely fine for a volunteer, but it also carries the message of "We don't care whether you need that" which might be easily misheard as "We don't care what you need". A volunteer has every right to think and act like that, but if overdone, this will cause the communities to drift apart. And then you'll have a hard time finding a common ground for "our".
And, by the way: What is a "marketing strategy"? I'd rather present my personal view. A marketing strategy does not close technical gaps. Marketing also isn't just telling the world how great Perl is. Marketing should, to an equal amount, be listening to the market. Who are the people who use Perl? Would you notice (or care) if they change to another language? Who are the people who don't use Perl, and why don't they? Every Debian installation comes with a bunch of Perl scripts. To what extent did recent Perl developments help them? Long-term compability helps them a lot, as there are quite a few of these scripts which haven't been touched for ten years or longer, but this doesn't actually count for "recent Perl developments".
I am aware that in your first response in this thread you posted a todo list which contained some items which qualify as "listening", but I fail to recognize who should do this work. In the same article you write that obsolete features have to die which actually may cause some people to move away from Perl, because they happen to use features you consider obsolete and have chosen Perl because of its long-term stability. Maybe you have listened to people and learned that they have all sorts of different problems, and came up with this:
Lanx: Perl's character is to try to comply to the needs of many target groups at the same time.
I agree, and as far as I understand, it is one of the design goals of Perl 6 to accommodate many different programming paradigms as one of the facets of "many target groups".
Lanx: At the moment we get beaten at most battle fields by more specialized languages, because their users get confused by all the other features.
I disagree with the "because". I find it rather easy to select the features I like, but I simply doubt that the Perl developer community of volunteers can keep up the pace on all battlefields at the same time. I think that this is the main reason why Perl gets beaten on some of the "trendy" battlefields.
Ovid's post is an attempt to focus the Perl developers on something he as someone who writes Perl applications can use. The ongoing discussion also shows that the community of people who write Perl applications isn't homogeneous at all. I am not familiar with Perlmonks nicks to see whether any of the P5P community has taken part in the discussion so far, but maybe they are just listening. That wouldn't be too bad.
| [reply] |
> cherry-picking on that post,
Yes you are.
> I disagree with the "because". I find it rather easy to select the features I like,
Perl has the reputation of the write-only-language which becomes unmaintainable by a team.
This could be related to people "selecting the features they like".
A team leader in application development is interested to have a common coding guideline, an employer to easily find new team members or at least easily train a newbie.
I daresay pretty much everything which makes Perl a great language for short scripts or as interactive shell is discouraged in PBP.
This is a highly schizophrenic situation, because people reading the perldocs have to keep all parallel realities in mind.
The even bigger paradox is that many Perl haters have no problem praising bash and Java in the same phrase.
My point is that this could be solved by readjusting the perspective, either by labeling or maybe enforced by pragmas.
- "Perl-shell" as a far better bash
- "Perl-app" for full scale applications
This plus a translation program which helps to translate the first to the later by walking the op-tree.
B::Deparse does already most of the job, like offering to translate special vars to use english variants and an opinionated indentation.
You can't really use Python as a bash replacement and you can't really scale easily to a big application with bash.
Perl can ... an this should be a central message in the way we are selling it.
For instance instead of apologizing for special vars, we would say:
Look they are very handy in "Perl-shell" and not meant to be used in this form in "Perl-app", why don't you "use anal"* anyway?
I hope my point is clearer now.
*) "anal" in the sense of super-strict
| [reply] |
