I think I can safely say that none of the real problems I face have much to do with the fact that I need to do casts, or the fact that I can't express something with less typing or whatever. In fact, none of the problems I face have much at all to do with the language I'm using. No, the problems I have now are the same problems I had 15 years ago. Reducing complexity, increasing robustness, enhancing expressiveness. Stuff like that. I suppose it's possible I'm missing something, but I don't see any language that helps me with those things at the fundamental level I'm looking for.

Developers need to remember that programming is the easy part. The hard parts are getting the user-requirements in the face of users who have only a vague idea of the benefits of the new computer system, or understanding how to interface to complicated backends where over 10 years of hard-coding by maintenance programmers has resulted in spaghetti systems.

That's why i don't even bother to respond to these anal why php sucks posts anymore. They fail to address the real issues when choosing a programming language:

• Will our programmers be more productive with Language X relative to other languages?
• Will errors be reduced and time to delivery be reduced?
• Can I easily find or train competent Language X programmmers?
• Will Language X be around and supported for a long time?
• Is Language X robust, easy to deploy and cost-effective for our needs?
• Does Language X scale in terms of project size and server utilization?
• Can Language X connect to my backend servers running something like DB2 or Oracle or SAP?

If Java or PHP or Cobol fits the above criteria, then go for it. Arguing about the lack of namespaces or call-by-reference issues is just silly. All languages have problems. The fact that Java is complicated, or PHP is inconsistent, or Cobol is verbose should not be the main consideration.

]]>http://shiflett.org/archive/73Someone finally wrote a good Firefox extension for del.icio.us. It's called Foxylicious. What makes it good? It does exactly what I described in my previous comments about del.icio.us:

Now, if only there were browser plugins for Firefox and Safari that integrated del.icio.us into the standard bookmark mechanism (with some intelligent caching to minimize traffic).

This extension adds my del.icio.us bookmarks to my standard bookmarks menu in Firefox, organizes them by tags (alphabetizing these would be a nice improvement), and lets me choose when to update them (so that it's not an abusive client). Other extensions just never seemed to grok it, as I mentioned before:

I've looked at this Firefox extension, but I fail to see what it offers that I don't already have. Giving me the ability to post is great and all, but this bookmarklet already does that (I use the popup version).

Well done, Dietrich. Foxylicious is exactly what I needed.

I really don't know much about PDO, i haven't used it yet. Most of what I know comes from:
Wez Furlong's first steps with PDO examples
Wez's Oracle PDO Article
John Lim's discussion of adodb and PDO
A sitepoint thread on PDO
I haven't seen any API type docs yet. I did download an older version of the PECL code and skim through it.

Alan has some interesting things to say. I have to agree with him on using libgda as a back end. Using a more mature, existing, debugged code base seems very reasonable to me. Could libgda be used as the PDO back end while retaining the PDO front end API?

When I first looked at PDO, the parameter binding is one of the things that really jumped out at me. It reminded me of register globals, a technique that didn't necessarily turn out well and was painful to back out of. Now that Alan says it, this technique is a bit more reminiscent of C than PHP. As i understand its an optional way to use PDO. A way that I would not use.

Wez comments:

- copying C: I agree that bound parameters can lead to magic code. There are two things to keep in mind: a good coding style (with comments) is the best remedy for code that might be considered magic.

I have to strongly disagree on the coding style point. Salting magic code with comments does not make it palatable. The solution is to remove the magic.

I am not familiar enough with PDO to understand the iterator argument. None of the examples I have seen actually use iterators.

What I would like to see out of a basic OO DB API in PHP is better support for translating the database record into an object. For example, the fetch(PDO_FETCH_OBJ) method returns an anonymous object. I would like a way for this method to construct an object of a particular class along with an initialization protocol such as unserialize has with objects.

I do think that PDO should be a part of core PHP, but perhaps one with a more mature libgda backend and a more evolved PHP front end API, influenced by Alan's feedback and DBDO efforts.

I have noticed that sometimes the API design in PHP tends to simply wrap underlying 3rd party C libraries, even when that design doesn't make the most sense in PHP. (for example the PHP wrapping of expat) PDO is a more of an attempt to design a PHP oriented API and then work the 3rd party libraries into the common design. To me, this is a step forward. However, the PDO API probably needs to go through a few iterations as Alan suggests before being frozen into core PHP.

Having completed my review, it is apparent that PHP 5 has most of the good parts from java, without bogging you down in syntax. I view this as a good thing, making it easier for programmers to drift between the two languages more easily.

If I was asked to recommend a book on java programming, I wouldn't hesitate to recommend this one. I would even consider recommending it to someone new to programming, because most of what it teaches applies equally well to other languages; it serves as a very useful primer, going into the right amount of detail, to make future employees useful regardless of the language that you're going to use.