Why PHP Is Fun and Easy But Python Is Marriage Material

http://onstartups.com/tabid/3339/bid/20493/Why-PHP-Is-Fun-and-Easy-But-Python-Is-Marriage-Material.aspx

by jasonlbaptiste • 16 years ago

106 64 16 years ago

onstartups.com

pmarin• 16 years ago

You have it doble posted: http://news.ycombinator.com/item?id=1840444

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

jasonlbaptiste• 16 years ago

WHOA, how'd that happen? pg ?

udfalkso• 16 years ago

Great title.

ryanwaggoner• 16 years ago

Some languages, like PHP, have very low learning curves — it’s super-easy to get started. And, that’s awesome. It’s easy-going, fun, and you feel super-productive (especially if you’re making a big change to something new). But, once you get past that initial dating period, you need to think about your future. You want to forge a relationship with a language that will be long-lasting, rich and deep. A language that brings the best out in you — over the long-term...Since I'm going to get into a long-term relationship with a language, I figured Python's a pretty good bet.

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.

Goladus2• 16 years ago

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)

fiveo2• 16 years ago

I was able to learn Python in 2 weeks (lazily) using just Byte of Python. Of course I can't build something clean and "Pythonic" with that kind of knowledge, but I managed to build a simple CRUD selling books online app using SQLAlchemy, CherryPy, and Genshi in 4 days (I need to build something for a scheduled interview).

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

RyanMcGreal• 16 years ago

Python is the piano of programming languages. Anyone can sit down and bang out "Three Blind Mice" within a few minutes; but a skilled professional can use the same instrument to perform Rach 3.

Yaggo3• 16 years ago

Python has nice, clean syntax and pretty elegant semantic, which translates as gentle learning curve. However, if your first language (prior Python) was something less elegant, say PHP, your mind may be too polluted to painlessly adopt all the Python elegance.

forgotAgain• 16 years ago

While I agree with the conclusion that the design of Python will over time make it the more productive language for development I don't agree with the importance given to Django.

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.

SoftwareMaven• 16 years ago

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.

avdempsey2• 16 years ago

I liked this line: "Though Ruby/Rails would likely have been fine too, there’s something about it that I just found unnatural. If I had a dog, the dog would bark at the Ruby code."

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.

ScottBurson• 16 years ago

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.

paradoja• 16 years ago

The «?» ending is common in (at least some implementations/variants of) Scheme.

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

seiji• 16 years ago

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)

avdempsey2• 16 years ago

True, not having parens on the end of the function call makes this look better (and those parens are optional in Ruby). Extra kudos to lisp flavors because you could argue they have even "purer" syntax than Python.

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

draegtun• 16 years ago

Hyphens in function names are great too

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 :(

jamesbritt2• 16 years ago

I'd get rid of the dog.

citricsquid• 16 years ago

So a few people said that PHP will die in the next few years because of things like Ruby and Python becoming better and better, does anyone here feel the same? I argued that PHP has such a low barrier to entry and is so accessible that I don't think it'll happen -- at least not to Ruby/Python -- anyone agree/disagree?

dshah• 16 years ago

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.

okaramian• 16 years ago

Exactly, legacy code isn't going anywhere. If you keep your eyes open you'll see plenty of Classic ASP around. It's a lot of investment to refactor an application from one language to another, and it's a waste of time from a business perspective if "stuff works".

jamesbritt2• 16 years ago

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.

michaelchisari3• 16 years ago

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.

mechanical_fish2• 16 years ago

the language has been improved to the point where most of the issues people have with it are aesthetic

Now, let's not go too far.

Goladus2• 16 years ago

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.

jacquesm• 16 years ago

If you are comparing programming languages and marriage then here is my advice: Stay Single.

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

cookiecaper2• 16 years ago

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.

ErrantX• 16 years ago

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.

jpeterson• 16 years ago

In Python land, the clear web framework winner is Django.

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

jamongkad• 16 years ago

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

mhd• 16 years ago

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.

sliverstorm• 16 years ago

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.

cookiecaper2• 16 years ago

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.

zeemonkee• 16 years ago

I find Django slightly unusual compared to other frameworks in that it has many CMS like qualities, such as predefined user/permission models and the admin (not surprising, given its origins). Rails, Pylons, CodeIgniter, etc. provide you with an ORM, but it's up to you to define your schemas.

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.

rick8883• 16 years ago

"The learning curve these days is not a new language (it takes a proficient programmer just a few days to get her arms around the basics of a new language). The learning curve is with the framework."

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.

commanda• 16 years ago

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.

terryjsmith• 16 years ago

jQuery is nice because you can jump back and forth between it and "regular" Javascript. Inside your $(id).click() function you can just as easily call document.getElementById. jQuery even provides you access to all of the DOM level objects in case you want to escape outside of it for a bit.

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.

dinkumthinkum• 16 years ago

Well, one major reason to use jQuery, besides all of the cool APIs, is that it encapsulates most of that messy browser specific stuff you have to account for which is not that analogous to what you have to do with most programming languages.

rick8883• 16 years ago

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

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

dasil003• 16 years ago

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

blacksmythe• 16 years ago

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

j_baker• 16 years ago

To be fair, a couple of classes domake necessarily make a framework: http://en.wikipedia.org/wiki/Hollywood_Principle

rick8883• 16 years ago

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

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.

silvertab• 16 years ago

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

brendoncrawford• 16 years ago

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

mgkimsal• 16 years ago

"with a well-known framework you have thousands of other developers available to help you if you should run into a problem"

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.

wenbert3• 16 years ago

I think PHP's strength is coming from the large amount of web hosting companies offering it. It seems to be the "default" they offer, along with MySQL. Also, those hosting providers are so cheap that for some it is the only choice that they have (including myself).

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.

Yaggo3• 16 years ago

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.

wenbert3• 16 years ago

I still can't afford $20/month. :-| That is almost the same amount I pay for my hosting for the whole year.

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

billybob• 16 years ago

Point #5 did a good job of addressing a debate we see here sometimes: "Language X serves our company well, but picky developers don't want to work for us because we use it" vs "I want to work in a job that uses Language Y because it's better." I think it's worth quoting:

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.

bergie• 16 years ago

The biggest issue with PHP doesn't really have anything to do with the language itself: there is a serious lack of ecosystem. Instead of sharing modules and libraries, every project seems to form an isolated environment where code from any other project is shunned. I've been thinking about ways to solve this, as the PEAR effort never really took off.

Why PHP Is Fun and Easy But Python Is Marriage Material

Related Stories