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.

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.

GMail - Not Python

AdSense - Not Python

GMaps - Not Python

Search - Not Python

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.

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.

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 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?

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.

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.)

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.

$ 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.

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

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

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.

Not really:

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

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){ ... }

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

Thanks for that lil' tidbit.

    @{$h{$k}}

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

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.

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}

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

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

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

I appreciate your thoughts.

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.

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.

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.

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.

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.

Best of luck to you.

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

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)

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?

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.

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.

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 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.

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

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.

Thanks. I'll take a look at that.

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.

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

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

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.

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

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

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

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.

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!

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.

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.

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

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

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.

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.

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?

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.

I tend to choose Python and more specifically Django.

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?

Everyone else has switched to PHP? Explain, please.

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!

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.

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.

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?

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!

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.

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?

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.

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