Slashdot Mirror
Spring Into PHP 5
Michael J. Ross writes "A professional programmer could at any time be tasked with developing a nontrivial application using a language or Web technology with which he or she is unfamiliar. A common response is to quickly scan code snippets in Internet newsgroups and online tutorials, copy and paste code that looks applicable to the task at hand, and then lose valuable time trying to make it all work and control what was created -- not unlike Dr. Frankenstein's experience. A smarter approach is to learn the language basics in sequence as rapidly as possible, not getting bogged down in excessive sample code. For developers seeking to learn PHP using the latter approach, Steven Holzner's Spring Into PHP 5, published by Addison-Wesley, would be an excellent choice." Read on for the rest of Ross's review.
Spring Into PHP 5
author
Steven Holzner
pages
340
publisher
Addison-Wesley
rating
8
reviewer
Michael J. Ross
ISBN
0131498622
summary
A comprehensive and no-nonsense primer on the basics of PHP.
This title is another entry in Addison-Wesley's promising "Spring Into" series, which, as suggested by the name, is aimed at developers who want to jump into a new technology and get up to speed as quickly as possible, but without missing any of the essentials. In the case of Holzner's PHP book, this goal is pursued by presenting the information in so-called "chunks," with each spanning just a few pages. Every chunk attempts to cover only one or a few related ideas, and is designed to build upon earlier chunks. The bulk of the explanation takes the form of code samples, which fortunately are short enough in length and clear enough in composition to be easily digestible. This is in stark contrast to far too many other programming books on the market, whose code samples can span multiple pages, making it difficult for the reader to discern all of the ideas that the author is trying to get across -- especially when the reader has to flip back and forth between pages. Even worse is how some authors (such as Deitel and Deitel) use lengthy code listings -- sometimes even complete applications -- to demonstrate many ideas at once, which can be quite confusing, especially for the newbie reading about a challenging language for the first time. As Holzner notes in his preface, his book is example-oriented, with dozens of tested code samples. But none are overwhelming.
Spring Into PHP 5 was published on 12 April 2005. It is organized into nine chapters, covering a range of topics: PHP essentials; operators and flow control; strings and arrays; functions; PHP in HTML pages; Web forms and input validation; object-oriented programming and file handling; PHP and databases; cookies, user sessions, FTP, e-mail, and hit counters. The book has two appendices. The first one, on PHP language elements, is remarkably complete, considering that it only fills 18 pages. Owners of the book will likely find themselves turning to this material quite frequently. The second appendix lists the most commonly used functions in PHP, particularly those dealing with arrays, strings, and files. These two appendices combined go a long way to making this book more than an approachable primer -- it could serve as a reference book for the language for any reader not required to dig into the more obscure intricacies of PHP. Readers with those needs will have to use more detailed sources, such as the online PHP Manual.
Each one of Holzner's chapters explains the core concepts, using the bite-sized chunks mentioned earlier. This approach is somewhat similar to the "recipes" found in many books published by O'Reilly Media, and it works well here for introducing a computer language. Holzner's writing style is clear yet never condescending, and concise yet never cryptic. The intended reader only really needs an understanding of simple HTML and how to edit text files, to make this book worthwhile and usable. The book is meaty with information, and yet not too lengthy. This is a refreshing change of pace from countless other computer language books that are bloated with redundant sample code and overly wide margins, apparently in an attempt to entice the consumer with maximum page count per dollar.
Some programming books try to move the novice along at too rapid a pace, which can get quite discouraging if and when the reader is unable to follow the discussion, and particularly if trying to follow the author in building a working example. But a far more common mistake among programming books, is to drag out the process with humongous code listings or redundant verbiage (such as following the senseless rule of telling the reader something three times -- a technique that makes far more sense for speechwriting). Holzner sets and maintains an excellent pace, partly by keeping the code snippets reasonably sized, and partly through his modular approach of presenting ideas in chunks.
The physical book itself is well made and attractive, with a readable font face and size, and intelligent use of bolding to highlight those lines of code upon which the reader should focus. My only complaint in terms of the presentation, is that the gray background used for the code samples could be lightened up a bit, to make the text itself stand out more, especially the bold text. All of the screenshots are in black-and-white, which works just fine, as there would be no value in using color in the majority of the sample Web pages.
The author does an excellent job of explaining and illustrating all of the most commonly used and needed elements of the language. But he provides little guidance as to when a particular technique or approach should be used over another. For instance, when explaining how the programmer can use PHP to connect to a MySQL database, the author presents two alternatives -- direct layer and Pear::DB -- but no recommendations as to the choice of one over the other. On the other hand, one might argue that to include recommendations of techniques, as well as language best practices, would require the book to be much longer than it is, which would detract from the book's goal of getting a programmer up to speed on PHP in an efficient manner. The serious programmer who wishes to take PHP to the next level, can be expected to read more advanced books, to learn from expert PHP developers posting in online newsgroups, and to learn from experience as the programmer creates his or her own applications.
Another potential point of criticism could be that the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL (the industry's favorite for use with PHP). But the database chapter, number 8, provides just enough information for the beginner to get started and to try out the basics. For simple database needs, the material in that chapter might be sufficient. Yet for more extensive MySQL usage, including installation and administration, other resources will need to be consulted. This book is clearly not intended to be one of those PHP + MySQL combo books that have proven so popular during the past few years.
The publisher's Web site for the book does not appear to have any collection of errata. Here are some that I found: On page 6, in the NOTE, "scripts can be used" should read "scripts cannot be used." On page 20, "#/ message to the user" should read "# message to the user." On page 49, in Table 2-4, in the last line, the formatting is partly wrong. Examples 3-1 through 4-14 contain incorrect indentation. On page 158, the last line in the $_FILES['userfile'] values is missing $_FILES['userfile']['error']. In Examples 5-19 and 5-20, the <head> and <h1> tags are missing ": Take 1." On page 169, the formatting of Example 6-2 is inconsistent with the others.
Aside from the errata, there were some other weaknesses -- none of them serious: The chapter summaries are useless, like in most other technical books, as there's not enough details to be instructive, and more details would make them even more redundant and space-consuming. On page 176, in Figure 6-6's caption, "Navigating" should be "Redirected." On page 197, the discussion of HTTP authentication is too brief to enable the typical reader to implement it. For instance, there is no mention of where to set $_SERVER[ 'PHP_AUTH_USER' ] to make it work. Chapter 7, on object-oriented programming and file handling, should be split into two chapters. Combining them makes no sense, and the author does not even transition from the first topic to the second.
Like others in the "Spring Into" series, this title is reasonably priced, at only $29.99 list for over 300 pages of quality material. The publisher, Addison-Wesley, has a page on their Web site devoted to the book, which includes a book description, a table of contents, an index, source code from the book, and a link for downloading a sample chapter (in PDF format), namely, Chapter 3, which covers strings and arrays. The site also has a link to a bonus chapter (also in PDF) that explains how to draw graphics interactively on a Web server and then send them back to the browser. Oddly enough, the page's title is "Spring Into PHP 5 - $20.99," but there's no indication as to how to get the book for only $20.99. That could simply be a typo. But there is a link to purchase the book online for $26.99. For those looking to spring into Web server-side development in general, or PHP in particular, it would be money well spent.
Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter for PristinePlanet.com. You can purchase Spring Into PHP 5 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This title is another entry in Addison-Wesley's promising "Spring Into" series, which, as suggested by the name, is aimed at developers who want to jump into a new technology and get up to speed as quickly as possible, but without missing any of the essentials. In the case of Holzner's PHP book, this goal is pursued by presenting the information in so-called "chunks," with each spanning just a few pages. Every chunk attempts to cover only one or a few related ideas, and is designed to build upon earlier chunks. The bulk of the explanation takes the form of code samples, which fortunately are short enough in length and clear enough in composition to be easily digestible. This is in stark contrast to far too many other programming books on the market, whose code samples can span multiple pages, making it difficult for the reader to discern all of the ideas that the author is trying to get across -- especially when the reader has to flip back and forth between pages. Even worse is how some authors (such as Deitel and Deitel) use lengthy code listings -- sometimes even complete applications -- to demonstrate many ideas at once, which can be quite confusing, especially for the newbie reading about a challenging language for the first time. As Holzner notes in his preface, his book is example-oriented, with dozens of tested code samples. But none are overwhelming.
Spring Into PHP 5 was published on 12 April 2005. It is organized into nine chapters, covering a range of topics: PHP essentials; operators and flow control; strings and arrays; functions; PHP in HTML pages; Web forms and input validation; object-oriented programming and file handling; PHP and databases; cookies, user sessions, FTP, e-mail, and hit counters. The book has two appendices. The first one, on PHP language elements, is remarkably complete, considering that it only fills 18 pages. Owners of the book will likely find themselves turning to this material quite frequently. The second appendix lists the most commonly used functions in PHP, particularly those dealing with arrays, strings, and files. These two appendices combined go a long way to making this book more than an approachable primer -- it could serve as a reference book for the language for any reader not required to dig into the more obscure intricacies of PHP. Readers with those needs will have to use more detailed sources, such as the online PHP Manual.
Each one of Holzner's chapters explains the core concepts, using the bite-sized chunks mentioned earlier. This approach is somewhat similar to the "recipes" found in many books published by O'Reilly Media, and it works well here for introducing a computer language. Holzner's writing style is clear yet never condescending, and concise yet never cryptic. The intended reader only really needs an understanding of simple HTML and how to edit text files, to make this book worthwhile and usable. The book is meaty with information, and yet not too lengthy. This is a refreshing change of pace from countless other computer language books that are bloated with redundant sample code and overly wide margins, apparently in an attempt to entice the consumer with maximum page count per dollar.
Some programming books try to move the novice along at too rapid a pace, which can get quite discouraging if and when the reader is unable to follow the discussion, and particularly if trying to follow the author in building a working example. But a far more common mistake among programming books, is to drag out the process with humongous code listings or redundant verbiage (such as following the senseless rule of telling the reader something three times -- a technique that makes far more sense for speechwriting). Holzner sets and maintains an excellent pace, partly by keeping the code snippets reasonably sized, and partly through his modular approach of presenting ideas in chunks.
The physical book itself is well made and attractive, with a readable font face and size, and intelligent use of bolding to highlight those lines of code upon which the reader should focus. My only complaint in terms of the presentation, is that the gray background used for the code samples could be lightened up a bit, to make the text itself stand out more, especially the bold text. All of the screenshots are in black-and-white, which works just fine, as there would be no value in using color in the majority of the sample Web pages.
The author does an excellent job of explaining and illustrating all of the most commonly used and needed elements of the language. But he provides little guidance as to when a particular technique or approach should be used over another. For instance, when explaining how the programmer can use PHP to connect to a MySQL database, the author presents two alternatives -- direct layer and Pear::DB -- but no recommendations as to the choice of one over the other. On the other hand, one might argue that to include recommendations of techniques, as well as language best practices, would require the book to be much longer than it is, which would detract from the book's goal of getting a programmer up to speed on PHP in an efficient manner. The serious programmer who wishes to take PHP to the next level, can be expected to read more advanced books, to learn from expert PHP developers posting in online newsgroups, and to learn from experience as the programmer creates his or her own applications.
Another potential point of criticism could be that the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL (the industry's favorite for use with PHP). But the database chapter, number 8, provides just enough information for the beginner to get started and to try out the basics. For simple database needs, the material in that chapter might be sufficient. Yet for more extensive MySQL usage, including installation and administration, other resources will need to be consulted. This book is clearly not intended to be one of those PHP + MySQL combo books that have proven so popular during the past few years.
The publisher's Web site for the book does not appear to have any collection of errata. Here are some that I found: On page 6, in the NOTE, "scripts can be used" should read "scripts cannot be used." On page 20, "#/ message to the user" should read "# message to the user." On page 49, in Table 2-4, in the last line, the formatting is partly wrong. Examples 3-1 through 4-14 contain incorrect indentation. On page 158, the last line in the $_FILES['userfile'] values is missing $_FILES['userfile']['error']. In Examples 5-19 and 5-20, the <head> and <h1> tags are missing ": Take 1." On page 169, the formatting of Example 6-2 is inconsistent with the others.
Aside from the errata, there were some other weaknesses -- none of them serious: The chapter summaries are useless, like in most other technical books, as there's not enough details to be instructive, and more details would make them even more redundant and space-consuming. On page 176, in Figure 6-6's caption, "Navigating" should be "Redirected." On page 197, the discussion of HTTP authentication is too brief to enable the typical reader to implement it. For instance, there is no mention of where to set $_SERVER[ 'PHP_AUTH_USER' ] to make it work. Chapter 7, on object-oriented programming and file handling, should be split into two chapters. Combining them makes no sense, and the author does not even transition from the first topic to the second.
Like others in the "Spring Into" series, this title is reasonably priced, at only $29.99 list for over 300 pages of quality material. The publisher, Addison-Wesley, has a page on their Web site devoted to the book, which includes a book description, a table of contents, an index, source code from the book, and a link for downloading a sample chapter (in PDF format), namely, Chapter 3, which covers strings and arrays. The site also has a link to a bonus chapter (also in PDF) that explains how to draw graphics interactively on a Web server and then send them back to the browser. Oddly enough, the page's title is "Spring Into PHP 5 - $20.99," but there's no indication as to how to get the book for only $20.99. That could simply be a typo. But there is a link to purchase the book online for $26.99. For those looking to spring into Web server-side development in general, or PHP in particular, it would be money well spent.
Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter for PristinePlanet.com. You can purchase Spring Into PHP 5 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
A professional programmer will never do the stupidity described in first paragraphs when dealing with new language and/or tool to perform task at hand. Although the book might be the best for beginners and advanced users, A PROfessional will not need it at all.
sex is better than war!
Thousands of website admins are stuck with a PHP recursion attack: "PHP = PHP Hypertext Preprocessor = PHP Hypertext Preprocessor = PHP Hypertext Preprocessor = PHP Hypertext Preprocessor"...
So I always try to learn the more complex ideas around the language or bring in ideas from Perl or C to my PHP code to make it look more advanced... so I tend to stay away from "learn ___ quickly" books -- I already know the basics of a lot of different languages and products, I want the more advanced stuff.
Here at work, just about every one of our developers can code in PHP ... Perl is a different story, and I guess that's why I make the big(ger) bucks.
my geeklog
Isn't PHP obsoleted by Ruby On Rails?
Is the book publishing industry becoming irrelevant? By the time the books come out the technology is often on the way down.
I am not sure the addition of more OOP support is going to take PHP into the "less hackish" language camp in my mind. Moving from PHP development to a Java or Python/Zope based model with more emphasis on MVC patterns and Unit testing, is much better than the old hack way of putting all the controler, model and view code on the same page. I guess for a quick and easy solution, PHP got your back, I am not really in love with how it scales up if you want to move into MVC though. Plus the fact that it is a functional language at its core is not too appealing from a OOP perspective. Though, I use it to program my blog, go figure.
It sounds like one of many tutorials that are readily available on the internet. I find it much easier to learn by example, but even those that prefer this method can find a tutorial to suit their needs. Actually coding is the only way to really learn the language and its nuances anyways. It seems like a book would be pointless given the vast amount of information available online, and the speed with which the latest information (as new versions are released) could appear online versus in a book.
This book is clearly not intended to be one of those PHP + MySQL combo books that have proven so popular during the past few years.
So, even though most people use PHP + MySQL and books of the type have been popular this one doesn't do that.
Another potential point of criticism could be that the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL (the industry's favorite for use with PHP).
But yet it does explain MySQL? Which is it? I'm not going to buy the book if the reviewer can't figure it out.
The publisher's Web site for the book does not appear to have any collection of errata.
It has errors that a reviewer found (but can't determine if it supports MySQL or not) and no corrections for them. Chalk another point up.
Aside from the errata, there were some other weaknesses -- none of them serious: The chapter summaries are useless.
I don't like to read through everything (I'm not looking for errors to review about) so I'd like a decent summary.
Combining them makes no sense, and the author does not even transition from the first topic to the second.
Mmm, makes me want to run out and buy the book. Bad writing on top of errors and poor teaching. Sounds like a great way to Spring into PHP 5 doesn't it?
Like others in the "Spring Into" series, this title is reasonably priced, at only $29.99 list for over 300 pages of quality material.
From what I have read here it's not much quality. So which is it? MySQL or not, quality or not?
For those looking to spring into Web server-side development in general, or PHP in particular, it would be money well spent.
I'll stick to learning from sample code. It's cheaper, better written, and probably easier.
In my experience a language becomes useful when you also learn the frequent idioms and know the available toolkits.
professional don't need to learn php because it's asp.net everywhere.
A smarter approach is to learn the language basics in sequence as rapidly as possible, not getting bogged down in excessive sample code.
Excuse me? Maybe I'm an anomoly, but I can't think of a better way to learn a language than by example. This suspiciously sounds like and excuse to cover up the fact that the book doesn't offer adequate material to show how one can code in real-world environments.
When I look for a good programming book, be it an introduction, advanced tutorial or reference, the use of lots of examples is one of the main standards by which I judge the value of the publication.
I hate it if a client is not willing to switch to a sane host and uses the el-cheapo-WalMart-PHP-only-shitshop his 13 year old daughter selected for him.
I'd like to see more comparisons between the two. At this point, it seems to me that if one were just starting out in web programming they might be better off going with Ruby On Rails. I don't see any advantages for PHP now.
something more useful would be a book teaching people effective ways of ripping other peoples source code, i very rarely if ever write original source.
Ruby On Rails, popular as it is with the fanboy set, is not a replacement for every web application framework in existence. Also, PHP is (ostensibly) a language and Ruby On Rails is a framework. Stupid comparison. You might as well ask if Ruby On Rails obsoletes bagel slicers.
PHP was obsolete the day it was born. It wasn't designed, it just happened, and it really shows. I can't fathom why anyone would want to do serious work in it. No, your little weblog package is not serious work.
By the way, you're a little behind on the latest thing to cheer for. I think we're all fapping over Django now, since it's built on what is in my opinion a more sophisticated language.
I haven't read my php4 book yet
From the Incredibly Obvious Dept
Learning a programming language is better than doing it half-assed.
Stay tuned for tomorrow's topic, 'Computers are easier to use if you know how to use them'
I did some memory profiling on some new PHP5 code I'm working on. The test code only defines classes and no object code is actually executed in these tests. All it does is call require(), no business logic is run. This is the average memory consumption of the script for ten runs on PHP 5.0.4 with various optcode accelerators:
No accelerator: 1,746,752 bytes
eAccelerator: 782,576 bytes
APC: 772,200 bytes
Zend Platform: 333,856 bytes
Apparently the opensource accelerators just don't optimize PHP5's new object syntax much, if at all. Without any acceleration, the god damn script without any business logic uses more memory than the interpreter footprint!
For comparison, here are the same stats for phpMyAdmin 2.6.2-pl1 on this system:
No accelerator: 2,079,744 bytes
eAccelerator: 337,392 bytes
APC: 338,416 bytes
Zend Platform: 391,992 bytes
Notice the opensource accelerators come closer to Zend here. I think this is because phpMyAdmin is not written in the new PHP5 object syntax and uses the old syntax instead.
Basically Zend has made it so PHP limps along like a trash can unless you shell out $1500 per server. It would cost us over $15,000 to use Zend Platform, but without it we can't really move off of PHP4.
echo "TD> blah blah blah
echo "TD> and so on
echo "/TR";
echo "/TABLE";
ick.
And I remember somewhere it said PHP stands for "Pretty Home Pages"
wtf indeed.
My turnips listen for the soft cry of your love
If the reviewer is really that confused, it might not be a good idea to take any of the points he makes too seroiusly.
"First, it has no mechanisms to enforce any kind of good web application design practices."
Can you name me a language that DOES have "mechanisms to enforce any kind of good web application design practices"? I'm not sure I can think of anything built into a language (i.e. not just an add-on library which, of course, PHP could provide) that does do this.
"Almost invariably, PHP apps are initially designed by people who are newcomers to programming and the web."
I've seen many state this and have suspected it myself, but have never come across any good statistical proof. Can you post your reference?
"But PHP doesn't provide any structure to help them make the right decisions,"
Can you give an example of this? I'd be interested to see a language feature of [insert other language here] that "helps [newcomers] make the right decision".
"so you end up with no separation between HTML and code, and you end up with an unmaintainable mess."
But what's to stop this from happening in ANY language? And what's to stop it NOT happening in PHP?
"Second, it's not a full-featured object-oriented programming environment like Java."
I'll give the you benefit of the doubt, here, and assume you missed that oh-so-important comma. However, I'd argue that "not object oriented" is not a fundamental flaw of a language. Say we only had OO languages RIGHT NOW. Do you think everything would run quite as smoothly?
"In Java, I can create objects, store them in sessions, hand them to threads, and store them using persistence frameworks. PHP has only the most rudimentary versions of such features."
Good for you. What are the advantages of doing what you're doing that obsolete PHP in every instance?
"Within a Servlet environment I can also create filters, something which doesn't exist in PHP."
Please explain more - I don't know what filters are. I'd be very surprised if PHP could not support whatever-they-are.
"There is hope. There are some tools like Smarty Templates and PEAR which help a little bit. In fact if beginners would force themselves to use Smarty Templates from the beginning they would get much better results."
I'll have to get back to you on Smarty.
"PHP doesn't have strong typing on variables, something which should be a part of any system that needs to be reliable."
WHY? How strong is the typing in the language used to write the OS you're running right now?
"There's no complition of PHP systems, which means that the only bugs are run-time bugs."
Why is a smaller number of classes of bugs inherently a bad thing? Or is that just an objective statement?
"PHP just isn't a good choice."
For what? Why? I'm still not sure I quite understand.
....php was, for me, the easiest language to pick up. There's a plethora of built in functions to help you do just about anything and the syntax is like a hodgepodge of other languages best points put together. Maybe not everyone feels this way, but it's definatley in my top 5 favorite languages to write in. The only book(s) i think any programmer needs to pick up PHP are the visual quickstart guides from peachpit press. (shameless plug i'm afraid, but i love their stuff.)
I'm about to migrate a site I administer, OmniNerd, to PHP5 from PHP4. Any areas of focus from those of you who have already done it? I do a lot of XSLT translations and I've noticed that I'm going to have to recode of xslt_process() calls. Any other major changes I should be looking for?
Mark A. McBride -- OmniNerd.com
It's fine with me if that eventually is RoR, but considering the much vaster PHP user base, wouldn't P5 be a better starting point?
My turnips listen for the soft cry of your love
PHP book reviews! Considering that there seems to be about 1-2 week, it would be a pretty good size topic.
I don't respond to AC's.
There was some discussion here at Slashdot a few days ago in another topic regarding the effect PHP is having on the reputation of Linux. Considering that it is often grouped with Linux in the LAMP model, and is also one of the more well-known open source projects, there has become a close assocation between the two in the eyes of the general public.
Now it's no secret that PHP has suffered from some pretty serious security issues as of late, such as the XML-RPC flaw. Then there are the routine problems of poorly developed blog and CMS systems being defaced. Many of these problems are attributed to inexperienced users writing what amounts to completely horrible code.
While the developers of PHP itself are very talented and quite respected, the users of PHP are starting to cause problems for the Linux community as a whole. Each time a site is defaced due to some poorly written PHP script, it is often portrayed as a vulnerability with Linux itself. Of course that is more often than not a complete falsity, as the fault does not lie in any way with the Linux kernel or its developers.
So while Linux advocates often promote the use of PHP for developing webapps on Linux, PHP is starting to become more of a liability. Every site running Linux and PHP that gets defaced due to terribly written PHP scripts reflects very poorly on Linux's public image. Now I have to ask: what is the Linux community willing to do about this problem?
Would they even be willing to go so far as to demand that the PHP developers include functionality to severely limit the ability of faulty scripts to run? It's quite difficult to say at this point. But if changes aren't made fairly soon, then things could degrade very quickly.
Cyric Zndovzny at your service.
I am not knocking this book by any means. It is probably very good. But can't any developer who knows a C-ish syntax language pick up PHP basics quickly? I learned it in a day or two just by analogy with C/Perl/etc. How much need/demand is there for entry level books like this?
Where computer books have value to me is when they teach me something that would take hours/days/weeks to learn by trial-and-error. Something non-trivial that can't be guessed from reading the doc. (Like setting up user authentication or something.) That's when I start thinking about spending cash on books which have value by saving me time and especially frustration. (The PHP Cookbook, for example.)
> PHP doesn't provide any structure to help them make the right decisions
I agree I haven't found the equivilent of Lint for PHP, that would solve all your complaints about PHP as a lanuage.
the language a person uses will not make a good programmer bad. And no amount of structured language will make a bad programmer write good programs.
I haven't found a single language, especially not java that does what you claim, their are many many tools for java, and C/C++, etc that do that. And even some of that functionality exists in the popular compilers.
Reviewer: "Another potential point of criticism could be that the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL (the industry's favorite for use with PHP)."
Parent post: "But yet it does explain MySQL? Which is it? I'm not going to buy the book if the reviewer can't figure it out."
The reviewer is saying the book explains how to use PHP with the database program MySQL, but not with other database programs such as Lotus Notes or Oracle.
If the reviewer is really that confused, it might not be a good idea to take any of the points he makes too seroiusly.
Are you inferring that the reviewer thought the book was a joke and that I should assume that from what he wrote?
I took a look at the header above his confused review and saw that he rated it an 8 (I assume out of 10). If you are really inferring that I shouldn't take his review "seriously" and that I should instead assume he was joking around about the book perhaps he should have rated it differently?
author: Steven Holzner
pages: 340
publisher: Addison-Wesley
rating: 8
reviewer: Michael J. Ross
ISBN: 0131498622
summary: A comprehensive and no-nonsense primer on the basics of PHP
If I misinterpreted your statement perhaps I shouldn't pay any attention at all to reviews?
Read the first line of my post:
This book is clearly not intended to be one of those PHP + MySQL combo books that have proven so popular during the past few years.
So, if it's not meant to be a PHP + MySQL book and it's not showing the other options what exactly is the book doing? The reviewer doesn't know.
Thanks for proving my point.
If your existing PHP4 setup is working fine, or at least acceptably, you may not want to transition to PHP5. It has been suggested that PHP 5.0.4 suffers from very poor memory usage.
c id=13297391
http://books.slashdot.org/comments.pl?sid=158685&
So at this point, it just doesn't sound like a transition may be a very good idea for a site that is already functional and running well.
Cyric Zndovzny at your service.
Without any evidence at all.
A smarter approach is to learn the language basics in sequence as rapidly as possible, not getting bogged down in excessive sample code.
Define "excessive". And why is that way smarter?
Learning by example is a pretty common pedagogic approach after all.
The whole "lambda" function concept is dumb how exactly? If you mean python having neutered lambdas instead of real ones, sure that's dumb. But the concept of lambdas isn't dumb at all.
Wait, there is still a programmer that doesn't know PHP?
color me stunned!
-mix
But yet it does explain MySQL? Which is it? I'm not going to buy the book if the reviewer can't figure it out.
In other words, the book isn't centered around building DB-driven apps using PHP+MySQL, even if it does discuss the topic. The reviewer wishes it also had chapters on PHP+PostgreSQL or PHP+Oracle, but it doesn't. Seems pretty reasonable and consistent to me.
Dewey, what part of this looks like authorities should be involved?
A professional programmer could at any time be tasked
tasked
Must be an MBA.
Overall, this is a pretty good idea for a book, but the editors/author should not have rushed it to press - the quality of the book appears to have suffered.
I would strongly encourage a potential buyer of this book to spend several minutes with the book and see if the style suits your manner of learnig. Personally, I prefer the O'Reilly Learning series approach to teaching a topic, but preferences vary.
Ken
...for about five seconds.
Seriously, if that's the extent of your case against Python, well...you make it clear that you've never actually written anything in Python and are therefore unable to have a valuable opinion of it.
If you're using an editor that doesn't understand tabs or one that can't convert tabs to spaces, well, you should seriously consider getting a new editor.
there's more than one way to do me.
The only book anyone should be using for learning PHP is the PHP manual. We write it for a reason. The manual is the only resource I know of which is almost always up to date, maintained, and largely error free (We have errors, but as soon as they're reported they are fixed, usually within hours of the report being filed. Most of these types of errors involve spelling or gramatical mistakes.). Books released on the subject all do the same thing: re-write what the manual has already adequately stated while throwing in errors left and right.
Arguably, there are a few books written which at first seem to be written well. Hell, who isn't tempted to pick up a book now and again which has names such as "Rasmus" and "Andi" etc stamped across the front in large gaping print. But these books are just as useless as those written by lesser-known authors, and shouldn't be used because of the same failings of other books: They're error-prone, and almost immediately deprecated. PHP changes rapidly, very rapidly. Possibly too rapidly for its own good, but that's another discussion entirely. Point being that you can't commit changes to the cvs repository of a book as you can to the PHP manual, and as such any printed book will fall far short of being as up to date as the PHP manual.
If you need a resource to "teach you PHP quickly" there is generally only one chapter you need to read in its entirety, and that is php.net/langref. Anyone willing to take the time to do that can pick up the (extremely easy and basic) syntax of PHP within 2 to 4 hours. From there all one need do is hit the extension documentation pages of any API they may wish to use, such as php.net/mysql, php.net/pcre, etc.
I can help you change tired moments into pleasure, say the word and we'll be well upon our way...
you don't understand 'cause you're a fewl
I realize that alot of Programmers like Java because it has alot of features, but as a user, I have yet to come across a Java website I did not hate. The minute it starts trying to force a loading of a runtime environment or jar files and screws up the back button or other standard controls I want to leave.
Not trying to hate on Java, but please give an example of a Java coded website that has a pleasant user experience or list the object oriented web programming languague you really intended.
While I agree that PHP isn't all that great I think you have the reasons wrong.
OO isn't a silver bullet. You almost always trade performance for development time and maintainability when you use it. That's not a bad thing and PHP minimizes the performance hit well enough to make it useful. In PHP its nice when the developer sticks to one or the other, though its obvious that most people don't because PHP is easy and the people writing it tend to be new to programming.
Strong typing isn't a silver bullet either, and I don't see how it makes your code more reliable. PHP tends to die when you perform numeric calculations on a string or vice-versa so problems can be fixed before going to production. I'd prefer it handle more like Perl where usually it does the "right thing" (it doesn't die at the very least).
Here's my problem list that I hoped would be fixed or at least improved in 5. (no such luck it seems)
Error handling is one of my biggest beefs with PHP. There are simply too many options and none of them are sane. Why can't we have a class as an error handler? Why is it that the error messages are spewed the screen as HTML by default? Why doesn't the command line mode revert to text only error messages? Why doesn't PHP just use the server error log like other languages and give you options to change it if you need to? That's what its there for!
References: Worse than PHP 4's objects are its references. Why can't I have references to objects or code? Why can't I pass a reference to any user defined or built-in function? (it used to work for user defined functions then they depricated it)? Seriously why does the function care if it has a reference or a value? To be fair I've heard some of these things have been fixed in 5 but I've still not found definitively if you can have code or object references.
Scoping: I suspect part of the problem with references are due to limitations in scoping. On the surface, having all locally scoped variables and specifying when you want to use a global one makes sense and keeps new programmers out of trouble. The problem is it leads to undefined variables everywhere when the programming forgets to use 'global $foo' in a function. This is also a problem that can be hard to spot initially because PHP doesn't bother to warn you if you've done that. The 'global' keyword also looks like a declaration so when I was first learning the language it was extremely confusing. PHP would be much more tolerable if they adopted something similar to Perl's strict mode where you declare your variable in the global, package, or local scope and it dies when you have variables that are undefined. This method is much better than having silently undefined variables.
Namespace polution: Why are there 14 billion functions I'll never use all in the same scope? Its silly. C came up with the idea of including what you need 35 years ago! Why are we regressing? Even if you don't like having separate namespaces, at the very least functions that go together could all be in a common file to be included and then you only import functions you need. And no OO won't solve this problem because all the core functions are still imported in, even in PHP 5.
Compiled modules: Why do I have to recompile PHP if I want to add image functions or some other module written in C?
HTML Centric: PHP centers around HTML (see my beef about the error messages above) This is a real annoyance if you want to output other things. Also the default embedding in presentation is irritating too. It was a bad idea with ASP, it was a bad idea with ColdFusion and its still a bad idea now and while the developers keep saying "you no longer have to embed it", so what? Make it where it can't be embeded. (yeah yeah, backward compatability and all that) Sure you can cause other languages to print out HTML using print statements, but its not the same. PHP is designed around embedding it within HTML. Print statements make obvious the need for templates. PHP makes a mess without making it obvious un
The Anti-Blog
In your extensive research, eh?
.. SNIP ..
brian@vicky> php -h
-l Syntax check only (lint)
No SIG for you!
I'm a huge PHP fan.
But even I'm getting sick of these PHP reviews.
I like the idea of the Visual QuickStart Guides - I've flipped through (and bought but not yet read) the one for Python, but the one for PHP doesn't cover PHP5-specific stuff, despite the cover blurb, according to some people who've read it. Hopefully an updated version is forthcoming.
I recently got, and am slowly going through, "Beginning PHP 5 and MySQL: From Novice to Professional," and it's okay, but no more than that. A strange ordering of what's taught when, but it's working thus far. I hope it works for me, as I'm taking over a PHP/MySQL project at work the week after next. Eek!
And of course, I just found out that an updated version is due out at the end of October. Figures.
I realize that alot of Programmers like Java because it has alot of features, but as a user, I have yet to come across a Java website I did not hate.
How do you know you are using a Java website?
The minute it starts trying to force a loading of a runtime environment or jar files and screws up the back button or other standard controls I want to leave.
The runtime environment and jar files are only loaded once - when the application server starts. From then on, these do not occur, so have no impact on anything.
The use of controls is highly specific to the way an individual developer has coded their website and used a web framework. It has nothing whatsoever to do with Java.
There is a difference between server-side Java where all you see is the HTML output and browser-side Java where you see the problems you mention.
"In Java, I can create objects, store them in sessions, hand them to threads, and store them using persistence frameworks. PHP has only the most rudimentary versions of such features."
Good for you. What are the advantages of doing what you're doing that obsolete PHP in every instance?
Scalability. The ability to share objects and information between threads, so that they can be used throughout an application and not just within a request or session is vital for large high-performance websites. It is simply not practical to drop through to the database to reload information each time when you have hundreds or thousands of simultaneous users.
"so you end up with no separation between HTML and code, and you end up with an unmaintainable mess."But what's to stop this from happening in ANY language? And what's to stop it NOT happening in PHP?
In Java, for example, there are web development frameworks such as Tapestry, Struts and JSF, that have cleanly separated presentation and code layers. As for stopping it in PHP - that is tricky, as PHP was designed for HTML + code mixing.
Please explain more - I don't know what filters are. I'd be very surprised if PHP could not support whatever-they-are.
Filters allow specific ranges of URLs to have additional functionality wrapped around the requests. This is a highly useful feature, allowing things like post-processing of HTML, or checking authorisation (and diverting to error pages).
There may be add-ins for this, but as far as I know, it is not standard for PHP, as it is in Java.
He was talking about applets, which suck except for special purposes. In those cases, only Java will do.
The global economy is a great thing until you feel it locally.
He was talking about applets, which suck except for special purposes. In those cases, only Java will do.
No - it is nothing to do with applets. He was talking about the frameworks available in Java to render HTML and handle web forms.
None of these things are the same at all.
Beginners tend to use global variables and long, imperative structures for pretty much everything no matter what language they're using.
They also tend to use the same control structures for everything until they start understanding other ones. And forget about OOP or functions. These things are advanced.
What they end up with is something that's supremely simple, but very, very dirty. The code doesn't scale at all. It almost has to be completely rewritten by hand even if they comment their work.
So simple can be bad. So what about advanced things? One primary thing that people do that's advanced is add syntactic sugar to make it easier for them to follow. An example of this is using Templates in C++, or "autoload" in perl. You really have to understand the inner workings of your language to do these things, but if you know them it eliminates code that doesn't contain anything meaningful (thus making it the code less complex to follow).
The list doesn't end there. What framework do you choose to do your design in? Using a suitable framework may be more complex for small projects, but considerably less complex for giant ones. Frameworks are usually very advanced topics, because they don't usually carry over between languages at all.
I'd like to think that I write less complex, cleaner, more advanced code than most PHP writers.
Mod me down and I will become more powerful than you can possibly imagine!
Actually, you are right! Ignore my previous post. The 'back button' issue confused me.
...copy and paste code that looks applicable to the task at hand, and then lose valuable time trying to make it all work and control what was created ...
This is what I call "Cargo cult programming" -- when you copy something that worked somewhere else, make what look to be the appropriate changes, and hope.
Although not admirable, I have done this a number of times. (JCL! Argh!) Sometimes you just need to make a minor change to a program in a language you don't know.
The Jargon file has a slightly different definition of cargo cult programming.'
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
Pedantry is annoying. Misguided pedantry is a hundred times worse.
"The book is clearly not intended to be one of those PHP + MySQL combo books" : The book does not have a heavy focus on MySQL.
"For simple database needs, the material in that chapter might be sufficient. Yet for more extensive MySQL usage, including installation and administration, other resources will need to be consulted." : The book covers MySQL, but not in too much depth.
"...the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL..." : The book does not cover databases other than MySQL.
While the reviewer might be faulted for his writing style, you can't get an actual contradiction out of his statements unless you grossly misinterpret him.
Finally, there's the whole matter of you judging the quality of a book on the basis of the presentation of the reviewer. If you find the reviewer so confusing and incoherent, shouldn't that just mean that you don't allow the review to inform your opinion?
You want the truthiness? You can't handle the truthiness!
The reason why PHP is *not* a disaster are:
1. It has mechanisms to allow you to program extremely tight web apps in one of several frameworks and programming models. This includes very Java-like MVC if you want or the very awesome Prado.
2. PHP does not tie you down to an OO paradigm, but lets programmers choose to implement an app using structured code, OO code or a hybrid of the two. This lets programmers code the way they feel comfortable.
By the way, PEAR is not a strong point for PHP. It's a useful programming library for beginners, but advanced programmers use it very sparingly since it's not laid out well, not documented well and in many cases does not perform well (especially the database classes). There are very well-written task-specific libraries such as Adodb that do a far better job and are becoming the defacto standard for PHP programmers.
Java filters are little more than a trick which Java (and other languages) programmers have been doing for ages. All they do is make programming a bit easier, which is great, but considering how much quicker PHP programming already is than Java programming, you can understand why Sun keeps trying to find ways to do all the hard work for Java programmers... they have to compete with better RAD languages.
PHP5's (and 4's) objects are certainly not as true OO as Java's, but that mostly stems from the fact that PHP isn't trying to be another Java. C++ isn't as OO as Java either, but it's still a useful language. PHP's objects are there to modularize and reuse code. They help improve the overall application design and move the business code away from the flow control code. The rest of PHP's design allows for its objects to not support everything that Java does. Sure, there are times this is a shortcoming, but its one of PHP's quirks that PHP programmers design their apps around. All languages are like that... it's very difficult to design and pseudocode a program without knowing which language it will be written in. That's like designing a database without knowing if it will be for Oracle, DB2 or MySQL... sure it can be done, but by not tailoring to the platform you can't workaround a platform's weaknesses or design for its strengths.
PHP is a great choice as a high-performance and flexible language. As one of the very few languages designed specifically with web apps as its primary goal, PHP is tailored to do exactly what web programmers need. Most of the limitations in the language are at the crossover point between traditional client apps and web apps and nearly all have simple workarounds, such as serializing an object when storing it in the session.
The global economy is a great thing until you feel it locally.
Thank goodness there are languages like, well, anything else that have a cleaner more consistent design.
."\n";
This just tripped me up the other day. I thought to myself "cool, now I can use the regular $obj->foo notation but have it call a method underneath. Just like Ruby. That will make refactoring a breeze" Boy was I wrong. Try this out:
class Crap {
private $attributes = array('crud' => array(1,2,3));
function __get($name) {
return $this->attributes[$name];
}
}
$c = new Crap;
foreach ($c->crud as $x)
print $x
Why does PHP make things look like they might work, but then they don't?
I'm also trying to figure out the purposes of "toString()", or why there's no "finally" for exception handlers, or why built-in functions don't throw exceptions.. what's the point of having them??
Yeah, newbies don't care, but you know, sometimes newbies actually get better sometimes and want to do more things?
I'm sticking with Ruby for now, thanks.
PHP ruins people who might have been somewhat decent coders, if they'd just started out in an environment that enforced some structure and best practices. PHP's biggest failing? It has no framework. It's just glue.
"It is simply not practical to drop through to the database to reload information each time when you have hundreds or thousands of simultaneous users."
...
... ?> at all.
It is. I've worked on a site (NB: NOT my URL!) that handles greater traffic than that, with a large number of DB requests on a large proportion of pages. NOT written in PHP. But not even running on a box of its own
"As for stopping it in PHP - that is tricky, as PHP was designed for HTML + code mixing."
If you want a dynamic web site, you have to mix HTML with something at some point. It may be characters in a file, string delimiters, php delimiters, whatever. I don't see anything in the PHP language itself any different from any other language in this regard. HTML is just a bunch of strings; PHP can be written with nothing outside of the <?php
"Filters allow specific ranges of URLs to have additional functionality wrapped around the requests. This is a highly useful feature, allowing things like post-processing of HTML, or checking authorisation (and diverting to error pages)."
Forgive me if this sounds flippant, but isn't that something than can be achieved with an array, a regexp or two, and REQUEST_URI? Is this something actually within the language itself?
It's Perl, not PERL. Unless you're running it on a MAC, I guess.
PHP is so easy because it's made for stupid people.
>php -l
call that lint if you want, that is just a syntax check.
5.0 is a small step ahead. 6.0 will be a new level for PHP.
In 5.0 only part of intended features implemented, and many of new stuff implemented half-way. Like for example, idiotism of exceptions being thrown in user code but not from standart PHP functions!
PHP 5.1 (due out this year) seem like a wasted time so far. Zend spent all time implementing useless "Data objects" instead of working further on new OO features.
"Data objects" itself is just a database access classes that are already available in numerous PHP class libraries. They just re-implemented it as PHP module.
One of most requested features, namespaces support was dropped in 5.0 because it was "too complex to implement". It may appear in 5.1 but more prabably in 6.0.
6.0 may also have strong typing anong other long-awaited features.
Hopefully 6.0 will be that "golden" version where it will please Java-minded developers and be compatible with un-responsible rapid development style.
Who modded this insightful?
Those worried about toolkits don't want to learn the language, they just want to use toolkits to make it appear that they know the language.
Look, dude, in my experience, a language becomes useful when you learn enough to do something useful. Not before.
So what you are telling me is, it's ok to hit the server for a piece of data that isn't changing soon or is complex to get? Lemme guess, calculate and store it in another table? Ugh. Amature.
A good template language limits the logic you can put in. It limits it by not giving you the functionality, or makes it hard to. That's why scriptlets in jsp are so disdained. If I can do on a whim, that's horrible. It's the reason why velocity, freemarker and others are prefered. But keep deluding yoursel fthat everyone has good enough expierience and diligence NOT to put complexity in your templates.. i'm sorry "php programs".
Quick, you have 500 templates that need a new filter. Sorry, "php scripts". I have 500 servlets that need a new filter. I'll finish way before you.
So you're saying that professionals use *gasp* ASP???
"It is simply not practical to drop through to the database to reload information each time when you have hundreds or thousands of simultaneous users."
..
... ? at all.
It is. I've worked on a site (NB: NOT my URL!) that handles greater traffic than that, with a large number of DB requests on a large proportion of pages. NOT written in PHP. But not even running on a box of its own
It is not practical for anything but the simplest and smallest of data items. If it were, sites like E-Bay and high-volume stock markets would work like this. They don't.
If you want a dynamic web site, you have to mix HTML with something at some point. It may be characters in a file, string delimiters, php delimiters, whatever.
Yes, but what you don't want to mix is logic. Someone should not have to look through lines of HTML to see how you are doing a price calculation!
Generally, web frameworks have specialised tags that are included in the middle of HTML to indicate where the results of processing are to be included.
I don't see anything in the PHP language itself any different from any other language in this regard. HTML is just a bunch of strings; PHP can be written with nothing outside of the ?php
You can, but the mere fact you have those enclosing symbols indicates that the language was designed to allow embedding in HTML, and not to discourage it.
"Filters allow specific ranges of URLs to have additional functionality wrapped around the requests. This is a highly useful feature, allowing things like post-processing of HTML, or checking authorisation (and diverting to error pages)."
Forgive me if this sounds flippant, but isn't that something than can be achieved with an array, a regexp or two, and REQUEST_URI?
It can, but why bother re-implementing this each time? Filter APIs allow Filter classes to be written in just a few lines of code.
Is this something actually within the language itself?
No. It is a standard part of the JSP/Servlet API, which is a subset of J2EE.
Idioms? Don't you mean memes?
(I'm making fun of the over-use of the word 'meme' round these parts, for those that are wondering what I am saying here.)
that code doesn't work because it's written incorrectly.
Learn the language 1st, then bitch about it later! =p
the only permanence in existence, is the impermanence of existence.
OH! You want to replace developers with a floppy disc. Good luck!
/some non-php language/, and it was so much easier to (debug|write)!"
I was addressing 'not being able to see compile errors in anything but a web page'...
What amazes me about this whole discussion is how nearly everyones complaints about PHP contain serious errors, and are totally unresearched. I can only assume this is largely based upon what other people told them, rather than actual experience.
I never have heard anyone, respectable or otherwise, proclaim "We took x application, and re-wrote it in
No SIG for you!
I don't usually post to defend those I am debating against, however...
Gonzo is back again. Sweet jebus you are dense.
This is totally unfair. The poster is asking questions I would expect from someone experienced with the PHP way of working. They are intelligent questions.
So what you are telling me is, it's ok to hit the server for a piece of data that isn't changing soon or is complex to get? Lemme guess, calculate and store it in another table? Ugh. Amature.
It is not that simple. Fetching data for each request or each session can be useful in some ways. It allows all all the data relating to an application to be changed without having to restart an application - effectively shutting down the web application. Changing application-scope data in Java is possible, but it requires careful and thread management.
"It is. I've worked on a site (NB: NOT my URL!) that handles greater traffic than that, with a large number of DB requests on a large proportion of pages. NOT written in PHP. But not even running on a box of its own ..."
The major bottleneck for most websites is the database. Pick up, well, pretty much ANY book about writing dynamic web sites, be it in PHP, Ruby, Java or whatever, and you'll likely find major sections dedicated to optimizing your db access code. Any help the language or framework can provide in this area directly leads to a faster, more scalable website.
Java has tonnes to offer here, nearly to the point of being ridiculous. With Hibernate (a popular Java data access framework), I don't have to write ANY data access code at all. All I have to do is provide a little extra meta information in my classes so it understands my relationships, give it a config file so it knows how to connect, and it takes care of almost all of the rest. It will even generate the database for you, if you want it to. For most tasks, it will do exactly the right thing without any extra work, yet still provides many ways to tweak the trouble areas.
PHP also makes it incredibly tempting to do the wrong thing. If I want to put a SQL query right in with my HTML template, it won't do anything at all to encourage me to do otherwise. In fact, in PHP this is the easiest place to put it... I suspect that many PHP programmers don't even realize that this is generally a very bad practice. Part of PHP's charm is that you don't have to learn complicated frameworks or patterns, which is just great for someone who wants to get off and running right away. However, without some sort of structure things can become an unmaintainable nightmare in no time at all.
"If you want a dynamic web site, you have to mix HTML with something at some point. It may be characters in a file, string delimiters, php delimiters, whatever. I don't see anything in the PHP language itself any different from any other language in this regard. HTML is just a bunch of strings; PHP can be written with nothing outside of the at all."
Logic and presentation should be separated. It makes updating both easier, and it helps remove unnecessary dependencies between the two. The easiest thing to do in PHP however is to just stick them all in the same file. Contrast this to a Java framework like Tapestry, who's html component is simply a plain jane html file, with a single extra attribute added to the tags that Tapestry is interested in. This can be previewed in a standard web browser.. the entire look and feel of the site can be changed by someone who doesn't even know what Tapestry is. And, when I decide I want to switch from HTML to WML, or to a desktop application, all of my logic is cleanly separated, ready to be reused however I like.
It is of course possible to do this in PHP using Smarty templates or something similar, but the easiest approach is to just not think about it. For simple applications, this may never turn into a problem, but for anything moderately complicated the lack of separation can turn into a real issue.
Don't get me wrong.. I think PHP is great. It was the first web programming framework I really fell in love with, and I've seen some amazing things done with it. It's incredibly easy to pick up, and it will scale just about as far as you want to go with it.
However, writing sophisticated PHP applications requires just as much discipline as writing sophisticated Java applications, and I just find Java gives you so much more. Take a good java programmer, give them best of breed open source tools like Hibernate, Tapestry and Spring or Hivemind, and they're going to code circles around just about anyone else. Using these tools you can prototype an application incredibly quickly (faster in my experience than PHP, Perl, or anything else except for Rails), then evolve that application one piece at a time into a full, production ready enterprise app.
Of course, n
That said, Ruby on Rails is amazing. If java isn't your bag, check it out. It has most of the best features of Java and PHP, almost none of the warts, and a whole bunch of great stuff you won't find anywhere else.
After all your praising of Hibernate, how can you recommend this? Hibernate is an elegant and robust ORM that isolates your code from database specifics and allows you to write highly portable applications. Ruby on Rails requires exactly the kind of embedded SQL you don't like if you are to do anything complex, and makes your application extremely dependent on the database schema and the specific column names contained within it, and has serious barriers to portability.
I agree strongly with almost every aspect of your post, but certainly not this last part!
The only thing worse than 'meme' is 'memetics'. Which in the real world outside the blogosphere-wankery is called, you know, anthropology. *sigh*
LOAD "SIG",8,1
the frequent idioms and know the available toolkits
What are you talking about?
Whereas if you take a look at any but the best-disciplined PHP project, there's not a file anywhere that doesn't have some HTML and some PHP.
Those who have experience in real web application design know what I'm talking about and understand the importance of this discipline. Guess what, people with that level of understanding probably also know how to use Java and know enough to appreciate it.
For the others who don't know this, you will keep on creating PHP apps. If your business does well, the demands on those apps will keep on growing, the apps will get more tangled as the less-clueful PHP developers expand them, and eventually you'll end up with a big mess and you'll need to spend some big bucks on someone like me to sort out the mess.
If a web-based business is really smart they'll spend some not-so-big bucks on someone like me early on to get their project onto the right foundation and then they won't need a major rescue effort a year or two later.
That's what I'm saying. Of course PHP isn't Linux. But most people, including the managers who are the ones making the final decisions regarding the use of Linux in enterprise or business settings, don't know that. They've come to think of the flaws in PHP scripts as being flaws in Linux.
This is both a social and a technical problem. You have to fix PHP so it is difficult, if not almost completely impossible, for amateurs to write scripts that can be exploited. Likewise, PHP and Linux shouldn't be linked as often by Linux advocates. The only way to fix this is to deal with all aspects of the problem.
Cyric Zndovzny at your service.
I'm still looking for a book that covers PHP 5's OO programming, including the Standard PHP Library (SPL), Pear classes (there are a million of them now), Smarty templates and more. I'd especially like a book covering the 100's of PEAR classes since 95% of them are not documented.
Rails lets you alias column names to provide some level of abstraction away from the database. Many people don't do this, as it's easier just to go with what's in the db, but renaming a column would only require one line of code to be added to object. It's also possible to perform some types of queries without any sql. Hibernate it's not, but I'd say that the average Rails app is more adaptable to db changes than the average JDBC application, which still isn't too bad.
PHP5 is a memory hog. I realized this after writing a sizeable application in PHP5's new object syntax for our 7-server cluster. Everyone is so busy comparing PHP4 to PHP5 by benchmarking a script that prints "hello world" 5000 times, nobody has noticed the memory usage.
PHP5 DOES runs great if you run it through Zend Platform (an opcode accelerator), which costs $1500 a year per dual-CPU server. There are free alternatives to this (eAccelerator and APC), but none of them optimize the new PHP5 class syntax like Zend, and talk of instability is common. Do some simple memory benchmarks and you will see (just load your classes, you dont even run any code it to see it guzzle memory!!).
For us to run PHP5, it would cost over $15,000 per year, which is more than our servers are worth!
I feel held at ransom by Zend. Small shops like us are left out in the cold. We are abandoning it and switching to mod_perl and Catalyst on CentOS4.
PHP does not feel "free" the way Perl or Apache are. I guess it is Zend's language after all.
Time to fork PHP into the bloated Java-chasing PHP5, and the nimble PHP 4.
:-)
Call the 5 fork PHOOP
Table-ized A.I.
correction: should be "so be it". See what monitors do to proof-reading ability :-)
Table-ized A.I.
Hibernate it's not, but I'd say that the average Rails app is more adaptable to db changes than the average JDBC application, which still isn't too bad.
I have to disagree. The average JDBC application explicitly extracts information for all columns, and the relationship between columns and Java variables can be tested either by compilation or by unit tests.
Hibernate it's not, but I'd say that the average Rails app is more adaptable to db changes than the average JDBC application, which still isn't too bad.
It is very bad! The point of systems like Hibernate and JDO and EJB3 is to progress away from database dependence. Rails encourages dependence on database schemas. This is something many of us have been trying to move away from for years.
Rails is a huge step back to the way things were a decade ago.
I was more interested in the rumors of PHP6 running on top of parrot. Many (most?) of the PHP developers are employed at Zend, so I don't see why they would do this. Of course, anyone could make a PHP-like language, but I believe their license prevents you from naming it something similar to PHP. ... we all know the language needs alot of work anyways. :)
> A professional programmer could at any time be tasked with developing a nontrivial application using a language or Web technology with which he or she is unfamiliar.
And an asteroid could at any time fall over your head. Seriusly, I have been presented with the task of develoing a nontrivial web application, and, after evaluating my options, I went with the language I was more comfortable with: C++ (the CGI protocol is *not* that complex).
I have never had such draconian requirements as to be forced to develop a new and complex application in a language I have zero experience with. I'm sorry, but I can't think of a reason for this to be, other that your boss/client beeing stupid, of course.
Anybody who doubts the power of how far PHP has come should have a look at the PRADO Framework. It's the fastest RAD framework I have ever used for PHP, with clean and clear separation of HTML Templates, Database Access and Modules
HTML Output in the CLI? Nope:Don't use the CGI if you really want the CLI SAPI.
Can't use strings in numeric operations? Or even dying? Nope:Everything is converted. A string to integer conversion takes the leading digits and makes that an int.
HTML Centric? Actually it's XML centric. are PIs.
Need to reference a function? Put the name a string in a variable:Modules have to be recompiled? Nope. Make a DLL or SO and load it via php.ini. That's where phpize is used.
You have a long way to learn PHP
b4n
> OH! You want to replace developers with a floppy disc. Good luck!
no, just to separate my 4am code, before the caffeine kicked in, from my in the zone code.
$ man php
No manual entry for php
Oh you meant read the online wiki. Where do I quickly and easily find those command line options?
As for dying because of problems with types. There are problems with some built in functions that don't properly convert. Try pulling numbers out of a regex match and then plugging them into checkdate(). It treats them as strings and returns false (PHP 4). Hopefully this is just a bug and will be eventually resolved.
As for references, no I didn't know you could do that. I knew you could pass a string of a function name to several built-ins so I assume this is the same mechanism. Still its stupid syntax, what's wrong with $x = &foo();?
The Anti-Blog
The PHP manual, which is a docbook - so you could call it anti-wiki ;), has a chapter about the CLI stuff: http://php.net/manual/en/features.commandline.php - or you should install the man page on Mac OS X I have one. Or you could just call php with -h - -v gives you BTW the version and tells you which SAPI it's been compiled with (cli, cgi, fcgi).
;) This stuff has been solved in PHP5.
p #language.types.callback for information about callbacks (that's how it's called in PHP).
The syntax $x = &foo(); would call a normal function called foo and assign a reference to the return value $x. That's already a valid syntax, thus it can't be used for a new feature. And it's the way you handle returned objects in PHP4. As Marcus Börger said: "If your OO code doesn't work , throws some amps around. If it still doesn't work user more"
The variable function call syntax has an other advantage - it can also be used for method calls. See http://php.net/manual/en/language.pseudo-types.ph
If you've more questions about PHP don't hesitate to ask =)
b4n
> $ man php
> No manual entry for php
> Oh you meant read the online wiki.
> Where do I quickly and easily find those command line options?
Funny, when I type "man php" I get this:
PHP(1) Scripting Language PHP(1)
NAME
php PHP Command Line Interface 'CLI'
SYNOPSIS
php [options] [-f] file [[--] args...]
etc.
I'm using a Mac, what are you using?
Amateurish. It doesn't even have input validation.
There are a bazillion frameworks for object-caching that don't require careful thread management. PHP doesn't even give you the opportunity.
I was going to convert our website from Windows IIS ASP to Linux/Apache/PHP. I had read all the hype and thought it would be a good move.
Oh boy it wasn't. I joined a list on php.net to help me figure out how to install. Almost all of the messages were about people asking to be removed from the list. Then I posted a question and was told I had to visit three different website in order to be able to submit it. After the third one the message was still not posted and my spam folder was growing fast even for gmail. I attempted to unsub using the directions at the bottom of some posts. It didn't work. So I contacted the list admin. After a few emails, he became belligerent and eventually claimed he had nothing to do with the list! I then went to php.net, but I read the fine print, that anything I sent to their address would be reposted on usenet for spammers to harvest my address.
So now my address is trapped on the spam list and my new gmail account is now full of spam (even with gmails filtering). I report each and every message now as spam. All I can say is that I'm lucky I didn't convert our production server yet, no telling what could be written in the PHP code. I have wiped the harddrive of the test box and reinstalled Windows IIS ASP. It is just amazing this spam harvesting scheme has come this far. Avoid the PHP spammers! Just say no to PHP.
There are a bazillion frameworks for object-caching that don't require careful thread management. PHP doesn't even give you the opportunity.
True, but you don't persuade developers to switch by insulting them.... (as the grandparent post did)