|
Why does Joel care about PHP at all?
PHP really isn't that clever...
PHP is as understandable as perl, but without the power. PHP is object-oriented, but not cleanly enough to get the kind of leverage you'd get with Java or Python (let alone Smalltalk or Ruby)
(PHP code is also very dependant on the way the server is configured for it. A few little tweaks and your PHP code won't work... and there'll be nothing you can do about it - not good for sites that use virtual hosting.)
More fundamentally, mixing domain logic and UI (which is the whole point of ASP/JSP/PHP) is a terrible idea - I was once responsible for maintaining a subsystem that was a giant HTML+JSP+Javascript+SQL cocktail. I resigned from that company, and I'm NEVER going to let myself get into that position again.
In my own projects and on my work project at the moment, we're using templating languages like HTML::Template, and Velocity to keep the view separate from the business logic.
Joel must know that PHP, ASP, and JSP are evolutionary throwbacks in terms of design. So why does he care so much about PHP? He's not going to compile CityScript into PHP is he? I don't know if that'd be a good idea.
Personally, I'd give up on PHP. It started life as a hack, and because it's easy to understand, people start working with it. But the whole idea is fundamentally wrong - why expend any effort on it when there are much better ways to do things?
Dafydd Rees
Monday, October 13, 2003
I know CGI, PHP, ASP and ASP .NET.
I consider PHP to be the BEST web development system, from those above.
However, when ASP .NET will have some bugs worked out, and more components will be available to it, it will be better than PHP.
Jinks
Monday, October 13, 2003
>More fundamentally, mixing domain logic and UI (which is the whole point of ASP/JSP/PHP)<
Hold the phone there sparky. I can't comment on ASP or PHP - as I've never worked with them professionally - but the whole point of JSP is NOT to mix domain logic and presentation, just the opposite in fact. When used correctly, JSP pages have actually very little Java code embedded within them and the Java code that is in them basically gets a collection of objects from the session or request object, iterates over said collection and formats individual objects however they need to be formatted in HTML.
Spoonman
Monday, October 13, 2003
Just like every other tool or technology, there are some problems PHP is good for, and some that it's not. One of the skills a programmer should have is to know which tool(s) to pick (rather than dismissing something out of hand). A programmer should also know how to use the tool(s).
I've been using PHP + MySQL to develop web and ecommerce sites for a few years and I'm bored with the arguments about separating UI from business logic. For a significant number of web applications that kind of separation is not only pointless (the HTML is full of "business logic" anyway) but impractical and time-consuming. It's like hiring an architect and engineer to build a doghouse.
You can use templates to tease the GUI parts out, but then you give up a world of web development tools that work with HTML but don't work with special template languages. And when you're done you can't look in one place to get what the program is doing--you have to look at the templates and the code that fills in the templates. Instead of writing a program that emits HTML--which is what PHP programs are--you write a program that emits parameters in a special language to another program that emits HTML.
It's easier to just read the PHP inline with the HTML. A few rules and conventions, some source formatting tools, and using included files to modularize is all the "software engineering" a lot of PHP code needs.
Some applications should be designed and written to last for years and scale and survive lots of enhancements and refactoring. Those are probably not good applications for PHP, or Perl for that matter. But a large number of applications will only live for a couple of years before they're replaced, they won't have to scale to millions of users, and they won't be significantly changed or enhanced. That's the space PHP excels in.
When I look at PHP code written by people are learned to program with HTML + PHP, I of course notice their lack of design and programming skills. But even experienced programmers move too much logic into the PHP code because they don't use the back-end database to do queries correctly, and they bring the database code right into the front-end. A lot of crappy PHP code exists simply because the author didn't know enough SQL to avoid sending a query and then looping over the result set and doing everything in code. It's as if SQL had no WHERE clauses, no JOINs, no computed columns.
PHP is not my first language, nor my favorite, but it has its place, and more important it's not going to go away anytime soon. I know I'll get a lot more business using PHP and making weak PHP code better than I will telling small businesses that they need to redesign and rewrite everything according to a textbook model in Java.
Some applications warrant a lot of up-front design work and best practices software design. And some applications don't. A lot of web sites are in the latter category, and that's the space PHP excels in.
Gregory Jorgensen
Monday, October 13, 2003
I'm assuming Joel and Fog Creek are trying to commoditize their products' complements. At the moment, FogBUGZ requires IIS. This makes it hard to sell to Unix shops. By porting FogBUGZ to PHP, Fog Creek opens up a vast new market. New markets mean more money. Whether you like ASP or not, that's what Fog Creek decided to use to implement FogBUGZ. I'm assuming they saw PHP as the closest thing to a Unix equivalent of ASP.
Also, I don't know about JSP or PHP, but ASP in no way forces you to mix business logic with presentation code. If you end up with a big mess of tangled business logic and presentation code, it a problem with the programmer, not the environment.
SomeBody
Monday, October 13, 2003
I have given this alot of thought actually. I my conclusion is that it is not ASP and PHP that are flawed. It is HTML.
To express serverside functionality in HTML requires the rendering of HTML so you cant help that the logic mixes with the presentation.
There are basicly two ways to do it. A) you use a template, lift it into the code and manipulate it , or B) You make code that writes the HTML from scratch like the typical PHP approach. Neither way is a clean separation even though templates are way better in situations where you have a designer person.
The fact remains, a HTML tablecell does not expose a "setContent" method, because it is not a logical entity. Its just markup, and the table becomes a table only when rendred by a browser.
Infact.. for some improved separation javascript might be the answer because with JS you can actually fill up a table in the browser.
But then youd have to trust the browser a bit more than one can do right now.
Eric DeBois
Monday, October 13, 2003
> In my own projects and on my work project
> at the moment, we're using templating
> languages like HTML::Template, and Velocity
> to keep the view separate from the business logic.
We use PHP with a powerfull templating engine; Smarty. Nowhere in our code you'll find HTML!
> More fundamentally, mixing domain logic and
> UI (which is the whole point of ASP/JSP/PHP) is
> a terrible idea [.]
Hmm, don't you contradict yourself here? Or at least drop the PHP part of your last remark (don't know about ASP/JSP enough myself). With Smarty we've seperated UI from other code (we furthermore seperated business logic and database logic by means of objects, but thats another can 'o worms).
Jilles Oldenbeuving
Tuesday, October 14, 2003
PHP is great. Unicode aside (and that _needs_ fixing!).
Just wish that it had (and used) a common database abstraction layer. Having to retype for each backend when you're using very safe SQL is a real pain.
i like i
Tuesday, October 14, 2003
See this post http://discuss.fogcreek.com/FogBUGZ/default.asp?cmd=show&ixPost=2218&ixReplies=1 for confirmation that a php variant of Fogbugz is on the way.
Tony E
Tuesday, October 14, 2003
Hey 'i like i',
You can use ADODB library from http://php.weblogs.com to get great database abstraction for PHP. You also have PEAR packages which allows the same.
PHP group has purposely kept database abstraction out of main PHP language.
JD
http://jdk.phpkid.org
JD
Tuesday, October 14, 2003
I think Joel's criticism of PHPs encoding is a little unfair.
If you think it is incomplete and/or badly documented, it's an open source project .. you are quite at liberty to sponsor someone to make the changes for you.
You could make the changes yourself, but it would obviously make more sense to find someone to do the changes for you - especially if they know PHP internally very well.
Ross
Tuesday, October 14, 2003
As regards the using php to move to a unix market, you can use ASP on unix with chilisoft ASP.
fw
Tuesday, October 14, 2003
PHP in no way forces code/html intermixing. I've written a whole suite of applications ( http://www.lazarusid.com/ebusiness.shtml ) using PHP that doesn't have the two intermixed. I've also found the language to be very well documented.
I will agree though that it is hyper-sensitive to configuration changes. I've also found that it's a speed dog, at least on UNIX. I started writing all of my CGI programs in C for the stability, and found happily that C also made a faster application, especially on a loaded server.
Clay Dowling
Tuesday, October 14, 2003
All of the people complaining about the mixture of PHP code with HTML tags are just doing it wrong :)
IMO, what PHP does wrong is cater to the worst instincts of incorrigible Perl hackers. (i.e. "Hey look, now I can write bad CGI programs in TWO languages! And the syntax is almost the same!").
I work with an unreformed Perl programmer who absolutely _loves_ PHP. His web apps are truly a thing to behold. What kind of thing, I won't say in public ;)
Rob VH
Tuesday, October 14, 2003
To answer the question "Why does Joel care about PHP at all?" I think Joel would care more about web sites and applications getting character encoding right. I too care about that, because I want a web that everyone can use, and I want data that is properly encoded, and to that end I want to properly encode any data that I create. Maybe it's more about doing it the right way rather than avoiding it or being ignorant of the issues...
pete
Tuesday, October 14, 2003
There are really only two fundamental problems I have with PHP, JSP and ASP:
1) Why do people have to invent new languages for templating HTML? A simple templating engine that does nothing other than expand strings by reference to named entities in an object model is all I need.
I wish people would get clever by trying to design a new language (and producing a third rate language that only works in the web context), when all they need to do is write a templating engine in an existing language.
2) Does the language I use to write web apps encourage people to write nice, clean, (well-factored,) object-oriented code? _Supporting_ object-orientation just isn't good enough.
If object-orientation is an afterthought, (like it is in Perl and in PHP) then most people won't use it, and you'll have the complexity of object-orientation _plus_ the complexity of huge amounts of redundant procedural code. (ASP isn't any better because object-orientation without polymorphism is virtually useless.)
The second point is really important to me. I work on an extreme programming project. Bumping into things I can't easily refactor "because they're not an object", or "because they're 'static'" costs the company time and money, and you know that you wouldn't have these problems in a better language.
Da
Tuesday, October 14, 2003
(sorry, that last posting should have been signed "Dafydd Rees" and not "Da". Dratted [ENTER] key.)
Dafydd Rees
Tuesday, October 14, 2003
"1) Why do people have to invent new languages for templating HTML?"
There are more factors involved in that then "templating HTML". Sometimes you need the write tool for the job. PHP is specifically designed to run in the webserver process and punch out HTML pages. Obviously, you could use Perl (w/ mod_perl) but Perl is ugly!
"A simple templating engine that does nothing other than expand strings by reference to named entities in an object model is all I need."
That wouldn't be enough for me. I need something a lot more complicated than that. I did look into using various template engines for PHP but in the end I just decided to use PHP itself as my template engine. I separate business logic from presentation -- I just use one language to handle it all.
"If object-orientation is an afterthought, (like it is in Perl and in PHP) then most people won't use it"
That's actually backwards. Object-orientation in PHP wasn't a afterthought, it wasn't even considered at all. "Objects" in PHP were just designed as nice way to encapsulate hashes. PHP was a procedural language, the designers never figured it was anything else. However, everybody started using PHP objects and creating large frameworks and class libraries. In became, much to shock of PHP designers, the main way that PHP programs were developed.
PHP is becoming more and more object-oriented over time. It's evolving based on how people use it and how it was designed to be used! In that end, PHP5 has all the object-oriented features of Java.
Almost Anonymous
Tuesday, October 14, 2003
I should have said "and NOT how it was designed to be used"
Almost Anonymous
Tuesday, October 14, 2003
" In that end, PHP5 has all the object-oriented features of Java."
Dear God, please no. Is it really that bad?
[...said the card-carrying member of the Object Liberation Front.]
Dafydd Rees
Tuesday, October 14, 2003
"but the whole point of JSP is NOT to mix domain logic and presentation, just the opposite in fact."
Yes, I agree, but if you give people the power to run arbitrary chunks of Java in their templates, then it's usually a matter of time before they do it. Put the programmers under enough pressure and they'll roll over and start hacking...
I've done enough J2EE to see this happen a few times and I want to fix the templating problem in the infrastructure - by having something simple, lightweight, that doesn't allow people to write cocktails of HTML+Java+Javascript and SQL in a single file.
You have to ask yourself why people are developing taglibs for things like SQL access? Do they need to talk directly to the database to draw the view? It isn't a hack. Is it??
One particular character actually used JSP to output an entire Oracle table into a Javascript array, ran the business logic in Javascript and then pulled it back in and wrote out the changed "record" to Oracle. It would be hysterically if it weren't true: there were fields called "username" and "password" in those records! Why did he do it? Was it because JSP made this sort of thing far too easy?
Although Velocity has other problems we've had to work around, it does stop people writing arbitrary pieces of business logic in the template.
Dafydd Rees
Tuesday, October 14, 2003
> Although Velocity has other problems we've had to work around, it does stop people writing arbitrary pieces of business logic in the template.
I really wanted to like Velocity, but the java apache projects feel like a bunch of unorganized senior CS projects. I've been a big fan of open source, java, and apache for a long time, but the jakarta projects are managed nothing like the httpd engine itself. In fact if someone pointed to jakarta and said, "this is what is wrong with open source," I would probably have to agree with them.
You could argue that jakarta is not a fair representation of Open Source, but since it uses the Apache name, and is contributed by many huge and influential corporations, I would disagree with this. In fact Apache httpd was considered a model Open Source project. Also Sun, the creator of language and specification, considers Tomcat to be the benchmark servlet engine implementation.
I made a decision a long time ago to use Tomcat, and it is a decision I am not convinced was the right one. To this day I have to restart the engine nightly for no apparent reason. The jakarta folks have failed to realize that, "get the latest version" is not acceptable in production environments, especially when configurations and APIs are not backward compatible. I still use jserv in certain situations, because I don't trust or have the time to port and stress test my production system under Tomcat. Call me a luddite, but I'm the one who gets those dreaded 3AM phone calls when the system stops working. What I have now is time tested, and I can't afford to change.
While there are many great ideas embodied in Jakarta, as a whole it suffers from poor execution.
christopher baus (tahoe, nv)
Tuesday, October 14, 2003
"get the latest version" is not acceptable in production environments, especially when configurations and APIs are not backward compatible"
Which is what I time and time again have tried to explain to PFY's straight out of a CS curriculum that wouldn't know about "production environments" if they where dragged over them barebacked a few times but always are convinced that the latest and greatest "free" software package is the only way forward.
Just me (Sir to you)
Wednesday, October 15, 2003
 Recent Topics
Fog Creek Home
|
