Puh, this post is getting long - looks like it should be split into several topics if we want to discuss it further:)
>Technically there are db independent layers on top of PHP but this >eats away >at the entire point of PHP (jump right in, whatever works, >patch it >together, and don't give a crap about code cleanliness), and >as a result >isn't all that popular out in the wild. Most people just >go with mysql for >everything and in that way 'normalize' their DB >work. This is, rather >obviously, crap, compared to wicket, grails, >play, rails, django, spring, >etc. Who says that there must be one way of using a tool? Blaming people for being stupid when using PHP does not make PHP into crap :) You will always have amateurs in the playing field, but that does not mean that a pro can't use the tool in a good way. I totally agree that it would have been nice with an abstract layer for the database in PHP, but I must say that I fail to see this as a major problem, as the job of writing a sufficient one boiled down to 364 lines of code in my case. >It's 2010, not 1992. The argument "It is written in C, therefore it >must be fast" is ludicrous. I'll happily modify my statement to "fast enough". I looked up the numbers and yes for calculations PHP is much slower, but in most cases I doubt that it would make an impact on your code. (I found a benchmark here: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&lang2=javaclient) I have yet to have written a php script that I thought "dang that page took forever to load" (and it didn't turn out to be a bad sql that did it). > Define "it is really good at it", because >unlike you I gave quite a list of reasons why PHP isn't very good at >it. Unless perhaps you've got some credentials as to why your opinion >should be taken by itself as particularly convincing, I don't see why >just saying "But it is good!" is going to convince anyone. - It got really good string handling operations and methods are often written such that their output goes directly to the html stream. You could say that it flows better than Java, as functions has been written to make web pages. In Java web was added on later. - Handling of strings in general is easier than in Java, and you have abilities like using variables directly in strings like "foo $bar", which makes for less glue code and better readability. - As with JSP you are in the web page from the get go. For simple stuff this is nice, and it is not hard to add a service level if you need to. The barrier for writing a web page is naturally very low. - Nice JSON handling is a plus for me when I integrate PHP with GWT. - There is no compile step involved - hit F5 and your code reloads, always. - The PHP documentation on the net is fabulous with lots of user contributed examples and discussions. If you need examples of use for a method call you can most likely find the resource there. That said, there are also bad stuff in PHP, but these points are stuff that I find make my development for WEB/ajax a simpler and leaner experience than in Java. >PHP is easy to create XML? You would probably use the libraries for XML handling as you would in any other language: http://www.php.net/manual/en/refs.xml.php. Granted there isn't any real native support for XML (as in some other languages), but it's xml support does not look too bad. >Sure, but PHP makes it particularly easy to write bad code. It's easy to write bad code in any language. It all boils down to how experienced the coder is. >See PHP screwing up backwards compatibility in a point release, being >completely broken >in turkey due to stupid case sensitivity rules in regards to PHP's >case insensitive function names, the slap-dash API design that has >zero consistency, 'magic includes', and many other head scratchers. Yes I've been hit some times by such stuff yes - none that I haven't found with a little bit of testing and an hour worth of fixing. Not nearly enough to scare me away from the language. And Java had its share also when you ported code from Java 1.4 to 1.5, so it's not like Java is perfect either. Languages evolve and as users we must adapt. >I don't think rolling your own db layer for every project jibes with >your earlier assertion that PHP "is really good at [the web]". You do use your web framework of choice in several projects don't you? Writing your own tools to make you more productive and reusing them isn't any different. Adding libraries to PHP makes it even easier to write web pages in it. Just as it does in Java. >> is that one language isn't a golden hammer - use Java or PHP >> where it fits. >Bad mantra. Becoming an expert in any one language is so incredibly >difficult, and takes so much maintenance (continuously working with >it so you don't forget and you keep up to date with new libraries and >developments) that, time-wise and code quality-wise you're far better >off hammering that nail into place instead of using a screwdriver. I agree that for becoming a good programmer in a particular language you need focus. For Java I'd say that amounts to a full time job (++), but that does not mean that you could not code in some other language in your spare time. That be Scala, PHP or whatever language that will help you scratch your itch. What I do not agree with is saying that professionally you should only solve a problem using Java. If you have several tools in your toolbox, use them for what they are worth. Whatever makes more sense and you are more productive in. If you know Perl and need to write a one time conversion job, then use perl if you think you can do it easier that way. If you think it can be solved using a regexp. then use sed, or open up an editor and perform the operation using an advanced query replace. And if you want a simple web page with some minor dynamic behavior, then why not use PHP? <clip nice things on what you should go learn in addition to Java> >This also explains why no java programmer should ever bother with PHP. Not all programming needs to be about expanding your horizon. In some cases you write code to get stuff done. PHP gets things done - easy to write, easy (and cheap) to deploy. Sure not all code becomes work of art, but who cares? As long as you can maintain it, and it solves your problem then I say fine. There is a big difference between writing code that you maintain yourself and code that you write for a company that must be maintained for years, most likely by someone else than you. And there is also a cost factor involved when deploying your code, as your code does also need to run if you want to use it. My current hosting plan is $80 a year - the cheapest I found for java at the moment was $360. I prefer my $80. >The only lessons you're ever going to learn there are bad ones, and >it's rather obvious it's not going to be the next big thing either. If you want to learn good programming techniques you go study, read books, learn patterns and do lots of practicing. What you learn you apply to all your coding - also your PHP code. Writing code in PHP does not infect you into doing stupid things :) And yes it is not going to be the next big thing, but it is here, now, ready for you to do your stuff in it. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
