PHP software

I picked up a book on PHP that seems pretty good as a learning book and reference material.

Problem is, they don't state the software you need to test your code!!

I've got Tomcat on my system as a webserver, but what else do I need to be able to run and test my PHP code?

Note: The book goes into depth into XML technologies: SAX, DOM, XPath, and XSLT. Software to run these scripts would be nice too.

(a web page tutorial for intro to PHP and setting up your system to use it would be great, first and foremost)

ugh PHP. Do yourself a favour and jump off a tall building.

lol PHP more like PRETTY HORRIBLE PROGRAMMERS.

gg fags you may not have noticed the file extension in the url

loaf you might've also noticed that people post twice a lot.

hey ever heard of namespaces?

LOL TOMCAT IS FOR JAVA NOT PHP YOU NUB

>>1

Google for php tutorial, asshat. The first, oh, I don't know, 10000 hits seem to be exactly what you're looking for.

Apache, mod_php
You can write your own XML parser, it's good for the soul... the first couple of dozen times anyway.

>>9
a true php programmer

>>1
Go http://php.net ,  download PHP 4.3.11 or 5.0.whatever (depends on what are you learning), and then you can get Apache and use mod_php as usual, or run the CLI client (php.exe; for PHP 4 use the one in the CLI subdir).

>>2-3 are DQN
Just because there's sucky people writing sucky software it doesn't mean it sucks.

>>11
PHP is easy to learn to do crap with (yet you still need to be a decent coder if you want to get things done the right way, as with any other language). But this great learning curve is, perhaps, what makes PHP get so many newbies and script kiddies writing crap, and this gave the language a bad fame among other language fanbois and short-sighted people.

Any programmer who can do C or Python (and Perl - but Perl has a similar problem to PHP), can write pretty dencent PHP code that doesn't suck and is maintainable and scalable. In fact, it's much more maintainable than Perl and Java, and that's why some companies are adopting it, besides the ease of development. Criticizing PHP becuase there are bad programmers using it is asinine.

As for namespaces I have 4 things to say:
1. C lived without them for decades. And most serious stuff is written in C.
2. Proper software doesn't need them, and if you're not writing proper software, don't complain. Use function prefixes, and don't abuse global variables. These are good practices even with namespaces.
3. PHP is, for now, not intended to write colossally large applications, you know. Blaming it for this is like blaming an Avensis for not reaching 320 Km/h.
4. I wish this gets fixed soon. Not only I'd like to have more language constructs, but I'd love to see fan(g?)boys losing their primary, favorite, ever used bitching point and STFU.

it's much more maintainable than Perl and Java

Elaborate.

And most serious stuff is written in C.

You're being liberal with the meaning of "most". All the world is not OSS.

lol stop arguing about maintainability when you don't maintain anything. Stop arguing about maintainability when you don't work with anyone else. Stop arguing about maintainability because you OBVIOUSLY DON'T KNOW WHAT IT MEANS.

>>12
namespaces no but modularity yes. C has actual modules and linkers , you can manage your symbols pretty easily, you can even have a published public interface. C has features which reduce the need for namespaces. When we use a dynamicly typed language like PHP usually namespaces provide the bare minimum of organization.

PHP SUCKS BECAUSE:
* shitty recursion
* not thread safe
* PHP is crippled for commercial reasons
* No namespaces
* Inconsequently named functions
* Magic quotes hell
* Inconsistent return and argument passing in the core lib
* no lexical scope
* too many functions in the main namespace
* duplicated functionality everywhere
* Poor quality libs
* Poor documentation
* Poor performance
* Shitty DBI
* No anonymous anything
* No references (other than named)
* ...
* PROFIT
* FACE IT REALLY SUCKS

http://n3dst4.com/articles/phpannoyances/
   1.  No real references or pointers, just reference-by-name and sort-of aliases. Sometimes, I want a pointer.
   2. No idea of namespace. Except maybe for classes, but even then the class definitions aren't namespaced. There isn't even a recommended way to name your classes to avoid hassle.
   3. No componentization unless you kluge it yourself.
   4. Desperately wants to be Perl, but desperately doesn't want to be Perl.
   5. No standard DB interface (well, except ODBC, but blech)
   6. All PHP community websites are written for non-programmer weinies. The whole thing seems oriented towards gimboids who can't understand the slightest bit of theory and have to be shown 'how to write a calendar' instead of 'how to use date arithmetic and come up with your own bloody answer'.
   7. No chained method calls. Please, someone tell me I'm wrong on this, but I couldn't make PHP understand $foo->bar()->baz(). And not only that, but no discussion of the subject, anywhere. Too confusing for your average PHP user I suppose.
   8. No globals except by importation - that's a side-effect of "no namespace protection".
   9. register_globals used to bite. At least it's now $_REQUEST, but that bites too. What's wrong with named arguments?
  10. Arrays are hashes.
  11. PHP works best when you forget everything you've ever learn about good programming practices. Unfortunately, that still doesn't mean that good practice is expendable. Your code will still bite.
  12. include() uses filenames. That's yet another namespacing thing.
  13. The built-in functions all look like they were rejected from K&R C for being too terse, or rejected from Java for being too verbose. Why not just choose sensible, meaningful names? Oh that's right - no namespaces.
  14. PEAR just ain't CPAN.
  15. You can't interpolate array indices in strings. Poop.
  16. No 'use strict;' (e.g., checking variable names)

http://tnx.nl/php
    * Re^2: Is Perl a good career move? by Juerd, 2005
          o Still no namespaces
          o No closures, not even anonymous functions
          o No good HTML parser
          o No easy MIME builder
          o No good WWW library
          o No CPAN
          o No arrays
          o Less useful logical operators
    * Yaywoo! by Dave Brown, 2004
          o No way to avoid the (unsafe) shell with system()
          o XY-problem
          o Huge proliferation of different functions to do more-or-less the same thing with minor variations
          o Second parameter and return value make no sense
          o Bad spelling in function names
    * Why PHP sucks by Edwin Martin, 2004
          o Bad recursion support
          o PHP is not thread safe
          o PHP is crippled for commercial reasons
          o No namespaces
          o Non-standard date format characters
          o Confusing licenses
          o Inconsequent function naming convention
          o Magic quotes hell
    * Perl vs. PHP - octo's subjektiver Vergleich by Florian Forster, 2003 (German)
          o Perl is faster than PHP
          o Perl is more versatile than PHP
          o Perl has better documentation than PHP
          o PHP lacks support for modules
          o PHP's here-docs are useless for Windows users
          o PHP lacks a consistent database API
          o PHP dangerously caches database query results
          o For graphics, PHP is practically limited to GD
    * I hate PHP by Keith Devens, 2003
          o Idiotic call-time pass-by-reference deprecation
    * Experiences of Using PHP in Large Websites by Aaron Crane, 2002
          o PHP promotes interweaving presentation with business logic
          o Not having namespaces causes problems
          o Global configuration with php.ini
          o Oversimplification leads to excessive complexity
    * PHP Annoyances by Neil de Carteret, 2002
          o No real references or pointers
          o No idea of namespace
          o No componentization
          o Wants to be Perl, but doesn't want to be Perl
          o No standard DB interface
          o All PHP community sites are for non-programmers
          o No chained method calls (Not true anymore --tnx.nl)
          o No globals except by importation
          o Both register_globals and $_REQUEST bite
          o Arrays are hashes
          o PEAR just ain't CPAN
          o Arrays cannot be interpolated into strings
          o No "use strict" like checking of variable names
    * PHP: A love and hate relationship by Ivan Ristic, 2002
          o The community gets on my nerves
          o Knowledgeable people are in a serious minority
          o Zend publishes articles suggesting insecure practice
    * My list of PHP shortcomings by Nathan Torkington, 2001
          o No namespaces
          o All functions are global
          o No real references
          o No real data structures (Not true anymore --tnx.nl)
          o No anonymous functions

ruby. IT IS SUPERIOR.

>>13
Elaborate.

Sure. _Properly designed, written_ PHP applications (read my previous post to see why this isn't that common, but PHP is not to blame for it) are easier to modify, extend, fix, and otherwise maintain, because of the KISS principle. Perl code tends to end up looking like noise, because of the liberal syntax, parenthesis/regex/scope nightmares (which shouldn't be abused, but the language is still prone to it), but it's against Java where PHP(5 if you want) really shows a huge difference. I'm speaking for my own experience as a developer who did both design/development and maintenance of mine and others' code.

Large Java applications end up being a lot of type juggling (which is not really _functional_ code that does something for your application, just support code) and an object nightmare, where anything inherits and implements obscure methods and trying to find what's being called and what does it do gets really time consuming. You're constantly jumping from here to there to see what's getting executed, and that, in my book, is known as good old spaghetti code.

Moreover, the Java API blows. To say it's overly complicated is a major understatement. You'd have to create an ExpressionFactory (which inherits various methods and properties from Universe > World > Intelligence > Ideas > Communication > Expression), to create an Expression object, wait, make that an ExpressiveExpression (Expression is deprecated), implementing the ExpressYourself interface; and pass a container of the syllabes you want to express, then fire. In the end, Java code looks like this.get().lol().silly(new TimeWaster(new WasteEvenMoreTime(IllogicalStaticMethod.getWhyShouldIBeDoingThis())).getSomeMore().get(); .

Breaking news: I get paid for implemented functionality, not the total amount of objects created (otherwise I'd be rich). In the real world (i.e. what you use to make bread and be able to browse 4chan at night), you need to write software that runs reasonably fast but more importantly scales well, is easy to maintain even if you're gone, and you can finish in a finite amount of time.


>You're being liberal with the meaning of "most". All the world is not OSS.

Yes, I understand. But see how most commercial software is OO while most OSS is not OO? Not OO is easier to understand and maintain - which is vital for OSS as everybody touches everybody else's code. Commercial software developers don't want this. They need to justify why you need to update to their new Easy Business(TM) system, which costs $10000, but man, it's object oriented and uses XML! (managers read this is good in magazines). They can't charge thousands of dollars for a 1.3 MB executable, can they?

>>14
I'm actually making bread doing this. And coincidentally, I'm working with another coder.

Perhaps you have assisted to one of Sun's presentations on why is J2EE so productive and maintainable. In Spain we have a proverb: "Tell me what you brag about and I'll tell you what you lack".


>>16
>　shitty recursion
Even though most recursive algorithms have a faster iterative implementation, I think there are some improvements in the Zend Engine 2.

not thread safe
It is thread safe (?). You can't do threads though, as of yet. You don't do that for web applications, and you rarely use PHP for desktop applications, though.

PHP is crippled for commercial reasons
Not rly.

No namespaces
Inconsequently named functions
Agreed.

Magic quotes hell
Disable it.

...

Poor performance
Compared it to Perl and was about as fast, and the Zend Engine 2 is getting faster.

PROFIT
Lol commie, gb2/Cuba.

FACE IT REALLY SUCKS
Lol fanboy, gb2/GameFAQs.


>>17
Sometimes, I want a pointer.
So do I, but keep in mind this is a scripted, high level language, not C. References and variable variable/functions will rarely be insufficient.

No idea of namespace. Except maybe for classes, but even then the class definitions aren't namespaced.
Exactly. I want this fixed, too.

No componentization unless you kluge it yourself.
I'm used to, but it would be nice to have something like Perl does.

Desperately wants to be Perl, but desperately doesn't want to be Perl.
Lol, true. But I think this is a good thing. I'd rather say, desperately wants to be as productive and cool as Perl, but desperately doesn't want to be as messy as Perl.

No standard DB interface (well, except ODBC, but blech)
Agreed. Use ADODB or whatever. Coming soon: PHP Data Objects, to fix this.

All PHP community websites are written for non-programmer weinies.
Most surely. Not PHP's fault though.

No chained method calls. Please, someone tell me I'm wrong on this, but I couldn't make PHP understand $foo->bar()->baz().
That's because you're using PHP 4 for what it's not. Use PHP 5 for OO. It does support that.

No globals except by importation
Even though you can use the $GLOBALS superglobal, you shouldn't. Having to declare which globals you are going to use is a very good programming practice. Lots of globals isn't.

register_globals used to bite. At least it's now $_REQUEST, but that bites too.
You should actually use $_GET, $_POST, etc., and no, it doesn't bit, unless you're a really bad programmer, and we already said we're tired of them, right?

Arrays are hashes.
Less syntax, more simplicity, existing code easier to extend. This is actually one of PHP's features over Perl. And even though it's very fast, if you want more performance, use C.

PHP works best when you forget everything you've ever learn about good programming practices.
Not at all. Because of people thinking this, lots of the available PHP code sucks.

include() uses filenames. That's yet another namespacing thing.
Breaking news: You gotta define the final name of the file somewhere! And You can use variables, or whatever you want.

The built-in functions
I agree that they are named inconsistently and should be deprecated in favor of better names.

PEAR just ain't CPAN.
The world was not made in a day.

You can't interpolate array indices in strings.
Not rly?

No 'use strict;'
Once again, it's an scripting language. You're not supposed to do this. Even though I'd like to, myself. I hope next versions of PHP have support for this.


>>18
Holy shit man, you're a serious fanboy, collecting that many complaints. Unfortunately, most are repeated, and I have covered most already. Furthermore, they are outdated. There exist anonymous functions, there are more graphics libraries than GD, including a GUI library that's soon getting better, etc.


Finally, I'll _once again_ remind you all that PHP is a scripting language designed for productive development of web applications, also supporting system scripts. You aren't going to write an operating system with it, and no, it's not fully comparable to Perl because Perl is also suitable for lower level applications. What PHP is aimed at is a subset of Perl's. Then why should you use PHP? Because it's better for what it's intented on doing. Better as in better code, simpler systems (KISS), and shorter life cycles. Blaming PHP for not having, say, threads, is like blaming Perl for not having more direct hardware access and absolutely strict, defined, custom memory handling, or like blaming C for not having variant variables and native hashes.

So, by your logic PHP is better than Perl because it's shitter?

And who said you can't write simple code in Perl?

Cool (sic) PHP features coming soon! Yay, other languages have only had them for 20 years.

I've seen undergrads write better languages just to test out parsec.

>>22
by your logic PHP is better than Perl because it's shitter?
"Better" or "worse" depending on what do you want to do with it, just like a spoon can be better or worse than a knife. And I never said it's shitter, don't try to twist it. I said it's simpler, more regular, and more easily maintained.

who said you can't write simple code in Perl?
Nobody. Just Perl is prone to obfuscation just like PHP is prone to bad programmers.

Cool (sic) PHP features coming soon! Yay, other languages have only had them for 20 years.
Then let's go insult Perl or C# for introducing stuff LISP had since my grandma was young.

I've seen undergrads write better languages just to test out parsec.
You reek of fanboyism. Nobody who's serious can state something like this; the PHP language syntax is far more regular and shorter than Perl's.

_Properly designed, written_ PHP applications

How does a properly designed and written PHP application compare to a properly designed and written perl app then? There is nothing inherent in perl that damns you to poor maintenance. Frankly, given that perl is both more powerful and expressive than PHP, I'm inclined to think otherwise. Feel free to refute though.

Java's libraries are a whole different story. My dislike for them borders on hate, but developers working on a massive scale swear by them. Who am I (or you) to say otherwise?

the PHP language syntax is far more regular and shorter than Perl's.

That is true. The library is another story though.

I don't want to get embroiled in this impending PHP vs Perl holywar, but I'd like to question this:

Compared it to Perl and was about as fast, and the Zend Engine 2 is getting faster.

Everything I know about the two tells me that is false. Of course, my anecdotal evidence is cheap. This might be worth more: http//shootout.aliot/...

Perl is always faster, usually uses less memory, and takes significantly fewer lines to achieve the same. Now whether those lines are readable is another story...

>>25
That's an interesting link. Notice though, that what I said wasn't absolutely false. I had noticed it was a little slower in some cases, but the difference, as you can see, is rarely above 5%.

As for memory, that link shows it almost always takes a little more memory too - never more than 2.5%, but there are a couple cases where Perl takes up to 15% more memory, which is IMO more important as they seem to fall in the "considerably" more, not "about as much". Then again, this is probably up to the way the algorithms are implemented.

Also, keep in mind these tests are fairly generic and not too webapp-oriented. PHP code would probably be a little shorter than Perl's for more typical web application tasks.

>the PHP language syntax is far more regular and shorter than Perl's.
can you give an example?

>>27

Parenthesis cannot be ommited in some cases for function calls. Regex not built into the language's syntax. Array and hashes share the same, simple syntax. Brackets aren't mandatory, and no postfix if/while/etc. hack. All variables start with $ regardless of what they are. Etc.....

>>26
Those aren't percentages. Those are multiples. PHP averages about 3x slower. If it was just three percent, nobody would give a hoot.

Then again, this is probably up to the way the algorithms are implemented.

That's also true. Take a look at that perl Ackermann function. Aiiii!

>>28
you are forgetting the multiple ways to declare blocks.

>>21

You're a joke.

Many languages do recursion well and do tail recursion right.
Not thread safe means that PHP + Apache 2.0 or any webserver you make up that uses threads, will suck. Also you're acting like the lack of threads is some great feature.
YES PHP IS CRIPPLED FOR COMMERCIAL REASONS. GOD. JUST BECAUSE YOU SAY IT ISNT DOESNT MAKE IT TRUE OR FALSE.

>Poor performance
>Compared it to Perl and was about as fast, and the Zend Engine 2 is getting faster.

Loaf no, you're probably just comparing mod_php vs cgi

>Arrays are hashes.
>Less syntax, more simplicity, existing code easier to extend. >This is actually one of PHP's features over Perl. And even >though it's very fast, if you want more performance, use C.
Do you know the difference between an array and a hash? This is not just a performance thing this is an algorithmic and memory thing.

You can't simply reply and say "It'll GET THERE" "OH WE DIDNT NEED THAT (ITLL GET THERE)" "OH USE THE SLOWER PHP5 WHICH WORKS SHITTY ON APACHE 2.0". Jesus Christ.

We have shown without a doubt that PHP is bad language.

Hey, hey, while I disagree with some of his assertions, and agree with yours, calling him a joke is a bit too much. If you feel the need to flame, go to /vip/ or /b/.

ALL CAPS is also lame.

>>32

a 2 programmer team claiming php is maintainable is a joke. SORRY IF OFFENDED YOUR LOWERCASE ASCII SENSIBILITIES.

>>33
Retarded adolescent prick.

Lol, I'm hardly offended, much less by uppercase AOLers ^_^. Well, I say if it's a joke, it's a well-paid joke! Ha ha ha.

I'm working with the other guy on a Java project, BTW, not PHP.

I'd rather be a bum than code PHP or java

I'm sure you would, mate, I'm suuuure you would...

Install LAMP

>>38
facepalm.txt

This, sir, was no mere bump. More like a free-falling airplane bumping into an explosives warehouse.

/prog/ is the only textboard that sucked more when it was new than it does now. Even with FrozenFaggot.

>>40
EXPERT METAPHOR

>>42
EXPERT FIGURE-OF-SPEECH CLASSIFICATION

>>43
EXPERT EXPERT-DESIGNATOR

>>45
EXPERT RECURSIONIST

>>47
EXPERT ITERATIST

>>46
EXPERT PSYCHIC

>>47
WAT

>>48
EC

>>49
O

>>50
I

IDE solutions to the x replied Why.

>>51
 REPL. lisp simply homoiconic the to and the other feel extremely and the because in forms All License the a to of Permissions. are covered  provided are this  Program. irrevocable the \?\ is │   │   ││  It's   It  material and 32; .scl .text 2, pushl include .def .text .type _decode_rle; Wordfilters? _decode_rle 'emu8086.inc'   .type  BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA BUFFA                    ●─╂─────────────────►┃  ┃      │  ┗━┿━┻━━━┛   ┗━┿━┻━━━┛

a
b

a
b

check em

>>20

You ever tried Zend Framework. It is a joke. Even a java library doesn't let you jojo so much between sources.

>>59
No, but I did try your mom the day she showed up wearing a pair of knee hight mens tube socks over her skin tight black leggings.

>>60

She's dead for a long time. Did you enjoy the earthy fragrance?

>>61
I am starting to doubt you even knew your parents.

Tell me, how was it in the orphanage?

>>62
It was full of "Russians".

>>63
You mean it was a zoo?

>>64
That was VIP quality!

>>65
Thank you! I'd offer you some dubs, but it appears that I already checked them.

Could someone here help me take down http://en.cubadebate.cu/  ... so we can [digitally speaking] fuck those authoritarian assholes in the ass?

>>67
How about I take you down?
*grabs dick*

TAKE DOWN MY ANUS!