Propagandist much...<br><br>In the end I would agree with this blog a fair amount... its a quick list of generalities of where the "web languages" are good and bad, and strong and weak, and where you should use them. I don't know who in their right mind would try to write a web front-end in C++ - but hey whatever.<br>
<a href="http://www.skitoy.com/p/web-20-development-c-vs-java-vs-php-vs-python/141" target="_blank">http://www.skitoy.com/p/web-20-development-c-vs-java-vs-php-vs-python/141</a><br><br>I pretty much agree with the blogs last statement...<br>
<p>What’s the upshot…</p>
<ul><li>Use PHP to build web front ends — the ability to find a PHP
programmer is pretty easy, odds are it’s not going to make/break your
application.</li><li>Use simple RPC mechanisms (e.g. JSON RPC) to Python back ends for
the heavy lifting — lots of choices here, but odds are it’s not going
to make much difference.</li><li>Extend your Python with (C) or C++ for the computational parts of your heavy lifting — think peep hole optimization.</li></ul><br><br><br><div class="gmail_quote">On Sun, Jan 31, 2010 at 2:23 PM, Adam Tauno Williams <span dir="ltr"><<a href="mailto:awilliam@whitemice.org" target="_blank">awilliam@whitemice.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>On Sun, 2010-01-31 at 09:50 -0500, Godwin wrote:<br>
> On Sat, Jan 30, 2010 at 3:32 PM, Adam Tauno Williams<br>
> <<a href="mailto:awilliam@whitemice.org" target="_blank">awilliam@whitemice.org</a>> wrote<br>
<br>
> Seems pretty familiar to me: we use VMware, Linux, Apache, PHP<br>
> (sadly),<br>
> DNS (bind), routing (RIPv2), VPN, IPtables, etc...<br>
> ..just curious, why 'sadly' on PHP.<br>
<br>
</div>1. "Invalid stack frame at line 0" crashes of the runtime rather than<br>
raising exceptions. This has something to do with string processing and<br>
possibly relates to #4. We see this occasionally in dealing with IMAP<br>
connections [message text] or processing XML.<br></blockquote><div><br>The only time I've ever received this error is when I referenced a de-allocated, or non-existing STREAM.<br>CURL was my problem - there have been a lot of fixes to curlib however.<br>
This can also happen if you exhaust the recursion limit of the underlying language -> but out of the million or so times I've debugged a PHP application this is _NOT_ the norm by any means, and its unfair to represent it as so.<br>
<br>PHP RC2 5.2.9 had some BAD problems where extra parenthesis and brackets could cause the Zend Engine to crash - the "WHITE SCREEN OF DEATH" -> most of these problems are fixed quickly and sure enough PHP 5.3 corrected them.<br>
<br>Because PHP is a mapping between interpreted functions and compiled C
functions it is possible to crash the Zend
Engine in such a way where it does not "catch" the error correctly.<br>
They usually correct these behaviors in time. <br>The Zend Engine under the hood is creating executable segments of memory after interpreting and linking your PHP code - this creates a very high performance language if this is understood and used correctly.<br>
<br>Poor OOP decisions.<br>I've seen many developers rely on OOP programming paradigms without properly planning out their application.<br>I'm not saying the language should be so particular or touchy that it will fail when your programming "style" isn't agreeable... BUT storing instance classes within instance-classes, and doing other "round-robin" Object interactions, not making singletons classes when needed,etc is a great way to get yourself in a world of debugging HURT with PHP -> the same is true in JAVA and Python.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
2. Terrible PDO performance with large result sets. Witness PHP's<br>
transfer of the data over the wire, which takes over a minute,<br>
<<a href="https://www.mormail.com/OGo12905012.2009051914.TransferRate.png" target="_blank">https://www.mormail.com/OGo12905012.2009051914.TransferRate.png</a>> while<br>
either .NET (Mono) or Python can retrieve the same data in slightly over<br>
one second.<br></blockquote><div><br>I'm sure the cause of this is ... your driver, your version, misuse of memory during iteration, or you aren't using a domain socket, or the lack of persisting a connection and iterating... We have excellent performance with both Postgres and Mysql PDO drivers in 5.3 - similar performance to Python at least.<br>
I don't know what version of PHP you are using exactly, but:<br>1.) PDO was a PECL extension before PHP 5.1... If someone writes a "bad" library implementation of Webkit in Python that crashes occasionally or performs poorly it doesn't have anything to do with Python as a language. Case and point - <a href="http://live.gnome.org/PyWebKitGtk" target="_blank">http://live.gnome.org/PyWebKitGtk</a> (QT's Webkit library performs much better in Python) - (or at least it used to)<br>
2.) PDO was experimental, and the drivers that implement each database were from the vendors - some vendors didn't participate so the community was left writing a driver instead. If you are inserting into a MSSQL database it doesn't surprise me - especially considering its using a Sybase driver under the hood several versions old most likely. (this is really Microsofts fault more than anything its not like they would help support PHP in any way, yet they advertise running PHP applications on their servers at <a href="http://w3cschools.com" target="_blank">w3cschools.com</a>)<br>
3.) There are direct implementations of each of the database drivers - no one "HAS" to use PDO. A database specific extension is provided for all of the same PDO drivers and one is implemented very well through the PEAR project.<br>
4.) THE DOCUMENTATION STATES: Note that you cannot
perform any database functions using the PDO extension by
itself; you must use a <a href="http://www.php.net/manual/en/pdo.drivers.php" target="_blank">database-specific
PDO driver</a> to access a database server. -> meaning that the implementation of each driver is to some level outside the scope of the CORE of PHP - with any extension to a language you should carefully research/test it.<br>
5.) There is a HUGE and ongoing effort within the PHP Core development to get the vendors together to correct/fix many issues with PDO and release PDO v2. <a href="http://news.php.net/php.pdo/1" target="_blank">http://news.php.net/php.pdo/1</a> -> You did not mention this anywhere so I am for the sake of completeness.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
2.5. Binding parameters in PDO queries is also very touchy, it is<br>
trivial to crash the interpreter [again, no exception occurs].<br>
<br>
3. The whole pass-by-reference vs. pass-by-value thing in PHP is a<br>
confused mess. Which maybe explains why seemingly valid code such as -<br>
<br>
for ($enterprises as $e) {<br>
$a = array('name' => $e['name'],<br>
'location' => &$ogo->getSubkeyReference($e, '_ADDRESSES', 'type' 'location'));<br>
}<br>
<br>
- will crash PHP cold, but -<br>
<br>
for ($enterprises as $e) {<br>
$l = &$ogo->getSubkeyReference($e, '_ADDRESSES', 'type' 'location');<br>
$a = array('name' => $['name'],<br>
'location' => &$l);<br>
}<br>
<br>
- works. Weird.<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
4. GC bugs. Occasionally we've had to manually unset values at the end<br>
of a script or PHP's garbage collection will crash as it seems to try to<br>
dereference objects in the incorrect order. Now we pretty much<br>
deference manually in most cases to avoid the risk of that condition.<br>
Sometimes the script will seem to work - you only notice if you are<br>
monitoring the error logs that the script is actually crashing the<br>
interpreter every time it runs. The consequence of which also has a<br>
measurable performance impact.<br></blockquote><div><br>I don't know which version of PHP you are using again... But Zend Framework is a HUGE OOP framework which uses all of the OOP features provided by PHP - Interfaces, Abstract Classes, etc...<br>
Not only does it NOT have problems but its adoption has become fairly standard.<br>The enterprise project Magento Enterprise runs many huge E-Commerce websites and uses Zend Framework - is Fully Object Oriented.<br><br>If you are having Garbage Collection problems it very well may be your implementation.<br>
The garbage collector in PHP 5.3 has been replaced, and will be updated or replaced again in php 6.0 because of features like Closures, and Anonymous functions being introduced.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> For what do you use it,<br>
<br>
</div>Large intranet and extranet applications.<br>
<div><br>
> and which scripting language would you rather use?<br>
<br>
</div>None of the other alternatives exhibit these behaviors.<br></blockquote><div><br>"These Behaviors" -> They exhibit complications of their own, and have problems of their own - its unfair to make it "seem" like Perl, Python, Tcl, Scheme, Ruby, Java, and the other host of languages that have been used over the years for server/web applications do not have "issues".<br>
<br>Java allows subclassing inner-classes - in the SUN JVM the implementation was copied / came from a Scheme implementation of the VM. When the application was re-written in C - corners were cut. Garbage Collection -> Instead of providing a robust poly-hierarchy for garbage collection - inner-classes simply COPY their parent at the time of execution, and this is how the keyword "parent" is exposed. If a parent instance class calls or interacts with a subclass 20 times - the Parent instance class will be copied in memory 20 times. <br>
I was there for the OOP discussion on PHP 5 and this is why it was chosen NOT to allow inner-classes in the same fashion Java does.<br><br>Python is not without its ongoing list of issues - Python has a very aggressive development schedule.. and maintaining version 3, and 2.6, 32bit, and 64bit libraries has created additional complexity within the community... It's not a bad thing - its just the reality.<br>
<a href="http://bugs.python.org/" target="_blank">http://bugs.python.org/</a><br><br>To each his own - different tools are good at different things - but I appreciate fair and balanced discussions about development - especially when PHP it is used so widely and has such an open and active community.<br>
I started programming in C++ and PERL... I could do more "stuff" in PERL at the time (being 14 years old) so that's what I "played with" most of the time. <br>Perl was so incredibly bad at one time - I would pull my hair out trying to do SIMPLE things -> I was once given the advice after I asked how I could make my Perl application easier to install to "Just ship your own version of Perl" ... IT WAS THAT BAD.<br>
<br>/le'sigh<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div><br>
<br>
_______________________________________________<br>
grlug mailing list<br>
<a href="mailto:grlug@grlug.org" target="_blank">grlug@grlug.org</a><br>
<a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
</div></div></blockquote></div><br>