Why PHP Is Fun and Easy But Python Is Marriage Material

I don't think that the analogy has to be considered in the context of a monogamous relationship. Marriage has not always been monogamous -- in fact, almost exclusively in the Western Christian tradition has marriage been considered exclusively monogamous, most other cultures have allowed polygamous marriages.

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.

Amen. I started on PHP and still use/love it. Got into python for an entirely separate reason and still use/love it. Learned C then C++ for university, still use/love it. Picked Ruby up on a whim about 8 months ago... well, you guessed it.

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

You say you don't believe that mashing together frameworks is actual development, yet you recommend the jQuery framework for front-end coding. Do you draw a distinction between front-end and back-end - is front-end work not really development?

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.

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

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 other words you have written your own framework that suits you well. I would guess the only thing that stops this from being a general purpose framework is documentation and marketing.

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

Ah yes, the inevitable "I write my own framework" post. This completely overlooks the fact that with a well-known framework you have thousands of other developers available to help you if you should run into a problem. It also overlooks the value of not re-inventing the wheel.

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

I think it's interesting that in the grand scheme of languages, Python has one of the gentlest learning curves. (I'd say as a general-purpose language rather than a web language, it's even gentler than PHP)

There are plenty of Django-friendly hosts available with easy deployment options:

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

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

I rock it old school and still prefer web.py over anything.

For the big stack frameworks, it's quite major. As he said, without the sheer market share that Rails has for Ruby…

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.

Well, let me just comment that I don't know a single line of Python, and yet I know what Django is (loosely) and have heard of it a lot.

Never heard of Pylons.

I have used Pylons extensively, but not Django. I really prefer Pylons's packaging and methodology. Django seems more like a "classical" web framework where everything is included and much has been reinvented. Since my exploration in programming is often a matter of personal taste (i.e., not forced by employer to learn something very often), I have not really spent much time with Django as that style of framework does not mesh with my preferences.

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.

Your dog obviously doesn't know Lisp :) Lisp allows any characters in a name (although some characters need to be escaped). So for example, I have a class called "2-relation" (because I thought "binary-relation" was too long). The use of dashes in names is routine in Lisp; names beginning with digits are not so common, but are perfectly legal. And yes, though it's not the traditional style, some Lispers (including me) end the names of predicates (boolean-valued functions) with question marks.

I prefer free form function names when when parenthesis aren't required after the function name. Hyphens in function names are great too.

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

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

I'd get rid of the dog.

:)

I don't think PHP will die in the next few years. For the same reason that C++ (and for that matter, even COBOL) haven't really died. There are enough people that need it kept alive that it will keep going for a while.

PHP die? Unlikely.

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.

Not when there's so many major open source projects written in PHP (Joomla, Drupal, Wordpress, etc), and PHP support comes standard in every shared hosting environment out there.

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.

Disagree, Python and Ruby have no better chance of killing PHP than they have of killing Perl. Neither language offers enough benefits to cause such a massive shift.

I disagree, though my use has changed. I recently worked on an app that only had a couple of views; almost everything else was handled by exposing APIs via Piston (which were consumed via jquery). Still, the value of the other features of the framework made it work using in the project.

WHOA, how'd that happen? pg ?