A Decade of PHP

digidave writes "It was slow to catch and a lot of people didn't get it. A lot of people still don't get it, but you can't argue with its success. June 8th, 2005 marks the tenth anniversary of PHP. Here's to ten more wonderful and exciting years."

Comments

Congratulations are in order!

[AKAImBatman]

Congrats to the PHP development team! PHP has long followed the KISS principle while still maintaining the Unix APIs that we've all learned to know and love. While it's not the best web scripting platform for all purposes, it is a free and flexible alternative for many, many dynamic webpage projects. It's only because of PHP that so many OSS web applications have been allowed to exist.

It was slow to catch and a lot of people didn't get it.

Ok, I'm with the slow-to-catch-on part, but what's this about people not getting it? The concept had to be one of the simplest ever designed. (Thus the reason why it's so common across web scripting languages.) Here is your HTML, here's a bit of Unix scripting langauge. Simple, see? :-)

On a slightly different topic, one wishlist item that I would like to see in PHP is Abstract Database Access. It's not really a good thing to hard code your application to a specific database, especially if it's a redistributable application. (e.g. PHPBB) The ODBC calls sort of solve this, but they do require that ODBC is installed, properly configured, and compiled into your copy of PHP. (Does anyone know if any distros now have ODBC as a "standard" library?) This assumption can't be made for most OSS applications, so they tend to tell you to just use MySQL.

Re:Congratulations are in order!

[quinto2000]

there are several classes, including the PEAR DB class, that provide a DB abstraction layer.

Re:Congratulations are in order!

[Ford Prefect]

On a slightly different topic, one wishlist item that I would like to see in PHP is Abstract Database Access.

Actually, what I'd like to see is bitwise-operations on strings - my Ogg Vorbis decoder written in PHP is currently languishing at just a bare-bones Ogg demuxer 'cos unpacking all the Vorbis packets proved just too fiddly...

Re:Congratulations are in order!

[AKAImBatman]

Dude, you need to provide links. I had to *gasp* Google it! ;-)

For others, PEAR can be found here:

PEAR Class Repository

The Database classes of PEAR appear to be documented here:

Database Package

Looking over the DB classes, it looks like they provide a fairly decent abstraction. Thanks Quinto, that will definitely be nice for future PHP projects. :-)

Re:Congratulations are in order!

[EraserMouseMan]

It's not really a good thing to hard code your application to a specific database

For most simple apps (90% of what PHP apps are) you should stick with SQL-92 syntax when you write your queries. Then just write yourself some generic functions that you pass your query and a connection string to. The functions determine the db-specific query execution code to use. I always use parameterized queries. So I've even got functions to switch the parameter character ('?' or '@' etc) to the syntax of the target db. For my apps, all I have to do is change the connection string (currently supports, MySql, Sql Server, any Odbc and any OleDb). No query or code changes required necessary.

But yea, it'd be nice if this functionality was native.

Re:Congratulations are in order!

[AKAImBatman]

You wrote an OGG Vorbis decoder in PHP? Maybe I'm missing something, but why? That doesn't strike me as a very good language to be doing such a thing in. The "PHP Way" is to leave heavy processing like that to an external library such as libogg/libvorbis. You can then use PHP as a frontend for presenting info, streaming the data, and uploading files.

I realize that PHP can be cool at times, but one has to use the right tool for the job at hand. :-)

Re:Congratulations are in order!

[The Irish Jew]

On a slightly different topic, one wishlist item that I would like to see in PHP is Abstract Database Access. It's not really a good thing to hard code your application to a specific database, especially if it's a redistributable application. (e.g. PHPBB) The ODBC calls sort of solve this, but they do require that ODBC is installed, properly configured, and compiled into your copy of PHP.

I've found ADOdb to be a very easy way of abstracting your database. Much easier than Pear::DB. Supports just about every database you can think of.

Re:Congratulations are in order!

[rho]

I've never understood the fanaticism of database abstraction. There's good reason to hardcode to a specific database, especially if you hardcode to a Free database like PostgreSQL.

For example, if you use a database abstraction, you have to make a lot of performace- or feature-robbing choices. There are still hosting situations where MySQL is still on 3.23, so you can't use the better parts of the InnoDB storage engine. So no foreign key constraints, no stored procedures.

On the other hand, if you do hardcode for PostgreSQL, you put a burden on the end user, sure--but in return, you're giving them a more robust, more featureful application that is easier to support and maintain. I personally like PostgreSQL because it seems less haphazard than MySQL, but you could very easily do this with MySQL, so long as you restrict yourself to the later, non-crippled versions.

The Arsdigita folks did this with Oracle. Leaning on a $tens-of-thousands database application may put you out of the realm of everyday developers, but it's far from insane.

This is "all the time I've spent dealing with other people's code that doesn't have a foreign key to be found and all integrity checking is done in the PHP code" talking. It's infuriating.

Re:Congratulations are in order!

[AKAImBatman]

I completely agree. The primary reason why native code would be nice is that a bundled API would help put peer pressure on coders to use it. Which means that we'd see fewer "quick hacks/prototypes" (that always turn into production sites) using database specific code.

Re:Congratulations are in order!

[dchaos]

Another db abstraction layer you might want to look into is Creole.
It's built for PHP5 but there is also a php4 back port made to support another project.

I've been using it for a little while and really like what I see.
http://creole.phpdb.org/wiki/

Re:Congratulations are in order!

[kjh1]

Hear! Hear! Thx Rasmus. I still remember one of my co-workers first encouraging me to use PHP for CGI scripting about 5 years ago, and me saying "Nah, Perl works a-ok for me." Well I also used the Bourne Shell for CGI scripting once upon a time too and moved along.

PHP really is the right tool for the job of building websites. It was designed with that in mind, so that's not a slam against Perl in any way.

To be fair, I should really check out Python and Ruby soon... The great thing about PHP now is that it has reached that critical mass where the numbers in users, libraries and tools are large enough to help you with almost anything. So there is that inertia keeping me, and I'm sure many others, from moving onto, or even trying some other language.

Here's hoping for another 10 years...

Re:Congratulations are in order!

[Ford Prefect]

I realize that PHP can be cool at times, but one has to use the right tool for the job at hand. :-)

That was precisely the reason I chose PHP - because it was absolutely the wrong tool for the job.

Well, maybe not quite as bad as some. Anyone want a port to Javascript? BBC Basic? Befunge? ;-)

Re:Congratulations are in order!

[Jack9]

In 1999 when I first started gathering talent for a web hosting company (in lieu of a PHP position, which I found a month later), I met set a meeting with a programmer named...John in a San Jose Embassy Suites. Upon hearing, the important detail; we would be using PHP in lieu of Perl, he promptly called me crazy and informed me he wouldn't be wasting his time considering working with someone who was trying to use PHP(PHP/FI at the time). Nice not working with ya John.

Re:Congratulations are in order!

[Anonymous Coward]

And then you want to get the ID of the row you just entered into the database.

Re:Congratulations are in order!

[AKAImBatman]

You can easily code your SQL to be database specific if you need it that way, but that shouldn't in any way stop developers from using a generic DB access API. A DB abstraction is nothing more than a mapping of functions, so there's rarely any performance hits. Which means that applications that don't need a specific database (e.g. PHPBB anyone?) could be portable out of the gate. And even if their SQL isn't portable, that's a far easier thing to fix than attempting to add a DB abstraction after the fact.

Re:Congratulations are in order!

[compm375]

Wait, so you chose the wrong tool on purpose and now you are complaining that it doesn't have what you need?

Re:Congratulations are in order!

[bhtooefr]

RPG IV? (Is that even POSSIBLE, seeing as sound output on an AS/400 terminal consists of beeps (IIRC)? Of course, WAV output could be done, but RPG aims for a printer - not even a screen)

Re:Congratulations are in order!

[mcrbids]

Hear here!

I've never understood the fanaticism of database abstraction. There's good reason to hardcode to a specific database, especially if you hardcode to a Free database like PostgreSQL.

You took the words right outta my mouth. I tend to work on large projects, usually the app has its own server (or servers) to work on.

I've hard-coded to Postgres since 7.0 came out, and I've NEVER regretted it. The only problem I've had is when one of my clients demanded "cross-platform".

I had more problems with that sucker than with three others combined. Since I couldn't assume subselects, there was lots of parsed queries that resulted in additional bugs, etc.

Pick a platform, then use it. If the platform is truly free, you aren't "locking" anybody at all, are you?

Re:Congratulations are in order!

[Just Some Guy]

If you think that "PHP" and "KISS" belong in the same sentence (without a negation operator), then you're nuts. Having separate functions (in the main namespace, no less!) for every possible way you might want to sort a list is not simple, reasonable, or the standard accepted way of doing such things.

When you can explain the core language and primary namespace to an interested programmer in under 30 minutes, I'll be glad to revisit the topic. Until then, Python is simple. Perl is even reasonable simple. PHP is not simple in any way, shape, or form (unless you're using the facetious Simple from SMTP, SNMP, and other horridly complex standards).

Re:Congratulations are in order!

[Anonymous Coward]

Addressed here.

Re:Congratulations are in order!

[masklinn]

Hey, spaghetti code is good... well, spaghettis are anyway

Re:Congratulations are in order!

[masklinn]

I don't remember seeing bitwise operations in Javascript...

Shame, that would be really fun, especially if we managed to create some sort of crappy sound out of the browser...

Re:Congratulations are in order!

[masklinn]

You could print out the representation (graph) of the sound waves couldn't you?

Re:Congratulations are in order!

[bhtooefr]

Come to think of it, I could print out the hex bytes that make up the WAV file, and use OCR to take them in...

The graph wouldn't be much work from there, though - once I have the hex bytes, it's trivial to make a graph...

Re:Congratulations are in order!

[dodobh]

The trick is to be able to have an abstraction interface between the database access and the rest of your code.

function get_info($dsn, $query, $parameters) {
}

Now the bulk of your code not know what DB you use.
tie your SQL very tightly to the database. Put an abstraction layer between DB specific code and non specific code. Works well.

Re:Congratulations are in order!

[Evro]

Speaking from first-hand experience, there comes a point where you reach the limits of Postgres. My company is fast-approaching that limit, and throwing more hardware at the problem is not the ultimate solution. Postgres is not a perfect piece of software - the fact that the VACUUM command exists is proof of that. Ever try vacuuming a 1+ terabyte database with 2000+ tables? In the end you save more time by dumping the entire db and restoring it.

Coding for one database rather than creating an abstraction layer is a horrible, horrible idea, unless you agree from the outset that you will never change the database backend. And even then, if you rely on the php built-in commands for database interaction, there's no guarantee that those commands won't change in the future - they have in the past: PHP has renamed a few functions to keep a more uniform naming structure. While the old names still currently work, in the future they may not. Even if they stay the same, maybe they'll introduce new functions that handle the data better, in which case an abstraction layer saves you tons of time.

If you agree never to update or change your system's backend then coding for a specific language and database backend may be appropriate. But if you care about designing extensible, upgradeable software that is platform-agnostic, a layer of abstraction is necessary. If I was interviewing someone and they presented me with sample code riddled with "pg_connect()" calls rather than abstracting that into its own library, my first question would be "tell me why it is bad to do this."

Re:Congratulations are in order!

[Anonymous Coward]

forth

(Que flames in 5..4..3..)

Re:Congratulations are in order!

[Anonymous Coward]

Ok, I'm with the slow-to-catch-on part, but what's this about people not getting it? The concept had to be one of the simplest ever designed. (Thus the reason why it's so common across web scripting languages.) Here is your HTML, here's a bit of Unix scripting langauge. Simple, see? :-)

Well, for instance I looked at PHP for 2-3 weeks, then I was zoped and never looked back. Way more useful, complete, better designed and so on. Slower maybe, but not I'm not saying it's the best choice for slashdot. It is for me.

Re:Congratulations are in order!

[MostlyHarmless]

You would be surprised. The PEAR DB API is vastly slower than the lower-level mysql_ calls. It introduces several layers of indirection, quoting, etc., which will be noticable if you have to run many small queries at once.

It has some quirks, too; who would have thought that, for a certain query that needs to run many times with different parameters, using PEAR's prepare function would be slower than interpolating the parameters yourself and building a new query each time? I've been told that using ADODB (another DB-independent API for PHP) induces less overhead. But I digress...

I agree that theoretically, a DB abstraction is just a mapping of calls, and not making use of the proper abstractions is usually a Bad Thing. Making use of a crappy abstraction, however, is a Worse Thing :-p.

Re:Congratulations are in order!

[stephenbooth]

Strange that you should mention PHPBB, the second person to do so. Last year one of my collegues and myself played a big part in porting PHPBB from MySQL to Oracle (building on some earlier work). The major problems didn't come from the SQL (although there were problems there) but rather from the use of non-ANSI datatypes which MySQL used and PHP supports.

We were porting it mostly because, like many enterprise level users, we already had a lot of Oracle inhouse so the marginal license and support cost was virtually nil and we already had the skills to support Oracle (so no retraining costs). The cost of not porting it and so having to run MySQL would have been prohibitive (support, training &c).

Stephen

Re:Congratulations are in order!

[daeg]

PHP 5.1 has a new module going in for a consistent database API. It is not an "abstraction" layer per se, however, any database with a supported driver (all the major ones already have one) can be dropped right in. Check out PDO: http://www.php.net/pdo -- more links are in the comments at the bottom, including a PDO wiki page. It is also in PECL right now and you can download compiled binaries for Win32 versions of 5.0 or higher; source is available for unix systems. The only major thing that I know of that it is lacking now is support for scrollable cursors, but Wez is working on that. My current app uses PDO and it is lightyears faster than PEARDB and ODBC. Plus it is OO based!

Re:Congratulations are in order!

[Anonymous Coward]

I'll tell you why it is a good idea to do this, SPEED and portability.

All I have been hearing is writing PHP so you can switch your database from MySQL to something else. This shows me that EVERY SINGLE ONE OF YOU have no idea on how applications are suppose to be written. I hate to tell you, but coming from someone who does this stuff for a living, you write your database first, FIRST, then use PHP, CF, .net, whatever to write the web app.

If you spend the time in using the features of the database to write business rules and processing engine, it will make not only coding the application with PHP, CF, whatever alot faster and easier, but also porting the application to another language like PHP,CF, whatever easier and faster because all of the hard stuff is at the database layer.

Also what happens when I use Excel or Access to directly connect to your tables and insert data? If all of your business logic is at the PHP layer, I can really screw things up. On the flip side though, if I use check constraints, triggers and defaults to enforce business rules, I don't care what your use to insert data because the database will throw an error back if the wrong type of data is inputted.

From your post, if you presented me with business logic and engines that were written in PHP and not at the database level, I would laugh in your face. This sort of behavior comes from the fact that most PHP programmers program with MySQL, which is SHIT to begin with. Use a real RMDB like Oracle, PostgreSQL, or SQLServer.

Re:Congratulations are in order!

[rho]

Good points in your reply. Thanks for that.

If I was interviewing someone and they presented me with sample code riddled with "pg_connect()" calls rather than abstracting that into its own library, my first question would be "tell me why it is bad to do this."

Well, it all depends, doesn't it?

First, there's a difference between coding an abstraction layer that facilitates interaction with your database, and coding an abstraction layer that handwaves away the peculiarities of any particular database. For example, if you have a function called "get_data_from_postgres_and_format_table()", that's an example of the first situation. Another way to do it that follows the second would be "format_table(get_data())", where the gathering of data from a database is generalized across databases, and the formatting of tables is done as a function of the application.

In other words, putting all those "pg_connect()" calls behind something that helps you develop your application faster is a good thing. However, it does not neccessarily follow that then formalizing a set of database calls that dissolves the differences between PGSql and MySql and Interbase is also a good thing.

I can use Drupal as an example, since I know it fairly well. The "Node" is the basic structure of the framework, and modules that extend the basic node must have the same ID as the node base. When presented, the node is a JOIN of the primary node and the extended node's tables. In Drupal, the work coordinating these is done by having, conceptually, a "get_me_the_next_node_id_number()" function and preventing future calls from grabbing that same number. This is all done in PHP, rather than simply saying, "Inser this and that in table 1 and table 2, and make table 2's ID equal table 1's ID."

My arguments also do not apply to a good 75-80% of Web-based applications, most of which simply use the database as a less-dangerous way of accessing and storing data in the filesystem. They would be equally well-served by flatfiles, but don't because of the security issues inherent in allowing a Web server process to write to the filesystem. I'm not terribly familiar with PHPBB, but I imagine that there are multiple workarounds hand-hacked in PHP to accomodate those folks whose MySQL wouldn't know a foreign key from a stored procedure. All of these things introduce bugs, performance issues, and maintainability issues just as severe as any dependance on a single database vendor does--they're just different.

I recognize that there are problems inherent in dealing with, say, PostgreSQL, but those do not go away with database abstraction. All database engines will have some level of maintenance issues--the benefit from depending on a single database is that you can codify the procedures in your documentation and maybe even your code--a cron-run script that automatically VACUUMs the database at 2:30AM--rather than weaseling out with a "The care and feeding of your database is beyond the scope of this document" disclaimer.

Finally, this really only applies to larger PHP projects. I've found that when PHP is used to do something quick-and-dirty, it's almost always hard-coded to whatever database the programmer happens to have. It's only when that quick-and-dirty program starts to become popular does everybody clamor for "database independence", and then the author will comply. So, as an application grows in features and complexity, rather than leaning on the database to do it's job, the programmer doubles his work by re-inventing ideas, and re-learning mistakes, that database vendors dealt with 10 years ago, such as concurrency and performance issues. So, ironically, the best design decisions are made when it was just a little hack, and "creeping CS-isms" strike it as it gets more widely used, crippling the speed at which development can take place.

Re:Congratulations are in order!

[rjshields]

I don't remember seeing bitwise operations in Javascript...

Look a bit harder.

Re:Congratulations are in order!

[Anonymous Coward]

Suggesting that it's incomprehensible how some people didn't get it is a bit assuming... For programmers, or people with time to learn it, maybe, but aren't you overlooking the possibility that some people are impatient, and that surfing through several hundred pages of how-to manuals in a time when PHP wasn't so well known, was impractical at best, difficult at worst? On that note, I think that's maybe why there are so many pre-packaged PHP kits...

Re:Congratulations are in order!

[Anonymous Coward]

Have to say I disagree here. You're obviously a dba, or at least too bloody database-centric.

Databases are for storing stuff. Constraints and validation sure, but business logic doesn't belong in the database layer imho.

Of course you shouldn't sprinkle it around in a dozen web pages either, it belongs in it's own logical layer, distinct from the presentation logic.

Re:Congratulations are in order!

[cvd6262]

Why climb to the top of a mountain when a helicopter is clearly the correct tool for that job?

Re:Congratulations are in order!

[dubl-u]

I've never understood the fanaticism of database abstraction. There's good reason to hardcode to a specific database, especially if you hardcode to a Free database like PostgreSQL.

Some of the fanaticism is more on general principles, and sometimes people can get needlessly dogmatic about that, which I agree is annoying. And certainly you can get benefits from departing from the path of vendor neutrality.

But much of the vehemence you hear certainly comes from people who have spent many weary hours switching an app from one database to another. It's no fun, and it feels like a waste of time. Especially so when the there was no good reason to write a tightly coupled app in the first place.

So my advice is: write your app as vendor-neutral from the start. Where specific performance or feature requirements make it much cheaper to couple your design to a particular version of a particular database, go for it. But always keep in mind the cost of that, which is reducing the future agility of your project.

Re:Congratulations are in order!

[FuzzyBad-Mofo]

Isn't ADO Windows-specific? Or is this something else?

Re:Congratulations are in order!

[telbij]

Coding for one database rather than creating an abstraction layer is a horrible, horrible idea, unless you agree from the outset that you will never change the database backend.

I agree that database calls should not be sprinkled throughout code for anything over 500 lines of code. But I don't particularly like the idea of full on DB abstraction such as PEAR_DB. Why? Because unless you are expecting to go cross-platform, you can waste a lot of time to support portability that will rarely be necessary. And of course it's never fully portable anyway due to non-standard SQL, etc.

With most web applications I always have some kind of canonical internal data structure (generally object-based, or possibly just hashes), and then create interfaces off of that to edit the structure via HTML forms, and to save / edit / restore from a database. Within the database maintenance code I give only minimal consideration to DB portability issues. If I want to port to another DB then there may be some work to do in that small portion of the application. In return I get a better performing application with shorter development times.

Of course my opinion reflects working on largely internal systems. If you are writing a commercial product or open-source project for wide distribution, then database portability can be a deciding factor for adoption of your product.

Re:Congratulations are in order!

[jadavis]

There are reasons for database-specific code: not all databases are the same.

The "lowest common denominator" data storage/retrieval does not actually mean you can use your database like a Relational Database Management System.

If you don't want your database to do what Relational Database Management Systems do, and you're just going to use it for flatfile-like queries, why not just use SQL-Lite? SQL-Lite has familiar syntax, but can be bundled with the application. You don't have to worry about what database the user has installed.

If you want a RDBMS, get a good one, and code specifically for it if you want. It will save a huge amount of application code. The ideal application does not redesign all of the features that it needs at the application level just to achieve the mystical "db-agnosticism". The ideal application design says: "These features already work in my database. I'm going to use my database."

Re:Congratulations are in order!

[Anonymous Coward]

um, php doesn't require that you "hardcode" anything. Hardcoding is the result of bad programming practice. PHP, like any other language, can be programmed poorly or properly.

php provides access to the mysql(postgres, mssql, oracle etc) interface. If you want to abstract that into a data access object, the programmer can easily build a data access class in php. I know because I did it.

You can also include a configuration file at the top of every script which sets the database variables so you don't need to "hard code" them.

Just put the config file in /etc or some other place outside of your include and web root directories, so you don't move it around with code changes, and it's not browsable, and you are good.

A lot of open source php projects put the config file in the web root. This is extremely dangerous since if the admin misconfigured the server or phps is enabled, the source code and data access username and password can be gotten easily.

PHP's "job", if you will, is to provide an interface to system libraries and programs. It does this. It also provides OOP capability so the programmer is free to build his own classes. Put data access and this capability together and you have your db abstraction class.

It's really up to the programmer to make this happen, since if the PHP folks did it for you, it might not be right for your application. This is where the programmer steps in and programs.

l8,
AC
(not involved in the PHP project, just a user)

Re:Congratulations are in order!

[jadavis]

Agreed!

There are two cases:
(1) You application's data needs are simple. Any ol' database will be more than good enough, it doesn't need to be an RDBMS. In this case, just develop for and bundle SQL-Lite and then you don't care what people have installed or not.

(2) Your application requires a Relational Database Management System. Choose one, and program for it. Don't chase phrases like "DB-Agnostic" by reimplementing features and capabilities in your application that are already implemented in your database of choice. Those features are in the database for a reason.

Re:Congratulations are in order!

[EraserMouseMan]

90% of apps don't need to use custom db functionality or need to be ported to other databases. On rare occasions you need generic queries/db connectivity. On rare occasions you need to tap into the custom db functions. Just do what the situation calls for and don't preach a "One-Db-Technique-Fits-All" gospel.

Re:Congratulations are in order!

[Anonymous Coward]

Amen to that brudda.

You are wrong about one thing tho... PostGreSQL isn't superior to MySQL because MySQL is haphazard, MySQL is just a simple lightweight database.

It isn't really designed to be "enterprise class".

PostGres on the other hand has serious transactional and integrity capability, not to mention that you can write stored procedures in almost any language you so choose.

If it's done right it's also amazingly fast, in fact way faster than MySQL for anything other than simple selects, though even that is very debatable.

Selects done with a stored procedure are simply blazing.

I won't get into flamebaiting mysql evangelists, but my own tests have shown that mysql is severely lacking when it comes to database updates where more than 20 concurrent users are involved in the same table. The excruciating response times on mysql/php forum sites that get busy is perfect evidence of this. I bet all are sending uncompiled sql queries over the wire or to a unix socket, and improper locking techniques used.

Maybe mysql has come a long way since then, but PostGreSQL is definitely not slower, when the playing field is leveled, and both databases used to their maximum capability, as opposed to using PostGres like you would mysql. This is typically how the MySQL benchmarks are created. Queries in code sent across the wire... it's laughable.

You can see for yourself. Build out a PGSQL and a MySQL on the same type of box. Build two web apps that do the exact same thing, include insert, update and delete operations, not just selects ; ). Use compiled stored procedures written in C on postgres, and do mysql however you like (LOL). MySQL will get chewed and spit out the tailpipe in a capacity test.

l8,
AC

Re:Congratulations are in order!

[julesh]

You can easily code your SQL to be database specific if you need it that way, but that shouldn't in any way stop developers from using a generic DB access API

I have yet to find one that actually fulfils the promise of database independence without getting in the way of being able to write useful queries. The problem is that every different database server out there has a different way of doing something.

Take automatically assigned row ids, for instance. I know at least 3 different syntaxes for specifying these in the CREATE TABLE statement. Sometimes your INSERT statement has to include the column but set it to NULL, sometimes it has to be not specified at all (i.e. you must give a list of columns to insert that excludes the automatic one). How about adding an interval to a date? Or specify dates at all (MSSQL seems to require dates to be specified in the format defined by the server's internationalisation settings -- fucked up, but that was the only way I could make it work last time I developed for it).

The only way to solve these problems is just to abandon SQL and build queries from a higher level specification. There are systems that do this (e.g. MS's "ADO"), but I've never found one I actually like using -- it's much more convenient to code DB specific SQL and then port if you need to work with a different DB server.

Re:Congratulations are in order!

[AKAImBatman]

Why do you insist on confusing database specific SQL with database specific APIs when I clearly pointed out that the latter is all I'm asking for? That is a REALLY annoying thing to do. Not to mention that it does zip to help the conversation.

All I asked for is a simple API for db_open, db_query, db_commit, etc. instead of having mysql_open, mysql_query, postgresql_open, postgresql_query, etc, etc, etc.

Re:Congratulations are in order!

[Anonymous Coward]

issue #1
a terabyte database belongs on DB2 in a mainframe, not a "little server". That's what big iron is for, giant databases.

issue #2
2000 tables? that sounds like a design issue. If you are partitioning the data this way (as I hope this is what you are doing) a zillion tables is not really the best way to go about it. You may want to go Big-O for transparent partitioning.

It sounds like you need an industrial strength db such as db2 or Oracle. PostGreSQL is the bomb, for what it is, an open source project, but you may have outgrown it and be ready for a bigger gun.

l8,
AC

Re:Congratulations are in order!

[Knightking]

That's coming (finally) in php 5.1 with PDO.

Re:Congratulations are in order!

[julesh]

Maybe I didn't make my point clear -- the question I intended to ask is why is a database independent API even useful if the code you're passing to it is DB specific anyway?

Re:Congratulations are in order!

[Lew Payne]

"... one wishlist item that I would like to see in PHP is Abstract Database Access. It's not really a good thing to hard code your application to a specific database, especially if it's a redistributable application."

Are you speaking for yourself, or for others? The reason I ask is because I do not want ADA in PHP. I want to code the application to the native database calls, for maximum speed and performance. It's bad enough that our applications have to be clustered as it is. We don't need another "universal, one solution fits all" abstraction layer sucking the performance out of our app.

So, how about if PHP were fitted with BOTH mechanisms? That way, you could choose your abstraction layer and not take away my choice in the process.

Re:Congratulations are in order!

[AKAImBatman]

Maybe I didn't make my point clear -- the question I intended to ask is why is a database independent API even useful if the code you're passing to it is DB specific anyway?

For the reason I originally stated. It's easier to fix the SQL to be portable than it is to fix every instance of API usage. Plus, the abstract API does not prevent you from tying yourself to the database if you so chose.

This was all in my post.

Re:Congratulations are in order!

[mixmasterjake]

Just because you use a good abstraction strategy doesn't mean you have to actually implement the code for every platform. I just write for the one that I need at the time & I can use as much platform-specific code as I want. But, having a strategy in place so you can plugin a new DB later is comforting.

As much as I hate to give up my SQL code, persistance layers for PHP like Propel and PEAR DataObject seem to be maturing nicely. DB abstaction becomes (in theory) a mute point. I'm really anxious for PHP 5 to become more widely installed so I can take advantage of these technologies that are already in production status for Java and .NET code.

Re:Congratulations are in order!

[julesh]

My experience has been that such API conversions can usually be handled by regexps, whereas the SQL conversions required are much more complex. But I guess your mileage varied...

Re:Congratulations are in order!

[EntropyEngine]

For me, PHP saved my business. I've recently started developing applications that make solid use of the Pear and Smarty libraries, as well as class-based object-oriented principles. This past week I've started using the GD.lib for building images on the fly. There's not much that PHP can't do...

Re:Congratulations are in order!

[njcoder]

"In other words, putting all those "pg_connect()" calls behind something that helps you develop your application faster is a good thing. However, it does not neccessarily follow that then formalizing a set of database calls that dissolves the differences between PGSql and MySql and Interbase is also a good thing."

No, you're right, but by abstracting the databse calls like that you have a single point to make changes if you ever want to switch rdmb's in the future. Which does happen. So you call format_table(get_data()) and you don't care what database you're hitting. If you change to oracle or mysql in the future, you just have to change your get_data and maybe your format methods instead of going into every file that has pg_connect in it and changing it.

I think this is a point you understand based on what you said, you just didn't explicitly say it.

Re:Congratulations are in order!

[davidfree]

I cant wait for IBM to bring PHP to the as400 as a native environment,

but have all the security issues in PHP be solved yet?

Re:Congratulations are in order!

[Anonymous Coward]

Take a midol.

Re:Congratulations are in order!

[melstav]

Well, maybe for the same reason that This guy wrote a webserver using Postscript.

Re:Congratulations are in order!

[Bitsy Boffin]

As others have said, there is PEAR::DB and adoDb, but I dont' like either of them very much. PEAR is just plain klunky (and heavy) IMHO, and ado is a bit wierd if you ask me.

It's not hard to write your own abstraction layer though, that way you can get it just how you like it :)

Re:Congratulations are in order!

[Ruphuz]

There is PDO for PHP 5.

Re:Congratulations are in order!

[AaronLawrence]

MSSQL seems to require dates to be specified in the format defined by the server's internationalisation settings

Apart from actually passing an appropriate Date type to the API (ODBC/ADO etc), there is a simple solution:

'yyyymmdd hh:mm:ss'

Some more info at, e.g. Tibor Karaszi's page

Re:Congratulations are in order!

[namekuseijin]

So that you can feel you have a big penis?

Same for coding apps in assembly or OSes in Python... it can be done, though isn't really worth the trouble and will feel very awkward.

Re:Congratulations are in order!

[julesh]

Apart from actually passing an appropriate Date type to the API (ODBC/ADO etc), there is a simple solution:

'yyyymmdd hh:mm:ss'

Ah, that explains it. I was using "yyyy-mm-dd hh:mm:ss", which is understood by every other DB server I've ever used, but which MSSQL failed to understand. Why doesn't it work with accepted standards?

Re:Congratulations are in order!

[shutdown -p now]

And what does the designer of such an "ideal application" say when the management decides they've paying too much for Oracle support, and tell him to migrate the software to MS SQL?

Re:Congratulations are in order!

[1110110001]

BTW there's already an extension for that in PECL: http://pecl.php.net/package/oggvorbis

b4n

What's not to get?

[Enigma_Man]

Seriously, honest question. What's not to get about a language? It's just another language with different options, styles, formats, and uses...

-Jesse

Re:What's not to get?

[i.r.id10t]

Shouldn't your sig be "CLOAD" and not "LOAD" ? I have my TRS-80 manuals here on my desk if you need a new reference....

Re:What's not to get?

[Anonymous Coward]

PHP is unique. It has highly advanced rooting and worm features.

Re:What's not to get?

[clifyt]

Looks like perfectly good Vic20/C64/C128 loading to me :-)

Then again, it could be that old Tandy / Commodore rivalry I always saw in the old computer users groups of the 80s. Don't worry, we always kick your Trash-80 asses.

Re:What's not to get?

[Skater]

REGISTER_GLOBALS is one thing to "get". Why was that turned on by default in earlier versions? Everything I wrote before they changed that option requires it to be on because I wasn't aware of the security implications. Nothing I've written that way is on the web anywhere, so it's not doing anyone any harm, and I've learned more about security since then - but what about PHP coders that have released code requiring it to be on? Having REGISTER_GLOBALS set "off" right from the start would've saved a lot of headaches, because it would've helped force better programming technique and maybe even better data validation.

Re:What's not to get?

[urmensch]

Perhaps I'm ignorant, but isn't LOAD for C64?

Re:What's not to get?

[Anonymous Coward]

Don't mess with the C-64 crew.

Re:What's not to get?

[Enigma_Man]

Couldn't the trash-80's set themselves on fire? :)

-Jesse, still uses his C-64 on occasion.

Re:What's not to get?

[markild]

I had the exact same problem when they released the first version without the register_globals being set to on as default. I think it was like 4.1 or something.

Anyways, it was then I discovered that it might be a good idea to read the readme files, and security threats. They had long been aware of the threats that it posed to have the option turned on, and they had warned us. The same thing goes for a lot of the big changes from php4 to php5 as well.

Re:What's not to get?

[chill]

Shouldn't your sig be "CLOAD" and not "LOAD" ? I have my TRS-80 manuals here on my desk if you need a new reference....

The C-64, and probably VIC-20, versions were LOAD "*",8,1 for the attached disk drive.

-Charles

Re:What's not to get?

[i.r.id10t]

Well, as long as we are going way OT, I have a Commodore CP/M kit here on my shelf as well.

Do these antiquities have any value?

Re:What's not to get?

[ajs318]

REGISTER_GLOBALS is not insecure. The default order of fetching -- cookies overwrite sessions, POSTs overwrite cookies, query strings overwrite POSTs -- is potentially insecure. Somebody could use a URL something like http://myisp.co.uk/~myspace/foo.php?auth=1 and, if you just relied on the value of $auth without regard to where $auth was coming from, you might get hurt.

It did say in the manual that this would happen and how to get at the different data sources if you cared. {And you can do sneaky stuff of your own, like if ($_GET["auth"]) { include "crash_browser.inc.php"; exit(); }; if you really want}.

Often, you don't really care where your data is coming from anyway. I personally would have had POSTs overwrite query strings, cookies overwrite POSTs and sessions overwrite cookies. That would have dealt with it even more simply -- though it probably would have made debugging a 'mare.

Re:What's not to get?

[homerules]

Those exploits pertain to the scripts not the language.

Re:What's not to get?

[Anonymous Coward]

Yes, there are plenty of people who would pay real money for such antiquities. Try an online auction.

Re:What's not to get?

[Skater]

Okay, thanks for the info. Still, it was a frustrating change since most installations now have switched.

As for not caring where they came from: I spent a lot of time writing a script that checked the sources of the variables (among other things) on a "new link" submission form in an effort to reduce spammers - but they still spent the time circumventing all of the restrictions I had in order to flood my database with links to adult websites. Apparently, they didn't read the part of the page that told them that I verify each submitted link is related to the site I run before it gets posted to the web.

So, after all the time I spent thinking about submission methods and the other related issues, they still spammed my database. I learned it's like a lock: if someone wants something badly enough, they'll get it. Still, I think raising the bar was worthwhile - if nothing else it slowed them down and made them waste even more time and money on a fruitless venture.

Re:What's not to get?

[ahdeoz]

You can set the order in your php.ini:

variables_order = "EGPCS"

Where
E = Environment
G = Get
P = Post
C = Cookie
S = Session

Good for them.

[Willy on Wheels]

I have been an avid user of php, I have even made my own website using PHP. It is so good that big sites such as mine use it. For all serious developers, PHP is the best choice for all php programming.

Re:Good for them.

[donnyspi]

"PHP is the best choice for all php programming."

That's not saying a whole lot :-). I know what you meant though and I agree that PHP is great.

Re:Good for them.

[generationxyu]

PHP is the best choice for all php programming.

You're absolutely right. I tried to do my PHP programming in BASIC once. Bad idea.

Re:Good for them.

[Enigma_Man]

All you whippersnappers, I do my PHP in assembly, and I like it!

-Jesse, not really old, but do like/use assembly daily.

Re:Good for them.

[elrous0]

Hey anyone remember learning PHP Cobol back in school?

-Eric

Re:Good for them.

[Anonymous Coward]

I do not think he meant what you think he meant.

Re:Good for them.

[foobar_fred]

My boss asked me to write some windows drivers in PHP. They were "PHB-PHP-PNP".

Re:Good for them.

[the quick brown fox]

You joke, but it's been done.

Re:Good for them.

[John Bokma]

"PHP is the best choice for all php programming." How do you want to program PHP without PHP? But serious developers should give PHP some serious thought. It's certainly not always the best option, and I doubt it often comes close.

Re:Good for them.

[fucksl4shd0t]

I do my PHP with two dry sticks.

Re:Good for them.

[MntlChaos]

By writing a Perl script, and piping the output through the php command, of course!

I don't really like PHP that much...

[Anonymous Coward]

What is so exciting about it? I can't find a single situation where it is better to use PHP than other programming languages. Why would anyone love PHP?

Re:I don't really like PHP that much...

[Peter Cooper]

It's not "exciting" but PHP is one of those languages that's successful and useful because of its marketing and "who knows who". You won't find many hosting companies that won't allow PHP scripts to be run on their servers.. whereas better languages like Python, Ruby, etc.. all have rather bad support with ISPs. The start of the problem is that most ISPs won't support FastCGI, and that's the primary way these other languages should be deployed on servers nowadays.

Re:I don't really like PHP that much...

[sffubs]

PHP is good because it's easy. It might often not be the most sophisticated, structured, or easily maintained language, but it is often the quickest and simplest solution to a problem. In that respect it fills an important niche.

Re:I don't really like PHP that much...

[Anonymous Coward]

How about:

Fast, Easy, Free, not tied down to an OS.

Re:I don't really like PHP that much...

[flatt]

Try this:

What is so exciting about it? I can't find a single situation where it is better to use [Language X] than other programming languages. Why would anyone love [Language X]?

Every language has both strong and weak points. PHP is extremely easy to learn and works great for both web programming and simple command-line purposes. That is unless you are just trolling. (Why does PHP hate the internet?)

Re:I don't really like PHP that much...

[Anonymous Coward]

Amateur programmers, mostly.

If you don't know a damn thing about web apps, PHP is easy to use and has a big community.

*shrug* I think PHP is an awful awful language.

The choices for function names, the global variables, the terrible value/reference confusion (still present in PHP5), the Java-like cruft, the lack of any decent metaprogramming facilities, the php.ini which means every installation is potentially different...ug. What a headache.

Re:I don't really like PHP that much...

[generationxyu]

Yeah -- find a webserver running PHP My biggest problem with PHP is that it makes it easy for novices to write code that runs on webservers, open to the world, taking data from untrusted sources, without the slightest inkling of anything security-related. Hop on bugtraq for a few days to see what I mean.

Re:I don't really like PHP that much...

[masklinn]

The start of the problem is that most ISPs won't support FastCGI, and that's the primary way these other languages should be deployed on servers nowadays.

That, or mod_perl/mod_python style

Re:I don't really like PHP that much...

[Peter Cooper]

Agreed, but mod_perl often relies on a lot of work in the Apache configs, and most shared hosting companies don't let you get that granular. Even when they do, I always "feel" like mod_perl is a bit of a kludge when being used on smaller apps.

Re:I don't really like PHP that much...

[Leroy_Brown242]

Yeah, for people like me, it's perfect.

I don't want to learn languages and become a programmer. I just want to do something dynamic on my web site. So, PHP allows me to get that done, without having to learn much.

Re:I don't really like PHP that much...

[nacturation]

It's not "exciting" but PHP is one of those languages that's successful and useful because of its marketing and "who knows who".

So it's successful because of its popularity? No flame, but isn't that a lot like Windows?

Re:I don't really like PHP that much...

[nacturation]

Windows is good because it's easy. It might often not be the most sophisticated, structured, or easily maintained operating system, but it is often the quickest and simplest solution to a problem. In that respect it fills an important niche.

Couldn't resist. ;-)

Re:I don't really like PHP that much...

[Anonymous Coward]

I don't want to learn how to drive, I just want to go places in my car.

Re:I don't really like PHP that much...

[bsytko]

Its exciting as Perl, Java, Python, or whatever else you want to use. You would love PHP if you build small apps that just get the job done. You don't need to implement a special MVC architecture if you don't want to. PHP is known for doing things quickly. If you need an app to update some news or something, you can throw it together in PHP in little more than a day. Its not that its better to use PHP than other languages, its that it can be used to do things quickly.

Re:I don't really like PHP that much...

[eric_brissette]

So you're from Boston?

Re:I don't really like PHP that much...

[RCanine]

I don't know what you're talking about. While driving down the freeway I see all sorts of billboards with smiling people that tout, "I <3 my PHP!" It's obviously caught on and become way mainstream.

Re:First AC

[AKAImBatman]

What the hell is PHP?

Probably a troll, but just in case anyone else doesn't know: PHP is a scripting language designed for generating dynamically created web pages. It functions by mixing its scripting in with the HTML, thus allowing programmers to reuse existing page designs. The scripting APIs are centered around those commonly used on Unix systems. PHP is usually bundled with Apache, so no installation tends to be required.

PHP Homepage

Congratulations PHP

[GnuVince]

You've done such a wonderful job that it's time you stop now and let something better take over :)

Re:Congratulations PHP

[Usquebaugh]

Yep, but it'll take another 10 years before the peons get it.

Re:Congratulations PHP

[rho]

Yeah, this sounds like what the PHP folks were saying about Perl something like 6 years ago. I know you were tongue in cheek, but really--isn't language bigotry a pretty old joke by now? Perl is still around; PHP will still be around; and Ruby-on-rails will still be around when SexCodeSuperFunNerds arrives to "displace" it.

Re:Congratulations PHP

[Anonymous Coward]

thank you

we have been searching for a cool name for our project we will be springing on the net soon

awesome

thanks again

Re:Congratulations PHP

[Black Perl]

isn't language bigotry a pretty old joke by now

You're one of those people who don't get it. This is not a language issue. In the not-so-distant future, developers will think it crazy not to use an MVC web framework for their web applications.

Ruby on Rails just happens to be first with an elegant, easy-to-use, true-separation-of-concerns, MVC web application platform.

The Java, Python, and Perl (Catalyst) folks have seen the light and are busy working on Rails-style frameworks. Seems like the PHP community hasn't seen the need yet.

Re:Congratulations PHP

[StandardDeviant]

Huh? Struts far pre-dates RoR and I'm sure other examples could be found as well of MVC web frameworks. Ruby is far, far from being the first mover there, whatever other virtues it might have. And, fwiw, there is at least one MVC PHP effort that I'm aware of, Mojavi.

Re:Congratulations PHP

[Peter Cooper]

I consider this a good thing. The RoR community is of a decent size where development is moving on at a steady pace and documentation is, mostly, plentiful.. but not big enough that you're flooded with thousands of third-world developers coding at 10 cents a line. Not that the third-world developers are a particular problem.. people who think they can code in the West are also a major problem as they tend to quote peanuts and end up costing their customers big time.

Re:Congratulations PHP

[Anonymous Coward]

umm. no-one said RoR is the first MVC framework. Its just the first one that's made for humans.

Re:Congratulations PHP

[rjshields]

something better

mod_python, anyone?

Re:Congratulations PHP

[rho]

n the not-so-distant future, developers will think it crazy not to use an MVC web framework for their web applications.

You know, I heard the same thing about Java back in 1996 or so.

Don't get me wrong, Rails looks decent enough, but neither is it a panacea. You can put together a really fast RSS reader, or a DB-backed recipe application, but these are trivial applications. Solving trivial problems elegantly isn't worthless, but thus far I haven't seen any Rails projects that compare in scope to something like Zope, or Drupal or even PHPBB.

Going through the various How-Tos for Rails, I keep saying to myself, "...or, I could just download foo, which is written in Perl/PHP/Python/AWK, but already works and is proven and does the same thing." PHP hasn't seen the need for copying Rails because they have a robust and featureful set of applications already. Dropping everything and chasing the next sexy thing might be entertaining, but it doesn't do much to help me, the working Webmaster.

I guess I'm just suspicious of using MVC (or OOP, or some other trendy buzzword) as a talisman. It smacks of cheerleading, and accusing people of "not getting it" doesn't prove the point.

Re:Congratulations PHP

[StandardDeviant]

Ease is in the eye of the beholder, and exists in more than one axis. What does switching to Ruby or Python buy me that C++/Java/Perl/PHP don't already have? Fah. Fad-ism sucks in pop-culture, and it sucks in IT as well.

Re:Congratulations PHP

[prockcore]

Ruby on Rails is great, but it really needs some time to mature. There aren't any books on it.

Things are also slightly broken. Using ":scaffold" works but "script/generate scaffold" doesn't get the names right.

The whole pluralizing tables thingy is waay too confusing, and the method for turning them off doesn't work for half the scripts.. so you end up with singular controllers but pluralized models.. breaking everything.

Ruby on Rails will be great in 5 years. Right now it's waay to immature to be used for anything important.

Re:Congratulations PHP

[Black Perl]

You're don't seem to be familiar with Rails. Struts is nothing at all like Rails.

Now if you had said Spring instead, you'd be getting a lot closer.

Re:Congratulations PHP

[Tablizer]

Ruby on Rails just happens to be first with an elegant, easy-to-use, true-separation-of-concerns, MVC web application platform.

RonR is still too new. It does simple things quick, but users can be demanding. Let's see how it stands up to complex requests. What works well for simple does not necessarily work well for complex.

Re:Congratulations PHP

[AmVidia HQ]

That's because you, my webmaster friend, do not write your own web app and just use what's out there. I do too, I started with phpbb and wrote a search engine around it (http://isohunt.com/), and have realized how repetitive and tedious writing web application interfaces in raw PHP is.

Rails is hyped for a reason. I don't care about MVC or OOP, as long as it's a modular and transparent framework with clean interfaces. The sophistication of Ruby's language constructs and Rails' clean design seems to be a powerful combination.

This is only from what I've skimmed from Rails' docs (which are well written and complete), so don't take my word for it. Others who have first hand experience with Rails please chime in. I'm especially interested in real world performance (compared with PHP) of RoR. Ruby's lack of opcode cache concerns me regarding performance. Perhaps it doesn't matter with persistence in Fastcgi.

Re:Congratulations PHP

[Anonymous Coward]

Sounds to me like someone hasn't run across Smarty yet.

Re:Congratulations PHP

[hawk]

Sure.

But real programmers will *still* be using Fortran . . .

:)

hawk

Re:Congratulations PHP

[Fweeky]

"Ruby's lack of opcode cache concerns me regarding performance."

With FastCGI you've just got a Ruby daemon just like any other; it's entirely persistant during the lifetime of the server -- you don't leave the interpreter and reset all that state at the end of each request. This is pretty important with all the setup Rails does with dependency injection, Routes etc.

mod_ruby behaves similarly AIUI; it's a single persistant copy of the interpreter, rather than starting from scratch each time; opcode caching is simply not relevent in these situations since the interpreter is always "hot".

PHP vs JSP

[SamSeaborn]

Congrats to PHP for its success, but I'm one of those who doesn't get it.

I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets.

Not trolling, just saying I'm surprised that Java and Servlet hosting isn't as popular as PHP. I'm obviously missing some key point.

Sam

Re:PHP vs JSP

[Frymaster]

I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets.

but procedural is a valid way to structure your apps... especially for web-based ones where that have, by nature, a page-based model and a very linear flow. you can write serious software using php4 without oop!

Re:PHP vs JSP

[NardofDoom]

The key point you're missing is that PHP doesn't have a rigid OO structure, which is why it's popular, especially for web scripting. People don't want rigid structures if they just want to throw a page together. It also is integrated well with Apache and uses similar control functions to C/C++, so programmers can switch between the languages easily.

Re:PHP vs JSP

[Anonymous Coward]

I suppose you don't "get" C either then.
PHP isn't supposed to be totally rigid OO, it just has OO capability if you want it.

Re:PHP vs JSP

[xannik]

I think the main reason is that OO is just not important when writing simple scripts that are taking information say from an HTML form and inputting into a database or some other simple yet highly used task. Most people that are using PHP on a shared hosting provider will probably not need to use any OO features. Now, the PEAR project for PHP does provide good abstraction for the language and I think makes PHP a much more usable system for higher end projects. I guess what I am trying to say is that for the common joe PHP is simple and gets the job done and if there is an easy way to do something normally people will flock to that solution. And I also think that PHP as of version 5 has become a much more mature option for even high end companies.

Re:PHP vs JSP

[Anonymous Coward]

Whilst I am not sure about the API side, I can say that PHP5 has done really well on the OO side compared to PHP4. I am really impressed with the level of thought, time and dedication gone into the making PHP5 by the entire team. Top notch.

If you have a few days take a look at PHP5, even if it only for curiosity. I did and I am glad. Well done to the developers.

Re:PHP vs JSP

[Chewbacon]

Congrats to PHP for its success, but I'm one of those who doesn't get it. I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets. Some people just can't break away from declaring and typing variables. I agree, it isn't normal and makes me feel like everything I write in PHP is sloppy, but I still get the language.

Re:PHP vs JSP

[FidelCatsro]

You can Declare variables in PHP its not needed but you can do it $blah = 1 ; $String = " " . and you can even give them a type by doing it $floatvar = 1.1.
It's not needed as noted , but if it helps you use the language then it's easy enough to imitate it .

Re:PHP vs JSP

[x8]

I'm surprised that Java and Servlet hosting isn't as popular as PHP.

This is not true at least for those who choose a programming language based on employment prospects....On monster.com there are usually 2 to 6 times as many job openings for jsp than php. Any insights on what indication this might have on a language's popularity?

Re:PHP vs JSP

[barzok]

As others have noted, you don't always need OOP. That OO exists is not a requirement that one uses it to solve every problem presented. Handling input from an HTML form and storing it to a database doesn't really need OO, does it?

Re:PHP vs JSP

[Kristoffer Lunden]

Back in the days, say a few years ago at least, getting JSP and Servlets up and running was a pain, even if you knew and used Java already, and had it installed. And then it was a pain configuring it all. PHP, as I remember it, has always just worked, with ease. No, I don't know how the status is today, and since I don't miss Java I don't need to know. Back then this was important though.

After all that was done, well then it was up to if you liked Java or not. And I've come to realize that Java is a language you either like or not, rarely any in-betweens. I came from Java, so in order to use PHP I'd have to learn a new language, granted it is not hard - and maybe that is the point. PHP is easier. It is not guarded by a lot of "safety syntax", but really, that usually isn't needed. Java is quite powerful, but it is also very verbose and does things the long way around, or at least it did.

I still use PHP now and then, if rarely, but right now I'm looking into Catalyst which seems really promising - it's inspired by Ruby on Rails and Maypole, among other things, but for Perl. I really wish there were some more examples and example applications to look at though, the documentation is pretty good (and there's always the source), but too see how it all should fit together, I'd like to see more from people already grokking it. I've been reading the mailing lists, this perl.com article and some other things, but that is what I am missing.

Perl has become the favourite language. It has CPAN (if Ruby had that on the same level, it'd probably be Ruby). It can do anything, and it doesn't get in your way. It also attracts lots of jokes about readability but that's just people who haven't actually made a serious try to understand.

Re:PHP vs JSP

[AKAImBatman]

I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets.

The answer is: Two completely different markets.

JSP requires a minimum investment in hardware, resources, and server capabilities that PHP does not. JSP also tends to require more backend APIs than PHP, because you try to keep as much out of the JSP as possible. As a result, JSP tends to be the best solution for Mid to Enterprise class systems, while PHP makes a good choice for Personal to Small Business uses.

Does that answer your question?

Re:PHP vs JSP

[dchaos]

I'm surprised that Java and Servlet hosting isn't as popular as PHP.

For us (web design/hosting shop) the choice between php and java came down to the overhead required on shared servers.

Our choices at the time were to use a single JVM to support all shared hosts on a server or use a separate JVM for each shared host.

The second option was out of reach financially (just couldn't afford shiny new servers, we had the servers we had - and had to make them work, and they wouldn't handle running dozens of dedicated JVMs.)

But the first option wasn't all that apealing either. If one site crashed the JVM, lots of client sites came down with it. In addition, there were some security issues with cross-site VM pollution that didn't give us the warm and fuzzy about sharing a single VM.

Don't get me wrong, I'm not anti-java. I had been developing with java for a couple of years prior, and wasn't really looking forward to "stepping down" to php. I liked java then, and still do, and wish it well. I may end up needing it again.

Now, this decision was made a couple years ago, and I'm sure much has changed since then, but I've been happy with the decision to use php. And now with PHP5, much has changed since then.

Re:PHP vs JSP

[Neil Watson]

The lack of rigid structure and thowing a page together are the very things make PHP a potentially dangerous language. When in the right hands PHP is a good tool. However, it does allow for sloppy work.

Re:PHP vs JSP

[killjoe]

What do you mean by "rigid OO structure"? The OO in PHP is not all that different then Python (although it's missing some of the functional programming aspects of python.

Re:PHP vs JSP

[jb_nizet]

I'm surprised that Java and Servlet hosting isn't as popular as PHP

The main reason, IMHO, is that PHP is much more easy to install on a typical Apache web server, and much more appropriate for mutualized hosting.

With PHP (as a module or CGI), once a HTTP request is finished, all the resources (memory, DB connections, file handles, etc.) are given back to the operating system. With Java, the JVM keeps running after a request, and might keep locks on resources without anyone noticing.

This is a key advantage of Java for private hosting, because it makes caching, connection pooling and so on easy to handle. But it must be a nightmare to handle in a mutualized hosting, because any sloppy programmer could eat all your memory and DB connections.

Re:PHP vs JSP

[Anonymous Coward]

I use java a fair bit and would say it isn't nearly as good for website creation. Firstly it is OO. Which websites are not.

Secondly it is SLOOOOWWW!!! It requires a hell of a beefy server in order to run a simple site! Compare that with PHP. Also JSP has a much slower response time to requests.

Re:PHP vs JSP

[ajs]

quoth Frymaster, "procedural is a valid way to structure your apps... especially for web-based ones where that have, by nature, a page-based model"

This is my basic gripe with PHP. It leads the unfortunate user down a path that suggests that each page is its own island, and any attempt to modularize or componentize that is, by PHP's nature, a secondary affair.

Take, as a counterpoint, something like TTK. Here, you are presented with a programming langauge in which you write your code, and a templating system in which you write pages for display and a set of tools for connecting the two.

It's not that a good programmer can't produce a workable system in PHP alone or PHP + other langauges (PHP backed by Perl or Java or C# is quite powerful, in fact), it's just that it seems that the majority of people writing PHP are hobbled by this unfortunate presentation of the language as a "page generator", and thus most of the code written in PHP is rewrite-fodder from day one.

As a templating system, PHP is quite nice, and I'd use it where appropriate.

Re:PHP vs JSP

[SamSeaborn]

Handling input from an HTML form and storing it to a database doesn't really need OO, does it?

I guess the answer is "it depends". ;-)

If I'm doing anything half-ways complex in web-to-db, yes I do want OO. I'll choose OO DB access in the form of Hibernate, JDBC, JBoss and EJBs and XDoclet. And I'll build my UI with an MVC-based JSP/Servlet framework, usually home-grown, but maybe using JavaServer Faces or Struts.

In my opinion, this kind of OO sophistication makes building even half-ways complex projects better.

Sam

Re:PHP vs JSP

[njcoder]

I agree with you. I prefer the Java/JSP/Servlet thing over PHP. It's easier to find cheap hosting for PHP than it is for Java though and I've had to use PHP a couple of times. It's not that bad but I wouldn't want to use it for a complicated site. Lunarpages.com has some affordable jsp hosting packeges. I think it's just 5 bucks more a month than they're normal package.

I can see building the business logic in java and using php to render the pages. I think there's a way to use php to call java objects. Not sure what version that's in or if it's supported by php4 which seems to be the most popular amongst web hosts.

I'm almost afraid to mention this, but one of the big reasons I like Java over PHP is performance. In my own tests I found Tomcat a lot faster than PHP. It wasn't a very scientific test. I had 2 pages about the same html size. The java based page used a controller servlet in my own mvc framework that loaded a header and footer file, did some cookie checking and even connected to a postgresql database on the same machine. The php file only inlcuded a header and footer. No mvc, no database access. The java page loaded about 2x as fast and I had about 2x the throughput of the PHP page.

The test probably wasn't technically fair. I used the latest tomcat build with the most current jdk (1.5). I didn't use apache as a frontend to Tomcat. For PHP I used the latest Apache 1.3 build with the latest mod_php and PHP 4.3.4. The reason for using this setup for PHP is that seems to be the most common among web hosting companies. Apache 1.3 seemed to be what was realling slowing things down because tests with apache as a front end for tomcat brought the numbers more inline. But from what I've seen most webhosts use 1.3 with php because of some threading issues with some php libraries and the apache 2 series of server.

I've also been able to do some neat things with threads in web applications with Java that have increased performance as well. I don't know if that's possible with PHP.

I did my tests not too long after there was the whole Friendster switching to PHP from JSP. I did some digging to get some info to see why the performance would be so bad for JSP. Turns out their architecture was all screwey. They had 50 servers hosting the site. Each server had a Tomcat instance and MySQL instance. They used some home brewed replication scheme to propogate the changes across the mysql instances. Any database write would have to be replicated to 49 other servers. That's gotta put some extra load on the db, especially since MySQL isn't that great for applications with a lot of updates. It's much better for mostly read sites. I remember someone also mentioning that they say a stack trace on a page and there was a Database.class with over 9,000 lines in it. They obviously didn't have a good multi-tiered architecture. That probably hurt their performance a lot. If they had their databases and app servers running on seperate servers they could have tuned each environment better for the task. Good connection pooling would also help, this is easy to setup since it's part of the servlet spec and all compliant servlet containers support it. Apparently the developers were authors of a JSP book which was supposed to give credibility to them being able to design a good JSP site. Unfortantely you need to know a lot more to develop a performant site. Most of the time the bottle neck isn't the application or the lanquage. It's the design or the database. A poorly designed database and queries usually going to bite you in the ass. Set up your data model correctly, do a bunch of explains on your queries to see how they perform and optimize them correctly, seperate your presentation logic from your business logic (this is more for maintainability than for performance), if you're running multiple servers seperate your appservers from your database and you can tune the os and memory for each function and you'll have a good platfo

Re:PHP vs JSP

[Anonymous Coward]

PHP is a wonderful example of the Unix philosophy of "worse is better".

By any technical measure it's a steaming pile of shit. But people find it easier to hack together a potentially-fragile-but-never-quite-breaking-perma nently website with a steaming pile of shit, than to write something robust and enterprise-ready with Java, or to learn a cool-but-tough-to-grok system like Ruby on Rails. So PHP is a great success.

Love it or loathe it, let it be an example to us all of the triumph of the worse-is-better philosophy, the success of open-source code from humble origins, and the promise free software holds out of empowering anyone to write their own software, regardless of how little they know about computer science!

Re:PHP vs JSP

[Splab]

PEAR is rubbish - only thing good about pear is its way to distribute software - I have yet to see an OO package programmed in an easily maintained way.

PEAR is just a set of guidelines for programming, and they dont even adress what really makes code unreadable (think functions with a couple of 100 lines of code and several responsabilities).

If you use PEAR code you wont do high end stuff since your software is busy loading all sorts of drivers it doesnt need.

Re:PHP vs JSP

[Splab]

Thats not declaring:

$string = " 5";
$number = 1;
print $string + $number . "\n";

Prints out:
6
If I told something its supposed to be a string I would prefer the interpreter bitched about it when I tried to use it for something else without explicit typecasting.

I'm not sure if I'm one of those who gets it or not - I program PHP profesionally (oxymoron?) but I really hate the sloppy types in PHP.

With PHP5 you can typehint and the OO part has been greatly improved.

Re:PHP vs JSP

[njcoder]

I've actually found jsp/servlet on Tomcat to be quite a bit faster than Apache/PHP on the same server.

Re:PHP vs JSP

[Lordrashmi]

Having a rigid structure does not prevent sloppy work. I can't tell you how much horrible Java code I have seen in my life.

Re:PHP vs JSP

[yetdog]

It probably means that since PHP is (designed to be) so easy, there are many more programmers out there for for the task. Many of these companies who consider PHP programmers to be dime a dozen, however, probably end up with a lot of sloppy code.

Re:PHP vs JSP

[asuffield]

The key point you're missing is that people are dumb.

The clue you missed is that pretty much everything written in PHP was fairly obviously written by somebody who wasn't very bright. Have you ever seen a well-written PHP application?

Not that java/jsp is the best system ever invented... but PHP is awful, and so it calls out to the legions of bad programmers in the world.

Here is a good article on why PHP is awful, for those who haven't actually used it: http://www.bitstorm.org/edwin/en/php-sucks/. It also links to a number of other articles which also make good points, at the bottom.

Re:PHP vs JSP

[mrandre]

Rigid is the key word here. As someone who has developed both PHP and Java, I can tell you I find the rigidity of java mysterious and stifling. Actually, I find PHP a little much at this point, so enamored am I of python and ruby. PHP _is_ flexible, and that's why it's popular. PHP is able to handle the work of a professional like me, but also to handle the simple little bits of a designer like my girlfriend. I can't imagine saying the same for a java system. PHP et. al. feel more natural, more like pseudo code. I've failed to understand how people find rigidity so appealing. In my experience, there is no substitute for good programmers. An anal language will only help an anal person. We don't need typed variables. We need coders who know what they're doing, which is more work, but more payoff. And also, that I've seen, more fun.

Re:PHP vs JSP

[FidelCatsro]

True enough , but for orderly code it helps and gives a slight impresion of it , which is all i really ment

Re:PHP vs JSP

[RoLi]

didn't feel it gave me the rigid OO structure

But creating HTML is a procedural task. You may argue that you can do it "cleaner" in a OO-way, but then you have a performance penalty. (For example if you have a quite long database query in a page you can deliver half of it procedurally while you would have to wait if you do it the OO-way)

That's why I always fell back to PHP, even though I really like Java.

Re:PHP vs JSP

[dubl-u]

I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets. Not trolling, just saying I'm surprised that Java and Servlet hosting isn't as popular as PHP. I'm obviously missing some key point.

As a professional developer with years of experience, I like Java a fair bit, and do 85% of my work in it. But I think that Java's rigid structure and sophisticated APIs are exactly why PHP is so popular.

The thing that PHP (and languages like VB) get right is that they're very, very easy for novices to get started. Your first hour putzing with PHP will let you get pages that do stuff. Your first hour with Java mainly involves figuring out why the goddamn CLASSPATH environment variable looks right but is actually wrong, or where to put your JSPs to get them interpreted, or what those mysterious error messages mean.

Also, a lot of sophisticated Java APIs are, in my mind, about 80% complete. They took a complicated concept (like encryption, or sending email) and came up with an API that is at least as complex as the domain, with some overengineering slathered on top. But they never did the final 20% of the work, which is to put a nice, simple API for basic uses on top of it.

So it ends up that the only people who use Java are professionals, because they're the only people with enough time and motivation to get past Java's terrible new-user experience. That's unfortunate, because I think languages like VB and PHP can teach people a lot of habits that are harmless at the scale of 10-1000 lines of code, dangerous at 10,000, and completely fatal at 100,000 and up.

Re:PHP vs JSP

[shut_up_man]

I recently described PHP to an ASP.NET programmer in the form of a medieval weapon analogy, thusly:

PHP is like a mace. Simple, brutal, uncomplicated. It requires minimal skill to build and minimal training to use, and does reasonable damage.

ASP.NET is like a morning star. It capable hands, it can be quite nasty, but it requires quite a bit of skill to use properly. Using it without the requisite skill will often result in the weilder clocking himself in the face or the goolies.

Of course, every programmer considers themself incredibly talented and capable... but we're constantly surrounded by idiots. If you had to fight next to a complete novice, would you prefer them using a mace or a morning star?

Also, the battleground itself affects one's choice of weapons. If I was in single combat with another knight in a dappled glade, a morning star would be a fine choice. Unfortunately, my current job is like a wild bar brawl, with debris flying through the air, no room to maneuver and people coming at me from all directions. A mace (or even a bar stool) is a much more suitable weapon for this field of battle.

Re:PHP vs JSP

[dubl-u]

This is my basic gripe with PHP. It leads the unfortunate user down a path that suggests that each page is its own island, and any attempt to modularize or componentize that is, by PHP's nature, a secondary affair.

You're absolutely right. On one of my projects, I'm writing a bunch of web code that works with a desktop client being built by another team. One of the desktop guys has worked with PHP and was interested to see my code. It just blew his mind that there was no place he could go to look at the pages, and that the resulting HTML generated was not closely coupled to what the URL happened to be.

And I think it's important that people learn that. URL=page made a lot of sense with the limited technologies available early on in the web's evolution, but it's a big handicap for large, modern, fully dynamic web sites. As far as I'm concerned, URLs are UI, not internal API.

Re:PHP vs JSP

[dubl-u]

but procedural is a valid way to structure your apps... especially for web-based ones where that have, by nature, a page-based model and a very linear flow. you can write serious software using php4 without oop!

Can and should are two different things.

I've got years of experience with both approaches, and I think that for a hundred lines of code, OO approaches can be overkill, especially for a novice. At a few KLOC, I think the balance tips to OO approaches. And at 20 KLOC and up, I think OO's benefits in maintainability and expressiveness make it a clear winner even for web sites.

But I should note that what I'm comparing here is high-quality procedural code versus high-quality OO code. There are a lot of people out there who think they're at the pinnacle of object-oriented design just because they're using OO languages like Java. That's bullshit. Those people I want to beat with sticks.

Re:PHP vs JSP

[jez9999]

Any particular reason why PHP is better than Perl with HTML::Mason? That's what I'm using with my site now, mainly because Perl wipes the floor with PHP, imho (where are the labelled blocks?? no, i don't want to uglify things with a function wrapper). Also, the people in PHP IRC channels seem to be, um, wankers, for some reason. :-)

Re:PHP vs JSP

[shiflett]

That lack of rigidity is something that many developers enjoy. Things like Java are often preferred by managers, and things like PHP (and C, Perl, etc.) are often preferred by developers.

Re:PHP vs JSP

[ajs]

quoth jez9999, "Any particular reason why PHP is better than Perl with HTML::Mason?"

I'm really perplexed at how you extracted my saying that PHP was better than anything from what I posted.

I'm not a fan of PHP in case you had a hard time guessing, though I'd still use it if I had a simple templating task that was single-page oriented.

Re:PHP vs JSP

[Anonymous Coward]

"But creating HTML is a procedural task. You may argue that you can do it "cleaner" in a OO-way, but then you have a performance penalty."

So why is PHP putting so much effort into becoming OO?

Re:PHP vs JSP

[njcoder]

" I recently described PHP to an ASP.NET programmer in the form of a medieval weapon analogy, thusly:"

And then the ASP.NET developer locked you in your locker I bet.

Re:PHP vs JSP

[shut_up_man]

Actually, he said that he preferred to be a knight than a belligerent drunk. We then moved on to discussing whether filthy bar wenches or gracious court ladies were more fun to play with.

Re:PHP vs JSP

[njcoder]

filthy bar wenches no doubt

Re:PHP vs JSP

[jbplou]

PHP backed by Perl or Java or C# is quite powerful, in fact

Using C# to back your PHP seems like the dumbest idea. If you want to use C# you should use ASP.NET and get full object orientation. Plus if I was going to have a server use PHP I wouldn't install the .NET runtime as well. This is crazy have interpreted code call managed code to try and eat up as much resources as possible. I'm not even going to get in to how JSP or ASP.NET blows away PHP and if you know Java or a .NET lanauage there is no reason to use PHP. PHP is like 'classic' asp something that needs to go away. OOP is the best way to make a large site.

Re:PHP vs JSP

[Tablizer]

This is my basic gripe with PHP. It leads the unfortunate user down a path that suggests that each page is its own island, and any attempt to modularize or componentize that is, by PHP's nature, a secondary affair.

Well, the ideal would be event driven based on a stardardized declarative GUI language, but browsers are not there yet. Thus, the page metaphore tends to fit the limits of HTML fairly well. But event-driven is not necessarily OO either.

And, one can componentize pages by using include files that have subroutines that take various parameters. You factor common stuff into includable libraries. (The FuseBox sandwitch layer approach has too course a granularity for such, IMO.)

Example:

include(headers.php);
headerX(title=>"Foo BAr", style=>"Peachy"....);
...

Re:PHP vs JSP

[Anonymous Coward]

> It leads the unfortunate user down a path that suggests that each page is its own island [...]

That part's what makes it easier for some people. Each page is a separate file. They output procedural code (HTML), so why not write them procedurally? Anything that appears on more than one page - for instance navigation links - can be an object instead. Not saying they have to be, they could just as easily be a plain text include file.

Re:PHP vs JSP

[VolciMaster]

Well, another thing is that the work is done on the server, no virtual machine required, just the PHP interpreter module. I realise JSP et al run on the server, but my experience has been that running Java code is slower than corresponding PHP. PHP speed and transpaency to me as a coder (it looks enough like the HTML it produces), that I use it for almost everything I need do that involves scripting.

Thanks for the career, PHP!!

[ylikone]

I've made my living for the past 3 years as an independent PHP developer. I don't care what anybody thinks of PHP, it makes me money to live.

Re:Thanks for the career, PHP!!

[BigGerman]

Offtopic? Did Slashdot add some kind of random moderation just to spice things up a bit?

Re:Thanks for the career, PHP!!

[downward dog]

The poster makes a valid point: PHP is a marketable language. Whether it is good or bad, perfect or not, it gets the job done for some people. Myself included. I'll give Ruby a chance someday, but for now, PHP keeps my clients happy.

Re:Thanks for the career, PHP!!

[the quick brown fox]

I'll give Ruby a chance someday, but for now, PHP keeps my clients happy.

And that someday, Ruby will make you happy. But don't learn it until you don't need PHP anymore, because you will never want to use PHP again.

Re:Thanks for the career, PHP!!

[downward dog]

And that someday, Ruby will make you happy. But don't learn it until you don't need PHP anymore, because you will never want to use PHP again.

You're probably right, and I would maybe switch this summer if I could convince my partner that it was a good idea.

Care to share your personal experience with Ruby? Had you used PHP or ASP or Perl beforehand? What was the learning curve like? How long before you were building complex web apps? What do you like about it so much?

Re:Thanks for the career, PHP!!

[gregarican]

I have been using Ruby for everything from admin scripts to SQL data transformation/importing to Tk GUI apps. After working with everything from Perl to C++ to Java to VB it was a pleasure to switch over to Ruby. There are lots of bindings available for it and the community is strong. Started using it last November and can't imagine switching back to another language.

Just a month and a half ago I picked up Ruby on Rails and haven't looked back. I haven't used PHP in production apps but have used ASP with VBScript and Javascript. Coming from that background Ruby on Rails is a welcome departure. The MVC concept is great and I was building relatively complex web apps with relative ease. I created an internal purchase order application that integrates with a central fax server, e-mail notification, etc. and can't imagine the pain that I would've endured doing it with ASP.

If you get a chance, read through the Practical Programmer's Guide to Ruby (Second Edition) and The Ruby Way. Those two books will sell you on what Ruby has to offer. It's powerful as Perl but pretty to look at and read through :-)

Re:Thanks for the career, PHP!!

[the quick brown fox]

Care to share your personal experience with Ruby? Had you used PHP or ASP or Perl beforehand? What was the learning curve like? How long before you were building complex web apps? What do you like about it so much?

When learning Ruby, there is only one idea that you will need to expend some effort getting your head around: blocks. Once you grok them, though, you will appreciate the power and elegance they give you. Using an API that takes blocks is nice. Being able to use blocks in your own APIs is even better.

In fact, Ruby fans wax rhapsodic about blocks so often that it irks a lot of Lisp and Smalltalk hackers who have had them for decades. It's not a new concept, just new to a lot of today's young programmers who grew up on C-like languages (myself included).

Other than blocks, I found Ruby's learning curve to be astonishingly short. In fact, I think it is a great first programming language. In the past I've done serious work in ColdFusion, Java, and C#, and dabbled in C/C+++, PHP, Python, Perl, Lisp, and Visual Basic. Other than blocks, I found Ruby to be the easiest to learn by far (and blocks are the best part).

The pickaxe book is the one you want. Also check out Ruby on Rails if you're primarily interested in webapps (I've only barely looked at it, but a lot of people seem to be ga-ga over it).

Student Suspended Over Suspected Use of PHP

[Conspiracy_Of_Doves]

http://bbspot.com/News/2000/6/php_suspend.html

Standard practice!

[Grendel Drago]

No, no. Standard practice is to just send them to Wikipedia or a google search to demonstrate that the information they seek is quite readily available, and make the original poster feel kinda dumb, while not wasting time on rewriting an intro paragraph and therefore handing a victory to a possible troll.

--grendel drago

Re:Standard practice!

[radja]

alternatively, you may direct them here, immediately proving your superiority and knowledge of the internet.

Re:Standard practice!

[OreoCookie]

Maybe the questioner is looking for a little more insight than can be gotten from a Wikipedia definition. By your reasoning nearly every comment on /. is redundant. The same or better information can be found by Googling for it.

Exciting?

[gamlidek]

Wonderful, maybe... but Exciting? C'mon! It's a development language.

I guess I'm one who still doesn't get it... /gam/

Re:Exciting?

[blueZhift]

It's a development language.

Yeah! w00t!

One of pillars of success: manual

[Pecisk]

Yes, that simple thing which is overused for learning and coding pratices. In the times when you are have to look for good perl manual, PHP manual from the very begining was perfect. That's it. And second best thing came when they added those comments for user experience.

So, in any way, PHP is such thing which just works.

Congrats! :)

Re:One of pillars of success: manual

[A beautiful mind]

Um, what are you talking about? 'perldoc' seems pretty good for me.

As i recall, when i first started to get familiar with perl, i was using perl in 21 days, then switched to perldoc and cpan.org documentation.

Also, please note the difference between a manual, a book and a guide. Manuals don't necessarily need to be easy to understandable, just coherent and clear. They are intended for those already familiar with the language, or at least some degree familiar with it. Given that php has so many functions, i'd say it's pretty needed.

Re:One of pillars of success: manual

[MostlyHarmless]

I agree that the manual is wonderful.

I especially like this table, which elegantly illustrates where weak typing[*] can creep up to bite you and why it is not necessarily easier than strong typing.

That the manual is so comprehensive and easy to access is also important when you constantly have to look up the names of common functions, because half of them follow C naming conventions (strcmp, etc.), half of them have prefixes (array_*), half of them follow no convention (htmlentities, etc.), and none of them are in any sort of namespace.

[*] I don't mean dynamic typing; I mean weak typing as opposed to strong typing. A language could be dynamic and still enforce the type of common sense that prevents 5 + "10 little piggies" from equaling 15.

Not that I'm bitter, of course...

Re:One of pillars of success: manual

[RSevrinsky]

I really don't think there was ever a time that it was hard to find a good Perl manual -- the perl manpages and perldocs were always exhaustive and always began with a sample code section. perldoc also had the ability to search perlfaq by keyword.

Now, if you want to talk about languages that are seriously lacking in manual comprehension, how about Java?

Re:One of pillars of success: manual

[Splab]

This is so true - Been programming PHP for a couple of years. My choise back then was the fact that it was easy to lookup functions and get some user comments/experience. The choise back then was PHP and JAVA, and that really is what took me down the PHP road.

That being said, I sure miss some stronger types, but you cant have it all...

(Ohh and today I actually had to make my first JAVA program in years, god that was a bitch to get working.)

Re:One of pillars of success: manual

[Anonymous Coward]

"Now, if you want to talk about languages that are seriously lacking in manual comprehension, how about Java?"

There are a ton of books on Java. You can find the API docs as well as a lot of tutorials on Sun's site. You can find API docs and other info on related project webpages (Apache, Hibernate, etc). Try a google seach for Class HttpServletResponse and the first link sent back is to the JavaDoc on Sun's site (even though HttpServletResponse is an interface).

If you use an IDE like NetBeans, Eclipse or IDEA, the JavaDoc comments can be displayed along with the code completion popups.

Using the JavaDoc tool you can easily document your own application and api's.

Sounds like you didn't look hard enough.

Re:One of pillars of success: manual

[Just Some Guy]

PHP manual from the very begining was perfect

I think you got the causality backwards. If PHP's manual wasn't top-notch, then noone would ever be able to figure out the 15 variations on each function (each with arbitrarily different argument ordering). People didn't flock to the PHP manual because PHP is such a great language.

In other words, PHP leans on a strong document set just to make it usable. That's quite different than most other languages commonly in use.

Re:One of pillars of success: manual

[Anonymous Coward]

Java.
It's a name, not an acronym. Nothing shows someone up as knowing nothing about Java more than capitalising the whole damned thing.

PHP 1.0 - 2.0 - 3.0 ...

[J-F Mammet]

PHP/FI 1.0 wasn't really a scripting language, it was more like a big perl (or was it C?) script that would put some variables in a html page. Not really that useful but a nice idea.
I discovered and started using PHP by the time the first beta of PHP 2.0 had been released. What a pleasure this was to convert my old clunky C CGI scripts to PHP. No more compiling, no more mallocs. Weee :)
7 years (I think, maybe it's 6) later I'm still using PHP for everything at work, and I certainly don't plan to use anything else (not that I could if I wanted, rewriting everything would take a few years...).
Congrats to the PHP Team, and thanks !

Slow to catch...

[ral315]

Apparently, it was so slow to catch that it was posted a day late!

Or is this a dupe from yesterday?

Re:Slow to catch...

[Anonymous Coward]

Apparently, it was so slow to catch that it was posted a day late!

And I was late, too, so I couldn't get my chance to say "PH(irst) P(ost)" :(

that's pretty good

[Anonymous Coward]

For a perl script cum slow perl clone...

PHP definitely does not follow the KISS principle

[Peter Cooper]

PHP has long followed the KISS principle

Are you smoking crack? PHP is more inconsistent than any other language I've encountered. I'm not disrespecting the team, as I'm sure they've worked hard, and it's great to celebrate ten years of an admittedly very useful language, but PHP is not an inherently easy language.. it's just one that lets you code sloppily and get away with it.

For a start, PHP functions seem to have no consistency at all. Sometimes you get verb/object, sometimes object/verb. Sometimes you get underscores, sometimes you don't. Consider.. is_object but isset. str_rot13 but strpos. php_uname but phpversion. There are hundreds of these. It's the reason I could never learn PHP, it's like learning Chinese, but I found Perl (and now Ruby) easy due to their relative consistency. Sometimes PHP uses "to", sometimes it uses "2".. huh what's that about?

Unlike Perl which has a few regular expression constructions and a handful of modifiers.. PHP has a whole glut of regular expression functions which have confusing names, some of which take certain modifiers, and some that don't. As someone who has mastered Perl's regular expressions I find it a major struggle when I have to tackle something in PHP (I admit, I've never 'learned' PHP, but I find it a very hard language to make quick fixes on for other people.. compared to, say, C, VB or Python, languages I don't know intimately but can easily hack).

PHP has thousands of core functions.. nuts! And why does PHP have such a bizarre lack of abstraction? PHP often has about 10 functions compared to other languages' single function.. with each of the 10 doing a slightly different thing. When it comes to being overly wordy and inconsistent, I doubt anything can beat PHP, but, well, I'd like to see someone bring up a language that is!

So if you were going to call any language "KISS", it'd be Ruby or Python.. but PHP? No way.

Success of PHP easy to understand

[iJed]

I think it is obvious why PHP has become so popular:

1. It is very easy to learn

2. It is easy to use (unlike ASP.NET) and relatively simple

3. The syntax is derived from C and perl

4. It is free

Re:Success of PHP easy to understand

[nick-less]

5. It features nice effects

$test = null;
if ($test==null) {
echo "test is null";
}
$test = array("1","2");
if ($test==null) {
echo "test is null";
}
$test = array();
if ($test==null) {
echo "test is null";
}

reply with your suggested result ;-)

Re:Success of PHP easy to understand

[moof1138]

Two other big reasons are

5. It's fast.

6. It is easy for hosting providers to deploy. There are tons of hosting companies out there give customers PHP support because it is easier to support on a box running a bunch of vhosts. Other web scripting environmants either have security issues (mod_perl is really scary if you don't trust other people running on the same host), have limitations for what directories scripts are run from, or are just a PITA to deploy in a simple yet relatively secure way. (That's not to say that PHP apps themselves are secure, but that you can set things up so that when you 0wn the PHP app you don't get much else.)

Re:Success of PHP easy to understand

[the eric conspiracy]

6. It works well on a shared server so hosting services can offer PHP/MySQL for $5 a month.

Personally I like Python or Ruby way better. Variant types are just not acceptable.

Re:Success of PHP easy to understand

[jpkunst]

If you use either if (is_null($test)) or if ($test === null) instead of if ($test == null) you get the expected results.

JP

Re:Success of PHP easy to understand

[killjoe]

equality is now a valid test of null. You should use is_null instead. You would not say "select * from mytable where mycolumn=null" would you?

Re:Success of PHP easy to understand

[nick-less]

f you use either if (is_null($test)) or if ($test === null) instead of if ($test == null) you get the expected results.

I know, the point is, the initial design was flawed, but instead of fixing it, they introduced kludges like "is_null()" or the "===" operator. Thats not exactly what I would call "easy to learn".

Re:Success of PHP easy to understand

[H0p313ss]

#6 is a BIG one, it's the only reason I'm playing with PHP rather than JSP or servelets.

Re:Success of PHP easy to understand

[cpeterso]

I think PHP's success is mostly due to being Perl-like, not CGI, and (most importantly) easy to install. I hate PHP, but I kept using it because my web hosting company had already installed PHP. I just needed to create .php files and scripting Just Worked(tm). I've since sobered up and use Python.

Re:Success of PHP easy to understand

[julesh]

The inital design isn't flawed. "==" does exactly what it's supposed to: test objects for equality (according to the definition of equality in force for that particular object), in the same way as calling ".equals ()" in Java or similar languages. "===" is used for checking for identity (equivalent to checking for pointer equality in other languages). It's a notational difference based around the fact that for 99% of purposes, what you want is "==".

The fact that "==" doesn't perform equality checking frequently confuses new Java programmers, BTW. This is clear evidence that neither approach is really better than the other, I think.

Re:Success of PHP easy to understand

[Sithgunner]

and the doc.

Offtopic??!!

[ylikone]

Whoever moderated this offtopic, are you on crack or what? How much more ontopic do I have to be?

Looking forward

[joebp]

Let's hope that in the future the PHP developers can come up with some ways to make the code produced by PHP developers more secure.

One of the huge problems with PHP is the massive number of XSS and SQL injection vulns present in code. Partially because PHP is used by beginners, but mainly because PHP does not help the developer write secure code. It's fast and easy to write, but allows you to shoot yourself in the foot. Just like C. See this paper on precise tainting for an example solution to the problems. It would break compatibility with most software written in PHP, but that's not neccessarily a bad thing when most of it is insecure trash.

Re:Looking forward

[Alioth]

The real secret is PGP stands for Pretty Good Privacy, and PHP stands for Pretty Hopeless Privacy, hence the security holes!

Re:Looking forward

[Anonymous Coward]

Don't you think all that is do with input validation though? Any language that accepts user input and tries to act on it is vulnerable I would have thought. It's not really the fault of PHP.

Re:Looking forward

[vgaphil]

One of the huge problems with PHP is the massive number of XSS and SQL injection vulns present in code.

$sqlStr = "select * from foo where bar='" . addslashes($bar) . "'";

It's not PHP's fault that people don't take the time to learn how to write secure code.

Re:Looking forward

[joebp]

addslashes should not be used to escape data destined for a database because it doesn't escape all the necessary reserved symbols associated with the underlying database engine.

It's not PHP's fault that people don't take the time to learn how to write secure code. But it should take the blame for making it so easy to do so and not guiding beginners to making the right choices. Even an extremely simple tainting system which throws an E_WARNING when incorrectly escaped user controllable input reaches any functions marked as dangerous (mysql_query, include and so on) would improve the situation greatly.

Re:Looking forward

[kuzb]

meh, you guys always do it wrong. Here is the *right* way:

<?php

/* Use this to normalize incoming data. Don't rely on server settings! Always test! */
function fixSlash($in)
{
return get_magic_quotes_gpc() ? stripslashes($in) : $in;
}

/* if you're expecting an int, best to cast it. same idea for floats. another method is to use ctype_number() to test to see if something is all digits. DO NOT use is_numeric() or is_int() as is_numeric tests for many different numeric representations and is_int() only works on real integers, not the strings that come back from a GET or POST */
$fromUser = (int)$_GET['someNumber'];

/* if you're expecting text, normalize it */
$fromUser = fixSlash($_GET['someEvilValue']);

/* now, use the escaping functions SPECIFIC to the database server used. In this case, we'll use MySQL */
$fromUser = mysql_escape_string($fromUser);

/* lastly, make the query. Standard SQL doesn't quote numbers; if this is a number, and not a string, remove the quotes */
$query = sprintf("SELECT * FROM foo WHERE bar='%s'", $fromUser);

?>

Also notice how we use the superglobals for everything (superglobals are $_GET, $_POST, $_COOKIE, $_SERVER, etc..) these will always work, regardless of the register_globals setting.

If you code in this manner, it doesn't matter what magic_quotes_gpc is set to, at all, ever. This method is primarily procedural, but if you have an OOP structure in place, it's a good idea to build a filter object. This object can then be called from setters to perform these tasks for you which can make it all very transparent once set up.

If you always code in a portable manner, you'll have fewer surprises later on.

Re:Looking forward

[ThisIsFred]

Sorry, but this isn't something that's exclusive to PHP. I've seen other less-than-perfect, non-PHP code that's full of holes. I've seen plenty of ASP developers make really stupid mistakes, like the ones where it's exploitable by simple altering the URL. Perhaps the opening chapters of any popular web+scripting language documentation should include explicit instructions on how to exploit the flaws. Not only would that provide future developers with ideas on how to protect their hosts, but it would also make poorly-coded systems a big liability.

Re:Looking forward

[shiflett]

PHP's ease of use and flexibility do make for a dangerous combination. There's no arguing that.

I'm not so sure that the answer lies in the interpreter, although I'm open to the idea. In the meantime, the PHP Security Consortium is an effort to help educate the community about secure programming practices (among other things).

I also try to do my part (in addition to my work with the PHPSC) by providing free articles, giving various talks (including the PHP Security Briefing), and writing Essential PHP Security. Education might not be the only answer, but I think it helps.

So, you're right that there is a bit of a problem, but some of us are trying to help.

Re:Looking forward

[Anonymous Coward]

sprintf is a waste of time:

$query = "SELECT * FROM foo WHERE bar='$fromUser'";

Also, using * in a select statement is generally frowned upon. Might want to double check your use of "mysql_escape_string" while you're at it. Hint: you missed the "real" part of it. And, just to nitpick, I see absolutely no empty string checking--and don't say to use empty().

Re:Looking forward

[kuzb]

Using * in mysql makes no difference at all. mysql_escape_string() is a real function (hint, you're a moron), and using sprintf() is cleaner, and allows stricter formatting. How you do interpolation really is a matter of preference only, so trying to nitpick on that instance really just tells me that you're being stupid.

Completely necessary

[crypto55]

"?php echo 'hello slashdot!'; ?"
Slashdot removes brackets :(

Re:Completely necessary

[PReDiToR]

Slashdot removes brackets :(

Try using &lt; and &gt; =)

Re:Completely necessary

[Anonymous Coward]

They don't remove &lt; and &gt; but they do remove &nbsp;

I get it just fine

[Anonymous Coward]

Much easier than the crusty old languages of the past like Perl or God forbid Python.

It's really easy for anyone to get up and running with PHP.

The only potential issue is that virtually zero hosts actually enable any of the safe mode stuff (Note I'm not bothered by register_globals; way overhyped problem).

Re:I get it just fine

[julesh]

Why would you care if your hosting provider is using safe mode? All it does (I believe) is disable some potentially dangerous functions, and restricts locations that files can be referenced from... you could just not use those functions and validate all your filenames before use.

Safe mode is not exactly the be-all-and-end-all of web security. It's more there to protect the host from you than to protect you from hackers.

Re:PHP definitely does not follow the KISS princip

[AKAImBatman]

Are you smoking crack? PHP is more inconsistent than any other language I've encountered.

Nope, I'm just a realist. PHP was designed to be a web scripting language that wrapped Unix APIs. Nothing more, nothing less. I in no way agree with the fanaticism surrounding PHP (it doesn't make a good general purpose language people!), but it does what it was designed for in a straightforward, simplistic fashion. I usually prefer to do things in JSP/Java, but if it's not an option for some reason then I prefer to use PHP over any other option. Especially over ColdFusion.

In the past two days, I have run across two separate CFM sites that crashed nonstop on simple operations. On one site, the exact same data entry would crash the first few times, then mystically work correctly. I know that a lot of people like CFM for its "simplicity", but it just doesn't cut the mustard for robust and reliable web code.

< use the short form >

[ylikone]

I prefer

Re:PHP definitely does not follow the KISS princip

[Peter Cooper]

Aha, I was looking for a worse language than PHP and I think we've found it. ColdFusion! How could I forget about that nugget of programming fools' gold ;-)

I would agree that PHP makes a decent web scripting language for basic tasks (polls, counter, guest book, a bit of remote inclusion), but I am horrified to see people actually using it for serious stuff like enterprise level systems. That sort of stuff makes the blood freeze. I feel really sorry for the corporations who get sucked into it.

Yet another language....

[David's Boy Toy]

The thing thats always puzzled me about php is that it seems to be yet another language for no good reason. Why would I use php instead of Perl/Mason?

Re:Yet another language....

[imgumbydammit]

If you are using Mason with mod_perl, it would be mainly because hosting with PHP is much easier to find. You never have to worry about scenarios such as: "if this hosting company goes under, where am I going to be able to find another one with similar features, similar prices, and maybe toll-free support (if your client has insisted on it)".

Re:Yet another language....

[Anonymous Coward]

Don't be ridiculous. Mason can be difficult or even impossible to install on many systems. PHP, like it or not, is ubiquitous. You are far more likely to find a host that supports some version of PHP than you are to find one that supports mod_perl or even CGI.

Now, as a language, perl knocks the socks off of PHP, which is the BASIC of the web. But most people who start using PHP already know a little bit of HTML, so PHP looks a lot more familiar than a language that uses a C-type syntax.

Re:Yet another language....

[Anonymous Coward]

I should clarify, since PHP does use a C-type syntax: Because it's surrounded by a lot of HTML, it appears familiar to HTML programmers, in spite of the syntax of the language (be it C-like or any other).

Database independence

[3770]

I support the idea of database independence.

But it should be done by using standard SQL.

Unfortunately, that is not a losing battle, it is a lost battle.

The database vendors doesn't care about standard SQL.

Re:Database independence

[stephenbooth]

Some do, some don't. It's now possible to write 100% ANSI compliant systems in Oracle and MS-SQL amongst others (those are the two I know of for sure, I also know there are others). Obviously you can choose to use non-ANSI compliant code if you so wish. Sometimes there are good reasons to do so, using supplied packages to perform tasks that would otherwise have to be coded is one. As noted earlier, writing your code to fit a particular RDBMS will often result in faster code. It may also give you a faster time to market (don't have to reinvent existing code).

Stephen

Re:Database independence

[3770]

Here is a good comparison that I use:

http://developer.mimer.com/validator/comparison/up d_comparison_chart.tml

Re:Database independence

[shut_up_man]

Correct... but it goes beyond not caring. Most vendors actively add to standard SQL, to lock people into their platform. Embrace and extend. Share and enjoy.

Re:Database independence

[Desert Raven]

It's now possible to write 100% ANSI compliant systems in Oracle

Really? Did Oracle finally change from the bizarre, proprietary syntax they use for outer joins?

Re:Database independence

[3770]

Yes:

http://developer.mimer.com/validator/comparison/up d_comparison_chart.tml

Well, you can still do it the old way. And they don't necessarily send a perfumed paper letter to all developers announcing that they support the standard syntax.

All database vendors want you to use their proprietary constructs. But they also want to make it easy for you to move to their database. So in some cases they support the standard, but doesn't announce it.

Here's something you can try. INFORMATION_SCHEMA is the standard way to inspect a database to find tables and columns for instance. SQL Server 2000 supports it, but they aren't really encouraging its use over their proprietary approach. They make it really hard to find.

Re:Database independence

[stephenbooth]

Looks interesting. It doesn't appear to be 100% accurate though. There are a number of features (e.g. E051-08, E021-06 and E021-04) that it says that Oracle 9 does not have but I know it does, or at least it has something matching the description given (maybe I'm misunderstanding something).

Stephen

Re:Database independence

[3770]

I think that the chart is rather accurate. I know the people that made it and one of them is in the SQL Standards committee (Åke Persson).

It may be really picky and unforgiving, however, and even a minor deviation from the standard might disqualify a feature from being listed as supported for a certain database. I can't say that that isn't the case. All I'm saying is that they guys that made the list know what they are talking about.

Åke Persson is also a compiler expert and he wrote this tool:

http://developer.mimer.com/validator/index.htm

You can use it to validate your SQL to SQL-92, -99 and 2003. Pretty nifty if I may say so.

Agreed - it's a great starter language

[cbreaker]

I'm no programmer. I never have been.

But I wanted to make a really cool web site for a game group I was in, and I dug into it. I found PHP, as it worked real easy with both apache and IIS.

I ran through some tutorials (there's a ton of them out there, online, free) and I started to get into it.

The PHP manual has a lot of information and detail about nearly everything the language can do. It's a reference but it's easy to read and you can sit down with it and learn a lot about PHP and programming in general.

The truth is, PHP isn't all that much different then Javascript, Perl, etc. The syntax is very similar. Many of the functions are very similar. After creating my web site, complete with mySQL/MS-SQL support, logins, cookies, and everything in between - I can look at all kinds of different language source code and figure out what's going on.

Other languages are documented too, but something about PHP and it's docs just makes it easier to start coding and learn.

Re:PHP definitely does not follow the KISS princip

[fbjon]

But on the toher hand, PHP isn't really ciplled in any way, is it? Sure the function names are varying, but that can be fixed eventually. It's just easy to do things right there on the spot, instead of doing it really elegantly, but if you force yourself to do things the right way, wouldn't PHP be as good as any other option?

Re:PHP definitely does not follow the KISS princip

[lawpoop]

I agree with the simple inconsistencies. What annoyts -- no, frustrates -- me most is that the functions that have a string and an array for an argument is that sometimes the array comes first, and sometimes the other argument comes first. I hate it.

sweet

[rwven]

I've been using it for about 5 years now and love it to death. Mucho Bueno! there is no more seamless interface to a mySQL database than that of PHP (IMHO)

Enterprise level systems

[ylikone]

Well, I program enterprise level web apps using PHP all day long. And I get paid good money to do it. I have a Bachelors degree in Computer Science and am not a complete programming newbie... and I think there is nothing wrong with PHP for enterprise apps. I suspect you are just being elitist... whatever... get over it. PHP is here to stay.

Re:Enterprise level systems

[Peter Cooper]

The fact you are using a Computer Science degree to back up your argument is telling. A Software Engineering would be useful, maybe, but a CS degree does not demonstrate you learned to develop enterprise level applications as this is not a focus of CS, as has been discussed many times in the "Shall I get a CS degree?" Ask Slashdot threads.

I'm sure you are developing fine enterprise level PHP apps, but I can also crack open a Mac Mini with a fish slice. It doesn't demonstrate it's one of the best tools for the job, even if it does work. (This is why most low-level systems software is written in C, despite there being plenty of arguments that there's "nothing wrong" in using others.)

And, yes, you're right, it's elitism. I'm elitist to the point where I feel that using any sub-par tool that's not suited to the task is not a wise long-term strategy. But, well, thanks for expressing that in some situations it seems to work.

Re:Enterprise level systems

[IKillYou]

This post is a joke, right? You didn't even attempt to refute any of the arguments against using PHP for enterprise-level work, you simply stated your opinion, branded the parent as an elitist, and stomped away.

Try this: If you really are using PHP for application programming, and if these applications are anything more than trivial in size, then you are almost certainly using the wrong language.

Convincing a manager to bless PHP for a project can be made very difficult if said manager has been previously traumatized by a poor application of PHP. So do us all a favor, and please use it in an appropriate way.

If your post was a joke, then I apologize.

Re:Enterprise level systems

[drxenos]

I'll put my Comp. Sci. degrees up against anyones Engineering degree(s) any day of the week!

Re:Enterprise level systems

[Mr. Slippery]

If you really are using PHP for application programming, and if these applications are anything more than trivial in size, then you are almost certainly using the wrong language.

On what basis do you make such an assertation?

Re:Enterprise level systems

[fucksl4shd0t]

I'll put my masters up against all of y'all's degrees. Got it from the School of Hard Knocks. Graduated head of the class, majored in kicking ass. Did my time, became the master and I wrote the book of personal disaster but I don't need no PhD to be a doctor of fuckin' misery!

Partially paraphrased, mostly quoted, Suicidal Tendencies :)

Re:Enterprise level systems

[drxenos]

Why do people always think that if you have a degree, you had it easy in life? I spend 10 years slaving in a minimum wage restaurant job (amount others: factory, newspaper delivery, slaugherhouse) and drove an hour to college everyday to get a BS. 10 years to earn enough for a 4 year degree. I've been knocked around a little myself.

Re:Enterprise level systems

[fucksl4shd0t]

For me, it's mostly the arrogance people with degrees usually throw out. If I got a nickel for everytime someone told me having a degree meant you were a "cut above the rest", I wouldn't have had to spend all those years slaving over a hot grill (I make SpongeBob look like an amateur fry cook), hot engines, and other stuff. Having a degree meant any idiot could come in and immediately become my boss without knowing either jack or shit about the work we were doing. I trained so many people with degrees it's just ridiculous. Worse yet was when those ASE-certified idiots showed up with their little technical certificates and all the arrogance and "oh I know more than you, I went to school" and then turned right around and asked "Which way do I turn the screw to loosen it?" (YOU IDIOT, you turn the BOLT righty tighty, lefty loosey)

But am I bitter? Hmmm, yes. By far, most of the BS/BA/insertyourfavoritedegreehere that I've dealt with went to school on mom and dad's dime, fucked around and got ejected from college with a degree worth about as much as the Wizard of Oz's gift of intelligence. And these higher educated idiots? You guessed it, I still had to teach them how to read, write, and do math to flip fucking hamburgers.

Of course, now I'm in school myself. :) But it's not a worthless degree I'm pursuing....

Re:Enterprise level systems

[drxenos]

I completely agree with you. The main reason I got my degree is because no one would hire me with it.

I know what you mean about "mom and dad's" money. I went to school with kids whose parents paid their rent, tuition, new BMW, etc. And I would hear them bitch about having to go to class. I was just glad I could afford gas that day and the car didn't break down.

The funny thing is now I work with the same type of people bitching about how stressful work is. I tell them until they've worked for chump-change in a restaurant, blown-away, short-handed and every customer and manager is treating you like a piece-of-crap, you don't know what stress it.

Good luck in school. It gets easier after graduation, trust me.

Re:Enterprise level systems

[fucksl4shd0t]

The funny thing is now I work with the same type of people bitching about how stressful work is. I tell them until they've worked for chump-change in a restaurant, blown-away, short-handed and every customer and manager is treating you like a piece-of-crap, you don't know what stress it.

That makes sense, doesn't it follow that if most people getting a degree are those spoiled brats that get C's because they can graduate with it and still have time to party, then when you get your degree and put it to work you should encounter the same people doing enough work of a high enough quality to "just get by" so they can go and party some more.

Heh. :)

I wholeheartedly agree with you that everyone needs to spend some time working in the restaurant business, and Starbucks doesn't count! It really builds character. You especially learn to deal with stress when you work at a burger place near a high school with an open campus and you learn to deal with having 200 kids get in line at the same time every day for lunch. The store brings in $1000 for that hour alone ('93-'94 numbers) and you work your ass off trying to make 200 hamburgers in 30 minutes. I find people who worked in food, whether they still work in food or not, are more rounded, flexible, and generally more competent.

Heh, so now I'm in school and the kids I'm next to are generally 6-12 years younger than me, and they all look to me for the highest grade. You know, the teacher says "The class average is XX, the lowest grade was YY and the highest was ZZ" and they just know I'm ZZ. I guess when you know exactly what an education is worth in the real world you're just inclined to get higher grades... :)

PHP: Hypertext Preprocessor

[55555 Manbabies!]

Here's to you, PHP, five golden manbabies of the goldest sort.

not just another language

[ylikone]

You obviously are not a web developer. PHP is many times quicker to use for developing solid web apps.

/former perl developer

Re:not just another language

[David's Boy Toy]

I've done quite a bit of web development in perl + mason. For those not familiar with it mason is a templating system that lets you embed perl in html www.masonhq.com.

Sometimes One Feature is all it takes

[Ridgelift]

I really think PHP's success is about one thing: cut and paste. When I didn't know squat about creating dynamic web sites, it was PHP that was the easiest to learn. All I had to do was cut and paste someone else's script into my HTML and voila! Also the installation, configuration, and documentation are excellent.

But most PHP applications I've developed usually start simple but grow into a tangled mess of code. I've tried to seperate my programming logic using templating systems, but it's just so much easier to slap in code into HTML that I cheat a lot.

I've been converted to Ruby on Rails because it's faster and easier to write clean, maintainable code. But PHP got me into web programming, and is still what I recommend to people who want to start creating dynamic websites.

All hail "worse is better"

[jkujawa]

The obligatory link: The Rise of Worse is Better

Re:All hail "worse is better"

[55555 Manbabies!]

I can't make heads or tails of that article. Thanks!

Wow 10 years...

[Anonymous Coward]

PHP finally reaches the average age of its developers and users! Way to go PHP!

I get it, but I don't want it

[Uzziel]

PHP is an abomination.
It was very clever and very handy when it was first developed, but there are many much better systems for building web pages available today.

Its object-oriented features are kludgy, its syntax is a throwback to C, and it in a realm where string handling is ubiquitous, it provides you with such great functions as strtok() and strncmp(). I mean come on, haven't we evolved just a bit past using the C standard library for string handling in our freaking web applications?

Personal Home Pages is fine for whipping up a quick data-driven website, but if you want to build a large application it's crap.

Re:I get it, but I don't want it

[aweiland]

PHP 5 OO features are far from kludgy (it's modelled after Java). Perl's so called OO is 10x more a kludge.

What's wrong with the C string functions? They're fast, useful, and a lot of programmers know them. You're not limited to them. You can use split() or explode() to do what strtok does but get an array. Plus they are a hell of a lot better for dealing with strings than all of Java.

And last I checked PHP stands for: PHP Hypertext Preprocessor.

Re:I get it, but I don't want it

[phpWebber]

I am not a great programmer and I have written my fair share of kludge code. Perhaps the things I coded might have been done better in other languages and by more qualified people.

That said, PHP has served me and my university (Appalachian State) very well. When I started here I was given a "Beginning PHP" book and asked to write a job board program. It was finished within 3 weeks. I'm not boasting, it is just that easy to learn.

Since then, students and staff have written phpWebSite and MANY modules both private and public. One module took two years to code and is massive. It will end up saving a campus department several thousand dollars a year. One talented developer (not I) replaced a workorder system (previously costing $50k) within months.

We have PHP, MySQL, Apache and Linux to thank for all of this. PHP is hardly an "abomination" and far from being "crap". For many people, it gets the job done quite well.

Here's to 10 more years!

Re:I get it, but I don't want it

[hondo77]

Hey, you stole my subject line!

Re:I get it, but I don't want it

[ThisIsFred]

Well, if string manipulation is your thing, Apache Rivet would be handy. If you like pain, and read Sendmail config files for fun, then you've always got a friend in Perl.

Re:I get it, but I don't want it

[Uzziel]

Reading Sendmail config files is the visual equivalent of sticking your hand down the garbage disposal.
Eek.

Re:I get it, but I don't want it

[Laconian]

If you checked a little earlier you would've found that it stands for Personal Home Page.

PHP is cool

[RNG]

I've been doing alot of PHP Programming over the past 3 years (after doing Java for the 4 years before that) and have grown to really like the language. It's easy, you can get started in 1 evening and if you have the proper background (ie: a few other programming languages), you can understand it (at least conceptually) just about as fast. If you know what you're doing, you can write proper frameworks the way you can in any other decent programming language.

However, if you don't know what you're doing, PHP makes it easy create to a garbled mess, tangled and obtuse enough give bad perl programs a run for their money. If you have the discipline to adhere to proper abstraction and coding guidlines, it becomes a very powerful language.

True, before PHP5 the object model was lacking but this should soon be a thing of the past. It's a great fit when coding dynamic web apps. It even makes a decent shell language + once you grok the idea of (generally) typeless data, you just appreciate it for the fact that it *just*works* and that it's practical.

Java on the other hand is fussy. I don't know how many times I've gotten a compile error when I passed an 'int' to an 'Integer' argument. I know *why* it's happening but I don't care! Java forces you be (theoretically) correct and complete, which is both a good and a bad thing. PHP *allows* you to be (theoretically) correct and complete but doesn't force you to do anything.

The biggest difference is the fact that java is further along in the frameworks which are available to the language. PHP has some nice stuff scattered in many places but nothing to really compare to Apache's Jakarta.

Re:PHP is cool

[Anonymous Coward]

> I don't know how many times I've gotten a compile error when I passed an 'int' to an 'Integer' argument.

Java 1.5 now performs auto-boxing and unboxing. This error won't bite you anymore. Mind you there's still plenty of other errors to get you.

Personally I like C# -- delegates are so much nicer than inner classes. And 2.0 has much better templates, because the VM itself supports them, and they don't rely on the unsound "type erasure" of Java.

I think I just lost every PHP coder reading this ... :)

So what...

[The Woodworker]

I was born clairvoyant and was writing PHP code in womb. BTW, if anyone wants I can give you a heads up on Linux 6.6.6 and Windows WTF. Those come out AFTER the apocolypse.

Does PHP Have a Generic Database API Yet?

[Anonymous Coward]

I looked at PHP in it's early days and passed it by for Perl instead primarily because of the poor database interface: PHP had a different set of functions for each database. PHP had nothing like Perl's DBI module, which allows you to code in a generic fashion regardless of database vendor.

[Damn! I can barely read the effin' CAPTCHA - I'm going blind posting to Slashdot! ]

Re:Does PHP Have a Generic Database API Yet?

[julesh]

Yes, as part of the PEAR library (distributed as part of PHP, but not built in -- it's implemented in PHP code itself). That's been around for several years, but most people don't notice it because the documentation is separate.

Re:Does PHP Have a Generic Database API Yet?

[uohcicds]

I think this is what an earlier post was talking about as well: a lack of consistency in the APIs. PHP does have dbx, which is an approximation to DBI, ODBC or JDBC. I can't say I've used it becasue I do tend to stick to the pg_ and my_ libs. and (at least in 4.x, I suspect it may have changed in 5.0.x), it's not standard and has to enabled as a compile option.

Of course, part of the reason for this inconsistency is efficiency. As far as I've seen, many of these calls are generally wrappers around the system libs for those items. For example, the pg_ calls wrap libpq. It makes it fairly painless to extend the language if you do this and the code generally perfoms quite well, but it does certainly lead to some increased cognitive overhead for the developer.

I also find PHP's OO functionality somewhat idiosyncratic: then again, so is Perl's. Python is so much better there.

At the end of the day, however, PHP is designed to help you build webpages/webapps and do it quickly. And it's very good at that indeed, just like perl or python or a whole load of others.

Why I love PHP.

[Anonymous Coward]

I'm a semi technical guy who runs a few websites for fun - I can't code properly (I'd love to learn, I just don't have enough time) but I love that I can get hold of thousands of open source web-scripts (Mambo, phpBB, Cutenews) that I can tweak and use for my sites. For that reason alone, I think PHP is great, and so are the guys who write and share those scripts.

That reminds me

[ch-chuck]

We'll be celebrating the foisting of Windows 95 on the world sometime soon.

Hell in a Bucket

[MichaelPenne]

"the rigid OO structure and sophisticated APIs"

Alot of people just don't really like rigid and sophisticated:-)

You imagine me sipping champagne from your boot
For taste of your sophisticated API
I may not have a rigid OO structure, babe
But at least I'm enjoying the ride, at least I'll enjoy the ride.

I guess the other thing is that Apache/PHP seems to scale better (or at least easier/cheaper than Tomcat.

I may be going to hell on an elephant, babe
But at least I'm enjoying the ride, at least I'll enjoy the ride.

Re:Hell in a Bucket

[njcoder]

Uhm... the article you linked to has some serious flaws. 1) it's from 2002. 2. It doesn't mention anything about java/jsp or tomcat so how can you claim it as a reference for php scalling better than tomcat?

Yahoo switched to PHP from their in-house scripting language. There's a yahoo developer here that posts from time to time. He mentioned that Yahoo uses Java for a few things.

Just depends on which OS you're loyal to

[EraserMouseMan]

PHP is to Unix/Linux.
what
ASP is to Windows.

PHP is more powerful than ASP but in the end it's popularity is due to its short learning curve. As a project grows and requires better performance, scalability and maintainability PHP/ASP really starts to suck.

If you expect your project to become large you'll want to bite the bullet and go with JSP/ASP.NET.

--
This post is 100% free of zealotry and techo-religion.

Re:Just depends on which OS you're loyal to

[BigTunaCan]

PHP is garbage. For any real web application use Java or .Net.

Re:Just depends on which OS you're loyal to

[Kryptkrwlr_XTC]

I absolutely agree. Large web applications are not always about connecting to a DB and spitting out/adding/appending data. They provide access to infrastructural services through abstraction for future business needs. Case in point, directory services. Both PHP and ASP can "do the job" but, why wouldn't you want to use the clean API's of J2EE and the .NET Framework instead of kludging together some barely functional solution?

Re:Just depends on which OS you're loyal to

[Karma Farmer]

PHP is more powerful than ASP

As horrible as ASP may be, it's not even true that PHP is better.

Re:PHP definitely does not follow the KISS princip

[bobdinkel]

As someone who has mastered Perl's regular expressions I find it a major struggle when I have to tackle something in PHP (I admit, I've never 'learned' PHP, but I find it a very hard language to make quick fixes on for other people.. compared to, say, C, VB or Python, languages I don't know intimately but can easily hack).

Just a quick point--you can use Perl's regular expressions in PHP. And that's usually what I see people doing. As a matter of fact, it is recommended in the PHP documentation that Perl's regular expressions be used: Note: preg_match(), which uses a Perl-compatible regular expression syntax, is often a faster alternative to ereg().

Re:PHP definitely does not follow the KISS princip

[killjoe]

Lucky for you there is a centralized, annotated, comprehensive, searchable, accessable by web services manual and a centralized repository of standard classes.

People underestimate the power of those two things. CPAN is the number one reason why PERL is still so popular.

Actually I can argue with it

[Soong]

PHP is a horrible language. Even perl is a better programming language. Java and Python blow it away in ability to create easy to maintain and efficient data structures. I'm amazed and fearful of the monstrosities that have been cobbled together with PHP (I'm talking about you Mediawiki and Drupal).

PHP is to web programming as x86 is to microprocessor architecture. It's nasty and inefficient and I can't figure out why so many people use it.

And like many other no-declaration scripting languages PHP is sorely lacking in warnings and errors. Forgot a dollarsign or typoed your variable name? Sorry, yer screwed!

To let you know where I'm coming from, Apache Tomcat is my favorite solution. But it seems that the project I most want to tinker with is Scoop and I'm finding mod_perl pretty workable and the way they architected that giant mass of perl is pretty reasonable.
</rant>

Re:Actually I can argue with it

[aweiland]

perl is probably the easiest language to write unreadable code in. I've personally never had problems creating clean and efficient data structures in it either.

There is probably equally if not greater monstrosities written in perl and other languages as PHP. It all comes down to who is writing the code. Even the authors of perl's famed CGI.pm don't "use strict" which is typically considered good practice.

Many warnings and errors are turned on in php.ini. It doesn't come preconfigured to show everything but you can turn a hell of a lot on. You can mix and match what types of warnings and/or errors are displayed depending on your environment (devel, testing, production).

Re:Actually I can argue with it

[pschmerg]

PHP *DOES* have warnings and errors, they are outputted directly to your server's error log, or if you'd like them to go somewhere else (like on screen) you can specify that in your php.ini.

Re:Actually I can argue with it

[Kainaw]

Java and Python blow it away in ability to create easy to maintain and efficient data structures.

You are making a great assumption that any and all programming projects depend on data structures. Just in case you dropped in on the planet recently, you might find it interesting to note that programming based on data structures is only one way of doing things. It isn't necessarily the best way.

I do data mining. Oh - data structures!!! No. If I were to focus on data structures, my programs would take forever. I focus on the functions and let the data structures fall in as necessary. It is hard for the average just-out-of-school programmer to understand, but it works, whereas a data structure-based approach does not.

I know that this is hard, if not impossible, or many programmers to accept. I ask our new employees to learn using ML. It is sort of like Lisp, so they can get used to it. When that is done, they can work on our PHP scripts that make no use of data structures, data types, data... well anything. Or, they can be like any of the dozens of guys who come in and claim that they can do it better in [insert programming language here] and then fail miserably with a simply data mining tool that takes 6-8 years to pull up a report.

Re:Actually I can argue with it

[julesh]

OK, I'll bite.

PHP is a horrible language. Even perl is a better programming language.

PERL is a better language for some purposes. However, for someone who is unfamiliar with it, code written in it is very difficult to interpret. PHP is easily read by people who understand C.

Java and Python blow it away in ability to create easy to maintain and efficient data structures.

True. Most PHP applications are simple front ends to database storage systems that don't need to do anything with data structures more complex than arrays or records.

I'm amazed and fearful of the monstrosities that have been cobbled together with PHP (I'm talking about you Mediawiki and Drupal).

I've never looked at the code for mediawiki (or any other wiki for that matter), but this is precisely the kind of application that PHP *is* good at. It's pure database manipulation and HTML presentation. I suspect it's pretty easy to read and fairly simple to maintain.

I'm afraid I'm not familiar with Drupal so couldn't comment.

PHP is to web programming as x86 is to microprocessor architecture. It's nasty and inefficient and I can't figure out why so many people use it.

Like processor architectures, web scripting languages benefit from network effect. When designing a web site, an important consideration is: "where am I going to get this hosted, and how much will it cost?". Because PHP and MySQL are so popular, you can usually find a host for sites that run on them very easily. Which is part of the reason they continue to be popular, despite any shortcomings they may have.

And like many other no-declaration scripting languages PHP is sorely lacking in warnings and errors. Forgot a dollarsign or typoed your variable name? Sorry, yer screwed!

For testing and debugging purposes, you should have 'error_reporting = E_ALL | E_NOTICE' in your php.ini file; if you do, it will display a warning message identifying lines on which you forgot a dollar sign (something along the lines of "undeclared constant '[identifier]' at [file], line [line]") or use the value of an uninitialised variable. This is perfectly adequate for finding this kind of error.

Re:Actually I can argue with it

[NuclearDog]

It's only lacking in warnings and errors if you configure it like that. Take the below code as an example:

<?
$name = $_GET['name'];
if ($naem == "Bob") { // Do something
}
?>

If you run that on my server, it'll give you a notice or warning or something about the uninitialized variable. Also take the following:

<?
$name = $_GET[name];
if ($name == "bob") { // Do something.
}
?>

That'll complain about the undeclared string constant (name) and how it's just going to assume you mean 'name'.

ND

Re:Actually I can argue with it

[ggvaidya]

perl -ne "s/Even perl is a better programming language/Perl is the bestest programming language EVA!!!!11! LOL/g; print;" parent.txt

PHP for teaching

[lbya]

So here it is 2005, and I need to teach the "interactive" part of the graphic design curriculum to college- and graduate-level art students. Is PHP appropriate for this today?

In a semester, I'd like my students to learn some fundamentals of programming. Like, what a variable is.

I find that when "interactive" classes are taught in environments like Flash or Director, design students wind up cobbling together bits and pieces of things without really knowing how the pieces work, and then they get frustrated when the whole thing doesn't work. Plus the environment itself becomes confusing (there is really no logic to Flash). Therefore I'm thinking I'd like to go "back to basics" for a semester. Just as design students know a lot about how printing works, they should know how code works.

The Processing environment was designed for teaching-- a kind of simplified Java. But while its graphics support is sort of strong, it doesn't have great network connectivity, with the result that things you make in Processing tend to feel a bit self-contained, like science experiments.

Going the opposite way, what do people think about PHP as a teaching language? It has syntactic similarity to C or Java, for learning "if then" and whatnot, in a way which could be applicable to other languages later on; has a lot of functionality in the core language; and maybe unparalleled online documentation. There is no development environment to learn other than a text editor and SFTP. And even though the idea of your code running exclusively on a server might be confusing, I think there could also be value for design students to learn the difference between server and client since it's a fundamental relationship in a lot of graphic design problems.

Remember also that these are design students not comp sci students, which partially determines the kinds of programming issues these students need to be versed in.

Thoughts from about PHP as a teaching language for non-programmers?

Re:PHP for teaching

[68kmac]

Well, I guess the good thing about PHP as a teaching language is that - when used for websites - it's interactive and gives you immediate feedback. It's also making it easy to come up with a useful program with just a few lines of code. So your students will be motivated and may even come up with something they'll use on their own websites.

On the other hand I tend to think that from the point of language design, PHP is not a very nice language to learn. It's a bit like the old Basic languages - everything is built in, so you'll end up with a language with a huge vocabulary.

What's worse, IMO, is that it's missing consistency. Some functions expecpt their parameters in one order, while other, related functions, expect them in another order. The lack of strong typing is also something that may not be the best for beginners. It might be easier to grasp at first but you'll run into all sorts of problems once your programs get more complex.

Mind you that I'm actually maintaining an open source project written in PHP ...

I think as a first language, for beginners, Python may actually be a better choice. It also offers the interactive bit and has a much cleaner design.

HTH

Re:PHP for teaching

[sherriw]

What about teaching them Flash Actionscript? Something designers might actually use in practice...

Re:PHP for teaching

[NardofDoom]

PHP is good for a start, but be sure to cover Javascript and the HTML DOM. It's unlikely that they'll encounter PHP in the real world, but Javascript will help them since it's the basis for DHTML and for some things in Flash.

And Javascript takes little more than a text editor and a web browser to create, so no expensive web host or SFTP.

Re:PHP for teaching

[julesh]

PHP is not a good teaching language, largely because its design encourages the use of global variables. It's nearly as bad as BASIC in that respect.

I'd say teach in a language designed for the purpose, or at least with the purpose in mind. Pascal, Smalltalk, Python or Java are all reasonable choices.

mysql_escape_string

[ylikone]

Look it up and use it. Not that hard.

Re:mysql_escape_string

[joebp]

mysql_escape_string is deprecated and should never be used in production code! The replacement is the hilariously named mysql_real_escape_string.

Your "not that hard" comment is rather amusing with this in mind.

Re:mysql_escape_string

[Splab]

Ohh, thanks for the heads up - we alwaysed used mysql_escape_string.

As of PHP5 we've switched to PGSQL - however we still have a few legacy sites, I'll be fixing those first thing.

Re:PHP no thanks

[Anonymous Coward]

This is not off topic. The poster had to glorify PHP and put down people who supposely "don't get it". Yeah he is entitled to his opinion - but if this reply if off topic the entire post is off topic.

Could someone compare and contrast it to perl

[goombah99]

Not flaming. No one has ever been able to tell me what niche php fills that perl and its modules does not. Please educate me.

Re:Could someone compare and contrast it to perl

[killjoe]

And vice versa.

It's just a language no big deal, use the one you like.

Re:Could someone compare and contrast it to perl

[Splab]

I've been trying to learn perl a few times, but I just cant figure out how the objects work. That is the number one reason why I wont use perl for anything more than a simple hack...

Ohh and when you come back to a PHP script after af few months (years?) its usually pretty easy to figure out what you where doing/thinking, but with perl, its around 30 minuttes and then I have no idea about what I was doing.

Re:Could someone compare and contrast it to perl

[Anonymous Coward]

PHP is a domain specific language for developing dynamic websites.

Perl is a language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. It's also a good language for many system management tasks.

Hope that helps.

Re:First AC

[metamatic]

PHP is usually bundled with Apache, so no installation tends to be required.

I've never seen a package of Apache for any Linux distribution that has PHP bundled in. What are you talking about?

Congratulations!

[vivin]

Congratulations to the PHP team!

I've only been using FreeBSD since '02. But I've grown to like it very much and I exclusively use it for server-side webdevelopment.

I had an internship during my junior and senior years of college where they wanted me to maintain a series of webpages that ran in Coldfusion. I got them to change it around to PHP.

The only thing that bugs me about PHP is the exception handling, but I hear that it's getting better. PHP does things far better than Coldfusion (yuck), and it's easier than doing [Perl] CGI (IMHO - although I love perl). The popularity, I think, is due to ease with which one can pick it up, and also its similarity to other languages like C and Perl. And then there's the fact that it can interact with a wide variety of databases.

The LAMP solution works really well, although I use FAMP (FreeBSD, Apache, MySQL, PHP), which works equally well.

Re:First AC

[Anonymous Coward]

I'd mod you up if it weren't for the risk of losing karma from metamoderation of it. :)

No, there's a difference.

[Grendel Drago]

"What is PHP" is the sort of question that a reference work is designed to answer. "So, what are some folks' real-world experiences with PHP, and how did it change your job?" isn't.

--grendel drago

too hard

[spudchucker]

Html and php are too hard to understand, I am having better luck with java.

So what does the future hold?

[GabboFlabbo]

So what does the future hold for PHP? I can't seem to find any information on PHP 5.1.

Anyone have any secret tidbits?

Re:So what does the future hold?

[Anonymous Coward]

This:

http://www.phpguru.org/article.php?ne_id=49

Re:So what does the future hold?

[Anonymous Coward]

From your link "Well well. 20 years old and still not showing it's age."

How do you trust someone that doesn't know what a decade is?

Huh?

[Anonymous Coward]

put the data specific code in the sql. or on the server itself via stored procedures etc. the abstraction layer should be that - abstract, otherwise what is the point? your approach does not future proof - you assume that postgresql is the quintessence of database design. what if next year it isn't? oh well, you've tied your abstraction layer to it. by the way none of the issues you raise (foreign keys, stored procedures) have anything to do with the abstraction layer, they are server and query specific.

Not so good an idea

[soloport]

Database abstraction is a frustration of mine.

Say, for example a "real" DBA writes a shopping cart schema / application, using a "genuine" (ACID-compliant) DB, the scalability will be phenomenal; The speed will be incredible because much of the code will be handed TO the database -- not parsed and parsed and parsed away at the PHP/Java/whatever-script level.

Now, let's say a "wannabe" DBA writes a shopping cart schema / application using MySQL. Then to "help" the Postgres folks out, the DBA adds an abstration layer. Woo hoo!!! Useless... Essentially, I'm offered a way to drive a Ferari (Postgres) down the sidewalk, negotiating with pedestrians all day, as if I were traveling by skateboard (MySQL).

Unfortunately, the number of examples of the later are a dime a dozen. The number of examples of the former are near zero. Think about why you'd even WANT abstraction. In most real-world cases it's rather useless and undesireable.

Re:PHP definitely does not follow the KISS princip

[bigman2003]

Well, your anecdote of 2 ColdFusion sites that crashed doesn't really prove much.

I've been working with ColdFusion for about 5 years now. My sites don't crash- and I get 10-20 million hits per month. Not huge, but a pretty good number. (No...this is not the site that is in my sig...)

I *might* get 2 or 3 'unhandled exceptions' in a day. And those are always caused by search engines that are hitting templates with bad queries. It is interesting to see the queries they send, "hmm...why did they decide to make the usernumber 99A4 this time instead of 994" the error is caused because *I* foolishly forgot to put a val() function around the number in a query. So I fix it, and move on.

If the person running the server has half of a brain, their sites won't crash. I've used ColdFusion from version 3, on up to 7. And they always put in great new features and capabilities that other web programmers need to work hours to duplicate- but for ColdFusion it is a built-in function.

Yes, people have been making fun of it for years- and it reached a peak when FuckedCompany was complaining about it a lot. But there are so many good things about it a lot of people turn a blind eye to. Hell, the Verity engine itself is worth the entire package price. I can set up a searchable index of PDF, Word, Text, files in about 30 minutes. This is stuff that people want, and really appreciate.

Career

[daeg]

I, too, have PHP to thank for a wonderful career. While I know that PHP is not the best language for the massive applications I've done, PHP developers are relatively easy to find and train. That is a major marketing factor for companies. Rails is great but how many (available!) workers are there? Very few. Same with Python. PHP can be very powerful when done right. The last major system I wrote with it included a call center (using the wonderful company Voxeo for hosting) that dropped right into the CRM and loan processing software. The current system includes a self-running tiered hosting system (Bind 9, Apache 2, PHP 5.1-dev, PGSQL 8); the daemons (written in PHP) detect server load and move sites accordingly to other slaves.

Re:Career

[doubledoh]

I don't agree that PHP can't be used for "massive' applications. If you can write a good small application using php, you can write a good massive application with the same tool.

I'm getting tired of hearing people arbitrarily say that php (and mysql) are not effective tools for massive tools or audiences.

Languages and server technologies have very little to do with an application's speed, security, or feature-sets. Ninety-nine percent of an application's success is how well it is written and organized. Previous posters have chimed in on this point. Bad code is bad code written in any language. Excellent organized, abstracted, and well documented code can be infinitely scaleable and easy to use.

PHP is not the problem, it's the php community. One of the negative effects of having a language become so popular and widely supported (like php) is that everyone and their brother starts coding simple php apps (that grow into jungles of tangled doom). I recently download a dating software suite written in php, and I couldn't believe how aweful it was. It was about 3 times more complicated and obsfucated than it needed to be. Why? Well, I got the impression that the coders were learning how to develop the application as they went along. There was no underlining design structure...just a bunch of addons and overall BS that quickly inspired me to hit the delete button.

Hardly any "php developers" that I know have actually read a book (on or offline) that discusses intelligent application and db design. Most people learn how to use basic functions and jump right in. This is great in that php allows you to easily jump in, but it is awful at the same time, because these messy amature coders decrease the percieved value of this potentially excellent tool-set.

Most ASP.NET and Java programmers that I know are *REAL* programmers that actually spent time studying *proper* application design and abstraction methods. PHP, because of it's easy accessibility (and web-based audience) attracts more lazy/inexperienced designers (imho).

In short, PHP is a great and powerful language popularized by not-so great budding web-programmers. As more *professionals* give the language the credit and chance it deserves, I think we'll see more powerful and scaleable applications emerge that will discredit claims that php is only good for smaller projects.

Ok, I'm done.

I chose PERL

[Dog135]

When I was trying to decide whether to learn PHP or Perl a few years back, I ended up deciding on Perl. My programming syle is: Give me a few simple commands I can easily learn, I'll figure out how to get the rest working. (Plus, cpan is just cool)

Also, I like to write a lot of simple CLI programs, and Perl is a natural for that. (Though I still write many of mine in C++ for the speed boost)

Re:PHP definitely does not follow the KISS princip

[arkanes]

Versions of CF less than 5 years old pretty much spank PHP. As soon as it got first-class UDFs, the power really expanded. CFCs are super. PHP gives you much easier access to some a lot of low-level functions (file manipulation is a pain in CF), but CFs modularity (what? There's more than just includes?) and stuff like the cfquery/DB abstraction layer is far superior to PHPs.

Why I Like PHP

[ajs318]

I like PHP because it's basically a bastardised dialect of Perl, and I like Perl.

I like Perl because it uses different operators for string concatenation and addition. That doesn't sound like much of a reason, but a lot of the programming I'm doing seems to call for either adding numbers or concatenating strings.

Now, in some languages, strings and numbers are completely different types. Then it's sort-of OK to recycle an operator to mean something completely different, because the computer knows what you mean. But there are several dynamically-typed languages which use + to concatenate strings. Then the magic guesser gets its knickers in a twist with not being able to work out whether something is really a number or just a string that looks like a number. This causes problems when you try to add numbers and find yourself concatenating strings. I wasted the best part of a day on a stupid bit of JavaScript for a DHTML application with increment/decrement buttons.

In Perl {and in PHP}, 3 + 4 gives 7. "3" + 4 gives 7. 3 + "4" gives 7. And "3" + "4" gives 7. If you actually want to concatenate the 4 onto the end of the 3, you have to use the concatenation operator . instead of the addition operator +. 3 . 4 gives "34". "3" . 4 gives "34". 3 . "4" gives 34. And "3" . "4" gives "34". That is simple.

Perl is a bit of a 'mare for n00bs because everything is a shorthand representation. There is the wonderful $_ which avoids cluttering up your script with temporary variables. You don't need brackets round function arguments {like the British BASIC dialects of the '80s}. Everything is optimised for the hardcore hacker, not the beginner. It only looks pretty when you realise that simplicity is beauty.

PHP has a more consistent interface than Perl. So you can't just drop in a regular expression, you have to call a function with the regular expression inside a string. It also does more stuff automagically for you, like keeping hashes ordered {Perl doesn't bother, expecting you to keep a separate array if you really care} and dereferencing everything {Perl expects you to manually create and dereference references when you make multidimensional arrays}. So it's probably a bit slower running, but it's quicker to get an app up and running.

Re:Why I Like PHP

[texwtf]

Perl has ordered hashes, just not as part of the core language. I use Tie::LLHash all the time in my code, e.g.

Re:Why I Like PHP

[Indigo]

I like PHP because it's basically a bastardised dialect of Perl... Heh heh. I dislike PHP for exactly the same reason.

Sorry to disagree with you

[Spy der Mann]

If you know the basics of multitier programming, you can make wonders with PHP. I built myself an MVC framework based on a php-based template engine (search 'Beyond the Template Engine' in sitepoint.com).

To add a new module, I just copy/paste from a previous module.php. The business tier functions are in the business subdirectory, it's just a matter of creating a new lib and add the corresponding functions.

The data-tier uses a (secured) derivative of PHPLib's dbmysql.php (there's a subclass for reading, and a subclass for reading/writing).

And what can I say about the templates? They just get the $data array. The greatest virtue of PHP IMO, is its recursive associative arrays, they're wonders for multitier!. The rest of formatting is a bunch of heredocs, sprintf's and echo's.

As for the always-used functions, i.e. security, privileges, etc, they're in the core/ subdirectory, and called by prepend.

It took me a couple of weeks to write it (after having studied multi-tier programming of course), and slowly i've been making modifications. I've added web setup and table upgrading(installation), database backups, a user log, upload/download logs.

Now, not everything is perfect. There IS a downside to using MVC in PHP: Adding new modules is so easy it gets boring. :)

See, It's not that there aren't ways to program a good e-business app using PHP. To quote Guybrush Threepwood,
"Yes, there are. You just never learned them."

Re:PHP definitely does not follow the KISS princip

[auctoris]

And for all the power (maybe more) of PHP with simplicity and consistency, there's Lasso. It's not free, but it's worth every penny.

PHP Roadmap

[youknowmewell]

Does anybody know where I could find the PHP roadmap (if there is one). I looked all over the place, searched the php website and mailing lists, searched google, but I got nothing. What's in PHP's future?

Re:PHP Roadmap

[Dr.Dubious DDQ]

I USED to be able to follow developments in PHP via the PHP Weekly Summaries, but these "weekly" summaries got sporadic late last year (several weeks without any, then the missing weeks would all show up at once) and now it hasn't even been updated in several months...

PHP IS still being developed, I assume, but I haven't spotted any news on it in some time...

Re:ASP was born in 1997 and...

[aweiland]

And Zend has the same corporate machine to push it's products as MS?

Single biggest reason

[ari_j]

PHP is the single easiest language to write simple web applications with. And by "simple", I really mean simple. Everyone suggesting Ruby on Rails to replace PHP has valid points, but forgets this little feature. Let's just compare the two for a moment. With Ruby on Rails, I read a 5-page tutorial that gets you up and running with a basic application. Just getting the application created took two pages of the tutorial.

With PHP, when you want to get started on something, you don't have to invest any time at all into setting yourself up to begin. You just dive in. The only command needed to start a PHP project is 'vi index.php', and immediately you are working.

You can fight over which language is the best at actually doing the job all you want, but the most popular language is the one that wastes the least of your time on logistics. That's why Perl is so popular for scripting, and it's why PHP is so popular for web applications.

Re:Single biggest reason

[Adnans]

I would say those 5 pages of tutorial are time well spend! By the time you're ready to access a database through PHP you will have won back the up-front Rails time a hundred fold :-)

The only thing PHP has going for it IMHO is the massive amount of cut 'n paste sources that are out there. Other than that, it sucks really hard when comparing it to RoR!

-adnans (who earns his living by doing PHP/Java and hopefully soon RoR)

Re:Single biggest reason

[ari_j]

You're right, but I wasn't talking about the merits of the language; rather, the reason it's popular. If people thought rationally about their decisions, they would use something else, but PHP gives the instant gratification that people want.

Give PHP a rest

[Colonel Panic]

Ten years of hard work. Now the tired PHP has earned a well deserved rest. Ruby on Rails is much more energetic at this point.

Re:PHP definitely does not follow the KISS princip

[atomm1024]

I use PHP as one of my main languages, but you make many good points. I really hate the function-name inconsistency -- it's a good thing it's so well-documented, because I need to look up the correct spelling nearly every time I need to use some string function. Or nearly any built-in function, for that matter.

Another thing I dislike about it is that it's not fundamentally object-oriented. That's one thing I absolutely love about Python -- _everything_ is an object. I love being able to perform methods on strings and arrays, instead of having to pass them to global functions. And with PHP's built-in functions, there's so much C-style pseudo-object-oriented programming ("POOP", appropriately), like where you call a method to create a session or context object, and you pass that context as the first argument to other functions that work with it. That's just bewildering. There's object-oriented support, so why on earth must they have such unelegant messes of procedural programming at the core?

The only reason why I stay with it is that it makes web programming much easier, since it can act like a template language, embedded within HTML pages. For serious non-web programming, I've been migrating to Python, for maximum harmony. I just wish it had better documentation.

Re:PHP definitely does not follow the KISS princip

[Anonymous Coward]

So you came accross a few sites that someone programmed poorly.

"but it just doesn't cut the mustard for robust and reliable web code"

Yes, It absolutly does. You obviously haven't used it on a high enough level. Extermely reliable code. Once you code it right, it will work everytime.

Reliable code is up to the programmer (scripter)

But, since this is super slash dot, I'm sure I'm outnumbered on the site.

Re:PHP definitely does not follow the KISS princip

[AKAImBatman]

Before I speak, allow me to point out that I've worked with ColdFusion for several years myself. So I know what I'm talking about when I say IT SUCKS!

The purpose of languages like Java (and by extension JSP) is to prevent programmers from making really stupid mistakes that make sites unusable. ColdFusion has NO protection against stupidity, and will happily blow up in the tinest of situations. Especially when its coupled with Stored Procedures (the 'Standard').

And yes, I'm leveling these accusations against CFMX as well. CF is just painful to work with, and creates many more problems for the programmer and users than it should.

Umm

[MichaelPenne]

are there any sites using jsp anywhere near the number of pages/day of Yahoo?

The largest jsp site I've heard of is ebay, ~1/3 the size of yahoo, and still using IIS for many of their hi-load parts (https://signin.ebay.com/ws/eBayISAPI.dll?SignIn&r u=http://www.ebay.com/).

BTW, why is it taking ebay so long to switch over to jsp?

Yahoo switched to PHP from their in-house scripting language.

And evaluated & rejected J2EE and jsp in the process. I'll let you google that for yourself:-).

Re:Umm

[njcoder]

"BTW, why is it taking ebay so long to switch over to jsp?"

Try asking IBM Global Services that.

"And evaluated & rejected J2EE and jsp in the process. I'll let you google that for yourself:-)."

Don't have to google it since I already know the answer. Have a look at why yahoo didn't choose JSP here.

Pros
- strongly typed
- good performance (JIT), sandboxing
- works w/lots of off-the-shelf software

But... you can't really use Java w/o threads
Threads support on FreeBSD is not great

So if it wasn't for FreeBSD, yahoo might have gone with JSP.

Re:PHP definitely does not follow the KISS princip

[MBraynard]

Please note, however, that CF costs moh-naaaay whereas PHP doesn't cost anything. I also use it for semi-enterprise stuff - works fine. ("but you can't afford CF?" - no, I'd rather save the money).

PHP MVC

[Anonymous Coward]

There are several PHP-based MVC frameworks. My favourite is Cake, who's basically an attempt on implementing Rails in PHP: http://sputnik.pl/cake/

Re:PHP definitely does not follow the KISS princip

[MBraynard]

PHP is not an inherently easy language.. it's just one that lets you code sloppily and get away with it.

That's why I love it!

Re:First AC

[foobar_fred]

Also, PHP is popular with bosses for writing windows drivers. This is called PHB-PHP-PNP.

Which libraries have threading problems?

[emarkp]

But from what I've seen most webhosts use 1.3 with php because of some threading issues with some php libraries and the apache 2 series of server.

Which libraries are these? I keep hearing the "some libraries" line, but have yet to see an enumerated list. I'd like to avoid those libraries.

Re:Which libraries have threading problems?

[njcoder]

"Which libraries are these? I keep hearing the "some libraries" line, but have yet to see an enumerated list. I'd like to avoid those libraries."

No idea. Apparently there are a lot of them. This quote is from Zend.com "Due to the fact that there are more rather than less of non-thread safe libraries...". (page http://www.zend.com/zend/week/week131.php#Heading3 )

It's a shame too. Apache 2 can be up to 3 times faster than 1.3 using mpm-worker.

It's how you use it...

[sherriw]

I've been developing website backends in PHP for 3 years, and large enterprise-scale apps for the past 1 year. It's a common misconception that PHP isn't appropriate for large applications.

It's all in how you use it. Do you hack together a bunch of pages with isolated scripts talking to html forms and databases in an ad-hoc manner? Or did you start with a solid application design model from the start and follow through with time-tested methodologies?

PHP gets a bad rep because of the large number of inexperienced developers using it with poor results. I've developed full CRM and ERP apps with it including invoicing and ticketing systems that scale beautifully and are a dream to maintain. PHP is fast, free, and easy to use.

It's the responsibility of the developers to use more mature practices when developing large apps- and to recognize the fact that small site admin areas often evolve into larger apps. Plan and design!

Re:It's how you use it...

[julesh]

Indeed. As someone who's recently worked on a 3-tier application produced using PHP communicating with XML between the tiers and using a PHP-based templating engine to produce the pages at the web tier, I feel qualified to say that PHP certainly can be used for such applications.

Sure, we pushed the limit a little, running up against bugs in the database API extension (here's a suggestion: if you have a choice, don't use Informix for your PHP applications) and bizarre incompatibilities with existing applications (PHP doesn't integrate well; it likes everything to be done its way... for instance, it expects data in cookies to be URL encoded). But it worked, and didn't cost us too much time over another solution. It was probably faster and easier than doing the same thing using Java servlets, I reckon.

Re:It's how you use it...

[doubledoh]

Doh, I just wrote pretty much the same thing in another post. Good points. I agree 100%.

I'm tired of people saying that PHP isn't good for large projects. PHP is sometimes BETTER for large projects so long as you design your core carefully and have an excellent structure in place.

I think that because php is so popular (and supported on every shared hosting server), there are alot of lazy/inexperienced coders out there that give it a bad rap.

But every other language is no different. Bad code is bad code.

Re:It's how you use it...

[yomahz]

I often wonder about PHP in large scale applications. I'm obviously ignorant about PHP and just as lazy about researching it but maybe you can share a few things that might clear up some of these perceptions about PHP.

1) Transactions
Not just database, but business logic transactions. What kind of support is offered out of the bag here?

2) RPC
What options are available for creating multi-tier applications? Are remote procedure calls limited to XLM and WesServices? Web services are great and all but not exactly efficient.

3) Clustering
Does it cluster well? Sharing sessions, state, etc. between servers?

4) MVC framework
Are there frameworks/support for decoupling your business logic from your view and controller without feeling like it's a kludge?

5) Testing
Is it easy to unit test the application outside of the server environment?

6) If PHP has support for all these, how much coding left to the developer to implement them? IMHO, if you're focusing on anything but business logic, you're wasting your time. A lot of people like to complain about how complex and massive J2EE projects can be but if you're worth a damn as a developer, you shouldn't be writing much of this code at all. With utils like xdoclet, spring, hibernate, maven and a good IDE, the only thing you should be coding is BL.

Re:It's how you use it...

[Anonymous Coward]

PHP gets a bad rep because of the large number of inexperienced developers using it with poor results.

Ah, PHP: the Visual Basic of the open source world.

Re:First AC

[Anonymous Coward]

I hate to break it to you, but the first AC wasn't me. The "first post" by me was the first post of this thread. I have no need for such silly AC games. Especially since my Karma is perpetually at its cap. Even if I were to get modded into oblivion a few times, it wouldn't even put a dent into the karma I earn from normal discussions. So, nice conspiracy theory there, but try again. :-) --AKAIB

Re:PHP definitely does not follow the KISS princip

[bigman2003]

Yes, that is a commonly heard complaint. "It has a low barrier to entry, and does not force you to do things correctly."

Oh well- that doesn't mean that it doesn't do really good things when people actually know how to use it.

I can still churn out good sites, good features, good logic faster than anyone else I know who use other languages.

And once again, if you are having problems with stored procedures, I would say you are doing something wrong. I use them fairly frequently, without problem. (SQL Server)

Version 4.5 was painful- it would suck up all of your memory, then die a painful death. But versions 5, 6 and 7 have been very stable. 6 and 7 are extremely fast.

I think it is a very good product. Not discounting the usability of other products, but this one mistakenly has a bad reputation.

We brought the cake

[mgkimsal2]

http://phpweblogs.com/phpcake.jpg

Yeah, we're a bit over the top for PHP. The whole company had cake and ice cream to celebrate. :)

Re:We brought the cake

[Anonymous Coward]

Your "whole company" could have a piece of that small cake? Wow, big company

Re:We brought the cake

[mgkimsal2]

Whoo hoo - got me there.

There's about 20 people here, and about 12 people had cake, some had just ice cream. Not a fortune 500, but still a real company using PHP.

Easy php installation

[PsiPsiStar]

If anyone needs an easy installation of PHP on a windows platform, try EasyPHP. The site is all in french, but it's free and good. It automatically installs and integrates PHP, MySQL and an Apache server.

Personally, I've set up a lot of moodle sites (www.moodle.org) which is the best free LMS I've found.

Check it out if anyone is into e-learning or web based training.

(Make sure you have a fast server if you want to put a lot of students on it. The quiz modules are very useful, but they use an ungodly amout of resources if you're teaching a class of +30 students.)

Re:Easy php installation

[mgkimsal2]

Not necessarily trying to get you to switch, but logicampus is another free lms, and scales well. It's target is probably a bit different from moodle, as it's not intended to be a quick 'run a class from this' system, but aimed at running a bunch of classes. Anyway, your issue of speed was what interested me, as I know the logicampus scales rather well. We've got someone running 6000+ students doing a couple hundred classes on what I would consider only moderate hardware (2 cpus, 1.3 ghz I think) without any speed issues at all.

In any event, it's still PHP that has made all this possible. Happy Birthday!

Re:Easy php installation

[PsiPsiStar]

Cool. I'll check it out. Thanks much!

Moodle can have a lot of simultaneous users. The problem is specifically with quizzes which create a number of simultaneous hits to the database when submitted.

Re:Easy php installation

[TheoGB]

I installed Apache and then regular PHP on my XP computer at home. Worked like a dream and wasn't remotely hard. The tough bit was then going through and making sure the configuration of my hosters matched what I had on my computer so I could reliably test out stuff. PHP has revolutionised the websites I use. It's fantastic.

Re:Easy php installation

[mgkimsal2]

I haven't tested moodle under any load to speak of (just a few simultaneous users) but hadn't noticed a huge issue. Then again, I wasn't looking for one. It might be worth it to profile with xdebug or the zend profiling tool in zend ide. Perhaps there are not enough indexes on tables?

Moodle's got ~140 tables, I think, and Logicampus has about 100. That's not a huge difference, but the more mysql tables open the slower things can get, especially under a heavy load with an unoptimized server config.

The sin of PHP

[Anonymous Coward]

My problem with PHP is the great sin of integrating layout with functionality.

There's also ADOdb

[Mitchell Mebane]

ADOdb Site

I've never used PEAR, so I can't compare the two, but ADOdb is quite nice from my experience.

Re:There's also ADOdb

[krumms]

ADOdb actually provides a PEAR::DB-like interface in there somewhere.

Jeez, can't anyone see...

[Anonymous Coward]

...the best thing about PHP is that every cheap hosting service includes it. It has already won. Yea like it is the only poor technology in the history of technolgy that has won.

Still, I have to feel with xmlHttpRequest being promoted so heavily the server side scripting as a whole will eventually die.

PHP is great. Would we all rather be scripting in asp?

Re:Jeez, can't anyone see...

[kuzb]

What, are you on crack? xmlHttpRequest REQUIRES having something on the server to talk to. This is genereally a server side language of some kind which in turn gives the client-side javascript what it needs in order to do something.

Server side scripting can't be replaced by javascript, and even if it could, it never would be, because javascript implimentations can vary so greatly from browser to browser.

Re:Jeez, can't anyone see...

[Anonymous Coward]

I stand corrected. My implementations have been static xml documents, but I would still need php to create the xml on the fly for truly dynamic interactions.

Will you ever forgive me and do I have to use crack?

Still broken.

[Pingster]

Ten years and the == operator is still completely broken. Any hope of fixing it in the next ten?

% cat test.php
<?php if ("spam" == 0) print "I am insane."; ?>

% php test.php
I am insane.

%

Suppose A equals B, and also B equals C. Any reasonable person would expect that A equals C, right? Oh yeah?

% cat equality.php
<?php

$a = 0;
$b = "eggs";
$c = "spam";

print ($a == $b) ? "a == b\n" : "a != b\n";
print ($b == $c) ? "b == c\n" : "b != c\n";
print ($a == $c) ? "a == c\n" : "a != c\n";
print ($a == $d) ? "a == d\n" : "a != d\n";
print ($b == $d) ? "b == d\n" : "b != d\n";
print ($c == $d) ? "c == d\n" : "c != d\n";

?>

% php equality.php
a == b
b != c
a == c
a == d
b != d
c != d

%

Try explaining that to a first-time programmer.

Re:Still broken.

[PigleT]

That's not so much a case of being still broken as having the right to its own expectations, in the absence of a defining standard.

Re:Still broken.

[Anonymous Coward]

try using === instead of ==.
i think it's the wrong default behavior, but it's not broken at all.

Re:Still broken.

[prockcore]

Suppose A equals B, and also B equals C. Any reasonable person would expect that A equals C, right? Oh yeah?

Not in set theory.

"A dog is an animal"
"A cat is an animal"
"A dog is not a cat"

If I were to convert your code into C, I'd get:

if (atoi("spam")==0) printf("I am insane");

Gee... C's "==" operator must be broken!

You're the one trying to convert "spam" into an integer.. and then being suprised to get 0.

Re:Still broken.

[merreborn]

== isn't broken, it's ambiguous and complex. It's also well defined and documented:
http://docs.php.net/en/types.comparisons.html

There are few if any cases where your (0 == "eggs" != "spam" == 0) case comes into play in the field. And for the cases where it might, we have the type-safe === and !== operators. Yes, it seems quirky to a programmer coming from a strongly typed language, but once you adjust, it's not a problem at all.

Re:Still broken.

[_undan]

Well, first of all, I'd ask you to put the crackpipe down. Then I'd belittle your argument by using caustic metaphors, like the following:

You: "PHP! IS A BANANA THE SAME THING AS BOLIVIA?"
PHP: "Um... what? Dude, I'm not a typed language. Don't harass me with that shit. That's Java's thing."

PHP has no "Whatchoo talkin' bout willis?" function. If you give it garbage questions, don't expect the answers to make any sense.

Re:Still broken.

[fred fleenblat]

Gawd, I remember PL/I being broken the same way 30 years ago.

Re:Still broken.

[Euler]

Use a *real* language like Python and you will get:

>>> int("spam")
Traceback (most recent call last):
File "", line 1, in ?
ValueError: invalid literal for int(): spam
>>>

This is the correct behavior for invalid input. Not C/PHP's idea of - 'Oh we can't represent _that_ result, so maybe the user would just prefer silent errors instead!'

Re:Still broken.

[Pingster]

Not in set theory.

The == operator in PHP has nothing to do with set theory. It's called the "equal" operator, so either it should behave in a manner consistent with equality or it should be named and written differently.

You're the one trying to convert "spam" into an integer.

Really. Tell me, where in

$a == $b

did I say "convert to an integer"? No, it was PHP's idea to convert... but only sometimes.

Re:Still broken.

[Pingster]

== isn't broken, it's ambiguous and complex.

Bwahahaha! Thank you, yes, that's the perfect wording. PHP isn't broken; it's merely ambiguous and complex. :)

Re:Still broken.

[Pingster]

If what you're implying is that == shouldn't be used to compare strings, then I agree with you.

Now tell that to all the hordes of PHP programmers out there who do this EVERY DAY.

Re:Still broken.

[prockcore]

did I say "convert to an integer"? No, it was PHP's idea to convert... but only sometimes.

You did it implicitly when you used "==". PHP will *always* convert both sides to the same type when you do ==.

PHP has the === and !== operators for what you're doing.

$a=0;
$b="hello";
$c="hello";

if ($a===$b) echo "never gets here";
if ($b===$c) echo "but these are equal";

Re:Still broken.

[_undan]

Yeah - I don't think it should, as to me, == is a logical operation.

=== is worse, as it makes no sense.

Using strcmp() is better, but it's somewhat unintuitive.

I guess it's a case of programmers needing to learn how to program.

My main point was that it's unfair to pick on PHP because of something which - when done properly - isn't a problem. (Not comparing 'int' and 'string' for starters...)

There's shit code being written everywhere in every language by people of all sorts of proficiencies.

Re:Still broken.

[Pingster]

My main point was that it's unfair to pick on PHP because of something which - when done properly - isn't a problem.

I think that's where we differ. Your suggestions about how PHP ought to be written are reasonable, but I actually am picking on PHP for its poor design. When I say "broken" I don't mean a bug as in the implementation deviating from a spec, I mean Broken As Designed.

When PHP was created, a choice had to be made about what == would mean. And that choice was made in such a way that it would invite bugs; it practically guarantees confusion. In no other language does equality fail to be transitive.

The == operator is typically described as:

A == B tests whether A and B are equal.

but in fact what it really does is:

A == B tests whether A and B are equal or if either of A or B is a number then it tests whether they have the same numeric value, where strings containing common formats for integers and floats are converted to the corresponding numeric value, strings not containing recognizable numbers are converted to zero, and undefined values are converted to zero.

That behaviour is unnecessarily complicated. I claim the design choice was poor, and the widespread misunderstanding and misuse of the == operator provides some empirical support for that claim.

Server Side = Stupidity?

[AVryhof]

I'm sick of people asking me if a browser could fail to render PHP.

They don't get it, what my PHP app is churning out is something between HTML 3.2 and 4 (I don't claim to be fully 4.0 when I'm not)

This is not JavaShit people...it is taken care of by the server before your browser even gets ahold of it.

*anger*
*anger*
*anger*

Ok, time for a coctail.
--
Random Signature #2
Generated by SlashdotRndSig via GreaseMonkey

Why PHP should NEVER be taught to beginners.

[Pingster]

The most fundamental aspects of the language are broken, and will probably never be fixed because they are so entrenched. Here's an example.

Suppose A equals B, and also B equals C. Any reasonable person would expect that A equals C, right? Oh yeah?

% cat equality.php
<?php

$a = 0;
$b = "eggs";
$c = "spam";

print ($a == $b) ? "a == b\n" : "a != b\n";
print ($b == $c) ? "b == c\n" : "b != c\n";
print ($a == $c) ? "a == c\n" : "a != c\n";
print ($a == $d) ? "a == d\n" : "a != d\n";
print ($b == $d) ? "b == d\n" : "b != d\n";
print ($c == $d) ? "c == d\n" : "c != d\n";

?>

% php equality.php
a == b
b != c
a == c
a == d
b != d
c != d

%

Try explaining that to a first-time programmer.

Re:Why PHP should NEVER be taught to beginners.

[Anonymous Coward]

It makes perfect sense if you happen to know PHP.

Re:Why PHP should NEVER be taught to beginners.

[poot_rootbeer]

Your example would also have "wrong" results if it were written in Perl or C.

The "==" operator is a numerical, not stringwise, comparator. An understanding of datatypes is crucial for any programmer, beginner or otherwise.

Even the TRS-80 BASIC I first programmed in 20+ years ago distinguished between numbers and text data...

It may not be insecure, but it is bloody annoying

[peredoc]

I maintain a website built around an interesting collection of commercial, open-source and homebrew code. Recently, we had one bug where one part of the site would stop displaying any data, seemingly randomly.

The only bit of information I had in the bug report was that occasionally that particular section of the site would die horribly, and it would only happen in Firefox. There was no browser-specific code, nor anything obvious that'd cause it.

After about a month of on-and-off head-scratching, I figured it out - and the problem was partially caused by REGISTER_GLOBALS. Another part of the site (built with a different product) was setting a cookie with a paramater name used by the first. The cookie took precedence over the empty querystring, and the first piece of code ended up using a random session ID as a search string.

Why the Firefox red herring? The component setting the session ID cookie was only used by the site staff, and we all use Firefox. When we dropped into IE, we'd only look at the public areas of the site, and so never recieved the session cookie from the staff areas.

Yes, this could have been fixed by code changes in one or both of the applications (and in the end, that's what I did - my initial knee-jerk reaction was to turn off REGISTER_GLOBALS entirely, but yet another package on the site depended upon it). But, REGISTER_GLOBALS encourages action at a distance - in this case, logging onto one part of the site affected an entirely different part. There should not have been any coupling whatsoever between the two components - but thanks to PHP's "helpfulness", a link was created.

Eventually, I hope to get rid of dependencies on things like REGISTER_GLOBALS in the things I maintain. For preference, I'd do that by switching to Perl or Python, but I don't have the time to do that. Instead, I'm stuck in PHP, and cursing some of its more interesting misfeatures...

Why database abstraction can be a good thing

[bharatman]

Two reasons why we use a database abstraction in my open source project.

1. We offer support for MySQL, PostgreSQL and Oracle in the product. People want to run it on those databases, and with an abstraction layer we can provide support for them. If you don't abstract out the database, then you're going to have a hard time time getting database independence.

2. Writing testable code. With a database abstraction, you can inject a mock database object and use it to exercise your code without having to actually talk to the database.

PHP is Commercially Viable

[Anonymous Coward]

Products like PHPAudit make PHP commercially viable as well. You can actually embed the licensing system into your PHP applications and use an encoder such as ionCube or Zend to create byte code that will protect your work from piracy.

A word about PHP...

[d474]

I tried learning PHP, but I just didn't "get it".

Re:PHP definitely does not follow the KISS princip

[julesh]

For a start, PHP functions seem to have no consistency at all. Sometimes you get verb/object, sometimes object/verb. Sometimes you get underscores, sometimes you don't. Consider.. is_object but isset. str_rot13 but strpos. php_uname but phpversion. There are hundreds of these. It's the reason I could never learn PHP, it's like learning Chinese, but I found Perl (and now Ruby) easy due to their relative consistency. Sometimes PHP uses "to", sometimes it uses "2".. huh what's that about?

Most of the functions in the PHP distribution are named after a function that does the same thing in the C library that PHP uses to implement the feature. PHP is designed so that if you're familiar with the C library that it is using, you can very easily get the hang of the PHP version.

This doesn't excuse some of the weirdnesses in the core library, though -- str_rot13 (and the other string functions with underscores in them) is clearly wrong, as the earliest string functions followed the standard C library naming conventions.

To address your other examples: isset() is an operator that looks syntactically like a function, and would have been named in this fashion to mirror the other such operators (sizeof(), unset()). is_object() et al are functions that were implemented independently of this, and at the time there was no conflict. I see no excuse for the php_uname/phpversion difference.

PHP has thousands of core functions.. nuts! And why does PHP have such a bizarre lack of abstraction? PHP often has about 10 functions compared to other languages' single function.. with each of the 10 doing a slightly different thing. When it comes to being overly wordy and inconsistent, I doubt anything can beat PHP, but, well, I'd like to see someone bring up a language that is!

I don't like to nitpick, but... those aren't all core functions. They're just functions that are distributed with the core, kind of like the applications that come with a Linux distribution. You can build a stripped down PHP without them, if you want.

Re:PHP definitely does not follow the KISS princip

[Christianfreak]

Sure the function names are varying, but that can be fixed eventually

At the expense of backward compatability. Who's going to pay to rewrite all that code?

Which fits in the 'easily/cheaply' side of the eq

[MichaelPenne]

if they had to switch their serverOS to use jsp, then it certainly would have been harder/more expensive to use jsp just in switching/retraining costs. If they had touse a commercial server platform to get equivalent performance, it would cost even more.

Of course we don't know how much it would cost to scale jsp to handle yahoo's load b/c no one has tried it yet. Hopefully ebay will release some numbers when they get it going and then we will have some real world data use to evaluate whether jsp can scale to handle the loads php can, and what that might cost to do.

So the best we have now is that jsp might be able to scale as easily/cheaply/well as php, on the right servers (what serverOS would you suggest?). Or maybe not.

By the way, do you think IBM's 'embrace' of PHP might have something to do with their experience with ebay?

Re:PHP definitely does not follow the KISS princip

[fbjon]

No need to sacrifice backward compatibility. If we want underscores as standard, simply make a new function is_set(), identical to isset(), deprecate the old one, and leave it at that. Old scripts will work, but new ones can be made in a coherent fashion.

Re:PHP definitely does not follow the KISS princip

[Disti]

Note that "Perl-compatible regular expression" isn't really completely Perl-compatible, but they might support some features that posix regexes don't and Perl does..

The point being that it's completely wrong to say "you can use Perl's regular expressions in PHP"..

PHP "Scales Down"

[DavidNWelton]

What you are missing is that it takes more to do Java. More resources, more knowledge, more expertise. You may have those things, but many more do not.

I wrote up some of my thoughts on the issue here:

http://dedasys.com/articles/scalable_systems.html

MetaHTML

[leighklotz]

Pre-dating PHP is MetaHTML, developed by Brian Fox (original author of BASH) and Henry Minsky. See the examples.

It lets you define your own macro tags, and it can access MySQL and other databases.

Try it if you prefer a cleaner syntax.

More like "a decade of spaghetti code"

[Laconian]

PHP might be easy to pick up, but boy oh boy does it encourage some bad practices. After I picked up ASP.NET, I said goodbye to the ASP/PHP paradigm and never looked back. I always shudder when I have to hack around with my Wordpress plugins, because they're just a mess of HTML interwoven with conditionals and loops. BLech! That's so 1998! Still waiting for the OSS response to ASP.NET...

Re:More like "a decade of spaghetti code"

[Anonymous Coward]

oh yeah you gotta love ASP.NET
chenge a select box, post
click a checkbox; post
ASP.NET is a pain because it posts your code every 5 seconds; that might be fine on an intranet, but what about those of us on dialup that like to fill out our forms fast.

and dont get me started on the development enviroment changing my HTML

Re:More like "a decade of spaghetti code"

[Kryptkrwlr_XTC]

No you are wrong! There is a property setting with every asp:Element called "AutoPostBack" by default it is set to false. If YOU set it to true then it will do exactly what YOU tell it to do!

As for the IDE changing the HTML style, learn to code it rather than using the designer.

After that post, I would want to remain anonymous too...

Try learning ...

[Ungrounded Lightning]

Seriously, honest question. What's not to get about a language? It's just another language with different options, styles, formats, and uses...


Try learning Navajo, or Basq, starting at an age greater than two years. Then say that again. B-)

like Yahoo?

[pyrrho]

http://news.com.com/2100-1023-963937.html?tag=lh

I've wondered how that turned out. I didn't read any disaster stories... did I miss them?

Re:PHP definitely does not follow the KISS princip

[bobdinkel]

I'll be the first to admit that I know precious little about Perl. So maybe you could educate me a little more here. Specifically, I'd really like to see a regular expression that you could use in Perl that you couldn't use in PHP.

To all you php haters

[Anonymous Coward]

$a = 'abc';
$b = $a[1]; //OMG $b has the chr 'b' in it

Perl people are just jelous =P

Re:PHP definitely does not follow the KISS princip

[ahdeoz]

okay, make a list of all the PHP functions whose parameter order or phrasing causes your brain to overheat, and then tell me whether you prefer camelcase or underscores, and I'll have the perfect language for you by tomorrow. Only you'll have to ignore all the extra functions that may duplicate the functionality of others, if you want there to be OWWTDI.

Seriously, if your only (cribbed) gripe with PHP is that perl has regular expressions built into the language syntax, and PHP uses functions, some of which may seem redundant) that's high praise indeed.

Re:Which fits in the 'easily/cheaply' side of the

[njcoder]

"if they had to switch their serverOS to use jsp, then it certainly would have been harder/more expensive to use jsp just in switching/retraining costs. If they had touse a commercial server platform to get equivalent performance, it would cost even more."

I don't understand the point of this statment. What yahoo said was they didn't choose jsp/java because FreeBSD's threads suck. That's not Java's fault. That's FreeBSD's fault.

"Of course we don't know how much it would cost to scale jsp to handle yahoo's load b/c no one has tried it yet."

We also don't know how much it will cost for Yahoo to completely handle Yahoo's load. Yahoo didn't rewrite their whole site in php and according to them, they have no plans to. "With recent advances in PHP, we have decided to adopt it for some of our new developments, in preference to some of our internally developed technologies,"

They're basically using it for new stuff instead of yScript2. And according to the presentation, one of the reasons they chose PHP is that they can tie it in to their existing C/C++ backend or to new C/C++ code when performance is critical.

So, we don't know how much of Yahoo's processing is done by PHP, yScript, yScript2 or C/C++. But we do know that it's not all PHP. And they're not using PHP alone, they're using ioncube's php accelerator which is free but not open source.

I don't know if you're trolling or you've only read the headlines. I'll give you the benefit of the doubt of not knowing the details. That link to the presentation should clear up some stuff.

"Hopefully ebay will release some numbers when they get it going and then we will have some real world data use to evaluate whether jsp can scale to handle the loads php can, and what that might cost to do."

Sun had released some information regarding eBay. They were consutling on the project as well. Their servers are Sun servers running Solaris. eBay gets something like 1Billion hits a day, which is comparable to yahoo which I think gets 1.5Billion. Yahoo has over 4500 servers, that works out to about 333,333 hits per server per day. That doesn't sound all that impressive to me.

Hopefully ebay will release some numbers when they get it going and then we will have some real world data use to evaluate whether jsp can scale to handle the loads php can, and what that might cost to do.

" By the way, do you think IBM's 'embrace' of PHP might have something to do with their experience with ebay?"

IBM will embrace anything they think will make them money. I don't think it had anything to do with eBay. IBM makes hundreds of millions of dollars from Java. The deal IBM struck with Zend is to develop Zend Core for IBM which is just a set of tools and integrations into IBM's database products. Namely cloudscape and db2. Cloudscape is open sourced but db2 isn't. Couldscape is a teaser to try and get people into DB2 if their needs ever outgrow cloudscape. All IBM is trying to do is get PHP developers to buy more of their products.

If you only read the headlines I can see how you might think more is going on but it's not.

Re:PHP definitely does not follow the KISS princip

[dickwolf]

Aha, I was looking for a worse language than PHP and I think we've found it. ColdFusion! How could I forget about that nugget of programming fools' gold ;-)

Ah, you took the words out of my mouth on this one :)

Signed -- another ColdFusion developer

Perl objects

[goombah99]

Interestingly, perl has exactly the same concept of an object as python. Exactly, 100% isomorphic. Python just hides it in syntactic sugar. Perl 6 and ruby now hide it to. But underneath all objects are containers like a hash or array that hold the attribute names, and know where there namespace methods are located.

In perl an object is normally a hash that know the name of the file it was declared in (the Bless operation installs the name of the current package/file into the meta data of the hash variable. ) Now it's easy. all attributes for the object are just the key values of the hash.
Whereas in C++ or pyhton you might write:
x.a
in perl this is
$x->{a}
That is, to get the attributes value just look it up in the hash using the attributes name as the key. Pyhton is doing exactly the same thing under the hood.

Methods are accessed using that package/filename one squireled away when the object was created or "blessed".

so if I wanted to assess a method (e.g. x.meth() in python) in perl I write:
$x->meth()
perl just goes the right file or package and finds a method by the name meth(). under the hood it's actually looking for a method named:
PACKAGE_NAME::meth()
so that you can have the same name meth() in different packages.

Finally inheritance is dead simple. You have a list of other package names. any method not resolved in the current package is searched for in all the packages in the list (in order) till it is found. (this also means an object could in principle, re-write its own inheritance hieracrhy if one could think of a good reason to do so).

Ruby and perl 6 hide away all those dereferencing arrow -> and braces and make it look like python. deep down its essentially the same.

Re:Which fits in the 'easily/cheaply' side of the

[njcoder]

I forgot to mention the main point I wanted to address.

It doesn't matter what Yahoo is running or what eBays is running. The vast majority of people out there are not going to be building sites that handle anywhere near the traffic that those sites handle. If your page renders in 100ms or 200ms it's not that big a deal.

What is important is that you figure out your needs, know what you need to plan ahead for, evaluate the available resources to achieve your goals and choose a solution that works with the skillsets of your team. Making a decision based on what unrelated websites use is a mistake. Almost anything can work. eBay went for years running on a single 3.3 million line dll. Eventually it got to much for them and made it difficult to add enhancements so they switched to J2EE. Yahoo built their own scripting language because there really wasn't anything comparable out there at the time. They even used their own webserver until apache was good enough.

My my, must have struck a nerve

[MichaelPenne]

We also don't know how much it will cost for Yahoo to completely handle Yahoo's load.

Actually, we do. Update your sources. Yahoo is ~3x as large as ebay, and all their presentation logic is in php.

"For example Yahoo!, which serves up 2.85 billion page views a day and supports 345 million visitors a month, uses PHP for all its presentation logic."

And of course their processing isn't all PHP. In fact one of Radwin's core points was that you can take repeatedly run php scripts, and turn them into php extentions to improve performance. It would be foolish to do heavy processing in php (or jsp).

Their servers are Sun servers running Solaris. eBay gets something like 1Billion hits a day

Rather goes to the heart of this issue, I think:

If x 'sux' on your servers (and remember you have hundreds of them), and x is required for y to work well, and you would need to buy expensive commercial servers to use y on your site, and z does as well or better on your existing servers than y could with servers that supported x, you would be pretty silly to replace your servers (or to run around trying to figure out who's fault it all is).

So the question was what servers would be required to get jsp to compete on scalability with php, and your answer is Solaris? Or do you just not have any idea?

they're using ioncube's php accelerator which is free but not open source.

So that IS kind of like java, then:-). On the other hand, Yahoo could switch to an open source accelerator if they wanted/needed to.

When is Sun going to open source java?

Re:My my, must have struck a nerve

[njcoder]

"Actually, we do. Update your sources. Yahoo is ~3x as large as ebay, and all their presentation logic is in php."

Ok I was off on the number of hits but that link you provided just proves that php is used for the presentation logic. Sounds like they're still using a good bit c/c++ for the business logic. You obviously didn't read the comments of the blog where Michael Radwin said:

"Actually, I did send the author various comments and corrections, but not all of them made it into the final draft. That particular comment was taken a little bit out of context (he asked if we did presentation logic in C/C++, and I answered that we never did it there, but instead at the higher-level languages like PHP). Oh well.

The percentage of Y! pages that are served via PHP is actually pretty high now.

In any case, given that Y! has 90 properties, there's pretty much nothing you can say about Y! technology that's uniform across all sites. You can't even claim that "Y! is a Unix shop" since we actually still have a Windows presence in some of our streaming media properties."

"And of course their processing isn't all PHP. In fact one of Radwin's core points was that you can take repeatedly run php scripts, and turn them into php extentions to improve performance. It would be foolish to do heavy processing in php (or jsp)."

Ok so you agree yahoo isn't completely done in PHP. The heavy processing is done in c/c++.

And you're right. You wouldn't want to do the heavy processing in JSP. But you can do it in Java and most people do. So you're still using the same technology, Java, throughout. When Java runs on a server it gets compiled to native code and can run as fast as c++. Radwin himself says "He's right that Java is actually faster than PHP because Java is a compiled language and PHP is not." He also says that 99.9% of the time it doesn't matter, but when you can use java instead of c++ and keep a consistent development language through out the project then it makes a big difference.

If you want more detail you can view the pdf of the ebay presentation from javaone at http://javaoneonline.mentorware.net/servlet/mware. servlets.StudentServlet?mt=1059358931640&mwaction= showDescr&class_id=21813&subsysid=2000&fromtopic=S earch That type of architecture is probbaly going to go over most people's heads. Have a look at some of the tutorials at http://www.netbeans.com/

So PHP may be easier for some people but c/c++ certainly isn't as easy. If you're going to have to learn a high level language why not choose one you canuse consistently throughout?

"So the question was what servers would be required to get jsp to compete on scalability with php, and your answer is Solaris? Or do you just not have any idea?"

I've personally run servlet containers like tomcat on windows, red hat, debian and solaris. All you need is an OS, (you can get debian or solaris 10 for free), a JDK (you can download Sun's JDK for windows, solaris and linux for free), a servlet container (you can get Tomcat for free and it runs on windows, unix, linux and others). In my tests on windows and solaris x86 I found that Tomcat 5.5 was faster than Apache/PHP by about 2x. That's pretty sad considering my php page just had a couple of includes and a little bit of formatting logic while my Java page did a hell of a lot more including connecting to a database!

Look at playboy.com, they use a lot of tomcat, resin and I think even jboss.

" When is Sun going to open source java?"

Who knows and frankly I don't care. It's free enough for me. Kaffe, GCJ, GNU Classpath and Apache's Ha

Re:PHP definitely does not follow the KISS princip

[colfer]

Since regexes must be quoted, there is a problem with the /e modifier which cannot be fixed.
See: http://bugs.php.net/bug.php?id=15050
It comes down to this:
$text=preg_replace("/(.*)/e","'\\1'",$text)
will never work right if $text contains the character ", and
$text=preg_replace('/(.*)/e','"\1"',$text)
will never work right if $text contains the character ',
because a backslash is introduced.
So you have the write a function to remove the \ and put that function in the replacement string.

And plenty of other features are missing that Perl has with m//, s///. For instance, m//g.

In general, Perl is more reliable than PHP, and I prefer it, but PHP does have two advantages:
1. on a typical Linux/Apache system, without mod_perl, Perl spawns a process on every reequest.
2. session-handling.

Re:PHP definitely does not follow the KISS princip

[shiflett]

It's KISS, not KICS. You can argue that PHP isn't consistent (although it's a tired argument), but you've done nothing to support your claims that it isn't simple.

PHP's simplicity stems from some of the things that you complain about - verbosity being one. Whereas Perl (a language I also love) has many powerful operators, these are not intuitive. An inexperienced developer has a lower chance of intuiting the purpose of a cryptic Perl operator versus a verbose PHP function name.

As for the consistency argument, much of that also stems from the fact that many PHP developers are also C developers. I think Rasmus once said something like, "If anyone ever changes strlen() to str_len(), I'll cram an entire K&R book down their throat."

Re:PHP definitely does not follow the KISS princip

[Tante]

Versions of CF less than 5 years old pretty much spank PHP. As soon as it got first-class UDFs, the power really expanded. CFCs are super. PHP gives you much easier access to some a lot of low-level functions (file manipulation is a pain in CF), but CFs modularity (what? There's more than just includes?) and stuff like the cfquery/DB abstraction layer is far superior to PHPs.

okay bullshit. How is registering each odbc connection really a layer of abstraction? Plus what about sql nuances between databases? Try using a real abstraction layer like Pear with php. You just give it a database and login info and you are good to go. That is abstraction.

How is this a troll?

[Anonymous Coward]

Someone's gonna get it from the meta-mods..

Unicode?

[Anonymous Coward]

A lot of people still don't get it, but you can't argue with its success.

On slashdot, of all places, you're saying we can't argue about something? :-)

So, how's Unicode support in PHP these days?

*...cricket chirping...*

It's great that PHP is being used by lots of people, but as long as it doesn't support Unicode, I'll never be able to use it on big projects, which means I'll never use it for projects that might grow big, which means I'm pretty much avoiding it altogether.

PHP may be more popular overall (or may not -- I'm not sure I believe that). But I suspect Python is much more popular with the "alpha" projects (in the sense of "alpha male", not "development"): big projects, international projects, etc. Given the choice, I want to bet my program on a langauge used by the top projects, not by the most projects.

A decade of PCP?

[Frank T. Lofaro Jr.]

A decade of PCP? Do you have any brain cells left after that?!

Oh, you said PHP. Well my question still stands. :)

Re:PHP definitely does not follow the KISS princip

[jez9999]

2. session-handling

CGI::Session.

Re:PHP definitely does not follow the KISS princip

[jez9999]

See if my site crashes. Then guess what language it was coded in (hint: not PHP).

Yes, I know I'm probably inviting someone to destroy it now. Oh well. :-)

Been there, done that

[MichaelPenne]

The shop I run has been coding web apps in various languages for going on 7 years now.

Once we dropped the others as much as possible and focused on php, our productivity went through the roof.

It's much faster to write the application in php, then identify performance issues and code those functions as c++ extentions than it is to write the whole thing in java. This is Radwin's point, and I've seen it proven repeatedly in practice.

'Java's as fast as C++'. OMFG. LOL.

Re:Been there, done that

[njcoder]

" The shop I run has been coding web apps in various languages for going on 7 years now. Once we dropped the others as much as possible and focused on php, our productivity went through the roof."

That's what happens when you consolidate your energies rather than using a random collection. I'd be interested to know what these other languages were.

"It's much faster to write the application in php, then identify performance issues and code those functions as c++ extentions than it is to write the whole thing in java. This is Radwin's point, and I've seen it proven repeatedly in practice."

There's a problem with that. You now have to have developers know php and c++ which negates one of the benefits of PHP being easier to program. Whereas with Java you're starting off with better speed and if you need to go to native api's you can still do that through JNI and going from java to cpp is a lot easier than going from php to cpp from a coding perspective. (The languages are more alike).

"'Java's as fast as C++'. OMFG. LOL."

Ok, now I know you haven't used java or haven't touched it in years. On the server side JIT compilation really shows it's strengths. And things are going to only get better as cpu's continue to have greater threading capabilities which PHP can't usually take advantage of until more modules are made thread safe. JIT compilers can inline a method increasing performance and use other static calls. Intel worked on features of the P4 and Xeon processors to perform better with code with a lot of branching and inderection. They did this with JVM's in mind. The JIT compiler can reduce the number of branches and it's branch prediction is right most of the time. More than static compilers anyway. Delays on these processors for a correctly predicted branch are down to almost zero clock cycles.

Here are some links in case you don't believe me.

Java Pulling Ahead, Java faster than c++, Computer Language Shootout, http://www.tommti-systems.de/main-Dateien/reviews/ languages/benchmarks.html">This shows them mostly similar, this is an interesting read too

Re:PHP vs JSP - why hosting isn't popular

[batkiwi]

This is why:
Mass Virtual Hosting with php:
1. set up apache for mass virtual hosting (likely with some control panel)
2. load mod_php
3. done

Now sure there's security risks, but if you use safe mode and restrict your base dir, you can alleviate a lot of that.

Now compare that to mass virtual hosting with jsp/servlets:

1. Load a seperate instance of tomcat per user on your machine

That's a big thing to do, and can result in a LOT of memory being used compared to the "1 apache to serve them all" model. That's why you won't see it on most 5$/month type hosting models, but will see it on dedicated (you get your own full server or virtual server) hosting models.

Re:PHP definitely does not follow the KISS princip

[AKAImBatman]

1. What is a PLP file?

2. I'll be nice and forgo any attempts to append ';drop database; to the query strings. ;-)

Wrong, wrong, wrong

[weston]

"you can use Perl's regular expressions in PHP."

Nope. You can't. Well, you can. Well, sortof. Sometimes. With some syntactical exceptions, and lots of thinking about escape sequences, and passing parameters a different way. And that's the gotcha. You start thinking it's going to be the same -- and it's not.

Re:PHP definitely does not follow the KISS princip

[Anonymous Coward]

when casual users talk about advantages,
they always expose their ignorance

1. apache spawns processes, and without mod_php,
it will spawn a php process on every request
2. you're joking right?

Anti-PHP sentiment

[TardisX]

Despite the majority of the Anti-PHP comments posted here being lucid, informational and non-confrontational, they are still moderated down.

PHP programmers - the Amiga owners of 2005.

K.I.S.S. DB wrappers

[Tablizer]

You don't even need to have something complex to wrap vendor-specific libraries. Make simple functions such as "openDB()", "query()", getNextRow(), and "execSQL()" that wrap vendor-specific stuff. Generally you only use one vendor at a time anyhow. Make an optional selector parameter if you need multiple vendor selectors. (Although PHP is goofy with optional parameters sometimes. I hope they fix that.)

Re:K.I.S.S. DB wrappers

[quinto2000]

yeah, actually I usually do that myself since I prefer a DB class that provides a further layer of abstraction, loading a config file with my db name, password, etc. I usually use only one DB (in MySQL terms) per application.

Mine has methods like:

• query (results as an assoc. array)
• exec_query (no results)
• query_retrieve_keyed_list (results as an array keyed on the first field)
• check_predicate (returns true or false, for SQL statements like "col 1 > col 2 WHERE id=2")

and has the additional feature of re-using a single MySQL connection.

but, I don't avoid MySQL specific stuff, so it's not really a database abstraction class as much as a PHP crappy database interface functions abstraction layer :)

Just one thing...

[Anonymous Coward]

one site to explain it all

Re:PHP definitely does not follow the KISS princip

[jez9999]

1. PerlPage; embedded Perl.

2. You can try. I think I've tested it quite thoroughly.

Re:PHP definitely does not follow the KISS princip

[arkanes]

• You can use native drivers in CF. Or a number of different connectivity backends.
• PEARs shitty pseudo-functional crappy SQL generating query engine is the worst damn way to access a database I've ever seen. I was trying to be nice in the original post.
• Even if PEARs implementation wasn't utter crap, CFs model would still be superior - because it's got a consistent, easy to use and easy to model query object representing the result set. Access to this object is consistent with everything else in CF, and it's a first class datatype. Even the block markup is superior in this case, because passing 400 line SQL statements around in strings to PEARS shitty functions sucks.

Get a clue

[MichaelPenne]

performance != scalability.

The original point was 'jsp doesn't seem to scale as well as php', and none of the reams of text you've pasted here comes close to disproving that.

What would are some very large sites using jsp, which for all the links you posted, you haven't been able to show.

More and larger sites use php than jsp. I pointed out ebay, which is still using dlls for much of it's heavy load. You brought up playboy, which seems to be mostly a static site running some cgi scripts: http://cyber.playboy.com/cgi/ab.cgi.

The proof is in the implementation, we know php scales and jsp, well there are plenty of fanboys who will post endless scholarly diatribes about how great it would be if someone would listen too you, but you don't seem to be able to produce any very high load sites to back up your case.

So I'll ask again, what are the largest sites running jsp? If you are going to post benchmarks again (b/c you can't find any jsp sites of major size), please try to stay on topic: benchmarks showing how java/jsp handles thousands of concurrent users, how it compares to apache/p* in a high performance cluster, etc.

Re:Get a clue

[njcoder]

"The original point was 'jsp doesn't seem to scale as well as php', and none of the reams of text you've pasted here comes close to disproving that."

No, the original point was that you said " guess the other thing is that Apache/PHP seems to scale better (or at least easier/cheaper [internetnews.com] than Tomcat." The article you link to doesn't mention java or tomcat at all. The presentation that is linked from the article doesn't mention tomcat but it does say good things about java/jsp/j2ee but they couldn't use it because freebsd's threading sucks. I should have known better than to start a discussion with someone that cites an article to back up his claim when it doesn't even mention what he's claiming.

"What would are some very large sites using jsp, which for all the links you posted, you haven't been able to show.More and larger sites use php than jsp. I pointed out ebay, which is still using dlls for much of it's heavy load. You brought up playboy, which seems to be mostly a static site running some cgi scripts: http://cyber.playboy.com/cgi/ab.cgi."

eBay used to use a dll. The dll is their old architecture, when they finish the migration the dll will disapear. eBay is a complicated site and the migration will take time. A lot of ebay is currently running on websphere. You can't easily tell because they don't use the .jsp extention for their files. That's a big site. They may have 1/3rd the traffic of yahoo but their profits and revenues are about the same. Playboy does use java. I think they use a mixture of JBoss and Tomcat. Just because a page says .html doesn't mean it's a static page. A lot of times, I've noticed this with JBoss especially, files look like html but they're not. You can see this at the sims online too, which also uses jboss. Look at this url from playboy http://www.playboy.com/magazine/playmate.html?sour ce=playmate_sectionfront since when can you pass query parameters to STATIC HTML? We used this technique with sites I've worked on as well where we set up our container to recognize .html files as jsps. If you look at netcraft.com for the server info you'll see playboy.com uses mod_jk whick is the connector to Tomcat. Sometimes it's hard to tell what sites use java since many times they'll use a servlet controller that calls the jsp's behind the scenes. Sometimes you'll see a .do which is the typical way to use Struts, but not always. Here's a bit of info on capital one they use java for a lot of their stuff. I think they use oracle's application server. B&H Photo uses java for their ecommerce site (Probably the most popular online photo/video retailer) but you can't easily tell from looking at the urls unless you know what to look for. bnh is the servlet context, controller is the main servlet handler and home is a page handler. Years ago they used to use Bluestones application server. Now it seems they're just using Netscape Enterprise Server. If your brouse certain sites with cookies disabled you can sometimes see a jsessionid in the url, that's a sign it's running a java web container. Verizon Online uses Java for their clients web email and a bunch of other support functions. Have a look at Bea's Client list among some other big names you'll find Amazon.com and FedEx. Ofoto.com, now Kodak Easy Share, uses jsp. Here's a story on jboss writing their own postnuke style cms in java because php didn't scale as well. These are just the few I could remember off the top of my head. And I've done my own benchmarks for m

Hacking on other's PHP code

[Anonymous Coward]

A big problem in hacking on other's PHP codes comes from the fact that the PHP code patterns of other people's code don't only contain the result of their preferred coding style, but also of the fact on which of a function out of several to accomplish a certain goal they've stumbled upon first.

This means that if you take several code portions written by different people that accomplish a certain task, they will look not only differently structured, but will also to a great deal use a different set of functions/methods.

what he means...

[namekuseijin]

"those aren't all core functions. They're just functions that are distributed with the core" ... is that there's no module mechanism in the language: all of them share the same namespace and name clashes can and will occur.

class alone won't cut it.

Re:PHP definitely does not follow the KISS princip

[colfer]

I admit I'm casual at work, but it is what I work on.
1. apache processes: PHP as a module is the most common setup I've seen, while mod_perl is a problem, esp. with shared hosting.
2. Sessions. PHP tries some good stuff, including rewriting all your links with the SID if cookies are disabled. But yes, PHP's possible flakiness is worrisome. Perl's still the gold standard for me. But compare trying to do *very* simple Sessions:
PHP:

session_start(); // turns on output buffering, handles cookie and non-cookie case
@$_SESSION[$ct]++; // read/write a session variable without any special syntax
// that's all, session writes when script ends.

Perl:
CGI::Session::CookBook
...and you have to worry about not printing before the cookie, etc.

Re:PHP definitely does not follow the KISS princip

[Peter Cooper]

It's KISS, not KICS. You can argue that PHP isn't consistent (although it's a tired argument), but you've done nothing to support your claims that it isn't simple.

But I'd say consistency and simplicity go hand in hand. If you need to keep looking at the documentation (as one respondent above claims he does when using PHP) or remember lots of functions parrot-fashion (like learning French nouns) then it's not "simple", is it? Simplicity is consistency.

Re:First AC

[Anonymous Coward]

I realise that, the point to me was, that question was redundant, therefore the ansver is too redundant.

If I'm reading a thread about PHP I actually can du just fine without posts explaining the basics of it, that's why I browse on +3.

Also, it's an interesting strategy that I have thought of trying some time, that's something moderators should be aware of even if your case wasn't that.

Re:

[Anonymous Coward]

If you ever plan on writing cross-system compatible code, you'll soon stop using that.

WRONG

[ylikone]

It is NOT depreciated. mysql_escape_string and mysql_real_escape_string do two slightly different things. Read it at php.net for yourself.

thank you PHP

[griasr]

thank you PHP. i owe you my life.