Re: veracity of whitepaper, please help stomp this misinformation

[email protected] (Michael Kunze)
Newsgroups php.evangelism
Message-ID <[email protected]>
Hi all,

while the mentioned whitepaper surely has a problematic approach, it
shouldn't be denounced as 'quite a bunch of shit' as others have done on
the php-dev mailing list. Unbased arrogance won't bring PHP any further.

I haven't had the time to go through the whitepaper thoroughly, but i
have recorded enough to say something specific.

First, the whole document uses some rhetorical tactics from the
textbook: Persuade readers to accept some reasonable sounding
assumptions and lead them to unreasonable conclusions. If you buy that
the existence of a function name like explode() in PHP will confuse
developers, then, of course, lasso is better than PHP. If you buy that
one must have an code obfuscating compiler to stop people from looking
at your code, the same applies.

I could go on for pages here...we all know these tactics from Microsoft.
I could argue that it is a feature and not a defiency of PHP to have a
lot of extensions not compiled in beforehand. I could say that the
existence of tons of readable scripts for PHP is a bonanza for every
serious developer. I could ask myself whether the prebuilt security
system of lasso is of any use in other than very special cases. I could
doubt the ability of the authors to do basic math in calculating the TCO
of PHP...

But there is a valid point in this whitepaper -- the lack of a working,
robust application server for PHP. The discussion within the PHP
community about the need for such a beast goes into the second year
now...and nothing real substantial has happened. I can imagine that most
of the better benchmarks for Lasso are due to object caching on the
internal app server.

Just my 2 cents

Michael
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.