in reply to Perl and London Broil: The future of computing magic?

Interesting thread here.

Monks know that this is not a “Perl vs. PHP” thread ... and, Monks know why.

Really, I think the core issue here is ... the standards of professional practice that we see in our chosen field. It runs the gamut from the seasoned pro to the tyro. And, of course, it shouldn't.

No one can seriously dispute that PHP is not a good, well-designed tool. The folks at Zend, in particular, are without question good at what they do. The problem we see, rather, is with the web-sites themselves. How rugged they prove to be; how long they last in service, especially as the business grows ... and as the personal computer continues its ever-more-rapid migration from the desktop to the shirt-pocket.

A few years from now, I think we'll see another few casualties along the computing roadside:   PHP and Ruby will have their hoods up. Java will be lumbering along with “WIDE LOAD” signs and escort-cars. COBOL(!) will still be zipping along on the nearby railroad tracks with its accustomed loads of heavy freight. And on the highway, Perl will still be doing “damn near everything.” Quickly.

There's a reason for that. And the reason is, adaptability. Because Perl consists of a fairly small but well-built core, surrounded by thousands of strongly-tested CPAN modules, it continues to have a strong life-span. Products built this way last longer.

It's a real shame that we don't have the notion of “apprentice...journeyman...master” in the software development trades. Maybe we should. Just getting a University degree is not nearly enough. (“Certifications” are truly laughable.) Maybe one of the reasons why we're grousing at PHP-junque ... why there is so much of it ... is really that “while experience is the best teacher, she runs a very expensive school.”

Replies are listed 'Best First'.
Re^2: Perl and London Broil: The future of computing magic?
by zerohero (Monk) on Feb 02, 2009 at 17:51 UTC

    >> Monks know that this is not a “Perl vs. PHP” thread ... and, Monks know why.

    Well one interesting question is: "Why isn't Perl used as much as PHP is for web development"? It got there first. It had the limelight. I'd argue it's technical merits better than PHP: language, CPAN, community. But look at the usage statistics for languages in the web sphere and you'll see PHP way out in front.

    PHP has proven it's usefulness in the web space. But why is it being overwhelmingly chosen over Perl for this task? Maybe monks don't perceive this as a problem. I think it's kind of a shame given the head start Perl had and technical merits of the language.

      On cheap/free hosts it is a pain in the ass to get the various modules you need installed.

      Even worse, there is no easy way to cross compile your modules your own modules. So if your host does not give you access to a compiler, many modules are impossible to use.

      There is often no easy way to see what modules are available on your hosting provider. So portability between providers is unsure.

      In practice, it is easier to get PHP working and move it from place to place.

      Since there are 306,127 different module distributions for template handling, can rely on your module of choice being installed on your next hosting provider?

      The core of the problem: As a skilled Perl programmer, it was easier for me to learn enough PHP to get a quick site together than it was to negotiate with the hosting provider to get a decent Perl kit. How much worse would the trade-off be for someone who didn't already know Perl?


      TGI says moo

      I think that PHP was definitely “more approachable.” Also, it's easy to conceptualize the notion that “the right|easiest thing to do is to just mix the SQL right in there with the HTML, since all you're really doing is CRUD.”

      “Easy to conceptualize,” “easy to deliver release 1.0” ... and utterly impossible to maintain as things change. Two or three years out, the app is $DEAD $BEEF. Everything's so tightly coupled together that you can't change either the presentation or the data-structure without starting over.

      I'm not sure that it's really PHP's fault, though, so much as the (lack of) experience of the programmers... And I'm sure that there must be some “dazzlingly good” PHP out there. I just haven't seen any yet.

      I think that PHP was definitely “more approachable.” Also, it's easy to conceptualize the notion that “the right|easiest thing to do is to just mix the SQL right in there with the HTML, since all you're really doing is CRUD.”

      “Easy to conceptualize,” “easy to deliver release 1.0” ... and utterly impossible to maintain as things change. Two or three years out, the app is dead beef. I'm not sure that it's really PHP's fault, though, so much as the (lack of) experience of the programmers...