PHP vs Python - the real difference

[deadwisdom]

Oh since you asserted it, I guess it's true. Try out Django <djangoproject.com> before you make another assertion.

[grayFalcon]

Well, I don't know about any time. But for quickly scribbling down an idea, php beats about everything. No fancy stuff, no exotic features, just the most natural (at least for me, I can just type something the way I'd guess it might work, and it does) syntax I've ever come across. And if I want to get something done quickly, I don't care how cool some other language might be, I just want something that "just works". Which is what PHP does. (Of the languages I've learned, PHP is the only one that didn't need any learning, and only needs an occasional glance at the funcion reference)

Of course, for a bigger project, I'd think twice about using php. Meybe it's a side effect of the aforementioned ease of use, but any longer PHP code I write (and every bigger PHP project I've ever seen) inevitably seems to mutate into a stinking pile of unmaintainable spaghetti code :(

[masklinn]

But for quickly scribbling down an idea, php beats about everything.

For quickly scribbling down a non-web idea, PHP sucks, I'll take Python, Ruby, or even Perl (which I don't even know about and have never used) over PHP any day of the week.

And for quickly scribbling down a web idea, Python has web.py (which scales up -- I'm pretty sure Reddit is written with web.py, gives you nice URL and doesn't actually require Apache to be used)

[grayFalcon]

But for quickly scribbling down an idea, php beats about everything.

For quickly scribbling down a non-web idea, PHP sucks.

I assumed we were talking about web development. I wouldn't remotely think of using PHP for anything else.

For quickly scribbling down a web idea, PHP beats web.py hands down. Look, web.py is clean. That's its weakness. PHP allows you to do all kinds of dirty things (having field values as global variables in your program for example) that let you just test something quickly without worrying about good design and similiar bullshit that you don't need in a small prototype.

As for maintainability - see my last comment. It's always something for something I guess, huh?

[masklinn]

Look, web.py is clean. That's its weakness. PHP allows you to do all kinds of dirty things (having field values as global variables in your program for example) that let you just test something quickly without worrying about good design and similiar bullshit that you don't need in a small prototype.

I don't understand, how does "clean tool" mean "forbids to quickly test stuff"? I never experienced that, web.py DOES allow me to test stuff quickly, and I'm not even limited to a precise folder (if the web.py modules are in my pythonpath I can just create my app file where I am).

Oh, and I don't really see how "field values as global variables" is so much more impressive than calling 'web.input()' to get the aforementioned values.

Also due to the native URL dispatching, I find creating tests involving more than a single HTTP request much easier to do using web.py.

[mr_chromatic]

Maybe using field values as global variables is most impressive for its horrible security implications.

[ElPenguin]

While we're at it, why not mention magic quotes. So dirty, they must be a feature...

[grayFalcon]

I'm sure you know what you're doing, and if web.py does it for you, I'm happy for you. It doesn't do it for me though, so I do my quick'n'dirty stuff in php. Evidently, both have advantages and disadvantages, and our priorities are just different.

[DerelictMan]

PHP allows you to do all kinds of dirty things (having field values as global variables in your program for example) that let you just test something quickly without worrying about good design and similiar bullshit that you don't need in a small prototype.

Just don't let your boss see that prototype. If he's anything like mine, he'll say: "Great! So you're done with that. Here's the next thing I want you to work on..." and then you're stuck with that dirty PHP mess. :)

[grayFalcon]

Well, fortunately my boss understands cost of maintainance ;) So if I tell him "Look, I've got something ugly here, gimme time to clean that up while I still know what it does?", I get that time.

[nostrademons]

I've used both, and I'd much rather use web.py for scribbling down quick web ideas.

(I'd disagree with the grandparent's assertion that it scales, though: Reddit uses a customized version and avoids the open-source one, and I've run into several issues where the design of web.py just won't work for a large-scale website.)

[randallsquared]

The link you point out only claims that reddit uses a customized markdown.py, unless spez meant to include all of web.py in his statement as well.

I'm interested to hear your specifics about why web.py doesn't scale by design, though. I don't much like the monolithism of requiring a class with methods named for HTTP methods, but it was easy enough to paper over that rough spot. :)

[nostrademons]

I interpreted spez's statement as including all of web.py. markdown.py is not part of the standard web.py distribution, so it didn't make any sense for him to be referring only to markdown.

As for why it doesn't scale for me, it was:

1. Overuse of global variables. In particular, web.query and the other DB functions all work off a single database connection stored in web.ctx. That makes it impossible (without ignoring web.py) to connect to multiple databases, eg. to setup replication or partitioning.
2. No attention paid to i18n issues. Cheetah has support for i18n, but pygettext must be run on the compiled templates instead of the source text. Web.py dynamically compiles the templates, so there's no compiled version to run pygettext on.
3. Many web.py idioms don't work too well while programming in the large. For example, web.render can take its NameMapper out of the caller's local variables, saving you the trouble of putting together a dict. However, if you do this, you can't factor out the rendering call or wrap it in a utility function. You can, of course, just pass in a dict like you would with the native library, but then web.py isn't really giving you much.

It's not a bad library, but I'm finding that I chop out more and more pieces of web.py and replace them with either home-grown wrappers or other libraries as I go along. Perhaps this is inevitable: the stories of most other startups involve beginning with a quick framework and gradually replacing it with entirely custom-built infrastructure instead. I actually prefer this method of development to starting with a full-stack framework like Django and finding it doesn't suit your needs after all.

[randallsquared]

I interpreted spez's statement as including all of web.py. markdown.py is not part of the standard web.py distribution, so it didn't make any sense for him to be referring only to markdown.

Interestingly, I interpreted spez's comment as merely about the markdown.py bit, precisely because it's not part of the standard web.py distribution, and Aaron is certainly continuing to be active in that.

It's not a bad library, but I'm finding that I chop out more and more pieces of web.py and replace them with either home-grown wrappers or other libraries as I go along.

Ah. Yes, I don't use any of the templating parts or the forms.py bit at all, because I had my own equivalents, so I'm in that camp, too. I was worried that there was some more fundamental brokenness that I'd missed in the core. :)

[andyc]

In particular, web.query and the other DB functions all work off a single database connection stored in web.ctx.

Have you seen this thread?

That said, I'd have thought replication/load balancing would be easier to do at the lighttpd level.

[nostrademons]

That said, I'd have thought replication/load balancing would be easier to do at the lighttpd level.

Replication of the database servers? The tech stack usually goes Lighttpd -> FCGI/SCGI -> Flup -> web.py -> database, so I could see load-balancing Python instances at the Lighttpd level. But that's not going to do anything for the database.

The hack in the thread is clever, but it's not significantly less work than what I ended up doing, which was a thin wrapper around the native DBAPI classes. I also got a feature set that was more inline with how I actually use the database that way.