[GRLUG] sysadmin job opening

[Ben DeMott]

Propagandist much...

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.
http://www.skitoy.com/p/web-20-development-c-vs-java-vs-php-vs-python/141

I pretty much agree with the blogs last statement...

What’s the upshot…

   - 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.
   - 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.
   - Extend your Python with (C) or C++ for the computational parts of your
   heavy lifting — think peep hole optimization.




On Sun, Jan 31, 2010 at 2:23 PM, Adam Tauno Williams <awilliam at whitemice.org
> wrote:

> On Sun, 2010-01-31 at 09:50 -0500, Godwin wrote:
> > On Sat, Jan 30, 2010 at 3:32 PM, Adam Tauno Williams
> > <awilliam at whitemice.org> wrote
>
> > Seems pretty familiar to me: we use VMware, Linux, Apache, PHP
> > (sadly),
> > DNS (bind), routing (RIPv2), VPN, IPtables, etc...
> > ..just curious, why 'sadly' on PHP.
>
> 1. "Invalid stack frame at line 0" crashes of the runtime rather than
> raising exceptions.  This has something to do with string processing and
> possibly relates to #4.  We see this occasionally in dealing with IMAP
> connections [message text] or processing XML.
>

The only time I've ever received this error is when I referenced a
de-allocated, or non-existing STREAM.
CURL was my problem - there have been a lot of fixes to curlib however.
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.

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.

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.
They usually correct these behaviors in time.
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.

Poor OOP decisions.
I've seen many developers rely on OOP programming paradigms without properly
planning out their application.
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.

>
> 2. Terrible PDO performance with large result sets.  Witness PHP's
> transfer of the data over the wire, which takes over a minute,
> <https://www.mormail.com/OGo12905012.2009051914.TransferRate.png> while
> either .NET (Mono) or Python can retrieve the same data in slightly over
> one second.
>

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.
I don't know what version of PHP you are using exactly, but:
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 - http://live.gnome.org/PyWebKitGtk  (QT's Webkit library
performs much better in Python) - (or at least it used to)
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 w3cschools.com)
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.
4.) THE DOCUMENTATION STATES: Note that you cannot perform any database
functions using the PDO extension by itself; you must use a database-specific
PDO driver <http://www.php.net/manual/en/pdo.drivers.php> 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.
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. http://news.php.net/php.pdo/1 -> You did not mention this anywhere so I
am for the sake of completeness.


> 2.5. Binding parameters in PDO queries is also very touchy,  it is
> trivial to crash the interpreter [again, no exception occurs].
>
> 3. The whole pass-by-reference vs. pass-by-value thing in PHP is a
> confused mess.  Which maybe explains why seemingly valid code such as -
>
> for ($enterprises as $e) {
>  $a = array('name' => $e['name'],
>             'location' => &$ogo->getSubkeyReference($e, '_ADDRESSES',
> 'type' 'location'));
>  }
>
>  - will crash PHP cold, but -
>
> for ($enterprises as $e) {
>  $l = &$ogo->getSubkeyReference($e, '_ADDRESSES', 'type' 'location');
>  $a = array('name' => $['name'],
>             'location' => &$l);
>  }
>
> - works.  Weird.
>

> 4. GC bugs.  Occasionally we've had to manually unset values at the end
> of a script or PHP's garbage collection will crash as it seems to try to
> dereference objects in the incorrect order.  Now we pretty much
> deference manually in most cases to avoid the risk of that condition.
> Sometimes the script will seem to work - you only notice if you are
> monitoring the error logs that the script is actually crashing the
> interpreter every time it runs.  The consequence of which also has a
> measurable performance impact.
>

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...
Not only does it NOT have problems but its adoption has become fairly
standard.
The enterprise project Magento Enterprise runs many huge E-Commerce websites
and uses Zend Framework - is Fully Object Oriented.

If you are having Garbage Collection problems it very well may be your
implementation.
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.

>
> > For what do you use it,
>
> Large intranet and extranet applications.
>
> > and which scripting language would you rather use?
>
> None of the other alternatives exhibit these behaviors.
>

"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".

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.
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.

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.
http://bugs.python.org/

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.
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.
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.

/le'sigh


>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shinobu.grlug.org/pipermail/grlug/attachments/20100131/cfeab986/attachment-0001.htm