[UPHPU] Rails vs PHP

Walt Haas haas at xmission.com
Mon Mar 26 11:02:07 MDT 2007


I believe that one reason for the PHP situation you describe is that the
language has appealed more to the quick-and-dirty approach than it has
to the kind of serious software engineering that puts well-designed
abstraction layers in important places.  So PHP projects tend to have
more mingling of functions that might better be separated, which in turn
leads the next developer to start from scratch because there is no
practical way to plug in a replacement layer.  MDB2 is a good move away
from this, hopefully there will be more such moves.

The question of where the market is going is an interesting one.  I see
three major trends pushing it:

1) The Internet is becoming a more and more dangerous place with more
and more people looking for holes that they can steal through.  This in
turn makes it more and more dangerous to put quick-and-dirty code on the
public net, so the cost/benefit tradeoff will tilt more in favor of
thorough vetting of code for security.

2) More life-critical functions depend on software than ever before.
The last company I worked for seemed to think that software debugging
could be limited by cost/benefit considerations.  Unfortunately for them
they were in the medical equipment business, and some of their bugs
could have fatal consequences for patients, so the Food and Drug
Administration ended the cost/benefit discussion with a court order
shutting them down.  Which I think was the right thing for the FDA to
do, knowing as I do how the place was managed.

3) CPU speed is hitting fundamental physical limits, so future
performance improvements will have to come from increased parallelism.
It's very difficult for a compiler to find parallelism, so there will
probably be increased incentives for programmers to show where
parallelism is possible.  Threads are one mechanism for doing this.
Functional programming languages such as Lisp and its descendants
organize the program in a way that encourages parallelism, but they
require the programmer to think differently about the problem, just as
OOP languages require thinking differently than purely procedural
languages do.  I'm expecting to see more of a trend toward any software
method that will help parallelism, which will in turn affect the way we
program.

-- Walt

On Mon, 2007-03-26 at 10:39 -0600, jtaber wrote:
> Hmm, I don't think most people are getting what I was actually thinking 
> when I jotted down my slides (so I probably need to refine them) - it 
> wasn't meant as a technical comparison (framework vs language issue) but 
> rather as a overall development choice issue - and how the PHP community 
> could learn a lot from Rails.  Once you use Rails and then look at the 
> various PHP spaghetti examples, you wince (as soon as I see a ISSET in 
> the code, I wince).   And how much developer time goes into PHP stuff 
> like helper code.   So much time to do simple PHP stuff!   A clean RAD 
> framework approach like Rails is definitely the future - once you really 
> use one, you see the productivity difference.  But how many people 
> really use Ruby:  5% ?  How many use python: 25-50% ?  How many use PHP: 
> 75% ? How many use java: 90% ?.   Thus, it's out of synch.  I really 
> think and was trying to note that PHP can achieve much of what has made 
> Rails so famous if the community adopted some standardized code such as 
> a front controller template, some standard code snippets for things like 
> validation, pagination, etc - some sanity and productivity to the 
> spaghetti madness.   But will that ever happen ?  Heck, there has been 
> little consensus or adoption on the 3 main PHP frameworks (how many are 
> actually using them?  5% ?   Thus, is it easier to just choose  
> something else such as Rails or Django or Scala Lift or ?  And so where 
> is the marketplace going and where do you want to be ? 
> 
> John




More information about the UPHPU mailing list