Why are they used to ksh? :)
Because at some point in time, it seemed to be the only usable tool?
Quoting the sig of roboticus: When your only tool is a hammer, all problems look like your thumb.
I vaguely remember one of my profs claiming that ksh was the only portable shell, because it was standardised. Well, we continued to write bash and perl scripts.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
| [reply] |
AIX background. KSH is the de-facto shell. You have to install ksh93 or bash to get something more modern (to use arrays and such). | [reply] |
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] |