Ask HN: Bet the farm. Python or PHP? | Hacker News Reader

Ask HN: Bet the farm. Python or PHP?

24 pointst0pj103 comments

1. Extensive support of libraries and frameworks. 2. Excellent community. 3. Rapidly develop and deploy. 4. Capable of scaling quite well.

Python and PHP score well on all four of these points.

I am about to embark on building a web app; calendar/scheduling/notifications with some social networking and people matching/search functionality. The site will be highly configurable/maintainable by it's community from establishing/interacting within groups to tweeking page layouts.

So far, I have chosen this stack:

Ubuntu, Apache (dynamic content), thttpd (static content), MySql, memcached.

I'm quite experienced in Perl but just a beginner in both Python and PHP yet I am determined to use either Python or PHP in my latest project.

I'm looking for the pros/cons and any other tips from the HN community. I'm at a fork in the road and I guess that once I make this choice, it'll be quite difficult switching after the initial framework is built out.

I'm not sure if I have/haven't given enough information to go on but I would appreciate everyone's input, not only on PHP or Python but on any of the other technologies I have chosen as well as critiquing my (currently vaporware) web app.

So which is it; PHP or Python?

View on HN

I've used all three of the languages you mention for relatively large web applications. People will say PHP sucks because it is ugly and retarded and only has one namespace. People will say Python sucks because of the whitespace issue and mod_python doesn't work on a $5/m shared hosting plan. Perl sucks of course because "the syntax is crazy!" But, huge sites are built in PHP (Facebook, Hype Machine, Flickr, half of Yahoo!), Python (much of Google) and Perl (craig's list). In my experience they are all about equivalent except for aesthetic reasons.

The headaches in a web app are usually at the user interface level (DOM/CSS/Javascript) and at the systems level (there's a bug in fast cgi! MySQL imploded!) and language choice gluing it all together is mostly a matter of taste. People with taste overestimate its importance. You can get pretty far in the internet biz with no taste (MySpace... originally done in COLD FUSION).

That said, the most tasteful option out of your choices is Python.

You can get pretty far in the internet biz with no taste (MySpace... originally done in COLD FUSION).

And don't forget those non-tasty table/tr/td non-div tags MySpace is also known for. ;)

Anyway, I think you have a point. Thanks for your insight.

Mod up for saying that language choice is primarily a matter of taste.

But, there were a few other considerations for me when I chose Python as my development language over PHP and Ruby.

I think that as far as language growth is concerned, Python has more buzz right now (no disrespect to PHP or Ruby intended). Google's app engine is all about Python right now, and that's going to dramatically increase the traction of Python in the web development world. Google is actively supporting Python development. Google has a lot riding on Python because it's one of the 4 sanctioned languages at the GOOG. I could be wrong, but I get the impression that Python is growing as a community and as a language faster than Ruby. This is why I chose Python over Ruby.

I also chose Python, because I think that there's aspects to Python that will broaden my horizons and stretch me as a programmer as I learn it. I don't really get that impression with PHP. All things being equal, I'd rather learn a language that will stretch me as a programmer.

Most of Google products were written in C++ or Java.

GMail - Not Python

AdSense - Not Python

GMaps - Not Python

Search - Not Python

source?

AdSense - http://www.reddit.com/info/6m9fi/comments/c04990m

Reference to Guice.

GMaps - my ex-TA was an intern at Maps team, she told me that mostly it is written in C++. She also told me how surprised she was when she found out that most big products were written in C++/Java instead of Python.

GMail - might want to ask Paul Bucheit, but I remember vaguely coming across a blog post/article saying that it is written in C++ and Java.

Joshua Bloch (Effective Java author) said that they developed in-house middleware that bridge Google's infrastructure with Java (BigTable, MapReduce were written in C++).

I suspect Google is using JNI to access C/C++ based framework/infrastructure.

So far, I only know 2 products written in Python:

1) YouTube (purchased)

2) Google Groups (semi purchased I think, from the people that brought you ClearSilver template in Python).

I heard YouTube had to integrate their code to Google's infrastructure, but I don't know if they had to re-write some stuff.

Why throw away Perl? You already know Perl, and Perl has lots of things that PHP and Python don't. Before you ditch Perl, look at DBIx::Class, Moose, and Catalyst. And the other 10,000 libraries on CPAN.

Then look at the 500 or so libraries available for PHP.

Perl has a really insane library culture, and it's very hard to give that up. I like the syntax of other languages better (Lisp is my favorite), but it's hard to give up the millions of hours of free work called the CPAN. Perl also has great tools for testing (see how many Test:: modules there are), and it has a culture of testing. So the libraries you download from the CPAN aren't some untested i-hacked-it-together-while-drunk snippets of code; they're all very carefully tested. What it boils down to is that when you move your app from development to production, you'll be reasonably sure that your libraries (and app) still work.

One line summary: Perl has more features and libraries than the alternatives, and you already know it! I think the choice is a no-brainer.

I really would like to use PHP or Python in a big project to at least get some experience.

I tell ya, I do love Perl.

With limited exposure to PHP and Python, could you elaborate on some of the things PHP and Python are lacking compared to Perl?

Neither PHP nor Python have anything approaching CPAN. Ruby is slightly closer with Gems, but even that's a joke compared to the might of Perl libraries. Seriously, that's the big thing that's missing. Other than that both PHP and Python are prefectly servicable, although you're going to have an easier time finding smart Python developers than smart PHP developers (Blub hiring paradox).

And perl has nothing approaching Python's readability. Perl may be easier to start with now but in 6 months, it will become a major headache. Read http://www.linuxjournal.com/article/3882 . Using Python would be an excellent choice imo.

Thanks for the link.

That's one thing I love about Hacker News; all of the links y'all leave that lead to further study and growth.

Python being readable is FUD. I've seen tons of horrible Python. Of course, I've also seen tons of horrible Perl (and PHP, and even Lisp).

Basically, in the hands of incompetent programmers, everything is unreadable. If you are disciplined, you can write easily-readable Perl. I (and my coworkers) do it every day.

Oh, one other thing... the linked article is from 2000. In the last 8 years, the Perl community has figured out how to program... so most of his points aren't relevant anymore. Nobody writes 2000-style Perl anymore.

one can write readable anything, but some languages encourage it more, both in the language features and syntax, and also in the community, tutorials, etc

Yes, Perl encourages readability in the language by one of its language features, the helpful prefixes in front of variable names.

This is a joke, right? You can't possibly be serious.

No, I was serious.

When I look at a variable in Python, say, p, to take an example from the code shown in the Python documentation, there is no way to tell what p is. Is it an array? A dictionary? A tuple? Something else? With Perl I get more information just by looking at the variable. That makes it more readable.

Python, on the other hand, is still very nice. Maybe one of these days it will get me, especially if the libraries grow to match the breadth of CPAN.

Incidentally, I often see people complaining about non-idomatic python tutorials here.

What I see from this is that people will try to TMTOWTDI regardless of whether or not that's the language's philosophy. At least Perl prepares you to expect people writing code that doesn't look like yours.

(And I'm used to people's weird styles. I have one friend who makes every line of code its own subroutine, and another that gives every method a super_descriptive_but_way_way_too_long_name. You get used to it, and emulate it when appropriate. It's better to decide on a style with your friends/coworkers instead of being told what to do by some guy that works at Google you've never met.)

Perl is more readable to someone who knows Perl, because it gives you indications what type each variable is:

$ for scalars (single values without dimension)

@ for arrays

% for hashes (like python's dictionaries)

With python, you have to guess.

Of course, many people who are intimidated by Perl have made the same statement about readability, and it is often repeated unthinkingly. That doesn't mean it's true.

On the other hand, Perl does make it easier to write unreadable code. Just like any powerful tool -- cars, telephones -- it can be abused.

All that being said, I think Python is a great choice too; I just disagreed on the readability point.

because it gives you indications what type each variable is:

Not really. Guess what type $foo is in each case:

    my $foo = [];
    my $foo = {};
    my $foo = "Hello, world.";
    my $foo = \"Hello, world.";

while completely ignoring the right hand side, i can tell they are all scalars.

Looking at the right hand side, I can tell the type of the value in that scalar type! ... the value type is a different thing than the variable type

We can really debate and argue about the value of typeful variables ... the value seem to be that it allow a combination of syntactic sugar and availability of the reference type!

So basically, if you want a reference type, you need syntax to dereference the reference.

And if you have that, you will eventually need syntax sugar for when you dont want to use the dereferencing syntax.

This is probably why in Perl things are the way they are!

I am not sure thought if the reference type is at all needed, it some occasions I see it clarify cases when values are passed by reference vs passed by value, because a reference in Perl is a real value, not something that is implied! ... but this i would say is largly subjective

I don't understand most of your post (too many ...s that aren't clear), but you should probably stay away from the word "type" when you are talking about Perl variables. "Scalar" doesn't really mean anything. If anything, it describes the cardinality of the contained value, but certainly not the "type".

Even values stored in variables have very flexible "types" that I wouldn't really call a "type".

If you store "42 is a number" in a scalar, you still don't have a type. Maybe it's a string, maybe it's an integer, maybe it's a boolean. Types only show up when you apply an operator. If you say "42 is a number" - 42, then the result is 0 because "-" coerces the string into an integer (actually a SvPv to an SvPvIv, and then looks at the integer part of the data structure). This is different from other languages that choose the operator based on the type of the value (look at how SBCL chooses the right + operator to used based on the types of the contained values. the exact opposite of Perl).

As an aside, this coercion isn't an implementation detail; Perl exposes it all to you. If you "use overload", you can have "boolify" subroutine called when someone does "!$your_object", a stringify subroutine that's called when someone does "$your_object =~ /.../" or "qq{$your_object}", a "numify" subroutine that's called when someone does "$your_object - 42", etc.

Anyway, not sure what my point is... but don't use the word "type" to talk about values or variables in Perl. It just doesn't make sense. Perl is totally different from other languages here, and the word "type" has too much incompatible baggage associated with it.

okay, in summary, I wanted to say.

In Perl $ means scalar, @ means array and % means hash

Those are variable types, you learn them by looking at the variable syntax or name

The value pointed to by those TYPED variables can be more complex, you can have integers, floats, strings, references, reference to a string, reference to array, reference to hash, array of strings, array of references etc .....

but the variable type won't tell you about these complex structures, it will only tell you that the value is $ scalar or @ array or % hash ... and in that there is no confusion, all the variables you mentioned above are typed scalar and can only point to values of type scalar

I understand your problem, since a scalar can be a reference to an array

you want to think that $ref = [] points to an array but it doesn't it points to scalar which happens to be a reference to an array!

you can for example do this

my $ref = [];

$ref->[0]= 0;

say $ref->[0];

$ref = {};

$ref ->{0} = 1;

say $ref->{0};

but you can't do this

my $ref = [];

$ref->[0]= 0;

say $ref->[0];

## $ref = {};

$ref ->{0} = 1;

say $ref->{0};

because in $ref ->{0} = 1 the assignment is to value referenced to by te scalar, and this value type is not a hash and can't have a hash member {0}

The whole references thing is the biggest pain in the ass in Perl syntax. List flattening, and the fact that arrays and hashes can only store scalars (or a reference to something else), etc. just expands into every nook and cranny of the language.

I still have a hard time with this aspect of the language after 10 years of Perl coding (with a three year break where I mostly worked with Python). And given how strong the tools in Perl are for working with hashes and arrays (grep, map, join, splice/unsplice, shift/unshift, sort, etc.) it really is a pain point. Perl 6 fixes many of the painful bits but not all.

But, nonetheless, I'm more productive in Perl than any other language. Partly because of the massive library of excellent pre-existing code, and partly because my problem domain almost always involves text parsing/processing and dealing with system-level data which are things for which Perl was designed.

And given how strong the tools in Perl are for working with hashes and arrays (grep, map, join, splice/unsplice, shift/unshift, sort, etc.) it really is a pain point.

Not really:

  my $ref  = [qw/foo bar baz/];
  my $ref2 = [map { uc } @$ref]; # [qw/FOO BAR BAZ/]

References, if anything, are just slightly ugly. I could live without non-reference values, however. They're basically useless, but sometimes they make the program more concise.

I think everyone realizes this mistake, however, and Perl6 only has types that behave like references:

  my @foo = split '/', "foo/bar/baz";
  function(@foo, 'hello');

  sub function(@foo, $string){ ... }

My point was that it is an additional bit of friction that isn't present in Ruby or Python (though they also have their own bits of friction). Even though I've written a lot of code in my life, I've never been a full-time software developer, and so it's one of the tricky bits that drops out of my head during the breaks in between writing code. I'm interacting with code written by someone very comfortable with these idioms, and so they show up all over the place, and I never quite get them right the first time. I just think it's an area that makes Perl trickier than it ought to be...it's not a deal breaker (PHP's lack of first class functions, for example, now that's a deal breaker). I'm basically a raving Perl fan, but arrays only holding scalars is a nuisance.

And, as I mentioned, Perl 6 goes a long way to correcting pretty much everything I don't like about Perl 5.

PHP's lack of first class functions

Thanks for that lil' tidbit.

It's the

    @{$h{$k}}

syntax that's fugly. +1 for Python.

Most fundamentally, PHP combines Perl's array and hash data structures. Although you can access name/value pairs as even and odd array elements, code that doesn't need both sets of properties will run slower and consume more memory because a structure implementing both sets of properties is implemented automatically.

Why use a languge like that when you're already familiar with Perl?

Thanks. I didn't know about PHP's array/hash combo.

Would there be nothing for someone familiar with Perl to learn from using a language like Python?

I appreciate your thoughts.

If I recall correctly, a PHP "array" doesn't necessarily iterate (with foreach) in numerical order. That's just weird.

Python... both languages are along far enough that they will meet all four of your points, but people that program in python are on average better programmers than PHP programmers. So it makes hiring good hackers easier by eliminating many of the bad hackers.

Other than that, if you like the syntax of PHP, it is as good as python as long as you program using the MVC paradigm. Personally I like the syntax of python a whole lot more than PHP.

I guess, for a lot of people, PHP would be easier to dive into than Python?

I get your point; without any other knowledge, you'd be better off selecting from a pool of Python developers than PHP developers when looking for good hackers. Correct?

Although I would be able to somehow separate the good hackers from bad by initially chosing Python, would you say that good hackers would also stay clear of opportunities where PHP is involved? What would facebook think about that? ;)

Just want to know your thoughts. Thanks.

php is not easier to dive into. it's messy and confusing. python and ruby are some of the easiest languages to learn.

You won't find any PHP hackers. The good PHP developers realized that PHP was a waste of their time a long time ago. All the novices have significantly lowered the average PHP developer's salary compared to other languages. Basically, there's no skill and no money in PHP, so the good people don't use it.

This is stated as an absolute where there are certainly good PHP developers that work at Yahoo and Facebook... still, a less extremely worded version of your statement is true.

upcoming.org was coded in PHP. That being said, anyone can code a website but creating a website of value that attracts users...

You won't find any hackers who use sweeping generalizations. Oh, wait!

I'm a hacker. I use PHP. I use Python. I use C++. I use Java. I use JavaScript. I use Prolog. I use C#. I use whatever language or tool is best for the job and I innovate with them however I can. I love getting my hands on new SDKs for every language and framework, learning their quirks and implementing fun things with them.

There is skill in any language you choose to use. That's up to you, not the language. In fact, a "bad" language require significantly more skill to use successfully and securely.

Now, I'm not going to disagree with someone if they provide cons/pros for different languages, PHP has its faults, maybe even more than other languages. But it strikes me odd that you'd be upvoted so much for saying that no hackers use PHP.

The presence of "novices" aren't going to scare away someone who likes to code and get the job done in clever ways. I'll also note, as someone who runs a game scripting community around Python, that novices produce some of the cleverest little tricks and really shouldn't be shunned anyway. We were all novices once.

In fact, a "bad" language require significantly more skill to use successfully and securely.

You seem to be passing this off as an advantage, but that doesn't make sense. Let's say you make furniture for a living, and one day you intentionally slice your arm off. Now you brag that having one arm is better than having two, since you now "require significantly more skill" to do the same work you could do before.

That doesn't make you a better furniture maker. It makes you a cripple.

Using PHP is the programming equivalent of cutting off your arm. It makes work more difficult, more painful, and slower.

But to each his own.

You've really got a bad taste in your mouth regarding PHP. I'm sorry to hear that because it's just yet another tool. It only has to be as painful and slow as you make it when you use it. I hope you have a chance to revisit it sometime with a modern framework like Code Igniter or CakePHP. I used to have a shade of the type of biases you show now, but after we've made half a dozen MVC web apps using Code Igniter (and Django) I've had to change my tune.

Best of luck to you.

I used to have a shade of the type of biases you show now, but after we've made half a dozen MVC web apps using Code Igniter (and Django) I've had to change my tune.

The possibility exists that you just don't know enough about programming to make an informed decision.

This isn't true in my very recent experience. I was recently (briefly; hired now) looking for a job in the DC metro area, and I find that even places that want you to primarily use Python or Java seem to also desire PHP experience, presumably because they have lots of legacy PHP code.

I would agreee Python really is 'that language'.

Python brought me back from a bored and frustrated programmer using Java to a hacker. I have programmed in Java since then and have been much better as a result of my work with Python.

PHP in my opinion is a very weak option today, and I think you would be crazy choosing it in 2008. I worked extensively in it about 8 years ago, but it's time has passed.

Like you mentioned, consider using MVC with Python. The separation between business logic and display code is priceless, and I guarantee if you do not clearly break apart these two you will run into huge problems.

Go with Python. PHP is probably the worst language I've had to use (Single namespace, poor unicode...)

Python on the other hand is pretty cool. It can be OO, functional, or procedural depending on how you want to look at it. It also has a lot baked into the standard interpreter and has some really awesome frameworks (Django, Pylons)

Single namespace in PHP - Ouch. You can gracefully get around this with classes perhaps?

Any thoughts on PHP frameworks?

On Python, I've heard that TurboGears is a pretty good framework as well.

I remember reading somewhere that you don't run Django, it runs you. Any fiction in that?

you don't run Django, it runs you

I use Django (GeoDjango actually) at my full-time job, and love it. My progression was PHP -> Python -> TurboGears -> Pylons -> Django. I can say with confidence that it is the best of them all. Yes, many choices have been made for you, but they have been made in an elegant, Pythonic way, and you retain the ability to get under the hood to a healthy extent.

May I ask why you switched from Pylons to Django?

The real reason I switched was because I began working at a newspaper, and Django and journalism are married/fused inextricably. Choosing Pylons over Django in a news endeavor would be rather ... odd.

That aside, I said I progressed from Pylons to Django because I would choose Django if I had to do the Pylons project over again. Why? Because although I rejected (rebelled against?) it at the time, being 'forced' into an ORM for data entities would have been a really good thing. Since Pylons "lets" you shirk an ORM, I did ... but the result feels more like PHP than Python. Turns out Django's hand-holding is, in many cases, good because the answer they provide is the smart thing to do. And doesn't that sound like a description of Python itself?

Would I choose an ORM-ified Pylons experience over Django? Probably not. Django routing seems better, there's Django-enhanced unit testing, and I even prefer the way Django forces you to keep Python out of your templates in favor of "template tags" and "filters".

Perhaps most importantly, Django has nearly-impeccable documentation, and a thriving community.

I have used Django at a well known web company and then at a startup and many other projects.

Django is fantastic, and 'it runs you' would only hold true if you used the basic features and built in admin system and nothing else.

Coming from a Perl background, you would probably be more comfortable with PHP. Definitely checkout the KohanaPHP framework (www.kohanaphp.com) for a solid, well-designed PHP5 MVC framework, With a good framework, you can write very readable and maintainable code.

I come from a Perl background and I'm definitely not more comfortable with PHP, despite having used it quite a bit over the past year or so for our company website, forums, store, etc. Python at least has first-class functions, and I had no problem using it for a few years when I was working in a Python shop (and I still miss IPython which rocks so hard...Devel::REPL is not quite an acceptable substitute). But, I find Ruby the most palatable of the currently trendy languages (though I do almost all of my work in Perl)...I was able to sit down and write working Ruby code with fewer bugs than I can with Perl, and I've been using Perl for 10 years. Python, after three years, I found my bug count was roughly the same as I write in Perl.

I'd have to agree with you. I have a few years of Perl experience and started a bit of PHP to help a buddy out and learn. Writing something that is trivial in Perl gets quite complex in PHP. It's definitely doable, just not as nice as I'd want it to be.

"Any thoughts on PHP frameworks?"

CakePHP is a powerful, popular one. It gives you Ruby/Django's famed MVC in PHP.

Not sure if first class functions matter to you, but last time I checked, PHP didn't have them, which is a major annoyance for me.

I also find PHP to be quite the cognitive overhead. The libraries seem to lack consistent naming conventions and since it's all one global namespace, there are a LOT of names to remember. Coding in PHP often feels like repeatedly looking up library functions and 'assembling' them, rather than 'writing' something.

I loooove Python. But if asked to "bet the farm" on a web app, I'd go with PHP because it's been successfully demonstrated again in again in every form of web app you can imagine. In a year, I'd recommend Python, but I still find Django and the other web frameworks a bit too immature and clunky to do things that PHP has been hacking with for years and years. As much as I hate to say it, for the Python community the web server has been an afterthought until the past two years. PHP was bred there.

I probably would say it's a closer call if we hadn't found a great MVC framework for PHP called Code Igniter that just makes PHP (of all things) much more pleasurable to hack in than it used to be.

All this being said, you're not risking much by going with Python/Django. But if the farm is on the line, I'd personally have to go with LAMPhp.

Code Igniter framework for PHP.

Thanks. I'll take a look at that.

My personal gripe with Code Igniter is that it doesn't have a built-in templating language (this is by design).

I absolutely love Smarty (smarty.net) and highly recommend it and have used it in many projects so far.

There have been attempts to integrate Smarty into CI but I saw a benchmark that showed that combination was unacceptably slow and won't scale well.

Thanks for the link to Smarty. I'm checking it out now.

CodeIgniter seconded. Makes PHP programming a lot easier. Also check out CodeIgniter fork Kohana. I use it to run an advertising network, works really well - ORM and tons of libraries (and of course, being open-source) makes it great.

Yup I have to admit CodeIgniter rocks. Made hacking in PHP worthwhile again.

Python. For a lot of reasons. It's easy. It has a lot of libraries. The Python based CMSs are better. And most importantly it's easier to find decent python programmers. The vast majority of PHP guys I have interviewed ONLY know one language: PHP. The python guys tend to be much more well rounded. Of course the PHP guys are usually cheaper. You get what you pay for in this case. I would also have to recommend against perl. I did perl for 10 years before I switched to python 4 years ago. I think their philosophies say it all: Perl: There's more than one way to do it. Python: There's one obviously right way to do it. Sure, that's a huge generalization but I find it true in a lot of cases. Perl really is line noise compared to Python. And reading someone else's Perl is a real challenge.

I can tell ya that reading and understanding some of my own Perl from even 3 or 4 years ago is a real challenge. ;)

All I can say is that I hope I'm getting better.

Python. It is more powerful with an extremely flat learning curve. In other words, you don't hit many walls with it. When you want to do something more powerful, the answer is 'right there'--it fits the brain.

This is a bit dated but may help: http://www.artima.com/intv/prodperfP.html

Once again, I appreciate the links. Thanks.

Learning curve is flat but with caltrops...

Python has functions as first-class objects, very simple namespaces (files/folders), generators, and a cleaner syntax not to mention a thriving, growing community, much more helpful/intelligent (at least in my experience) than PHP's.

PHP has a lot of coders that are one step about script-copy-pasters.

No questions about it - Python is the way to go.

I spent a lot of time bellyaching about this when starting my company - looking at PHP, Perl (preferred by the devs), and Python (preferred by the advisers I trust).

In the end, we went PHP, and it was hugely lucky - we were able to hire a couple of devs on very short notice because we were in PHP, even though we use a less popular framework called Qcodo. After they were hired, I asked them what they thought, and there was no way they were going to learn a new language to join us, but they were ok learning a new framework.

My feeling is that PHP has the largest base of developers out there, and that means that you've got the biggest base of potential co-workers. If you yourself are a great hacker, you can prop up whoever else you're working with. If you're building an app/business to scale, you have to have other hackers join you.

Hell, Apple has a hard time finding Objective C hackers, and they're Apple.

Another PHP framework: Qcodo. Thanks.

I think, maybe wishfully, that the product will need to scale which means bringing on other hackers to join.

If you're hiring candidates that wouldn't consider learning a new language to join an interesting startup -- well, good luck!

Python. PHP is really good for hacking things out, and there's a case to be made for using Python for the back end programming, and odds-and-sods of PHP to extract data into templates and so on - but fundamentally if you have real code to write, use Python.

PHP ain't bad, but PHP code is fragile. The language, over a year or two, meanders about breaking code willy-nilly, and that alone is good enough reason to steer clear of it for serious applications.

1. Based on content management: PHP. The biggest publishing site on the Web, Wordpress, uses it.

2. Based on libraries: PHP. You have PECL, PEAR, ezComponent, Zend and many others. Whatever you need, it has it.

3. Based on syntax: PHP. It's damn simple.

4. Based on deployment: PHP. It's fast and painless.

5. Based on execution model. PHP. mod_php, as an apache module, works and it’s scalable.

6. Based on frameworks: PHP. Symfony and Zend Framework offer a modular, MVC, loosely-couple architecture. They not only provide a solid infrastructure, but also an extensive component library.

7. Based on performance: Any, as long as you cache everything.

Good luck!

calendar/scheduling/notifications with some social networking and people matching/search functionality. The site will be highly configurable/maintainable by its community from establishing/interacting within groups to tweeking page layouts.

How much of your app can be built by hooking together existing Drupal modules?

If the answer is "lots" -- and because your brief description sounds like a long list of stock parts from the Social Network aisle at Costco, I wouldn't be surprised if it is -- perhaps you should consider Drupal. Which means PHP, alas, but that's a small price to pay for avoiding the annoyance of building every single one of your site's 120,000 proposed features yourself, from scratch.

If the answer is "a lot, except for features X and Y, and I hate Drupal's existing, buggy options for Z" the Drupal community will be really happy to see you develop and contribute open-source code that can do X and Y. And we probably all hate Z, so fix it and you'll be our hero. You'll have plenty of time to work on Z because you won't be spending time redeveloping things like "basic user logins with emailed password reminders", or "users can create and join groups which have their own subsites" from scratch -- yet again -- in a language whose idioms you haven't learned yet.

If the answer is "not much"... may I suggest that you seriously reduce the scope of your first project?

Of course, if the proposed app is less of an actual future product than it is an excuse to broaden your mind by learning a language that's not Perl or Java, you should probably grab onto Python or Ruby with both hands. PHP has many practical features, but it doesn't have much to teach a Perl programmer.

I appreciate the advice.

You know, I sometimes feel as though I'm living under a rock. It pains me to expose my naiveté, but I never really heard of (even the word) Drupal until about a month ago and all of a sudden /bam/ I must've overheard Drupal in conversations at least three or four times since then. I never really put two-and-two together on this one; selective hearing perhaps?

I tell ya, I'm always learnin' something new.

Thanks for opening my eyes.

Don't worry about "Extensive support of libraries and frameworks", you don't need it. All web sites I built, large and small, required only two additional components: the DB glue (typically mysql) and UTF support (mbstring). There may be specific situations when you might want to send https requests or use compression, but that's ok, even that is not called "extensive libraries and frameworks". The bottom line is, a good web site has a clean, simple source that doesn't depend on third-party code that much.

The best advice is try both PHP and Python and choose the one that matches your taste.

http://www.google.co.in/search?q=php+sucks http://www.google.co.in/search?q=python+sucks http://www.google.co.in/search?q=django+sucks

PHP. Why? Because if you ever move your app to a hosted server, you'll have tons of hosting options with PHP. Only a few with Python.

Hopefully, PHP would still be the right choice for me if I then have to move beyond the single hosted server.

That is interesting though; that there does seem to be a ton of hosting options with PHP versus Python.

What are your feelings as a beginner in each language? Have you found any little design decisions that leave you scratching your head, or make you start cursing loudly at the computer? Have you built anything with them? If so, did you run into any issues that you feel were a result of the language?

I'm a bit of a hedonist, but if I were in your situation, I'd probably try to pick the one that was the most fun to work with. As you say, once you've started building, it won't be (or maybe for you it will be?) as easy to switch, and you probably don't want to figure out that you hate coding in whatever you've chosen while trying to finish your web app.

When in a variant of your situation (PHP/a PHP framework versus Python/Django), I chose Python. I'm not you, so we may have totally different tastes and may have come to a different conclusion given the facts. I've been pretty happy with my choice, though.

Thus far, I've built very simple pieces of PHP such as logins, maintaining sessions, writing/reading to/from MySql. My one concern with PHP is the overwhelming "alphabet soup" of functions.

I haven't done anything web-facing with Python just yet, just using it to; parse files, some socket programming - basically getting a feel for the language.

So far, I couldn't say I've run into any issues resulting directly from the languages themselves.

Thanks for the input.

>calendar/scheduling/notifications with some social networking

Why?

More and more web apps are coming out with social networking tied in, and very few of them succeed BECAUSE they have social networking tied in. Socializing a site is a bit more than giving people profile pages and enabling them the ability to "friend" people, at least that's how I look at it.

So my question to you is this: how are you planning to make the social aspect of your site actually work? How are you going to make the ad hoc benefits of social networking replicate to an online presence? Will people actually benefit from socializing, or are they just going to have friends who they will have the extraneous ability to leave comments about?

Wow. Lots of questions. Thanks!

On a plan to make the social aspect work, is there a finite list of ways to choose from? I don't believe there's really only one way. It definitely seems that "social networking" could have a negative effect on my plan yet I hope to do things a little differently.

There will be some socializing benefits.

When I say "how" I don't mean are you going to use OpenSocial or anything like that. I mean when you implement it, how are you going to make it useful?

I don't mean to be coy, but it comes down to giving people something that 1) removes, transfers, or simply defers pain and 2) simply increases happiness.

I would think that's useful in some way to some people at least some of the time.

Language isn't as important as the framework you will use for developing the web app. Have you looked at Django vs. Simfony, etc? Why not consider Ruby and Ruby on Rails?

I tend to choose Python and more specifically Django.

Why don't you do a small prototype in both, and see where each one takes you? I'm not really a programmer, but I've got a dating web app running on around 50 pages of php.

i never used Perl, one of the few languages i havent even tested.

so it has a culture of libraries people say but what kind?

making a lot of really high-quality ones like in python or just spewing out tons of buggy libraries with poor documentation and it is hard to find what you need or something in between?

PHP. So in a year down the road, you won't have to make the switch to it like everyone else has.

Should I read that as a little tongue-in-cheek? :)

Everyone else has switched to PHP? Explain, please.

Why two web servers (thttpd and apache) instead of just one, say lighttpd or nginx?

If I go with PHP, Apache will be running non-threaded.

To run Apache/PHP as lean as possible, I'll take advantage of thttpd's polling to quickly serve up any static content I have to as many simultaneous connections as possible.

I haven't taken a really deep look at lighttpd nor nginx.

I see what you mean though, why would I use two distinctly different http servers where one would simply do?

Could you give me some hints as to what I'm missing out on if I stay with Apache and thttpd or what I'd gain going to either nginx or lighttpd?

Thanks!

Apache buys you two things: rock-solid, time-tested stability, and millions of words of writing both online and in print about administration and tuning.

Lighty and Nginx are both (like thttpd) leaner, potentially faster, and "sexier." Neither has the proven stability or community that Apache does, and neither is going to help much if your bottlenecks are at the application layer, rather than just shooting raw bits over a network cable.

Neither has the proven stability or community that Apache does

I care about the community/support aspect and you're right; I think going solely with Apache, and skipping the leaner httpd engines, is definitely a possible choice for me.

Thanks.

nginx seems to be the "in" server with the Rails crowd.

For some things lighttpd is easier to configure than Apache and if you're running a recent version there are neat things you can do with it's lua support, e.g. http://blog.innerfence.com/2008/05/31/presto-move-content-to...

Apache is probably better for people who want to worry about their app first and their infrastructure second. After your app is under control and you have time to worry about performance and configuration then you may want to look at the others.

Then there's also other servers like Squid and thttpd. If you don't know why you would want one of them then you're probably better off not thinking about them for now. To be honest I don't know what thttpd has going for it these days. A previous company I worked for standardized on it early on and then ended up adding so much to it they would have probably been better going with Apache.

Anyone here have any good reasons to go thttpd?

Or just Apache. Apache serves static content faster than the vast majority of us will ever need, and dynamic content as fast as Lighttpd or nginx, in general (because the slow part is the code in Python, or PHP, or Ruby, or Perl). Run WSGI or mod_fcgid or mod_rails, or whatever, so your interpreter only spawns once, configure Apache appropriately, and you'll be fine for all but the most insane loads.

Why are you determined to use either Python or PHP in this latest project?

I would make sure you have a good answer to that question before using something besides Perl.

I actually know Perl and Java pretty darn well.

I wish to constantly expand my understanding of computing in general, and learning a new language is a great way to go.

I hope to not only learn a new syntax or two but also learn to think in different ways. This works with human languages, too. Yosh!

Ah. Ok, then that makes things easier.

For your case, don't use Python, nor PHP. Both are pretty much just like Perl and Java with only minor syntax changes.

If you want to expand your understanding of computing in general, while also learning a new language, and while doing a webapp, if I were you I'd learn Common Lisp and try out Hunchentoot. There's even some screencasts for that setup floating around.

Going with Python or PHP after Perl and Java is not going to be terribly enlightening for you.

Thanks for the advice.

I've also been learning Lisp (sbcl) over the last six months and have tried out Hunchentoot with elephant, cl-who, and parenscript.

I'd say one of the things keeping me from going with Lisp is the potential pool of developers to pick from when expanding the operation. I think I would have a better chance at enlisting others with PHP or Python than with Common Lisp. Is this line of thinking wrong?

python

Excellent discussion by some obviously very experienced and intelligent people. I haven't used Perl too much, I'm much more experienced in Python and PHP, but I think all are capable languages.

I think the most important things to consider are things that you can't really relate effectively to a forum discussion like this and that is what your real skill levels at each of these languages is and the availability of skill in your area and network of friends.

I would lean more to those factors for making the final decision because it makes no matter that python might have wome extremely elegant and powerful syntax or library for coding a specific functionality if nobody working on the project is familiar enough with the language know the syntax or the library.

The primary investment in any new app like this is "developer time". Managing that resource requires the juggling of many more factors than the capabilities of any given language.

Ruby

Slow

Python, It is more responsive than php.

By more responsive, you mean from rendering the html/css/js sent back to the browser? Or more responsive when connecting to the back-end MySql database?

If you could elaborate, I'd appreciate it. Thanks!

Reply on news.ycombinator.com