In this setting, Perl isn't even considered a real programming language. It's referred to as "scripting" as opposed to "programming"...
I had thought we had gotten rid of that false impression, but I guess not. I was surprised a month ago when I was talking with one of the board members of the local ACM chapter. Upon seeing Perl on my business card he said, "oh, so you do scripting?"
This is an example of how Perl's wide dynamic range of problems it can address seems to hurt its reputation.
Further, to do anything "fancy" you need some modules from CPAN, and installing these modules would mean QA testing, and a production roll-out with change form and managerial approval. If you knew how many times I had to write my own (limited / broken) version of a good code I could have gotten from CPAN ... well, I'm sure Larry Wall is weeping out there, somewhere.
It sounds like you have political/managerial problems that are beyond the scope of Perl.
Do the VB developers have the same restrictions when they use third party code? Do they not use third party code? Or is it only open source code that scares them?
Does a product like PHP, that rolls-in a lot of functionality, get around this? If so, does that mean your QA group qualifies every feature built-in to the environment?
The other side effect, is that something that could be easily done in Perl get's written as a DOS Batch script or as a VisualBasicScript ... because those interpreters are ubiquitous on the servers.
You could use a tool that packages the Perl script as a self-contained executable, though it might be too heavy weight for your application.
Does anyone else want or expect fully formed Perl apps for web deployment? Maybe if there were more then just little Perl "scripts" for quick CGI tasks like hit counters or guest comments, more novice programmers would use and learn Perl instead of starting off with PHPBB or something and going that direction.
They exist already, though as you can see from my other posting, the PHP ones outnumber the Perl ones (at least when it comes to CMSs).
I think what needs to happen is to look at what needs to change further up the production chain. Writing more Perl apps won't have as much impact as creating a web development environment centered around Perl that makes writing Perl apps as easy as writing PHP apps. and makes deploying Perl apps. as easy as PHP for both the user and the ISP.
The prospect of wading through tons of OO PHP code in order to customize a CMS is disheartening. Having to learn Python just to use some of the great Python based CMS's is even more depressing.
I agree.
Although it doesn't really count for anything, it seems worse to have to learn PHP or Python just for the sake of customizing a CMS when there doesn't seem to be any reason why those languages provide an advantage when creating a CMS. If they did, then I wouldn't mind learning them.
I, like I'm sure most programmers, am eager to learn new technologies that provide new capability, but completely lack enthusiasm when the technology is merely a lateral move for the sake of career or other business considerations.
I don't want to keep learning how to do the same things in diff erent
dialects, I want to learn how to do totally new things in the dialect I already know.
Exactly.
I don't want a "broad" knowledge of programming, I want a "deep" knowledge. ...I want to explore deep CS problems...
And Perl certainly has enough depth to keep you busy for a long time.
In a perfect world, I'd be paid (well) for being really, really, really good at programming in a language with broad capacity and that I like - Perl. In the real world, I have to go out and learn Java (which I have so little interest in) because that is what is being asked for in countless job postings.
Yup, that frustration pretty much sums up my interest in mind share.
-Tom
_______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
