|
in reply to why i may have to leave perl...
I have seen a lot in this thread, and indeed in general talk, about how perl should be extended, or managed, in order to make it a panacea for all that needs to be programmed.
Don't get me wrong... but all languages have their unique niche.
I love perl, perl is a GREAT language for the things that I do with it... but it's not the right programming language for every situation.
Perl stands for Practical Extraction and Report Language... not Perfectly Everything's Replacement Language, for every other language and system on the planet.
Yes, improve, work, make perl WONDERFUL! Just don't make it impossible and useless. You can only change it so much before losing sight of the fact that it is GREAT for certain things.
I still think that in certain situations, it is better to embrace the fact that a different language should be used, rather than forcing a nice square peg like perl, that fits wonderfully into nice square holes, into a round one.
This will just make the people who had THAT experience with perl as their first real experience not want to embrace it like we have.
Whatever you do with perl, whatever solution you come up with... make sure that it is the BEST solution to the problem that you can thing of. If you think that lisp is the solution to the problem, and you can code it in 20 lines in lisp, why make an issue of it and vow to use perl in this project. Instead, take what you have learned from the experience, and if it seems practical to extend perl to make such endevours practical under it, then come back, and give this back to perl.
This is the way that we make the language that we love the language that everybody loves, rather than the language that is cryptic and painful to learn.
Just Another Perl Backpacker |
RE: Perl's Niche
by tilly (Archbishop) on Aug 10, 2000 at 21:37 UTC
|
Perl was originally intended for parsing and printing
formatted reports.
When was the last time you personally used formats?
(merlyn can skip that question. :-)
Perl has changed niches before and undoubtably will in the
future. Please don't lose sight of the fact that Perl was
meant to evolve over time. As long as that happens within
reason, it can do that and keep its flavour. Just as it
has in the past. | [reply] |
|
|
Yes, but change and evolution takes time.
Perl as we know it has evolved over many years.
And I do love the language.
Heck, if you want to change the package management and such of it, go right ahead.
What I am saying though, is don't use it for a purpose that it is not CURRENTLY designed for, that will only cause it's audience to shrink, rather than grow.
Just Another Perl Backpacker
| [reply] |
|
|
There are people who still use Perl for its original
purpose and simply love formats.
Have no concern, the people guiding development know the
language very well and care deeply about where it is
coming from. I have confidence that in the end things
will work out and the language will be better than ever.
There may be a few bumps on the way, but I trust the
process.
This is all IMHO of course.
| [reply] |
|
|
RE: Perl's Niche
by knight (Friar) on Aug 11, 2000 at 22:08 UTC
|
I have seen a lot in this thread...about how perl
should be extended, or managed,
in order to make it a panacea for all that needs to be
programmed.
I don't see this thread as suggesting that
perl is the answer to every programming problem.
I do see people wanting to use perl
to solve some
programming problems in an
enterprise computing environment,
and finding that some aspects of
how it's packaged
and its culture has evolved
throw up some barriers to acceptance
in that environment.
Implicitly, you're suggesting that these
barriers are intrinsic to perl
and that, essentially, it isn't an
appropriate language in the enterprise--that's
simply not perl's niche.
I think the point is that there are
enterprise programming tasks for which perl
would be the right language,
if only people could satisfy some of the
traditional MIS concerns
about introducing any
new tool to the environment:
packaging, administration, engineering process...
The question isn't, "Can we extend perl's
syntax and modules so that every enterprise
RPG/Cobol/Lisp/whatever program can be rewritten in perl?"
It's, "Can perl's surrounding
infrastructure be cleaned up a bit
so that an enterprise programmer
can choose to use perl when it's appropriate
without scaring management and the IT department?" | [reply] |
|
|
Well, no, I'm saying that there are SOME tasks, but this situation doesn't sound like one of them. I generally don't look at perl as a language whose properties loan themselves well to such large groups. There are ways to do it. If you can separate EVERY task into a PM, and test those properly, then you have a fighting chance.
Just Another Perl Backpacker
| [reply] |
RE: Perl's Niche
by coreolyn (Parson) on Aug 13, 2000 at 04:24 UTC
|
I disagree with the attitude of not trying to expand perl's
utilization beyond what it is currently being used for. It
seems to me that if perl folk embrace that philosophy it
will fade as a once popular 'fad' language. Finding new
innovative ways to use perl is part of what the language is
about.
Currently 'speed to market' is a huge key variable in web
application development. Nothing beats perl for rapid
prototyping. Additionaly I don't know what Larry put in perl
that gave it it's 'people power', but this too is a quality
that large MIS Departments can only strive for. I don't know
any other language that is as FUN as perl, and the 'fun' factor
is everything to anyone that works with code for a living.
What is frustrating is that the powers that be in the
perl community could solve the problems of Perl in the
enterprise simply by providing easier methods for perl's
installation by decentralizing it's core distribution modules.
In other words making the default installation according to
the user's enviornment. While the mechanisms exitst for such
installations, documentation is scarce, (References would be
appreciated), and they are far from the default. MAKING PERL'S
DEFAULT INSTALLATION CONTINGENT UPON THE INSTALLING USER'S
ENVIORNMENT RESOLVES THE MAJORITY OF ISSUES SURROUNDING PERL
IN LARGE ENTERPRISE ENVIORNMENTS. Furthermore, it makes ISP
system administration, and standard system administration
easier as well. It also eliminates the mess in /usr/local/lib
that comes with utilizing the different perl rev's/distros
This appears to be a mostly trivial change for perl that
could open huge doors for the language. The failure of perl
people to see the benifits of coming through that door cause
me to worry that perl is having a hard time getting past it's
adolesence and taking it's well deserved place in large scale commercial
application development. What if the original system
administrators that exploited perl didn't extend it's use
into the web because it was only good as a sysadmin tool?
coreolyn Duct tape devotee.
| [reply] |
|
|
I am not saying don't expand perl's utilization. What I am saying, is that if it ain't the right tool for the job, use the right tool, instead of banging on a screw with a hammer, get a damned screwdriver, don't try to use a nail, when a screw is what you were asked for. If you see something that can be improved in perl, improve perl. I can CERTAINLY see improving perl to fit a situational problem. What I can't see is using it in a project that you don't think can be accomplished with it, it just doesn't make sense.
Just Another Perl Backpacker
| [reply] |
|
|
