Forum OpenACS Q&A: Updated technical answer for "the PHP Question" Requested

Can someone offer an update to the "why Tcl and not PHP?" answers found at

https://openacs.org/forums/message-view?message_id=15692

and

https://openacs.org/forums/message-view?message_id=16951

(The answer then -- summer/ fall 2000 -- seems to have been that Tcl was a better fit than PHP for the speed/ scalability-enhancing multi-threading capabilities of AOLServer -- which based on Philip's book was the reason NaviServer/AOLServer was originally selected over Apache for aD sites and ACS.  Was this a function of inherent advantages of Tcl itself, or related to differences between the Tcl and PHP interpreters developed for AOLServer? Is this still the case?  Have Apache and for that matter MySQL evolved since then to close the gaps between them and AOLServer/ Postgres?)

Please help me address this question by arming me with good technical answers so I can pitch more effectively!

On a related note, does anyone have any views on how

http://tikiwiki.org/tiki-index.php

compares with where we currently are functionally and architecturally with OACS/.LRN?

One of the forum threads contains a message:

https://openacs.org/forums/message-view?message_id=15923

that mentions a possible port.  Are these two related?  the old link seems dead, but perhaps someone knows some history...

Thank you.

I found this critique of PHP:

http://www.bitstorm.org/edwin/en/php-sucks/

Can someone help me gauge its accuracy and validity?

TikiWiki is very nice in some ways.  But it is extremely slow.

Even with the use of the PHP accelerator code like APC or MMCache I found its performance to be very poor.

It would take more than 1 second to generate a page in some cases.

So effectively the server could only serve 60 page hits per minute, max.  On the same hardware, an out-of-the-box OpenACS could serve 9 pages per second (540 page hits per minute).

Nice features:

if a module is installed, it can be set to automatically show up as a portlet on the home page

any page can be turned into a PDF by clicking a link

it keeps track of where you have been on the site, so you can easily go back to where you have been

There are others as well.  However, I would say that it is more difficult than OACS to customize, due to their using so many different PHP packages (Smarty for templates, ADODB for database access, etc.), which require you to know all about how those work in addition to knowing how everything fits. For instance, Smarty uses C-style date specifiers, while PHP has its own.

I'm not sure you should have to market on that level, as you will loose any real argument with IT guys when it comes down to their core fears:

- Knowledge. There a hundred thousands of people that write knowledge of PHP on their resume. They know it, because it is easy to learn, there are courses for PHP in every university and if you want to extend your PHP solution you can just pick the guy around the corner. Though this statement is naive as it seriously neglects the fact that in any decent sized software project, knowledge of the API of the toolkit is considerably more valuable than knowing the programming language (ever saw someone advertising: "Looking for developer with BASIC skills?". On the other hand there are ton's of adverts for people with "Visual Basic Skills"). And I'm pretty sure you can ask any developer in the community that the ratio "learning tcl" vs. "learning openacs api" is around 1:10. But again, this is something often overlooked by IT people

- Our neighbours are using it, we use it, you can't fire me for choosing what they choose. Though this isn't as strongly true as it was before, you still won't get fired for choosing Java, SAP or any other major force in the landscape.

- Market awareness. There are 173 books in german on PHP. There are 19 on TCL. There are around 700k hits for "tcl language" on google, around 8000k for "php language".

Now for some of the good things of TCL:

- Reliability: The language is 15 years older and still as capable as PHP, with a higher grade of maturity (as the links you mentioned above show. The deficiencies are to me clear signs of immaturity).

- Ease of learning: If you know Perl or PHP, learning TCL is a piece of cake. You have to get used to different conventions, but any decent develop should be able to do this.

But why have this argument in the first place? The only answers to this should be:

a) Language does not matter with regards to scripting languages, as you can learn them within a couple of days. The API and development tools are what counts.
b) When Naviserver / AOLserver started, PHP was not even in existence (it's predecessor was developed in 1995). TCL is more mature and used in high risk environments.

Optional: c) In contrast to PHP, TCL does not come from a web only background. This actually might backfire, depends on how you argue the case.

Last but not least, you should always argue with the whole package:

- A multithreaded webserver that runs the worlds most busiest sites, serving personalized content without much of a hickup. Furthermore, this webserver happens to have years of refinement spend on it, bringing it to a fast and reliable state for the applications it runs.

- Postgres / Oracle. In a highly complex environment it is mandatory that your databases fullfil the ACID tests, support transactions and allow operations to be executed via a programming language within the database itself. MySQL does not fullfil these criteria, at least not a year ago and still not completely this year (support for programming language is still missing. Sourceforge (I think) got screwed because the MySQL backup was broken because of a transaction problem. The choosing of Postgres should therefore be justified and you never get fired for buying Oracle :).

- A serious number of pre integrated modules containing over 2 million lines of code (is this the correct number? Roberto ?)

- A vibrant and active community willing to help out people who stumble across any problems with multiple dedicated major players investing over 3 million dollars per year in the development of the toolkit.

And if people ask you why so few people have heard about OpenACS and .LRN be upfront and name the culprit: "Bad marketing".

I usually have success in this argument by "ignoring the question they asked and answering the question I wish they had asked me."

That is, I don't talk about tcl vs php/java/perl etc, but redirect the discussion to focus architectural choices. Then I extoll the virtues of AOLserver.

It is much easier to position the OpenACS as a toolkit built around a wonderful piece of software that runs AOL.com, Mapquest.com, Netscape.com, Moviefone.com, etc than it is to fight Tcl's relative obscurity.

Once I position it in terms of its success in the real world, I open up the technical reasons for a preference of AOLserver, which are:

* Multi-threaded server (like apache 2, but done many years beforehand and is much more reliable)

* Pooled DB connections (like JDBC, but done many years beforehand.)

* Native DB APIs (also like JDBC, but built for particular DBs so more efficient)

* Embedded Tcl interpreter (lightweight, simple, extremely fast scipting that, in concert with the previous three characteristics, makes AOLserver an amazing web application framework.)

The collection of these characteristics make up what is Apache + mod_dbi + mod_favorite-language on steroids. Add in the AOLserver Dynamic Pages (and the OpenACS templating system) and there is a solution far more elegant than anything that PHP or Java offer.

If the fight continues after this, there's not much that can be done probably because the person is particularly set on PHP and Apache or is very against tcl and AOLserver.

If the person is really language agnostic, though, then this is usually a very compelling argument.

talli

Thank you Malte and Talli.

Rest assured my question above is in the context of advancing the case (for a relatively non-technical audience) based not on Tcl vs PHP, but on .LRN vs. custom development using PHP or some-much-less-mature-than-.LRN-framework based on PHP.

Nevertheless the question comes up.  And of course the question begged is "if Tcl has these advantages, why is PHP more popular?"

BTW, did anyone submit anything, or is anyone going to,

http://tcl.activestate.com/community/tcl2004/

?

That question is up there with, "If Saddam had WMD, how come we haven't found any?"

Do like our Leader and avoid it. If you want to win these people over, get them to ask the questions you want to answer.

talli

Path dependent accidents of popularity don't mean much.
if Tcl has these advantages, why is PHP more popular?
Because popularity often has very little to do with quality, of course.

Why, is not entirely clear - as far as I know popularity is not yet a scientifically understood phenomenon. But the fact has been well known for a long time, perhaps for millenia... As Paul Graham pointed out, there's good reason that the common phrase, degenerates into a popularity contest has a strongly negative connotation.

Talli's final answer above is right, of course. Btw, I don't often think about such marketing questions and techniques, so I'm glad to heard this sort or thing every once in a while from those who have.

Experiences of Using PHP in Large Websites is a good article.

I looked at PHP "application frameworks" a while ago and they all (a) sucked and (b) had rabid fanboys.

I found these pages useful:

http://www.databasejournal.com/features/postgresql/article.php/3288951  evaluates MySQL v PostgreSQL

http://www.redhat.com/docs/manuals/database/ may be helpful to those seeking to illustrate commercial support for PostgreSQL

http://panoptic.com/wiki/aolserver/43 lists sites using AOLServer, including several major AOL services.  It should be edited to reflect OACS/.LRN users (any volunteers?)