Don't get too hung up on any one language or framework. Stay flexible and hold the door open to something new and better if it should come along.

Even python - without a doubt a more elegant better designed language than php - has its shortcomings.

And php, for all its shortcomings has its clever bits too (except, that it didn't so much as go through a design phase as it went through growth out of necessity).

From that context, the headline makes better sense -- you are not necessarily considering Python as the only tool in your toolbox, but as something that is worth taking home and making a life with, i.e., using Python as a mainstay in your professional life.

Python, like all programming languages, has its shortcomings, you are right. But potential wi(fe|ves) have shortcomings too -- in this mortal sphere, nothing is perfect, but we can't let that paralyze us.

All the language wars make me smile; rather than complain about the shortcoming of X, just use Y to solve "that" problem.

This is my main problem with this line of thinking. Developers aren't actually developing anymore. They are mashing together frameworks.

I've looked into frameworks like Django. It's not good because it abstracts away the functionality of the database. It's nice that everything is an object, but if you want to do something more complex and go around the framework, things get messy and start to feel hackish.

I am a PHP developer and I generally don't use a PHP framework. I have my own set of classes that I wrote (and improve on). I have also used the smarty template engine in the past, which works really well for keeping HTML separated from the actual code (and it has built-in caching). Jquery is also great for the front-end.

I started development with pascal, then moved to c/c++, and finally PHP. I like PHP because it is a high-level enough language that makes development easy, yet it's still powerful enough to allow for complexity and lower-level functionality. The c-style syntax doesn't hurt either.

PHP 4 and below had many security issues (what were they thinking with register_globals?), but 5.1+ has made some major changes.

In my experience, the time it takes to become proficient with an existing framework is generally a lot shorter than writing a framework yourself. And, generally, the existing one will have been vetted by thousands of people before me.

I use it sparingly. Mostly because there are many quirks between the various browsers and jquery seems to have a pretty good handle on it. As an example: rather than using one of the many bloated pagination libraries I found based on Jquery, I rolled my own in less code. It ended up much smaller because I didn't have to incorporate everything in the existing libraries. Most frameworks throw in everything, because they have to account for all possibilities, rather than just the ones that you need. You end up with bloated code, unless you know how it works behind the scenes (and many times even if you do, you can't take out the parts that you don't need).

Most frameworks do not let you do this and you have to actually have to work at it/hack at it to use functionality that isn't provided by them.

I was thinking the same when I first worked with frameworks (Rails at first, Django now...). First there was the honeymoon phase, where it seems like the framework does everything you need... then you start to encounter the first problems (i.e. try to do something thats a bit more complex...), and you start thinking; Well, the framework does everything for you 90% of the time, but the 10% when it doesn't makes up for the time you saved...

But I found that after working with a framework for a while (almost 2 years with Django in my case) you get to know its strength and its weakness, and you get to do more complex stuff a lot more easily (for example, I often resort to raw SQL with Django, it's just a matter of doing Model.objects.raw() ). In the end, I think it's worth working with a framework because well, obviously it prevents you from having to re-write boring boilerplate/glue code, but it also (usually, or perhaps I should say, hopefully) means you are working with a well-tested codebase on which to build up on. In my case, I would say the time it took me to really learn how to work with Django was worth it today, if only for the time it makes me save now!...

Usually you have one framework and then you mash together a bunch of libraries. The framework exists as a way to abstract the most common functionality of your chosen platform. A good framework eliminates a lot of boilerplate without getting in your way when you need to go beyond the common functionality.

The ironic thing about your post is that PHP itself has a bit of a nascent framework quality to it. It was developed before web frameworks of course, at a time when everyone was writing Perl CGI scripts using a bunch of libraries. The revolutionary aspect of PHP and mod_php in particular, was that it had automatic hooks into all the common aspects of the HTTP cycle, including the page metaphor, which meant you could change a static page into a dynamic page with no effort. PHP was state of the art when websites were mostly still just pages. Serious programmers laughed of course, how could you build a serious application in this glorified templating language? So they continued to develop their "proper" frameworks like Struts, Zope and countless others rooted in the experience of GUI developers from ages past.

However as web development experience and understanding matured, there was a widening gap between PHP and the enterprise frameworks. And this gap is squarely where Rails was dropped in 2004. There are so many things that are common to all web applications that PHP doesn't handle. DHH's brilliance was not so much in the details of the original Rails code, but in picking and choosing best practices and unifying them in one package in a minimal way. I think this was instrumental in web framework developers from all languages re-evaluating what was really necessary and what cruft could be eliminated.

Nowadays Rails is pretty enterprisey in capability, but it still avoids most of the overhead present in enterprise frameworks of 10 years ago. The minimalist torch has been carried forward by upstarts such as Merb and now Sinatra.

The strength of these various frameworks is that they do things that tens of thousands of developers need to do every day in a standardized way that's had massive input and refinement over time. When you use these frameworks you can hire people and they hit the ground running. When you use your own personal library then every new developer has to get up to speed on your dime, and you foot the bill of maintenance yourself rather than gaining the advantage of a large open-source community.

  >> I generally don't use a PHP framework. I have my own set of classes that I wrote (and improve on).

In a way, yes. It's a boiler plate of classes that I use for most projects (db, sessions, and some other helpful funcs that I built).

If I could take out all of the crap that I don't need that is usually in most frameworks, I might consider using one.

> I've looked into frameworks like Django. It's not good because it abstracts away the functionality of the database.

The Django ORM is no more or less easy to do your own queries as CakePHP, Propel, Doctrine, Hibernate, or SQLAlchemy:

  blogs = Blog.objects.raw('SELECT * FROM myapp_blog')

Not always true - I'd say often not true.

1. I have to learn where to get support from these thousands of other developers.

2. I have to read through dozens of posts from others asking the same questions I have, but often phrased inconsistently.

3. I have to figure out which answers are correct, and which are wrong, and which were correct 2 years ago, but aren't right currently because 2 libraries are now deprecated.

4. I have to learn enough about the framework to be able to formulate coherent questions using the proper terms and express my specific problem.

5. I have to deal with 0 people responding after 4 days of posting.

6. I have to deal with responses just being "me too".

7. I have to deal with responses being "RTFM" or "LMGTFY".

8. I have to deal with well-intentioned people who ask me for help replicating my setup in their environment so they can help me.

And there's likely more variations I could think of that make the magic "there's thousands of developers to help" argument null and void in many situations.

I started out as a PHP programmer and have loved it over the last few years, but after spending the last couple months playing with Python, this is exactly how I feel.

I'm not sure if I can do the same with PHP and some of the PHP libraries (like, for an example, using Smarty, PHP, and a whatever-lightweight-ORM in PHP).

Not to pick on you in particular, but comments like this are a pet peeve of mine. While Python is easy to learn, and most languages are, but even if I'd built a little application in Python as you had, and knowing what I know already, I still wouldn't say I know Python.

Maybe I'm the exception to the rule, maybe my definition of knowing a language is much more strict then most, but I really don't think you can learn a language, any language, in 2 weeks.

I've done apps in Java, C, C++, Python, Perl, PHP, and even Obj-C now. Real working apps that do things, but I'd feel very uncomfortable claiming to know all those languages.

Oh, I know the syntax. Basic syntax is easy for any language (with my vast knowledge of C-style syntax languages providing a good basis for this assumption =)). But really knowing a language? Being able to create an application from scratch? I mean, really knowing, not just hacking together stuff you find from tutorials on line and running to SO whenever something happens a Google search doesn't solve.

I fully realise that my standards might be a bit to high. I just don't know by how much? Am I really just not giving myself enough credit, or am I reading too much into this?

Edit: fiveo, I'm not focusing this at you, obviously. This is merely a general observation. =)

But the point that I'm trying to make is that it's so much easier to learn and build something using Python, even if it's not top notch or following best-practice/patterns or trying to be Pythonic all the way.

Of course this is not sufficient knowledge in the long term.

While I have been learning Python for over a month now, I still do not have a server to run my stuff on. I run it on my local machine but it feels different when you have it "out there".

After a month of looking at and learning Python, I fell in love with it. Bottom line, if web hosting companies offer Python as one their "default" installations, then I would directly jump right in.

Python is nice because it has great web frameworks available - and at the same time, I can use it as tools to parse my huge CSV files (and other tasks) while I'm offline.

Python is a very "comfortable" language to learn - I never had that feeling when I tried to learn Ruby.

http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts

If your needs are more exotic, you can buy a VPS for $20 per month.

FYI, I live in the Philippines. If get a Linode, I will not be able to afford to pay for my internet connection hehe

I am however planning to get a VPS though. I'll find a way :P

Or deploy your apps on Google App Engine! It's free (within the free quota), supports WSGI apps, so you can run Django-nonrel, Tornado, Flask, Pylon, Tipfy, or whatever your favorite Python web stack is.

Google App Engine sounds good. I will give it a spin as soon as I can... Appreciate the response :)

Is this really true? Personally, I prefer Pylons by a large margin.

That's true for big full stack frameworks, where most of the contenders disappeared. Real competition seems to happen mostly in the mini framework area, due to people being forced to ditch more and more parts of their full stacks and wondering why they couldn't instead build upon a small platform. Flask is gaining traction here.

And then there's app engine, where things run a bit differently, and forcing django et al on top of it can feel a bit unnatural. Tipfy seems to be en vogue there.

In Python country, you always had quite a number of projects that ran outside the mainstream, though. Tornado, cherrypy, web.py, web2py etc.

That said, I have recently been tinkering with a Satchmo cart. I am under the impression that Django apps that utilize the Django backends can be converted into plugins for other Django apps with trivial or near-trivial effort, and that gives Django-based applications a lot of power, because if both Satchmo and some Django-based forum use the Django admin and user database, I can plug in or replace forums really easily without creating a bunch of extra overhead for my users. That is very appealing to me, and the first reasonable use of a "big" framework (like Django, Rails, or Cake) as far as I am concerned. It has encouraged me to explore Django/Pinax more thoroughly.

Not that this is necessarily a bad thing - it can save a lot of time in certain projects. Sometimes though it's overkill for projects that don't need these features.

So I'm glad that Django isn't the one and only framework in Python, as it's good to have a choice. Multiple frameworks also mean competition and more ideas and approaches, which benefit everyone.

Never heard of Pylons.

That's how I felt when I started learning Ruby after years and years of Python. Ruby has method names with question marks in them...my dog would bark at that.

In Common Lisp and other Lisps, on the other hand you'll usually see «-p» instead of the «?».

  (member? 'a some_list)
  member?('a', some_list)  <-- ugly
  member? :a, some_list

  (check-user-credentials session user)
  (is-user-authorized? page user)

Mostly, I'm just tickled by the idea of "would my dog bark at it?" as a mental test.

Totally agree and there are good reasons why they are useful: http://news.ycombinator.com/item?id=1842575

BTW, While perl6 added hyphen usage to variable names :) unfortunately I don't think it added question mark :(

:)

The install density is way too high, the language has been improved to the point where most of the issues people have with it are aesthetic, and there are a good amount of solid development frameworks out there to fill in any gaps.

I think anyone who says PHP will die anytime soon is engaging in simple wishful thinking.

Now, let's not go too far.

But I'll try to sum up: PHP was designed as a minimalist, procedural language designed to help occasional programmers write interpreted scripts that run in brief, efficient bursts to generate responses to HTTP requests in a classic CRUD-app context. It's designed to be the perfect language for someone who wants to embed code in a set of HTML templates, upload them to the server, and test them by clicking around and making sure the pages look right.

These are PHP's great strengths, and the reason why it isn't going anywhere. But they are also its weaknesses. Attempts to drag PHP too far out of its sweet spot get gradually more painful until you start to cry and switch to something else.

Today PHP makes me cry because Ruby is so, so much easier to test. Tomorrow there will be a different reason to cry.

I have experience with both PHP and Ruby, by the way, and am lead developer for a very large open source application built in PHP, used mostly for pragmatic reasons, but I am interested in hearing what language features people feel PHP is missing.

I just had to virtualize multi-threading in PHP with pforks and shared memory.

Among the people I know who are primarily Ruby devs I find some number who are looking at Haskell, Clojure, and JavaScript, and some may just move from Ruby to language X.

Among the PHP people I know, some have an interest in Ruby, but few seem inclined to make the switch. Same goes for ASP/.net devs I know.

And, overall, I get the sense there are more PHP developers than Rubyists (at least in my part of the world).

I gave an intro Ruby class at a recent CodeCamp, and attendance was much lower than similar presentations I've given in previous years. (My intro Haskell presentation had more people.)

All this is anecdotal, but PHP seems to work really well for solving enough problems for enough people. We can dismiss these people as lacking sophistication or 1337-ness but apparently they are quite happy, and there's something to be said for that.

I find that more view effort is being placed in browser code (JavaScript) and the back end is becoming less presentation oriented. Therefore the need for a framework like Django is diminishing.

Lets say you’re something like me: You’ve learned PHP and used it to build and launch “real world” apps. For you, the cost of change is high (maybe even prohibitively high). Really hard to justify the change, because though you might grudgingly admit that Python is better, it’s not better enough to warrant switching. You’ve got a startup to grow, you can’t be bothered with trying to join the cool kids.

But, I’m to advocate for some empathy here. Lets say you were on the outside looking in (i.e. you’re a gifted developer looking to join a cool new startup). Since you’re really good, and demand for great developers always exceeds supply, you essentially get to pick where you want to work. All things being equal, you’re going to pick the place that is doing Python vs. PHP. Of course, not all things are equal, and you might actually pick the startup whose business you think has the best chances of success or whose founders you like and respect. But, often, it’s hard to know that stuff upfront, so you focus on what you do know — that developing in Python’s a better “bet”. I wouldn’t fault people for solving for their self-interest and preference. They’re not trying to talk you into switching, they’re just saying that it matters to them.

http://news.ycombinator.com/item?id=1840442