Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PHP 5 in Practice

samzenpus posted more than 7 years ago | from the read-all-about-it dept.

Book Reviews 116

Michael J. Ross writes "Computer programming books come in all varieties, but there are at least four general categories: introductory texts, which typically have the lowest content per page; language references, which have become increasingly supplanted by online sources; "advanced" treatments, which are often a mishmash of errata-riddled articles; and "how-to" books, usually at the intermediate level, and sometimes presented as "cookbooks." It is that last category that has been growing in popularity, and for good reason. When an experienced software developer needs assistance, it is rarely for language syntax, but instead a desire to see how someone else solved a specific problem. For solutions using the PHP language, one source of information is PHP 5 in Practice." Read the rest of Michael's review.

The book was authored by Elliott White III and Jonathan D. Eisenhamer, and put out in July 2006 by Sams Publishing (an imprint of Pearson Education). Given today's standards of hefty technical books, this particular one is relatively light, weighing in at 456 pages, which are organized into an introduction, numerous chapters, and three appendices.

Its introduction is more interesting than that of most similar books, whose introductions usually consist of formatting conventions and explanations as to why the book was written — all such content providing little to no value to the impatient programmer facing a deadline, and invariably ignored (the content, that is, not the deadline).

White and Eisenhamer took a refreshingly different tack, and chose instead to explain their use of coding standards, comments and whitespace, braces and parentheses, PHP short tags, PHP mode, and other language considerations that are more useful than the typical rundown of somewhat childish icons used in other texts, such as light bulbs and red warning signs.

Switching to the other end of the book, we find three appendices. The first one briefly discusses issues one might face in migrating from PHP version 4 to 5. The second introduces the Standard PHP Library (SPL), and the objects related to its primary design pattern, the Iterator. The third appendix discusses what composes the bulk of output from my PHP programs: error messages. Seriously, this appendix is worth reading, if only for the suggestions as to what to look for when you encounter some of the most common PHP error messages.

The bulk of the book's material is divided into 20 chapters, which are themselves divided into two parts: PHP internals, and applications. The internals are: strings, numbers, time and date, variables, arrays, functions, classes and objects, and files and directories. Starting off with a discussion of strings, might seem odd to the neophyte programmer, but to the veteran who has had to learn several languages during their career, the choice makes a lot of sense. There must be countless developers out there who, being fluent in the C language and object-oriented concepts, jumped into writing their first C++ program, and had to hit the books for the first time when they wanted to do some non-array-based string handling.

The book's second part covers some of the most common applications in PHP programming: Web page creation (using XHTML and CSS), Web form handling, data validation and standardization, sessions and user tracking, Web services and other protocols, relational databases and other data storage methods, e-mail, XML, images, error reporting and debugging, and user authentication and encryption. That last chapter, in the next edition, should be relocated so that it precedes or follows the chapter on sessions and user tracking.

Many of the chapters begin with a "Quick Hits" section, which briefly summarizes how to perform many of the most common and essential tasks related to that chapter's topic. For instance, in the chapter covering the use of variables, this first section explains how to: check if a variable has no value or if it is empty (not synonymous in PHP), undefine a variable, cast it to a certain data type, and do the same thing for a value. There is one minor erratum that should be noted: On page 71, in the first "Quick Hit," it reads "a variable has bee. given a value." ("been"'s "n" ended too soon.)

Each section within the chapter briefly explains the problem domain, and then presents sample code to solve the given problem. The code itself is fairly well commented, and the variable names are adequately descriptive (unlike in some programming books, whose coding standards border on the criminal).

All in all, the book offers a lot of worthwhile solutions to a wide range of problems, and does so in a straightforward manner. It is for this reason that it is not evident as to why this particular PHP title has received so little notice. For instance, on Amazon.com, it has received only one reader review, as of this writing, and does not even make it into the top quarter million books ranked in sales by Amazon.com. It is a pity, because the book deserves much more attention.

Even though this book is to be recommended, and is packed with code and text that are well worth studying, it has one unmistakable weakness for which this writer can think of no adequate justification. The book contains almost no illustrations, even when they are clearly called for — in fact, especially in those cases. For instance, the section that shows how to generate a calendar, does not show a calendar! The code is present, but the sample output — which is what the poor reader would appreciate, to see the results of the code — is missing.

Granted, an absence of figures and screenshots might be understandable for the first part of the book, which covers the PHP language itself. But the second part, covering applications, has far too many unillustrated PHP scripts. These include sections focusing on drop-down menus, progress bars, and graphical charts Web forms. In the last chapter, there is a section with code that generates captchas, but the reader is not shown what they look like. The entire 18th chapter is devoted to images, but contains not a single one! I cannot imagine why the authors and/or publisher chose to leave out these essential graphics. Was it to save money? Whatever the reason, it was a significant mistake, and one that should be corrected in the next edition.

Readers who agree with this assessment, or who have other thoughts concerning this otherwise excellent book, can leave feedback via the book's Web page on the Web site for Sams Publishing. This page offers details on the book, a description and table of contents, links for requesting instructor or review copies, and a tool for searching the book's contents within the Safari online technical library. The book's introduction states that the Web site hosts all of the code listings, as well as a list of errata. Yet, I was unable to find either one. (Sadly, the Pearson Education sites are still some of the least usable in the technical book publishing world.) Much better results were obtained on Eli White's site.

Despite an inexcusable and almost complete lack of needed illustrations, PHP 5 in Practice is possibly one of the most meaty, immediately useful, and fluff-free PHP books available. No serious PHP programmer should be without it.

Michael J. Ross is a Web consultant, freelance writer, and the editor of PristinePlanet.com's free newsletter. He can be reached at www.ross.ws, hosted by SiteGround.


You can purchase PHP 5 in Practice from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

116 comments

Sorry! There are no comments related to the filter you selected.

Update on the link (-1)

Anonymous Coward | more than 7 years ago | (#17986638)

For some reason, the post links to B & N, but it seems Amazon has it cheaper [amazon.com] . Take a look at the "Used and new..." listings. Why does the article link to an overpriced site?

Re:Update on the link (-1, Flamebait)

cloudkj (685320) | more than 7 years ago | (#17987694)

hey asshole, how do you always get such a quick post for these book review spam links you post? i'm actually very curious about your method. it can't be via rss since there's a delay. how do you do it?

Mod parent down - spammer (0)

Anonymous Coward | more than 7 years ago | (#17987776)

Non affiliate link [amazon.com]

Re:Mod parent down - spammer (0)

Anonymous Coward | more than 7 years ago | (#17987816)

Where is there a referral link in there? Usually you can tell from usernames like the infamous "kaleidojewel" in there, but this guy doesn't seem to be doing that.

Re:Mod parent down - spammer (0)

Anonymous Coward | more than 7 years ago | (#17993136)

This link is not to the book. It is to a gay sex book.

Opposite way of thinking? (5, Insightful)

Larsiny (753559) | more than 7 years ago | (#17986704)

When an experienced software developer needs assistance, it is rarely for language syntax, but instead a desire to see how someone else solved a specific problem.
Is that really true? I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax (and sometimes even the libraries/classes already available) to allow me to do what I want. Is this because I'm only a recent (2 yrs) CS grad? Isn't this the normal way to approach the problem due to the myriad languages used out there? It seems to me this might be true only if you're very familiar with a particular language and are trying to use that for everything which may or may not be possible.

Re:Opposite way of thinking? (5, Insightful)

DamnStupidElf (649844) | more than 7 years ago | (#17986792)

Is that really true? I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax (and sometimes even the libraries/classes already available) to allow me to do what I want. Is this because I'm only a recent (2 yrs) CS grad? Isn't this the normal way to approach the problem due to the myriad languages used out there? It seems to me this might be true only if you're very familiar with a particular language and are trying to use that for everything which may or may not be possible.

Congratulations, you have discovered the difference between "experienced software developers" and computer scientists. Computer scientists know what they need to do and how to do it, so long as they can express it in the language they're using. Experienced software developers often know incredible amounts of detail about programming languages, but not necessarily about advanced algorithms and data structures.

Re:Opposite way of thinking? (1)

BostonVaulter (867329) | more than 7 years ago | (#17988088)

Computer scientists know what they need to do and how to do it, so long as they can express it in the language they're using. Experienced software developers often know incredible amounts of detail about programming languages, but not necessarily about advanced algorithms and data structures.
So does that make Computer Scientists better? Or software developers? Which is more important, knowing advanced algorithms and data structures, or knowing the intricate details of a programming language so you can optimize that much more.

I'm just a lowly college student (EE) so I don't know the answer.

Re:Opposite way of thinking? (1)

tha_mink (518151) | more than 7 years ago | (#17988256)

So does that make Computer Scientists better? Or software developers? Which is more important, knowing advanced algorithms and data structures, or knowing the intricate details of a programming language so you can optimize that much more.
I suppose if you're 100% of one and 0% of the other, you're pretty much useless. I don't think it's a better or worse situation.

Re:Opposite way of thinking? (2, Insightful)

dkf (304284) | more than 7 years ago | (#17988298)

Which is more important, knowing advanced algorithms and data structures, or knowing the intricate details of a programming language so you can optimize that much more.
Knowing about algorithms and data structures is more important than knowing the detailed specifics of any particular language, since they illustrate more different ways to tackle a problem and seem to be harder to learn (well, for many people). It's also good to know lots of different languages, again because it effectively gives you more tools for your mental box of tricks. After all, you wouldn't want to go round being seen as the person who uses a 12 pound hammer to drive in screws or saw intricate holes in a piece of wood...

Re:Opposite way of thinking? (1)

tknd (979052) | more than 7 years ago | (#17989226)

They're both equally important.

For example you can know that the Quicksort algorithm has the best characteristics for your task but be forced to implement it in a language you don't know OR you can know that someone else implemented Quicksort in your language and not know if it's properties are what you need. In both cases where you only know one or the other, you are using time. If you knew both, you potentially used zero time (knew it was the right algorithm for the task, knew that the language or a library implemented it) to solve the problem.

The reason why the first two cases are costly is because when implementing you waste time implementing and testing and in the second case you waste time researching the implementation to determine if it meets your needs.

Re:Opposite way of thinking? (2, Interesting)

jadavis (473492) | more than 7 years ago | (#17992690)

If you're an experienced developer, you'll be able to apply the right tools for the problem in a way that interfaces with complex business processes. You'll complete jobs quickly and have a lot of happy customers. However, sometimes customers might become unhappy if your solution doesn't continue to work for their changing needs, or becomes expensive to maintain or alter. You might occasionally surprise clients with additional cost because a tool you used doesn't work well for a new demand.

If you're a computer scientist, you'll be able to solve complex problems in a robust, flexible way. However, you might use the wrong tools, not enough tools, or take longer to accomplish the task initially. Your customers will stay content because your solution will continue to work (although you should learn to equate silence with "thank you"). You are less likely to encounter unexpected extra costs (but that's because you probably wrote too much of the code yourself).

I would say that for short-term projects, lean in the direction of "experienced developer". There's no substitute for a developer that just gets the job done, quickly and under-budget, in a way that works seamlessly with the business needs. However, for long-term projects, lean more in the direction of computer scientist. The computer scientist will be better able to respond to new demands from the system quickly (without costly rewrites or data migration nightmares). Ideally you want someone who is both, and understands when to use which principles.

Re:Opposite way of thinking? (2, Insightful)

nadamsieee (708934) | more than 7 years ago | (#17988920)

Congratulations, you have discovered the difference between "experienced software developers" and computer scientists. Computer scientists know what they need to do and how to do it, so long as they can express it in the language they're using. Experienced software developers often know incredible amounts of detail about programming languages, but not necessarily about advanced algorithms and data structures.

And true software engineers know both. :)

Re:Opposite way of thinking? (3, Insightful)

fireboy1919 (257783) | more than 7 years ago | (#17989264)

I take it you're a computer scientist. :)

As someone who knows fourteen programming languages, but also has a degree in CS with a minor in math, the reason for the that practice among software developers is not because they don't know how (although, admittedly, I've met a few who probably couldn't write low level stuff for themselves), but because there's a best practice way of doing a lot of stuff in any given environment.

In other words, you try to do things the same way that most people who use the language do it so that your code can be used by other people, and so that you can use other people's code to help you do it. Otherwise you have to reinvent the wheel a lot.

Programming languages are a math unto themselves. It's pattern recognition, and "speaking" the languages is the crux of most of it. A CS program should teach you how to learn them quickly. The seasoned programmer, whether CS grad or experienced developer, should be the ability to think in different languages by understanding the differences in their patterns.

Re:Opposite way of thinking? (0)

Anonymous Coward | more than 7 years ago | (#17993554)

My *ASS*.

Sure... as if you don't consult a single book when you are coding in a different language. I seriously doubt you know 14 languages as well as you think you do.

Or are you a wussboy who makes the compiler pick out your syntax errors for you? I think that's the case.

If you can write something simple, oh, like abstract classes, in 14 languages and get every single one to compile correctly on the first try, hats off to you: You actually *know* 14 languages.

But no, I seriously doubt you can do it.

Re:Opposite way of thinking? (2, Insightful)

drooling-dog (189103) | more than 7 years ago | (#17989354)

Most often what I'm looking for in example code is not an algorithm, but rather an idea of what available functions, classes, and idioms address the problem at hand (and how to use them). That's usually the biggest nuisance when jumping between multiple languages, especially when they're used infrequently.

Re:Opposite way of thinking? (2, Interesting)

biz0r (656300) | more than 7 years ago | (#17986840)

... I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax ...
Thats a problem where you are not familiar enough with the syntax of a language. I would probably guess its because of your limited experience with it.

... and sometimes even the libraries/classes already available) to allow me to do what I want. ...
Thats a problem that even very experienced developers hit often, this is exactly what you were talking about in your (the parent to this) post.

Language syntax is something you learn and then can mostly just take care of without having to refer to reference manuals...however, class definitions, function and method declarations, data structures, etc...those are all something you often will reference out of documentation of sorts when you need it. I have been developing in PHP for about 8 years now but I STILL go to the manual on php.net to see the function arguments/etc (although, granted, with PHP this is largely an issue with the inconsistent naming/etc).

Re:Opposite way of thinking? (1)

Bastard of Subhumani (827601) | more than 7 years ago | (#17986938)

I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax
Isn't that what a language reference/online help is for? I believe TFA said that.

Sort of ... (0)

Anonymous Coward | more than 7 years ago | (#17986998)

Most programmers use only a subset of a given language. That suffices for 99% of what they want to do. When they have a problem, they will indeed appreciate finding someone else's solution. The problem is that whoever coded the solution probably did not use exactly the same subset of the language. That means the programmer will either: a) paste in the solution if it works without modification. or b) hit the books to try and figure out how the solution works. That often means looking up the syntax of something unfamiliar.

So; a little from column A and a little from column B ...

Re:Opposite way of thinking? (1)

misleb (129952) | more than 7 years ago | (#17987064)

Is that really true? I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax (and sometimes even the libraries/classes already available) to allow me to do what I want. Is this because I'm only a recent (2 yrs) CS grad?


Yes.

Isn't this the normal way to approach the problem due to the myriad languages used out there? It seems to me this might be true only if you're very familiar with a particular language and are trying to use that for everything which may or may not be possible.


Sometimes it makes sense to try to solve a problem with a language you know well than to try to learn a whole new language because, in some theoretical way, it might be a little more suited. That isn't to say that you should program an ecommerce site in assembly just because yo happen to be a very good assembly programmer, of course. Just use your head. Know when to learn something knew and when to use what you know to get something done within whatever time/resource constraints you h ave.

-matthew

Re:Opposite way of thinking? (2, Insightful)

jimstapleton (999106) | more than 7 years ago | (#17987238)

I'm the same way, but I've been programming for 10 years. I'm more likely to get tripped up on quirks of a language, even one I know well, than to not be able to figure out an algorithm to solve a problem.

Actually the most common problem is usually a small typo, that I don't see for three hours...

Re:Opposite way of thinking? (1)

mysticgoat (582871) | more than 7 years ago | (#17993610)

Actually the most common problem is usually a small typo, that I don't see for three hours...

Heh, I know those little gotchas better than I'd like. It seems no matter how experienced I am with the language du jour [ldj], I'm going to lose some time to one or two of those guys every week.

But when I'm starting work in a language that is pretty new to me— PHP at the moment— what I'm most uncomfortable about is whether I'm choosing a suitable approach to the problem at hand. For an instance, with parsing and lexing issues, Perl's regular expressions make for some elegant ways to finesse many problems— but is an approach that is elegant in Perl on the client going to be practical in PHP on the server? Or maybe PHP offers some optimized built-in functions that would be even more elegant than Perl's regexes?

Most of my time in starting up with a new language is lost researching those kinds of questions. And I very much like good code cookbooks for that kind of research. What I really hate is getting deeply invested in one approach, only to learn that the ldj provides better support for an entirely different approach.

Syntax and such isn't worth my study until I'm actually coding. I'll spend a couple of hours or so looking over a language's syntax, but mostly I'm just trying to learn my reference material so I can quickly find my way back to where the answer was when I need it. I find that I absorb a language's syntax through my fingertips, as I write/rewrite the code. The real problem with a learning a new language is learning how to think within its constraints and advantages.

Re:Opposite way of thinking? (1)

frostoftheblack (955294) | more than 7 years ago | (#17987924)

Can't you do both at the same time? When I need help with a problem I usually have a vague idea of HOW I want it to get done, but not necessarily the proper syntax. If I can find a book/article/reference that shows me the problem solution, then isn't its syntax already included? In that case, what is wrong with looking up a way to solve the problem, seeing as they both give the correct answer?

Re:Opposite way of thinking? (2, Insightful)

Just Some Guy (3352) | more than 7 years ago | (#17989228)

Is that really true? I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax (and sometimes even the libraries/classes already available) to allow me to do what I want. Is this because I'm only a recent (2 yrs) CS grad?

Yes, but I think it also speaks to the level of challenge to your comfort you've been faced with. There are three major roadblocks programmers run into:

  1. Language syntax. This should mostly cure itself over time.
  2. Algorithm choice. Again, experience tends to take care of this, regardless of the language you're working with today.
  3. Best practice. Unless you become one of the experts in your field, you should be asking your self how those people have solved the same problem you're working on. The best algorithms and perfect syntax won't help you apply a bad solution to the problem at hand.

Cookbooks mitigate the last of these. Sometimes you just want to be told how to best solve problem X - the syntax and algorithms will come naturally afterward.

Re:Opposite way of thinking? (1)

Jack9 (11421) | more than 7 years ago | (#17990792)

When you are asked to do serious work, it's about the most efficient way which has inevitably been worked out by someone else with a bigger budget and more time. The rest of the people claiming that a good programmer already knows how, have been solving the trivial for so long they can't imagine the larger problems that experienced programmers face.

Re:Opposite way of thinking? (1)

I Like Pudding (323363) | more than 7 years ago | (#17991176)

I have this same problem with Lisp. I can never remember where the parentheses go!

Die already (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17986724)

Can't PHP just die already and make room for proper languages and proper development platforms, like Ruby/RoR, Python/Django/TurboGears, C#/VB/.NET, etc, etc?

Re:Die already (0)

Anonymous Coward | more than 7 years ago | (#17986814)

I was right with you there buddy, until you mentioned Ruby/RoR and C#/VB/.NET

Re:Die already (1)

Bastard of Subhumani (827601) | more than 7 years ago | (#17986978)

... I was too till he missed out perl.

Re:Die already (0)

Anonymous Coward | more than 7 years ago | (#17987024)

> ... I was too till he missed out perl.

**shudder** ;-)

Re:Die already (1)

nuzak (959558) | more than 7 years ago | (#17992636)

Actually that's @{&$shudder->()} to you fella ;)

Re:Die already (0)

Anonymous Coward | more than 7 years ago | (#17987066)

VB?

Buy my forthcoming PHP book instead (3, Funny)

Anonymous Coward | more than 7 years ago | (#17986768)

Chapter 1 will discuss building PHP CLI classes that download and install OpenJDK. Chapters 2-22 will teach you Java.

Re:Buy my forthcoming PHP book instead (0)

Anonymous Coward | more than 7 years ago | (#17991146)

OMG PHP is so awful! Aaah!!!!!!!!!!!!

You might also keep all your knives in the cupboard 'cause you have yet to learn not to hold the pointy end.

Go code with your language of choice and stfu.

Thanks,

G

Where's the security section of the book? (4, Insightful)

Mysticalfruit (533341) | more than 7 years ago | (#17986878)

I'm a bit disappointed to read in the book review that there wasn't a chapter dedicated to security. Considering that PHP will let you do things like do external includes from other web servers that can modify your PHP environment, etc...

What PHP needs is not more features, but better designed security model.

Re:Where's the security section of the book? (1)

burnin1965 (535071) | more than 7 years ago | (#17988360)

What PHP needs is not more features, but better designed security model.

While improvements in security should be high on the list of PHP development objectives I think PHP gets a bad rap for what are short comings in the design and coding of the applications written in PHP.

Many PHP applications are designed to use a single database user for all queries against the application database thus providing the equivalent of admin or root access to the application database if a security bug is found in PHP or in the coding of the application itself. This seems to be a systemic problem in web applications whether they are written in PHP or some other language.

And now for the shameless plug. Seeing this short coming I've been working on a security model for PHP applications that avoids placing the database owner's username and password in a plain text file and using it for every database query in the application.

phpgirder.sourceforge.net [sourceforge.net]

Re:Where's the security section of the book? (0)

Anonymous Coward | more than 7 years ago | (#17989118)

Someone else replied saying much what I'm about to say, but I want to reinforce it.

Application security should _not_ be the responsibility of the programming language. It should be the responsibility of the application developer.

To use your example: Using external includes is not a security risk unless I'm using them the wrong way.

Imagine what C would look like if they tried to solve software security defects at the language level.

If PHP were a WYSIWYG type of "drag this box here and link it to that box, and press this button and you have a CRUD SCREEN!" language, this would be different, but it's not. it's a full featured web dev environment that NEEDS and in fact THRIVES on flexibility.

Re:Where's the security section of the book? (2, Informative)

wizzahd (995765) | more than 7 years ago | (#17989408)

Application security should _not_ be the responsibility of the programming language. It should be the responsibility of the application developer.

Couldn't agree more!

Not to mention that PHP security is not that difficult to implement! If you verify =all= of your input (which you should be doing anyway, in any programming language, for any application), you've solved most of your security issues. If you allow a $_GET variable to go straight into an include statement without testing/filtering/verifying/SOMETHING, you don't understand security in the first place.

Re:Where's the security section of the book? (1)

1110110001 (569602) | more than 7 years ago | (#17989324)

Considering that PHP will let you do things like do external includes from other web servers that can modify your PHP environment, etc...

allow_url_include is Off in php.ini-recommended. You have to do something wrong to allow external includes.

Re:Where's the security section of the book? (0)

Anonymous Coward | more than 7 years ago | (#17989780)

"The book's second part covers some of the most common applications in PHP programming: Web page creation (using XHTML and CSS), Web form handling, data validation and standardization, sessions and user tracking, Web services and other protocols, relational databases and other data storage methods, e-mail, XML, images, error reporting and debugging, and user authentication and encryption . That last chapter, in the next edition, should be relocated so that it precedes or follows the chapter on sessions and user tracking."


Were you expecting a spoon-feeding?

Re:Where's the security section of the book? (1)

suv4x4 (956391) | more than 7 years ago | (#17990074)

Considering that PHP will let you do things like do external includes from other web servers that can modify your PHP environment, etc...
What PHP needs is not more features, but better designed security model.


Noone is putting a gun on your head to do an external include on a random external file.

*Any* reasonably flexible language allows you to shoot yourself in the foot, if you so desire. This is why serious programming is best kept away from little children.

PHP is... (0, Flamebait)

Viraptor (898832) | more than 7 years ago | (#17986910)

"PHP is not a real language" flame war starts in: 5, 4, 3, 2...

Missed it by one... (1)

Ron Harwood (136613) | more than 7 years ago | (#17986958)

You were one post late... admittedly, he was very polite for a troll.

Re:Missed it by one... (1)

Bastard of Subhumani (827601) | more than 7 years ago | (#17987068)

If you're referring to Mysticalfruit (533341), he's expressing his honest opinion. Regardless of whether he's right or wrong, or whether you agree or not, if that's a troll then it takes one to know one.

Re:PHP is... (4, Funny)

jo42 (227475) | more than 7 years ago | (#17987158)

Yes, realize that the acronym for PHP Object Oriented Programming is POOP.

Thus, the title of the next PHP book should be along the lines of "How To Write Real POOPy Code".

Re:PHP is... (1, Funny)

Anonymous Coward | more than 7 years ago | (#17993078)

There was a perl interest group a while ago dealing with object persistence systems like Tangram and Class::DBI. They called it Perl Object-Oriented Persistence, and the mail list was the "poop-group"

PHP for web (0)

Anonymous Coward | more than 7 years ago | (#17987062)

I've loved PHP for the last few years. If it has taught me anything it's that Snape kills Dumbledor in Harry Potter. Enjoy PHP! I know I do.

I think... (5, Funny)

e2ka (708498) | more than 7 years ago | (#17987110)

thissounds() like_a_really() interestingBook()

Re:I think... (1)

hyperstation (185147) | more than 7 years ago | (#17987148)

OMFG, that is so true. agrrrrrrraaa!

Re:I think... (0)

Anonymous Coward | more than 7 years ago | (#17987462)

Note inability of the devs to camelCase functionNames() and provide an optional loadable secondary lookup table that aliasesold(), depreciated_names()

If that and lack of namespaces aren't enough to make you want to punch yourself in the balls rather than use such a crappy language, there's no shortage of other reasons. [wikipedia.org]

Re:I think... (0)

Anonymous Coward | more than 7 years ago | (#17988616)

Why would anyone use camel case function names in a language that doesn't support case sensitivity in function names?

PHP is a tool for a specific purpose. Directly embedding code in HTML text. You can argue that PERL, Ruby, Python, Java, .Net, etc are better for this. But, none of them really do that (exception being ASP.NET). All the other languages have to completely generate all of the HTML every time they execute. PHP has a much quicker turnaround time from the time the web designer generates a pretty page to the app developer produces code to make the variable part of the page get generated.

So, lets get to the list: The no shortage of other reasons link point to a list of 7 (that's actually kind of short) items that some people complain about in PHP.

  • register globals - has anyone in the last four years ever located a PHP installation that uses this? Agreed this was a horribly bad idea, but long since been fixed.
  • confusion about escaped quotes - so the programmer can get confused, therefore the language isn't good enough?
  • native unicode support - okay, this could be legitimate, but most languages since the dawn time (1970) haven't had unicode support, and the world got by just fine using multibyte strings without direct unicode support
  • variables can be used before they are defined - ok, C does that too, I always compile -Wall C, and I always use E_NOTICE on PHP
  • namespace support - (you already mentioned, I guess no shortage is actually 6) You shouldn't be writing enterprise wide databases in PHP, you should be designing dynamic HTML ages in PHP, You shouldn't have conflicting function names.
  • dynamic typing lacks predictability - ok that's fair
  • internal consistency in function names - You've already mentioned it, so I guess no shortage is really closer to 5, but this is the one thing that really irritates me about PHP (and overall I like the language). I mean really who came up with isset($a), is_array($a), empty($a), array_key_exists("foo",$a), and never said "I need a function that does X I should see if there's a function does something similar and try to follow that naming convention."

So In summary, PHP is the right tool for the job (sometimes). As all real languages are C, and any non-C language is really just a configuration file for a protracted C program, and C does not support namespaces, I must conclude that absence of namespaces is not sufficient grounds to want to punch myself in the balls.

Re:I think... (1)

poopdeville (841677) | more than 7 years ago | (#17989832)

PHP is a tool for a specific purpose. Directly embedding code in HTML text. You can argue that PERL, Ruby, Python, Java, .Net, etc are better for this. But, none of them really do that (exception being ASP.NET)

Perl can do it too. Look up Template::Toolkit on the CPAN. Mason does it too, if i recall.

Re:I think... (0)

Anonymous Coward | more than 7 years ago | (#17989968)

Why would anyone use camel case function names in a language that doesn't support case sensitivity in function names?

camelCase is used for method names for a reason (hint [w3.org] ) and global functions should use underscores.

register globals - has anyone in the last four years ever located a PHP installation that uses this? Agreed this was a horribly bad idea, but long since been fixed

Fixed into $HTTP_*_VARS, $_GET, $_SERVER, $_POST, $_COOKIE, $_SESSION, $_FILES, $_ENV, $_REQUEST and $GLOBALS superglobals yet idiots still print_r() unvalidated input!

confusion about escaped quotes - so the programmer can get confused, therefore the language isn't good enough?

In SQL quotes are escaped with another quote so 'foo' becomes ''foo''. Magic quotes was a stupid MySQLism that caused real pain moving code between servers.

native unicode support - okay, this could be legitimate, but most languages since the dawn time (1970) haven't had unicode support, and the world got by just fine using multibyte strings without direct unicode support

Sorry, I was under the impression PHP was a specialist language for the web? How long has javascript had unicode support again?

variables can be used before they are defined - ok, C does that too, I always compile -Wall C, and I always use E_NOTICE on PHP

PHP has variable variables for self modifying code etc.

namespace support - (you already mentioned, I guess no shortage is actually 6) You shouldn't be writing enterprise wide databases in PHP, you should be designing dynamic HTML ages in PHP, You shouldn't have conflicting function names.

Was that an admission PHP is useless for large scale projects without namespaces?

I must conclude that absence of namespaces is not sufficient grounds to want to punch myself in the balls.

Try writing something more complex than a homepage or forum and it just might!

Re:I think... (0)

Anonymous Coward | more than 7 years ago | (#17991118)

I must conclude that absence of namespaces is not sufficient grounds to want to punch myself in the balls.
Try writing something more complex than a homepage or forum and it just might!

I have written a web based system that has a much higher degree of complexity than a forum (in the range of 30,000 lines) in PHP. No conflicts in function names. It is true there were one or two occurrences that might have been better suited to namespaces, but not generally. This code also supports multi-lingual strings for anything and has a hindi po file (even without unicode support for the code). I have also written more C code than anything else. Complete web servers (even one capable of supporting PHP as a dynamically loasded plugin) without ever having a namespace issue. Your operating system is much more complex, and wasn't written with namespaces. (I should note that being a long time C programmer has led me to tending to name functions _modulename_fxnname() which is kind of a self-implemented unenforced namespace.)

I did concede that PHP is not a solution for every problem, but it does handle embedded web pages better than most languages.

By the way I do use variable variables frequently. I actually kind of like them. It makes writing certain kinds of configuration files easier.

And idiots using unchecked $_HTTP | $_POST variables can/will/does happen in any language.

Re:I think... (1)

encoderer (1060616) | more than 7 years ago | (#17991432)

And for what it's worth, every benefit of namespaces can be had using the scope resolution operator:

class myClass
{
      function someMethod() {
      }
}

x = myClass::someMethod();

Re:I think... (0)

Anonymous Coward | more than 7 years ago | (#17987996)

don't forget that (thissounds() === thisSounds() === ThisSounds() && interestingBook() === InterestingBook() === interestingbook())

ah, the joys of PHP! I love the smell of consistency in the morning.

Probably to the opposite of most people, I jumped the Java bandwagon to get back to PHP. PHP's OO features actually have a lot of niceties that Java could learn from (namely, "magic" methods)

Teaching Bad Practices (Hopefully Not) (2, Interesting)

HighOrbit (631451) | more than 7 years ago | (#17987114)

A few years back (circa 2002), I whipped up a rapid application prototype with PHP while working off from some on-line tutorials and using Beginning Php 4 from Wrox. I think the book and the tutorials were good a teaching the basic language features and syntax, but they taught me to use PHP dangerously because they did not teach good practices. My application worked but never got out of the prototype/demo stage back then for business reasons. Recently, I went back to it on my own time to try to clean it up, move it to PHP5, and make it deployable. I now cringe with horror at the extremely bad practices I was using back then. Granted, it was just a prototype, but I thought I was doing it "right" because I was following the examples in the book and the tutorials. I was doing stuff like accepting form data and passing it to the DB with out validation, outputting user submitted variables without checking for XSS, registering globals, etc, etc, etc. I was doing the kind of things that give me nightmares now.

So here is my point, all the tutorials, examples, and books that the neophytes are using to learn are _WRONG_. They are teaching _BAD_PRACTICES_. Because PHP is necessarily meant to be in a network environment (excluding the rarely used cli) and it WILL be exposed to potential maliciousness, secure practices should be taught markedly at the beginning, not as an aside. So as part of teaching how to pass form parameters they should include validation code, even if they have to comment that section as " /* trust us on this part for now, we'll show you how this part works latter, just remember you always have to validate the input before you use it */".

I think PHP is a great language for its purpose, which is simple web-apps. Lots of the criticism about its brain-dead defaults is correct, but they can be overcome with good practices by the application developer. PHP can be great, but it is typically taught wrong at the beginning and that just snowballs.

The editors and authors all the PHP books and tutorials out there need to make sure the new editions encapsulate good practice at the beginning of the learning process.

first disclaimer- I haven't read this particular book. I hope it is better than the other PHP books to which my comments apply.

Second, disclaimer- this is mostly a repost from my post [slashdot.org] at this discussion ( PHP Application Insecurity - PHP or Devs Fault? [slashdot.org] )

Re:Teaching Bad Practices (Hopefully Not) (1)

mysticgoat (582871) | more than 7 years ago | (#17994086)

So here is my point, all the tutorials, examples, and books that the neophytes are using to learn are _WRONG_. They are teaching _BAD_PRACTICES_.

Yes. Sort of.

I first encountered this when I was involved along with 2 or 3 other guys in helping a neophyte Delphi programmer write an inventory system for her husband's plumbing business. This was back in the days before time, when the intarweb was still Darpanet so all of us were using CompuServe. She would run into a snag trying to apply something from Jeff's book or the Borland manuals, post about it, and we would try to help her figure out why it wasn't working in her application.

After a while, I realized that there was an underlying problem we were not addressing: she was attempting to model her code after the snippets in the books, but the snippets were written to highlight a particular feature under discussion; they were not real world examples. Once we clarified with her that the books were showcasing the features in ways that would make them stand out without confusing real world context, her questions changed from "why doesn't this work" to "should I try using this approach instead of that one" and her project began to move along. (Her long term goal was to complete her Masters in mathematics or something like that once her youngest one was in kindergarten; learning Pascal and OODB design was a way to keep her mind limber during the rugrat years.)

Call this "showcase syndrome": I've seen it often enough among neophytes that I think it deserves to be a named entity. It is the mistaken belief that you can take code snippets from a programming book and plug them into a real world program in the same way that you can use an algebraic expression from a math book to compute a real world value.

Back to the point: Don't EVER rely on introductory books to present good programming practices. It cannot be done; there is too much that needs to be simplified to present the basic concepts in a way that is easily comprehended by the someone who does not yet have a broad background. There is a similar problem with language references: much contrivance of example and presentation is needed to fill the immediate need.

That's why there are code cookbooks, compendia of best practices, and so on.

Captchas (1)

linvir (970218) | more than 7 years ago | (#17987144)

In the last chapter, there is a section with code that generates captchas, but the reader is not shown what they look like.

What the hell? How can you write about captchas without showing pictures?

Here is a good example. Note the varying font and background noise.
Here is a bad example. Note the uniform font and straight lettering.
How else do you get this point across properly?

Re:Captchas - decoding (1)

stormeru (1027946) | more than 7 years ago | (#17988812)

I think that decoding captchas using PHP [megaleecher.net] would have been a more interesting chapter.

PHP 5 in practice (0, Troll)

imbaczek (690596) | more than 7 years ago | (#17987330)

sucks.

my recent delvings (1, Funny)

Anonymous Coward | more than 7 years ago | (#17987500)

I recently finished up Gone With The Wind. Would you consider this book:

A. Funnier than GWTW
B. Just as funny as GWTW
C. Not as funnier as GWTW

Your valued insight into this fine work would be greatly appreciated and it would help me make my next book purchase easier.

Thanks in advance.

Another big, fat book of examples. Yawn (2, Insightful)

Animats (122034) | more than 7 years ago | (#17987580)

Another one of those huge low-density books of examples. Do we really need another one.

What's really hard today is finding a good reference manual. The original manual for Algol was 17 pages. The original manual for Scheme was 21 pages. 456 pages for PHP is a bit much. A big plastic card that boiled the language down to two pages - now that would be useful.

Re:Another big, fat book of examples. Yawn (3, Informative)

DarkSarin (651985) | more than 7 years ago | (#17987700)

Try this: the cheat sheets on this site are generally quite good.
http://www.ilovejackdaniels.com/cheat-sheets/php-c heat-sheet/ [ilovejackdaniels.com]

Enjoy

Useful cheat sheets. (1)

Animats (122034) | more than 7 years ago | (#17989424)

Now that's useful.

Today I could use ones for Perl and Python; I'm converting someone else's regular expressions from Perl to Python. Both have almost the same syntax.

Save $11.60 by buying the book at Amazon.com! (0)

Anonymous Coward | more than 7 years ago | (#17987662)

Barnes and Noble is selling this book for $39.99, but Amazon.com is only selling it for $28.39!
 
Save yourself $11.60 by buying the book here: PHP 5 in Practice [amazon.com] . That's a total savings of 29.01%!

As a longtime(past tense) PHP developer I can say: (3, Informative)

LuckyStarr (12445) | more than 7 years ago | (#17987836)

PHP books are good for one thing - making some money for the author(s). That being out of the way, here comes the rant:

With languages like Ruby, Python, Perl, etc. around, why bother with PHP?

PHP has:

It does however have a good documentation. Without it though, programming PHP would be impossible. Try coding PHP without the documentation at hand.

"Was it function_name($foo, $bar) or functionname($bar, $foo)? Or rather prefix_function_name($foo,$bar,$baz) where $baz is always empty?"

I could go on and on. These are just the facts. What I ignored are the countless hours I wasted trying to debug some perfectly good looking piece of code only to find out in the end that PHP is the problem. On that occasions PHP ate away a part of my soul. (pretty poignant, eh?)

And yes, in case you wonder, I did very large PHP stuff. Megabytes of code in CVS. Luckily no more. (Could be written in kilobytes of Ruby anyway.)

Re:As a longtime(past tense) PHP developer I can s (0, Troll)

tha_mink (518151) | more than 7 years ago | (#17988138)

I could go on and on. These are just the facts. What I ignored are the countless hours I wasted trying to debug some perfectly good looking piece of code only to find out in the end that PHP is the problem. On that occasions PHP ate away a part of my soul. (pretty poignant, eh?)

Are you SURE it was PHP? I wonder how you could spend "countless hours" debugging PHP code? I've been at the PHP language for years and the one thing you CAN say about PHP vs other languages is that it shouldn't take "countless hours" to debug. I mean...countless hours? Ate your soul? Perhaps programming isn't really for you. Maybe sales? or marketing?

Re:As a longtime(past tense) PHP developer I can s (2, Interesting)

LuckyStarr (12445) | more than 7 years ago | (#17988816)

Are you SURE it was PHP? I wonder how you could spend "countless hours" debugging PHP code? I've been at the PHP language for years and the one thing you CAN say about PHP vs other languages is that it shouldn't take "countless hours" to debug. I mean...countless hours? Ate your soul? Perhaps programming isn't really for you. Maybe sales? or marketing?
You are right. It shouldn't take countless hours to debug. Note my emphasis. Debugging code written by a sane developer in any sane language would not take countless hours. Yet the world is full of programmers which abuse PHP to a level where you start to get the feeling that a complete rewrite of "the thing" is "the way to go". Many of these programmers are good programmers and rather build abstraction-layers instead of spaghetti-code. On the other hand, 20 layers of abstraction on top of each other do not make it easier to find that bug that is hunting you (through Sales, or Marketing).

And in the rare case when you actually find that bug, it turns out you can't fix it because the whole card-house would crumble into oblivion if you did. So you build workarounds (which accumulate) that are the heralds of death of the system.

I should have said that I did not in fact write the whole 30ish MB code base myself. I inherited it and got to live with it or do something else. It wasn't planned, it wasn't built using development methodologies (think XP, Scrum, etc.) but rather using a whip. The explanation for the system then is something along the lines of "It has grown organically.".

And although I see myself primarily as a programmer, I am in fact working on extending my abilities to encompass marketing. So your evaluation flatters me. ;-)

Re:As a longtime(past tense) PHP developer I can s (1)

georgeb (472989) | more than 7 years ago | (#17988866)

Amusingly enough I have encountered the same sort of frustration that the grandparent post author has. Just never ever try to write a SOAP server using the core SOAP module :D I mean it, you will go insane in a matter of days. Even for day-to-day tasks, because PHP makes simplicity it's creed you will run into all sorts of problems the minute you grow your project into something bigger. Most of the problems I have run into were undocumented or poorly documented "features", I'll admit, but on occasion the dent my head left in the wall was caused by pure and simple brain damage on the part of the PHP developers. The SOAP core module is a good example. PDO is another. I was once considering switching from the PEAR DB layer to PDO, given that it was advertised as a superior solution and given that PEAR in particular is a very bad piece of programming one should avoid at all costs. On paper PDO looks great. The implementation sucks. Half the time the database was returning an error the PHP process would segfault. Consider this, many a year has passed since Apache mpm-worker has been around as a stable and reliable solution. Even to this day I am forced to rely on mpm-prefork. PHP would randomly segfault otherwise, because some of the core modules are not yet multithreading aware.

Re:As a longtime(past tense) PHP developer I can s (1)

Khuffie (818093) | more than 7 years ago | (#17988156)

I needs to look into this Ruby thing. Can you recommend any good Ruby books? I know there's plenty of stuff online, but I'd much rather read through a book for stuff like this.

Re:As a longtime(past tense) PHP developer I can s (1)

LuckyStarr (12445) | more than 7 years ago | (#17988906)

Well, theres why's (poignant) guide to ruby [poignantguide.net] which is licensed under creative commons. So it could be that somebody made a book on demand out of it. Personally I used "Programming Ruby" of which the first edition [rubycentral.com] is also available online. "Rails Recipes" is a very good reference book for repeating patterns using Ruby on Rails. Rails though also has it's annoyances so I am trying to find an excuse to build something with Django and Python.

Re:As a longtime(past tense) PHP developer I can s (2, Insightful)

jimicus (737525) | more than 7 years ago | (#17988234)

I'd go on and say that IMO (which genuinely is humble, as I'm a sysadmin who's prepared to look at and tweak code if necessary, rather than a fulltime dev), PHP has promulgated an entire mass of badly written, badly commented, ill conceived code.

Sure, it's possible to write bad code in any language. But PHP is like the BASIC of the web. Popular, (yes, there was a time BASIC was popular) yet treated with contempt because it's just so easy to shoot yourself hard in the foot. At least with C, you usually know pretty early on if your code is really badly thought up. With PHP, however, it seems that nobody quite realises what a festering mess they've produced until someone else points it out, by which time it's taken as a personal attack.

Re:As a longtime(past tense) PHP developer I can s (1)

Tablizer (95088) | more than 7 years ago | (#17988244)

With languages like Ruby, Python, Perl, etc. around, why bother with PHP?

Hide the kids; here comes another language/paradigm holy war....
           

Re:As a longtime(past tense) PHP developer I can s (3, Interesting)

georgeb (472989) | more than 7 years ago | (#17988426)

With regard to the link you provided under "no usable object-model" - I would have to agree with the PHP developers on that one. self::$var or self::CONSTANT is supposed to bind statically. That is how self is supposed to work and actually what the bug reporter was trying to achieve is impossible in C# too AFAIK.

Namespaces are upcoming in PHP6 (again, AFAIK).

The rest of the observations are correct to the best of my knowledge and make PHP quite a horrible choice for all projects beyond a certain complexity threshold. Personally I wouldn't think of Perl as a substitute, even though I understand in many respects Perl is superior to PHP, I just find it difficult to make the right choices when it comes to picking a module for a given job. I think Perl suffers from a lot of duplicated effort, there is no concerted effort to establish a de facto framework of modules.

PHP is dying a slow death in my eyes because of all the inconsistencies. The object orientation feels more like a patch or a workaround rather than a core architectural choice. The total mess created by the ton of functions in the core is not going to go anywhere with the devs maintaining backwards compatibility indefinitely.

Re:As a longtime(past tense) PHP developer I can s (1)

nuzak (959558) | more than 7 years ago | (#17989064)

> Namespaces are upcoming in PHP6 (again, AFAIK).

That's nice. Is not segfaulting when the stack depth is exceeded also a planned "feature"? Because every report on the problem is still WONTFIX.

Picking on PHP just isn't worth the effort anymore. Nor is waiting for it to be fixed.

Re:As a longtime(past tense) PHP developer I can s (2, Interesting)

tknd (979052) | more than 7 years ago | (#17989430)

Personally I wouldn't think of Perl as a substitute, even though I understand in many respects Perl is superior to PHP, I just find it difficult to make the right choices when it comes to picking a module for a given job. I think Perl suffers from a lot of duplicated effort, there is no concerted effort to establish a de facto framework of modules.

In perl's defense, I think that's sometimes the biggest reason I choose perl over the others. The good thing about duplicating or reinventing the wheel is sometimes you need different wheels for different tasks. It also facilitates evolution and a plethora of ideas that you would otherwise miss if you had put everyone together and told them to make THE ONE best module because there will always be drawbacks to even particularly good implementations. The result is perl's library (cpan.org) is massive. When I look at other things like Ruby, though I like the language features, the library work simply isn't there yet.

As a side note, there's some really cool libraries out for perl. Check out moose [cpan.org] or catalyst [cpan.org] for example.

Informative? This is A Flamebait post. (0)

Anonymous Coward | more than 7 years ago | (#17988832)

How do I know?

(Could be written in kilobytes of Ruby anyway.)

bullshit

This person has probably never coded PHP, but has programmed in other languages much, and jumped ship to ruby.. He is a Ruby fanboy, He has the sense to search bugs that point out some flaws in PHP, but I can easily paste links to a bunch of ruby bugs. Yet the mods are so fucking blind they don't see this.

Furthermore, Ruby compared to PHP is an even lazier language. You probably dont have to understand many programming concepts if you can cut countless hours into minutes with Ruby. The language does not encourage strong security, good coding practices, and last time I checked the development of the project is only a few years old. I remember PHP's functions just fine, and are you going to make fun of c++ or java for their wierd naming of functions and classes? And don't get me started on the original Ruby "how to code ruby in 10 minutes" video, where the guy is having to change the config files over and over just to get the thing to work.. Mod parent flaimbate..

Re:Informative? This is A Flamebait post. (2, Informative)

LuckyStarr (12445) | more than 7 years ago | (#17989132)

bullshit
So why do you post anonymously? :-)

This person has probably never coded PHP, but has programmed in other languages much, and jumped ship to ruby.. He is a Ruby fanboy, He has the sense to search bugs that point out some flaws in PHP, but I can easily paste links to a bunch of ruby bugs.
Please do. I am sure they are 1. already fixed or 2. not present in the new parser (YARV) which is going to be Ruby 2.0

I began coding PHP around 1997. Then I did not know better. Now I do. Although I generally program in languages featuring a garbage collector (memory allocation is not mine) I keep adding new language to my tool belt on a regular basis. Python is next.

Furthermore, Ruby compared to PHP is an even lazier language. You probably dont have to understand many programming concepts if you can cut countless hours into minutes with Ruby. The language does not encourage strong security, good coding practices, and last time I checked the development of the project is only a few years old. I remember PHP's functions just fine, and are you going to make fun of c++ or java for their wierd naming of functions and classes? And don't get me started on the original Ruby "how to code ruby in 10 minutes" video, where the guy is having to change the config files over and over just to get the thing to work.. Mod parent flaimbate..
Please get your facts right when flaming. Ruby was started in 1993. PHP/FI was started in 1994. At that time PHP was not even a language. PHP3 (on which all the crap of today is built) was released in 1997!

ok moron.. (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17989740)

So why do you post anonymously? :-)

Because I can, I don't need a userid to call your bullshit

Please do. I am sure they are 1. already fixed or 2. not present in the new parser (YARV) which is going to be Ruby 2.0


Sure thing bud:

http://rubyforge.org/tracker/?atid=1698&group_id=4 26&func=browse [rubyforge.org]

Please get your facts right when flaming. Ruby was started in 1993. PHP/FI was started in 1994. At that time PHP was not even a language. PHP3 (on which all the crap of today is built) was released in 1997!

Funny, for someone whos programmed sooooo much, you'd figure they'd know a little history about that language.

From Wikipedia

http://en.wikipedia.org/wiki/Ruby_on_Rails [wikipedia.org]

Ruby on Rails was extracted by David Heinemeier Hansson from his work on Basecamp, a project-management tool by the web-design company 37signals.[1] It was first released to the public in July 2004.

OK July 2004 means Ruby on Rails not even 3 years old. Unproven to say the least. Now stop trying to bullshit everyone by spreading misinformation

Re:As a longtime(past tense) PHP developer I can s (1)

nozavroni (1021425) | more than 7 years ago | (#17988904)

I have a hard time believing you really worked with PHP for any length of time. While some of your points are in the ballpark of valid, for the most part you're just repeating the PHP slander I hear all over the internet. The fact is you can shoot yourself in the foot in any language. The reason PHP takes so much heat is because it's free,it's popular and it's extremely easy to learn and so it's easy for beginners to make mistakes like not filtering/validating user input and not escaping output, but any experienced developer should know to do this. I'd like to hear you point out an example of a bug that took you HOURS to debug. I really would.

Re:As a longtime(past tense) PHP developer I can s (1)

LuckyStarr (12445) | more than 7 years ago | (#17989346)

Let me tell you something about the slander you hear all over the internet: It's all true.

Re:As a longtime(past tense) PHP developer I can s (1)

nozavroni (1021425) | more than 7 years ago | (#17989722)

that's a pretty strong argument. With all those facts you just pointed out, I guess I have no choice but to concede.

Re:As a longtime(past tense) PHP developer I can s (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17992570)

He linked to them. Most of them are WONTFIXes right from PHP's bug tracking system. What the fuck more evidence do you require?

Re:As a longtime(past tense) PHP developer I can s (1)

not already in use (972294) | more than 7 years ago | (#17988942)

As someone who's spent more than 4 years with PHP, I couldn't agree with you more. The only thing PHP has going for it is that it is widely supported among web hosts. I also think that Ruby and Python syntax may scare off a lot of people, whereas PHP is pretty much C syntax.

Re:As a longtime(past tense) PHP developer I can s (0)

1110110001 (569602) | more than 7 years ago | (#17989672)

no first-class functions (and no, create_function does not count)
Not all programming languages have and need this.

no usable object-model (check out response of developer below!)
self is bound at compile time. That's how it's defined. If you want to create active records like in Ruby just wait for PHP6 (currently the keyword is static).

problems with recursion
Infinite recursion is a problem in all programming languages - and a mistake. Several extensions help to avoid the segfault.

countless other horrible mis-designed "features" (not even starting on the security problems)
Check the dates of your bugs. For isset() use the magic method __isset(), the links in the second bug don't work, a static method doesn't have an instance and thus no $this. PHP 5 also warns about using a method as static without defining it as static.

Seems like you just want to use PHP as language X, which won't work and that's not PHPs fault. Use X and be happy.

Re:As a longtime(past tense) PHP developer I can s (1)

nuzak (959558) | more than 7 years ago | (#17992610)

> self is bound at compile time

Wow. That alone is enough to just make me double and triple take with WTF's. The very construct that is supposed to represent late binding in every other language is deliberately and specifically early-bound in PHP. In an otherwise duck-typed language, even. It's like the PHP devs read a book on object oriented design and then designed the language specifically to defeat it.

Re:As a longtime(past tense) PHP developer I can s (1)

1110110001 (569602) | more than 7 years ago | (#17993298)

self:: in PHP is not the same as self. or this. in other languages. It seems like you're describing $this, which does refer to the current instance (you could call that late binding if you're into buzzwords).

Re:As a longtime(past tense) PHP developer I can s (2, Interesting)

specific_pacific (904746) | more than 7 years ago | (#17990168)

That's why Smart Developers (C) use http://cakephp.org/ [cakephp.org] ;)

Re:As a longtime(past tense) PHP developer I can s (0)

Anonymous Coward | more than 7 years ago | (#17990668)

Smart developers avoid PHP and if they are forced to use it they avoid PEAR and bloated PHP frameworks because they're so slow.

Re:As a longtime(past tense) PHP developer I can s (1)

theuedimaster (996047) | more than 7 years ago | (#17993656)

"It does however have a good documentation. Without it though, programming PHP would be impossible. Try coding PHP without the documentation at hand." You're right, knowing the classes and libraries for different languages is always so easy..... you are just born with it right? What I'm trying to say is that any language, including php, can be manipulated to suit your needs with knowledge of the basic syntax. And like any language, when you want to take some shortcuts and make use of some helpful libraries (or php functions?), you will have to learn them.

Re:As a longtime(past tense) PHP developer I can s (1)

herve_masson (104332) | more than 7 years ago | (#17994260)

I could not agree more. PHP has been a nighmare for me _because_ I've a strong programming background (>15y) in various other languages (C, perl, objc, c++, etc). Everything I could find in PHP was either "unconventional" (read: different for no good reason), buggy or simply horribly flawed. I wasted days understanding the (lack of) logic of the whole thing, not mentioning crashes and such.

I believe people hate php as much as they have experience in programming (and inversely, beginners usually enjoy it). Sure, we also have exceptions with large php projects that are well designed, and managed by good programmers.

As long as you don't want to give your code a good structure, use generic coding, rely on an efficient OO runtime, etc. php is okay. Not many tools are available to beginners ; perl, ruby and python are certainly much more demanding.

Short answer (4, Funny)

tedhiltonhead (654502) | more than 7 years ago | (#17987984)

> PHP 5 In Practice

Way shorter book summary:

Don't.

You'll get no disagreement here (2, Interesting)

bbtom (581232) | more than 7 years ago | (#17988408)

I've gotta agree with some of the presuppositions and points in this review. PHP - in the right hands - is a powerful language. It's great that you can whip things up quickly. But too many of the books go through the fairly simple bits in mind-numbing detail (like, I know what an array is). Thanks to Eclipse and oXygen, most of the time that I'm at a screen, my editor can load the documentation in to a panel while I'm typing it (along with remembering class names, variable names and so on). If I'm coding PHP (or a lot of other languages, for that matter), Eclipse has the language reference. And oXygen gives me the documentation from XSD/RNG/DTD schemas for XML/XHTML etc. Language references aren't useful in dead tree format.

But something that dead tree can be useful for is conveying development experience. Of course, this can be transmitted in other means. Books that give me best practice guidelines are often far more useful than language guides. For instance, in PHP, there is a function called file_get_contents(). It does what it says. You give it a URL or file and it reads it in to a string. But what the language reference *doesn't* tell you is that for getting things off the 'net libcurl is a better way of doing it - it's quicker, more powerful and has a lot of extremely useful options - in short, something which, if one is intent on building a serious web application in PHP, one should probably use. This is one of the reasons why I think language references would be better if managed on a wiki - or, as PHP does it, with comments attached. That way, people can post code samples, bug reports, workarounds, common errors and so on. This is useful.

A measure of a successful technology book these days has to be "does this make me a better developer?". The fact that we have books which deal with best practice means that online documentation has gotten better and better and publishers are responding to that. Most of the languages and frameworks I use I carry the specifications for on my Palm Pilot in Plucker format. Reference books can't compete with that. A few publishers I've seen are shifting towards a tutorial style (in the web design sphere, Friends of Ed is a good example of this).

Re:You'll get no disagreement here (0)

Anonymous Coward | more than 7 years ago | (#17991974)

I've gotta agree with some of the presuppositions and points in this review. PHP - in the right hands - is a powerful language.

The problem is that if you've got the right hands, then you know better not to use PHP in the first place.

More good PHP Books (2, Interesting)

nugsack (219073) | more than 7 years ago | (#17989524)

Here is a good source for browsing PHP Book Reviews [top-books.org] . PHP In Practice [top-books.org] hasn't made the top 50 yet.

programmingbooks.org (1)

draed (444221) | more than 7 years ago | (#17989588)

Rank this book if you've read it!
http://www.programmingbooks.org/PHP [programmingbooks.org]

There's a lot of horrible programming books out there. I wrote this web app to help programmers easily find the good ones. Basically programmers rank their top 5 books based on category(in this case, php books). It only works if people use it though, so rank the good programming books you've read!

Picture books? (1)

Nazlfrag (1035012) | more than 7 years ago | (#17990208)

So instead of pages of useless screenshots this book decided to go with content? What a gaping flaw! There are many books on PHP full of screenshots and little else if that's your thing. I see it as a bonus - if you want to see the screenshot you'll have to start doing some coding. Personally, I like PHP for a quick and dirty script, but would not recommend it for a project that was larger than around 3 lines of code.

Wonderful! (1)

kimvette (919543) | more than 7 years ago | (#17991042)

Can someone point me at a torrent of the eBook version?

(I kid, I kid)

Blah Blah Blah!!! (2, Funny)

Delifisek (190943) | more than 7 years ago | (#17992248)

Same sh*t another day.
Some uber programmers doens't like PHP because of someting else... Then start to bashing again and again

Php can't do this, can't do that. Php can't scale, Php was ugly, yada yada yada....

First purpose of Php was templating engine for HTML.

Other things comes afer.

Also, Zend try to add OOP. WHY? Why we need OOP aproach, run once scripts...

In php you cannot store objects in the Memory by default... (if you not use Memcaced/Seralize things)

I still don't get it. It was stateless universe. Evrything runs once and goes to ashes.

Whe we need all those OOP overload ?

Maybe to get more respect from other languages ?

Paaah...

Php language for who can barelly handling HTML.
It may not look nice. It may have some problems. May diturbing over obsssed engineers.
Of course, you may do more nice OOP thing in ruby, python of course you may do some hiber,uber,hypernate in JAVA.

And you cannot give
this much ability
under this cost (both cpu/ram)
and with this usability...

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>