Slashdot Mirror

That's my impression as well. A somewhat simplistic description of PHP 4's syntax is that it's similar to Perl, but is resembles 'C-like' syntax more than Perl does. A lack of things like implicit variables in PHP seems to make it a little easier to come back to a project months later or look at someone else's code and follow the program logic a little more easily than Perl is. (PHP 5 is adds syntax features that resemble Java more, as well).

PHP has a fair amount of strength in the text-handling area, similar to Perl, but PHP is a bit more 'focussed' on talking to network servers (database servers, webservers, network sockets, ftp servers...).

On the other hand, PEAR and PECL don't have nearly the mind-boggling breadth of add-on modules that Perl's CPAN does...

(As usual, I'm compelled to note that PHP is no longer 'just for web pages' any more than Perl is 'just for generating reports'. I've found it handy for a lot of small system administration tasks that Perl is also good for. You can even use Ncurses or GTK - or, conceivably, Java GUI classes to build standalone apps with it, if you feel the urge...)

That's my impression as well. A somewhat simplistic description of PHP 4's syntax is that it's similar to Perl, but is resembles 'C-like' syntax more than Perl does. A lack of things like implicit variables in PHP seems to make it a little easier to come back to a project months later or look at someone else's code and follow the program logic a little more easily than Perl is. (PHP 5 is adds syntax features that resemble Java more, as well).

PHP has a fair amount of strength in the text-handling area, similar to Perl, but PHP is a bit more 'focussed' on talking to network servers (database servers, webservers, network sockets, ftp servers...).

On the other hand, PEAR and PECL don't have nearly the mind-boggling breadth of add-on modules that Perl's CPAN does...

(As usual, I'm compelled to note that PHP is no longer 'just for web pages' any more than Perl is 'just for generating reports'. I've found it handy for a lot of small system administration tasks that Perl is also good for. You can even use Ncurses or GTK - or, conceivably, Java GUI classes to build standalone apps with it, if you feel the urge...)

1. Think of a task that will take about 20 minutes to program
2. Program it in both Perl (use perldoc as another poster suggested) and PHP (use php.net/manual/en)
3. Wait 2 weeks
4. Attempt to add a simple feature to each script. Time yourself and compare
5. ???
6. Profit!

When I go back and look at my Perl scripts I wrote a couple weeks ago, it takes me a while to get my head back into the script. With PHP, the code is always straight forward. It may be more verbose, but I understand it much more quickly than my Perl.

Besides this, I've found PHP's documentation to be far superior to any other languages'. When I do web programming, give me PHP anyday.

The only thing Perl has over PHP in my mind is that CPAN is currently far superior to PEAR. If you need many special libraries, you may want to consider Perl.

1. Think of a task that will take about 20 minutes to program
2. Program it in both Perl (use perldoc as another poster suggested) and PHP (use php.net/manual/en)
3. Wait 2 weeks
4. Attempt to add a simple feature to each script. Time yourself and compare
5. ???
6. Profit!

When I go back and look at my Perl scripts I wrote a couple weeks ago, it takes me a while to get my head back into the script. With PHP, the code is always straight forward. It may be more verbose, but I understand it much more quickly than my Perl.

Besides this, I've found PHP's documentation to be far superior to any other languages'. When I do web programming, give me PHP anyday.

The only thing Perl has over PHP in my mind is that CPAN is currently far superior to PEAR. If you need many special libraries, you may want to consider Perl.

One apparently-little-used feature I've been wanting to play with lately is the PHP/Java integration. I've been assuming that PHP5 will be more conducive to this.

I've never QUITE managed to get this working on PHP 4 (though since I don't have any specific reason to use it other than 'I want to play with it', I haven't put all that much time into it, either.). Anybody tried this on PHP5 yet? Or know of a fairly thorough explanation of getting it installed and configured?

Most of your criticisms of PHP are totally on the money.

But come on. Once a programmer really gets into perl, only another hard-core perl person can read their scrawl. Don't get me wrong, I love perl. But it's a horrible choice for a large project with many developers.

I've not dug into perl documentation for a while (has it been years?), but last time I checked, it was about 100 man pages. With php, if I think there's a function called split, I type http://www.php.net/split and there's the docs.

Re: perldoc, c'mon! I get the impression you've never had to maintain code written by a hard-core perl programmer (or maybe you are one). For hobby stuff, use any language you want, but for business purposes, I don't want to have to search for developers who are so fucking specialized in perl. With PHP, I can make anybody who learned the basics fo C and make them productive in about 48 hours, working on someone else's code. With a big perl codebase, that same person is going to have to be twice as expensive if they're going to jump in head-first.

Re: too many overlapping core functions - I don't know what you're talking about. There are a few aliases in there (ie: chop or rtrim (which actually is annoying, since chop() should work like it does in perl, IMO)), but I don't see a lot of overlap.

I think perl is really neat, but it's overkill. I know that's the tried and true criticism, but I really think it's true. I don't want to give a group of 4-12 developers of varying cluefulness that sort of capacity to create havoc for each other.

It's Free.

It's free (as in beer). You can get pretty cheap hosting

There are a ton of really useful libraries to play with.

You can (half-assedly) write handy scripts with it, even though everybody uses Perl for that. (PHP scripts can be executed from the command line).

It resembles other languages, which means that when you decide to learn Perl or C or Java, the syntax won't be so foreign.

Some other reasons I can't remember, I just finished off a bottle of wine (damned puritanical co-workers!)

It's Free.

It's free (as in beer). You can get pretty cheap hosting

There are a ton of really useful libraries to play with.

You can (half-assedly) write handy scripts with it, even though everybody uses Perl for that. (PHP scripts can be executed from the command line).

It resembles other languages, which means that when you decide to learn Perl or C or Java, the syntax won't be so foreign.

Some other reasons I can't remember, I just finished off a bottle of wine (damned puritanical co-workers!)

http://php.net/mbstring

First, the two languages are very similar, with PHP biased towards web-programming, mostly by the absense of particular libraries. But PHP is also emerging as a general purpose language. There has been some experiments to get a GTK capability to PHP.

But, if you already have a staff trained in perl, there's IMO not any real reason for you to switch to PHP.
I have, however, developed a preference for PHP, it has a simpler syntax, and better naming conventions. PHP has more text and perl have more meta-characters when defining arrays, doing string manipulation ect. PHP is simply more readable, to beginners at least. What is the point for example for an array to be prefixed by % or @ or $, depending on the context?

I'm mostly of that opinion as well. The author of bTemplate wrote an essay on using PHP as its own template engine. That said, I actually prefer to use Smarty since I do coding and design for our intranet. I've found it easier to switch hats when I have to switch syntax as well.

Whoever said that PHP only uses inline HTML for the presentation layer is a tool.

There are several templating
engines available that effectively separate the application
layer and the presentation layer for PHP applications.
These engines are quite heavily used also (check the source code of most large
open source projects and commercial applications...)

Whoever said that PHP only uses inline HTML for the presentation layer is a tool.

There are several templating
engines available that effectively separate the application
layer and the presentation layer for PHP applications.
These engines are quite heavily used also (check the source code of most large
open source projects and commercial applications...)

Whoever said that PHP only uses inline HTML for the presentation layer is a tool.

There are several templating
engines available that effectively separate the application
layer and the presentation layer for PHP applications.
These engines are quite heavily used also (check the source code of most large
open source projects and commercial applications...)

Whoever said that PHP only uses inline HTML for the presentation layer is a tool.

There are several templating
engines available that effectively separate the application
layer and the presentation layer for PHP applications.
These engines are quite heavily used also (check the source code of most large
open source projects and commercial applications...)

Whoever said that PHP only uses inline HTML for the presentation layer is a tool.

There are several templating
engines available that effectively separate the application
layer and the presentation layer for PHP applications.
These engines are quite heavily used also (check the source code of most large
open source projects and commercial applications...)

Whoever said that PHP only uses inline HTML for the presentation layer is a tool.

There are several templating
engines available that effectively separate the application
layer and the presentation layer for PHP applications.
These engines are quite heavily used also (check the source code of most large
open source projects and commercial applications...)

If you put a site together with a little planning and a properly setup cache and then use a template engine that supports output caching you can rival static pages depending on how often the page "needs" to hit the DB.

This really all depends on the sites content, an average ecommerce site probably only needs to hit the database once a day, slash on the other hand could cache the front page for non-logged in users for 5 minutes, which I believe they are doing now with perl.

As usual YMMV.

Do yourself a favor and do not mix business and presentation...

Somewhere down the line you are going to have a person working on design that doesn't understand PHP and breaks something. Then you can either spend who knows how long to figure out what is broken or throw out their work and just roll back to what's under revision control (you use revision control, right?). Either way you wasted time. Or worst case, nobody notices the logic is broken and it makes it to production.

Go find a template engine that you like and use it. You'll be happy in the long run.

Here's a couple to get you started.

PHPLib
Smarty

I've been using PHP extensively for years now and I can't say I've ever run into a problem with its handling of data types. Let's not forget that PHP is, after all, a scripting language.

I've been using PHP extensively for years now and I can't say I've ever run into a problem with its handling of data types. Let's not forget that PHP is, after all, a scripting language.

Actually, PHP folks seem to think mixing business and display logic is a bad idea (like the rest of the world): smarty.php.net

Well for those of you that don't like MySQL's restrictive licenses and want a quick little SQL db, PHP 5 is shipping with SQLite.

An interesting little database to say the least.

MySQL client libraries have been included/bundled with PHP for a long time now, and MySQL support was enabled by default. As of PHP 5, these client libraries are no longer bundled, and MySQL is not enabled by default. This essentially makes MySQL support like any other PHP extension, nothing special. To install, simply download MySQL and configure PHP with --with-mysql. Not a big deal. You do the same for PgSQL, CURL, TIDY, GD, etc.

An official FAQ on this issue can be seen here:
http://us2.php.net/manual/en/faq.databases.php#faq .databases.mysql.php5

You'll notice that the license issue isn't the only reason PHP 5 stopped bundling these MySQL libraries so I assume despite this license change PHP 5 will not bundle MySQL by default. One might say the marriage continues to exist...but that it's no longer "forced" onto people.

Oddly enough, EV1 themselves falls into this category. PHP.net's main site is hosted at EV1.

"Designing form-based web pages now requires beta testing against IE6, Netscape 7, and every version of Mozilla that ever existed."

There are some solutions which allow you to control the environment your scripts are running in... If you've got anything remotely suited to server-side, then it can remove many PITA (notably, it can save you from having to use Internet Explorer)

Plus, everyone who uses Internet Explorer needs to disable active scripting anyway, just to make it safe to browse the web with. So javascript stuff just stops working, until you get a browser that can deal with it safely, and give you the confidence to re-enable scripting with some limits.

Note: Since PHP 4.3 there is a bundled version of the GD lib. This bundled version has some additional features like alpha blending, and should be used in preference to the external library since it's codebase is better maintained and more stable.

Things are tight fisted because Sun wants a solid, CONSISTANT platform. This was a MAJOR REASON for the lawsuit that they fought and WON against Microsoft and their VM implementation

And, open-source software would be inconsistent because.......?

Inconsistent, like Apache?

or, perhaps, MySQL?

I get it. You mean inconsistent like this, this, or this?

Oh, the above aren't languages, like php or perl?

Eh, wait a minute. These are all *successful* projects, that are consistent?

If Sun were to open Java sources, it would be trivial to introduce a license (EG: GPL) that would largely offset forking of the codebase. Their best bet would be to pull a "QT" - open the source as GPL, then sell commercial licenses.

You can connect using a persistent connection instead of a short one. with the php function ibase_pconnect. That way your connection will be reused. The database performs quite well in my experience.

Firebird (and Interbase) are also supported in PEAR which enables you to write database portable code to a large extent. I use PEAR DB myself.

Firebird (and Interbase) are also supported in PEAR which enables you to write database portable code to a large extent. I use PEAR DB myself.

Firebird is supported by PHP quite well. Just take a look at the InterBase Function Reference for more information.
I guess Perl has a module for it as well...

PHP's PDF Forms support seems centered around Adobe's FDF toolkit. This article and the PHP manual should be enough to get you started, if only for the right search terminology to get you closer to your application.

Come on, guys, learn something from history, avoid making the same mistakes over and over again, and add lexical closures to PHP.

PHP has create_function().

Yeah, sure, "just around the corner". That's what they said a year ago :P

Some interesting slashdot PHP5 references:
"PHP5 is well under development and a beta is expected out by March 2003 and released summer 2003"
Introduction to PHP5

General PHP5 References:
Changes in PHP 5/Zend Engine 2.0
Pidget: The PHP Widget Library

class MyClass {
private $Hello = "Hello, World!\n";
protected $Bar = "Hello, Foo!\n";
protected $Foo = "Hello, Bar!\n";

...
}

function myCallback( $var ) {
echo $var;
}

function doCallback( $callbackFunc ) {
call_user_func( $callbackFunc, 10 );
}

doCallback( "myCallback" );

I hope Mono really will allow me to use .NET assemblies from within open source languages that I am more familiar with.

I may never write a .NET application, but I am very likely to use .NET assemblies from within PHP5 thanks to Mono and the PHP Mono Extension.

-Jackson

For what it's worth, PHP 5 will have the SQLite embeddable database engine bundled by default. Which means that you won't have to install a separate database engine for lightweight SQL database tasks.

JP

Personally, I like Basic because of it's ease of use. Recently, I have been getting quite attracted to PHP for similar reasons.

Please don't use "Basic" when you mean "Visual Basic". You'll pollute my memories of the good old days on my CoCo...
10 PRINT "TMS RULES!"
20 GOTO 10

Anyway, I like PHP fine, it's what I'm paid to hack with these days. (And I'm the one who argued for it over our existing CGI C/C++.) But, PHP variable names are case-sensitive.

(Which, in a language where variables aren't pre-declared, so such things can't be caught the compiler, may be dangerous:
$someVar = do_it();
echo "do_it() returns $somevar"; // bang head against wall wondering why do_it() always returns 0...

Names of functions, which do need pre-declaration, are case-insensitive. That is ass-backwards.)

(I have experienced this in PHP which is case-insensitive and it bugged the hell out of me [and my program])

I beg to differ! Quoth the PHP manual:

• The variable name is case-sensitive.
• A constant is case-sensitive by default.

(I have experienced this in PHP which is case-insensitive and it bugged the hell out of me [and my program])

I beg to differ! Quoth the PHP manual:

• The variable name is case-sensitive.
• A constant is case-sensitive by default.

(I have experienced this in PHP which is case-insensitive and it bugged the hell out of me [and my program])

I beg to differ! Quoth the PHP manual:

• The variable name is case-sensitive.
• A constant is case-sensitive by default.

Perl was amongst the first. Perl was created sometime in the eighties, well before the net. PHP has it's roots in another product, created in 1995. ASP was even later, coming out in 1996. While CGI can be written in pretty much any language, perl has long been recognized, as leading the way forward in CGI, it doesn't do this anymore, since specialized languages and frameworks have come out, but that doesn't make it any less true, that Perl was there first and foremost (look at the URL of this site, see the .pl?) (and let's ignore that Java isn't a scripting language).

The other thing you say, is mostly personal opinion, but weighted against these comments, I wouldn't put much into them, you obviously weren't there back then. CGI allowed for dynamic content, a site such as /. couldn't have been created, without CGI.

General

Ah, now this is the part I enjoy. Lots of soaring generalities, without a single hard fact in sight. Saves the trouble of having to do research. 8-)

What I'm going to discuss here is some of the real and imagined philosophical differences that both cause, and are caused by, some of the technical and organizational differences we've discussed. Like most such discussions, there's little that's hard-and-fast here; there's plenty of overlap in attitudes among people in the various camps. And there's certainly plenty of completely deserved flak for both sides to take, as well as undeserved flak they've been forced to. Still, I think it's important to examine some of these splits, without trying to presume that one is "correct" and the other is "incorrect".

Realize, I must emphasize, that a lot of this is very general. Practically every point is riddled with exceptions. And both systems often don't "follow the rules", or fail to meet their own expectations. It's more a question of inclination that of exceptionless implementation. I'm just saying this now, so I don't have to keep qualifying and re-qualifying every statement I make, until it's impossible to read.

Chaos vs Order

One common generality is that the Linux methodology is the living incarnation of chaos, whereas the BSD methodology is far more about control. To a large extent, it's true. Linux grew out of a spare-time hacking background, while BSD grew out of a controlled engineering background. Of course, there's plenty of weekend tinkers writing BSD code, and plenty of full-time professional programmers sloughing away at various parts of Linux. But the feel of the systems still does reflect that sort of schism.

We've already discussed the construction methodology; BSD builds up a core system which is uniform, whereas Linux distributions takes pre-existing pieces and pretty much puts them together helter-skelter. Naturally, the BSD method is far more amenable to keeping things ordered, while the Linux method practically necessitates utter chaos. That's not to say that chaos is inherently bad, or order inherently good. They're just different environments.

Linux will also generally chase new versions of other programs much more closely, adopting particularly more major changes like Apache 2 much sooner than BSD will move that way. Now, the stricter separation of "base" vs "ports" in BSD, as well as the structure of the ports tree itself, make it easier to have multiple parallel versions of packages in BSD. Sometimes, it's even possible and easy to have multiple versions installed at the same time. Linux, by not having that sort of separation, makes it very difficult to have parallel versions, and instead almost requires a single "blessed" one.

And the primacy of source-compiling in packages also makes it easier to handle multiple versions. For instance, PHP must be compiled differently depending on whether you're using Apache 1.3 or Apache 2. With from-source packages like ports, I can define an environmental variable when I compile and install PHP to tell it whether to use Apache 1.3 or Apache 2. With binary packages, you'd have to have 2 separate packages available, which will lead to confusion sooner or later.

Right vs Wrong

The difference can also be seen in the way core code is integrated. BSD tends to always shy away from hackish solutions when there's even a hint of a proper solution in the wings. The theory is that it's far easier to wait for the clean answer, than to integrate the dirty answer now, for several reasons. For one thing, if you integrate the dirty answer, that reduces the incentive to implement a better one. For another, once you dirty up the architecture to integrate something it'll never get cleaned up again. You know it as well as I do. Oh, sure, you'll say it's temporary. But you know

Timothy, can you fix it?

I'd suggest taking a look at this page:

http://www.php.net/mirroring.php

I've set up a mirror for internal use at work. Just run rsync in a cron job every week or month or whatever to keep things up to date.

J

The online docs do not say HOW to program in PHP.

The Apache 2.0 installation documentation (http://www.php.net) suggests "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows." The reasoning I found, after researching this on Google, had to do with a lack of testing and the fact that something could go wrong because Apache 2.0 is multithreaded (or something like that). So, if you have two versions of an application, both of which meet your needs, you pick the one that has been proven in the field (in this case, Apache 1.3.29). I probably could have used Apache 2.0 without incident, but there was really no reason to risk it.

Note that the numbers are "per domain" So 2003 is better proclaimed the Year of NameVirtualHost. Hopefully, this means that there really are more httpd's out there, but the correlation was not made in that necraft study. Hopefully someone will do (perhaps already has done?) a study to establish IP# to domain name ratios. My guess is that there is a lot more virtual hosting being done now then there was in, say 1999, when having a corporate web site was more directly related to purchasing dedicated web server equipment. I'll bet that the Microsoft push into public key infrastructure will be used to leverage growth for IIS but at these rates, it may well be hard to catch up with Apache.

But perhaps the real story for 2003, as far as growth technologies go, is likely PHP. The ratio of deployments and actual usage to press coverage of the technology is pretty impressive too. :)

Then, with more and more languages, especially ones with VMs, you get further and further away from the hardware. The end result: you lose performance. It does more and more for you, but at the expense of real optimizations, the kind that only you can do.

Now the zealots will come out and say, "Language X is better than language Y, see!" To me this argument is boring. I tend to use the appropriate tool for the job. So:

• Python for scripts, prototypes, proofs of concept, or components where performance generally is not an issue.
• For desktop apps, Visual Basic (yep, most IT apps are in VB). There is no justifiable reason for an IT department group to write a sales force reporting system in C++! If you want C++, go get a job at a software company. Stop wasting money and time making yourself feel like a hotshot. [I'd consider Kylix here if it was based on Basic. Why? Because honestly, Pascal is just about dead, and Basic is the king of the simple app. Let's just live with it and move on. I do want a cross-platform VB . . . ]
• For web apps, well, I stick around PHP/ASP.NET. Why? Portability! And moreover, the sticking point in a web-based app is not the UI layer; it's usually the underlying data extraction and formatting. Don't waste your time with lower level languages there. IMHO it's just not worth it. JSP and Java stuff, yuck! Too much time for too little bang.
• Java/C# (also consider mono/LISP for most production apps. Why? Portability! I want no vendor holding me by the balls. I want platform independence on the back end, and these are the few ways to achieve it. I'd include Haskell/OCAML here when appropriate. Perl? I'm loathe to use Perl as production, considering most Perl code cannot be understood 2 weeks after it's written. I'd rather take the hit in performance and be able to pass the code to someone else later.
• C++/C for components--just components--where performance is at an absolute premium or there exists some critical library that only has this kind of interface. But this step has to be justified by the team, with considerable explanation why a different architecture could not suffice. Otherwise, the team could waste time checking for dangling pointers when instead it could be doing other things, like finishing up other projects.
• Assembly? Only when there is not a C complier around. Embedded stuff. Nowadays, you just do not have the time to play.

Yes, my teams use many languages, but they also put their effort to where they get the biggest bang for the buck. And in any business approach, that's the key goal. You don't see carpenters use saws to hammer in nails or drive screws. Wise up!