volks,
p0: let's chill a bit and think about the 'well reasoned'
portions of the kvetch so far.
{ the alternative is the I WILL let my Pixies Out
and that will not be a pretty sight... }Prefatory Kvetch:
I think one of the ultimate problems is that unlike the benchmarking that we can do inside of Perl to at least put some 'technical numbers' around the cost of doing 'foo over bar' - the assertion
'foo is simpler than bar'
is less easy to demonstrate imperically. All of which gets compounded by the 'time to market', 'head count costs', 'refactoring costs'.... So for a field that is alledgedly about 'computational arts' - so much of it has less to do with the computable, than with the art....
p1: the economic problem -
The motivation for new perl learners is not very big because most of the
jobs can be found in PHP/ASP and only after that in perl/Cold Fusion.
Unfortunately you make a really scary argument here. Why learn Perl if it really is tomorrow's Cobol.
Amongst the questions then is whether the 'available jobs' are being driven by 'weird market hopes'. In this case that majikally the 'problem' that they want solved will be solvable simply with 'just some PHP/ASP stuff' - hence that they can pick up cheaply that 'will code HTML for food' person...
When what will ultimately happen is that they will need to deal with the actual 'software development cycle' and the consequences that they did not start from a design pattern of any type at all....
If we should have learned anything from the e-Biz/Internet Craze then it clearly would be the difference between being able to type text into a text editor and being able to DO software development based upon 'best practices' in the art.
I am MORE than willing to concede right here and now that there are people with CV's that say that they were the VP of engineering, the Chief Architect, <Very Professional Sounding Tytel Here>, who can 'legitimately' say that was their actual title at dot.bomb.com and may have been hired by people who just do not have a technical clue about what those 'roles' are - nor how to tell 'capability' from 'good marketting spin'.
5) From my time spent in the job market I would say it is pretty well divided among all of the languages, especially since most postings read something like "6 years of experience in Perl, CGI, ASP, PHP, Oracle, COBOL" (love that last one) which is a very poor indicator of the actual market...
So a part of the 'professional' problem here is how to differenciate the 'pros' from those who are still learning... On both sides of the hiring table...
I'm almost willing to say that we may be doing people harm by trying to sell perl as a simple easy thingie poo. At least as easy as <HotCrazeKultHere> - since software stuff tends to get complex real quick, and no amount of Management Hopes that 'a little scripting' will majikally rescue their delivery date.
cf:
<http://www.wetware.com/drieux/CS/lang/shellScript/ JustSomeScripting.html>
p2: the Keep Perl Alive Position: [..]
[..]
If we say that perl don't have any problem it will be used
less and less without having any problem. I think that we
should point out which are its problems because maybe they can be solved.
Hopefully we all agree on this! as it is clearly just the right thing.
Hopefully we are actually going at 'the real issues' about what really needs to be added/updated to Perl.
Just an odd thought here - have you been following the P5EE discussions?
p3: The windows/*nix problem:
I hope Perl 6 will have much more standard modules and the modules from CPAN will be able to be installed without compiling them with a local compiler.
This is a reasonable enough argument, if one is looking at the 'perl only' model - but I think a part of the advantage of 'needing a local compiler' is that they are such lovely pieces of technology. There is the advantage that gcc 3.3 comes in more flavors than I would prefer to think about. But there are also RPM - red hat package managers - and ActiveState is doing a very good job, or so I am told for those who 'just want the binaries'.
We should keep in mind that even if the most web servers are running under Unix/Linux, most computer users and possibly web developers are working under Windows and the CPAN modules should be all compatible with Windows also, and not only with Linux.
This is a 'strange' position, and forgive me, it is hard for me to imagine that I would be developing for target platform <foo> to which I did not have something that was at least analogous. { note - yes, I do have code out there that will run on an OS that is not in the crib, but that's life, in that case it was a 'one off' of stuff we do have in the crib. Ok, I take that back, I have code for systems that do not run anymore, unless someone out there wants some Cray-2 code.... But back then I did have access to it...}
I'm trying to understand why one would be a professional software developer who has not started the process of building out their own 'lab' to work with. This of course goes back to the previous comments about having the compilers, since you want to not only understand the process that your clients will be dealing with, but actually reading other people's code is a really good way to upgrade your own bad habits...
For a really small investment one can pick up things like solaris boxes, one can even spin up cheap BSD boxes, run them as headless machines, with a single monitor, mouse, keyboard on a KVM switch, a small 10/100 switch, enough Cat-5 wire, and one has a development environment in which they can build out their project.
Nothing like seeing HOW that will really work in Apache 1.3.X and the Apache 2.X - and then save up their shekels for a solid OS X box and one is styling...
{ depending upon the tax laws in your country, and the
competency of your CPA, much of that can be buried as
business related, yada-yada-yada }My point here is that as a professional in this trade, this IS my workstation - these are my tools - this is where the Majik Happens.
6) I feel sorry for the development house (and their clients) that
develops their site on a different system than it will be served (and I
don't mean a developer sitting at a Windoze machine ssh'd into the
server since that can't count because in that case they don't need the
modules locally). Which means that if they are serving on Windows they
know what is available and are more likely able to get something to work
(I mean they are developers they ought to have a compiler available on
their own platform and know how to use it). On Linux/*nix of course
this is mostly moot... (and there is 60+% of us on that platform)...
Or is the insanity here that the 'accounting department' got a really good break on windows machines, even if the developers are developing for *nix boxes.
Let me warn those who have not seen it, when this HAPPENS, it is a good time to circulate your resume before the firm craters.
I will admit to having swapped out the Monitor,Mouse,Keyboard and Sbus card from an old Sun Box, turned it into a headless server, then picked up a cheap NT4.0 box - and ran the Xwindowing server on it. Made a great Xterminal. I do not mean to start an OS 'flame war' here folks - trust me, if you code to the WIN32 API, and that is where you find your happiness, go for it!
But I think the unpleasant part is if folks are being nickled and dimed at the engineering end of the house and can not get the tools that they need, that really is the scary thought.
Generic Arguments and Problems:
1) Still not possible to prove that PHP is used more than Perl, which also makes it impossible to prove it isn't....
Things that can not be proven are a great place for religious wars - the point that was being raised was an 'economic issue' and has the problem that it's merit is NOT tied to the technology or to a technical analysis.
There is the additional problem that there is 'web technology' that is being constructed that will not be 'seen' on the internet because it is not for the internet - so we should also put that problem into play. Sending a web-bot out to count pages will not tell you all of the pieces of the project that brought you the page.
2) All of the modules you stated exist for PHP, exist for Perl, many of
them probably before those for PHP were developed. CPAN is the envy of
all languages, ask a Java developer familar with Perl sometime about how
they feel about CPAN...
A part of why I referenced the P5ee project is that they also understand that Perl is up and running on OS's for which there is no JVM at this time, and most likely will never be, in the main because as 'legacy hardware' no one in the Java community will be going back to cover those bases. While the FREAKS in the perl/gnu world just keep right on adding into the FREAKING list of config.guess file... oh dear, people really should read the latest one and take the step back through the portal to a kinder gentler time...
[..] ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
