[ale] J2EE vs PHP

[Ronald Chmara]

On Mar 11, 2004, at 5:48 PM, Fletch wrote:
>>>>>> "Ronald" == Ronald Chmara <ron at Opus1.COM> writes:
> [...]
>     Ronald> Now the author might simply have realized that every
>     Ronald> language has multiple deployments, and thus coded for in
>     Ronald> such a way as to test what deployment is in use, or coded
>     Ronald> for the lowest common version.... but no, PHP is faulted
>     Ronald> because in the computer world, there are versions of
>     Ronald> software!  Oh my!
> The main reason I've seen cited for this issue being a problem is that
> PHP (apparently, from my readings) has a bad history of interface
> drift between versions, with things changing without any deprecation
> even between minor versions.

Uh, wow...... Okay, and yet they've kept tons of functions around, 
hidden, and working the same as they did in PHP2, aside from bug fixes, 
in spite of heated arguments to dump them (they're generating warnings 
now)? Can you think of a specific function that was being referred to? 
That last major change I remember was 2->3, when it was re-written from 
the ground up. Close brackets had to be added to code for 
compatibility.

I'd guess this actually stems from a few other things, that I 
definitely *have* run into in real life:
1. New functions are created, and documented, that make life a lot 
easier. Programmers use them. Programmer then deploys on older version, 
and sees his work fail (happened a lot with database convenience 
functions). Because they are core functions, not CPAN, a CPAN update is 
not an option.
2. Casual users of PHP don't read release notes. Heck, programmers of 
PHP don't always read the notes. PHP turned off global_vars, people 
didn't read the latest notes, and a good 90% of all PHP programs didn't 
work with a stock install. Required a one-line edit to fix the new 
default, but it's gonna take years before all PHP code passes muster 
(compare to perl and taint issues).
3. Magic quotes were being relied upon by users. They were broken, so 
some admins turned them off. Programmers have to compensate for both 
conditions (on and off) if they want to deploy on multiple machines.
4. As cited in the article, PHP can be built with, or without, support 
for certain functions. If a user has no control over the build, they 
have no control over what library-based functions are available beyond 
the base (compare to perl where users are forbidden from adding CPAN 
modules that require system libraries).

> [...]
>     Ronald> target-specific items as runtime requirements. If one
>     Ronald> doesn't know what version of perl is going to be in use
>     Ronald> (with what CPAN modules), or what version of java is in
>     Ronald> use, or what version of bash is in use, is the *language*
>     Ronald> at fault because the programmer is choosing to use version
>     Ronald> and implementation-specific features?
> If the language itself mutates significantly enough between versions
> that there isn't a stable target to code for I'd say yes it's a flaw
> in the language.  As a point of comparison, probably 85%-90%+ of code
> written for Perl 4.0.36 (which is going on at least 10 years old)
> would run without changes under the latest 5.8 (and the one big change
> that it might need would be "foo at bar" to "foo\@bar" since arrays now
> interpolate in ""'ed strings).

With PHP, that'd be 3.0.17 (ish)? (I don't recall off the top of my 
head). Between 3 and 4, a whole bunch of OO work was added (along with 
tons of other helpful functions), so if a GPL purist wanted a GPL PHP, 
OO is out. Again, however, that's a complaint about *forward* 
compatibility. The online PHP manual notes when functions were added 
for a good reason. :-)

> [...]
>     Ronald> Personally, I prefer PHP, but that's all about how I
>     Ronald> program, and I haven't seen a whole lot that I *can't* do
>     Ronald> (on an application level) in PHP.
> I hear some people love Visual Basic, too.</minor flamebait> :)

Fair enough. I don't use PHP for mundane-text-file-whacking (though I 
could). That's why we have perl. :-) </minor flamebait>

> Neither the article nor I ever said you couldn't do things in PHP, but
> rather that the language itself doesn't lend itself to some things
> (say, writing a Gtk+ GUI app . . .).

The initial question was about web applications. The article was 
complaining about it in that context.

But, since you asked (heh):
http://gtk.php.net/
:-P

>  But I'll personally just stick
> to Perl where I can use either m//, s///, or index() rather than have
> to try and memorize which of the 20+ functions behaves the way I want.

It's not like it's so complex to use regexps that there are books about 
it. :-)

I generally don't use the slower php regexp engines (speed hit) if I 
don't have to, so I guess I've memorized using more functions as a 
matter of code optimization. (Perl has a lot more front loading, but 
note that it handles compiles differently, so there's not that much of 
a speed hit.)

Seriously though, nice link. A bit silly in some ways. "PHP has too 
many functions" is probably my favorite, and some simple digging would 
have turned up the information on making PHP's internal namespace 
consistent (it's supposed to be modulename_functionname) .... but 
overall, worth a giggle.

-Bop