Joe Stump: Why I switched from PHP to Python

http://www.joestump.net/2009/09/why-i-switched-from-php-to-python.html

by dannyr • 17 years ago

92 95 17 years ago

sophacles3• 17 years ago

Hah, just be careful, having to go back the other way is kinda painful. I keep a file for myself called pythonisms.php in it i define a few functions that let me continue to think in ways I've come to love in python. One example, the get function. It takes 3 arguments, and works like python's dict.get(). I seriously have no idea how I did php without it.

zokier• 17 years ago

Does one really need to explain why he switched from PHP to anything?

sophacles3• 17 years ago

This sort of thing is still needed. I have a friend who's boss wont let him use anything except c, php, and perl. Any attempts to get python in there are met with resistance and vague hysteria. More posts like these from can slowly lower people's loyalty to php, and contribute to saving my friend and many like him.

igorgue• 17 years ago

Well, I'm actually in the same problem, but I inject Python every time I can, because is not the same saying:

"Can I do this in Python?"

than

"I already did this in Python!"

jrockway5• 17 years ago

Well, is Perl really a problem? Anything you can do in Python you can do in Perl just as easily; Perl actually has more abstractions available for the programmer than Python. (Grammars in regexes, real closures, coroutines, a metaobject system, etc.)

Also, last time I checked the programming language shootout, Perl 5.10 is slightly faster than Python 3.

So with that in mind, the logical "step up" from Perl would be something like Haskell. Python is pretty much Perl with different syntax, less features, and the impression that it's "cleaner" because nobody ever bothered using it for "quick and dirty" scripting.

ojbyrne2• 17 years ago

It's all about the self-promotion. Joe works hard to get his image out there.

quizbiz• 17 years ago

I still don't understand why php is so frowned upon here. Easy and quick implementation and a low learning curve.

jamongkad4• 17 years ago

Speaking as someone who is tangled in a love triangle between Python and PHP. I do agree that PHP does have it's strengths. For the programmer just making a living, it's quite ok to etch out just using it.

In terms of web applications, what you can accomplish in PHP you can pretty much do in Python. But the difference comes in when you do "care" about the tools you're using.

When you want that extra power. When you want something sane to work with.

Python and friends give provide that for you.

I do love PHP, it's deployment is a snap and the frameworks we have now are kick ass. But Python is such a joy to work with it. And the longer I work with it, it gets harder to come back to PHP.

nostrademons4• 17 years ago

There's a complexity ceiling that you hit fairly quickly in PHP. Since there's no consistency in any of the libraries, you have to cram a massive amount of information into your head (or sit there with the reference manual open and look up every function call). If you're doing a quick one-week project, PHP is probably the tool of choice, but there's a large middle ground where PHP apps become way too spaghetti-ish and yet you don't want to shell out the upfront cost for a C++ or Java webapp.

code_duck• 17 years ago

Didn't the article just explain that?

I use PHP every day, but have grown a bit tired of the lack of sophistication inherent in the language. The huge flat namespace, the inconsistent design of the standard library, the absence of advanced language features (functions aren't even a first class data member), and so on.

electronslave3• 17 years ago

As a former academic gone mercenary, I love that programmers of all skill levels can get into organization, language and specification through Python. It's a wonderful gateway to learning, and in this case, it seems to have done exactly what Python was specified to do!

For my own projects, I've used pretty much all the fad languages from BASIC to Pascal to C. I've used industry-adopted languages like Tcl, Java and Perl. I've experimented with Lisp and Erlang.

After all is said and done, I like Python/Cython/C. It gives me the option to use a glue language for the Windows programming I've done, which is perfect. It gives me a compiled (albeit ctypes-restricted) subset language for writing hashing/storage/whatever functions. It gives me a super-awesome library set that comes built-in.

I know it'll go away someday, but I'm glad to have worked in Python for as long as I have.

timwiseman2• 17 years ago

I know it'll go away someday,

Aside from the obvious that just about everything will go away someday, is there a reason you believe this?

From my vantage point (albiet limited) python looks like it has staying power. It is easy to use, effecient enough (and with unladen swallow in development it may get a lot more effecient soon), and currently seems to be gaining ground instead of losing. Eventually I am sure that it and any other language you can possibly name will get supplanted, but I am not aware of any particular reason to expect that any time remotely soon.

electronslave3• 17 years ago

From my vantage point

I might have dated myself above by mentioning Tcl and Pascal, but I've been programming for a few decades. Without ruining the cosmic punchline: all things go away surprisingly fast.

kragen3• 17 years ago

is there a reason you believe this?

http://en.wikipedia.org/wiki/Anicca

python looks like it has staying power

So did the Roman Empire, JOVIAL, FORTH, and PL/1.

aristus2• 17 years ago

Python is remarkable for having a dozen or so major language features disallowed by fiat (removal of the GIL, unrestricted anonymous functions, TCO, braces) but still being extremely powerful, expressive, and used by programmers of all skill levels.

It's difficult to be obscure in Python. Yet if I really need to do something jinky like remapping an outside library's methods, I can do it with a few lines of slightly-uglier code. That's a very hard balance to make.

Good design involves a lot of "no". I don't think languages are an exception.

chromatic• 17 years ago

> It's difficult to be obscure in Python.

It's occasionally difficult to be obscure with Python syntax. It's not at all difficult to be obscure with anything in Python above that level. Even then, if you do weird things with metaclasses or decorators, it's easy to be obscure with Python.

jnoller• 17 years ago

Minor correction. The removal of the GIL is not disallowed by fiat. The removal of the GIL was attempted (via granular locking) and destroyed single threaded performance. That's unacceptable for a variety of reasons. In the same thread, Guido has repeatedly stated that the GIL was a tradeoff, and he would welcome anything that helped lessen it's impact/remove it should it be proven not to significantly harm Python's primary function.

If someone showed up with a patch tomorrow which allowed free threading without seriously breaking python, or crippling single threaded performance, or making extension modules impossible to write, I could very well see it getting in. In reality, doing this requires a serious reworking of the interpreter (ala unladen swallow) to make it even feasible. There's a lot of things the GIL actually helps, for example the ease of writing c-based extension module, unfortunately they come with a price.

The price is/was seen as an acceptable tradeoff, and I think it has served it well, even if if it disappeared tomorrow no one would shed a tear.

Also, braces aren't a feature :p

hristov2• 17 years ago

You must be old. Basic hasn't been a fad since the 80s.

gaius4• 17 years ago

I assume he means VB(.NET).

abdulhaq• 17 years ago

BASIC was never a 'fad' - it was frequently all you had (other than machine code). Remember, no internet, no CDs, even no modems for the vast unwashed such as myself - just a tape deck, 16K ROM and a TV.

The first language where I got to choose it was Lisp for the Sinclair QL, ~ 1985.

PonyGumbo• 17 years ago

You must have an interesting definition of 'old'.

steveklabnik4• 17 years ago

While Python is a great language, aren't "Things Guido doesn't like aren't supported at the language level" and "Python treats developers as adults" sort of at odds?

  * TCO is dangerous and hard, let's not support it in the language
  * ++ is ugly, let's not support it in the language
  * Assignment during comparison leads to bugs, let's not support it in the language
  * Python gives you more than enough rope to hang yourself, but at least hanging yourself is an option.

One of these things is not like the others.

msie• 17 years ago

I don't like assignment during comparison either. I do like TCO and ++.

steveklabnik4• 17 years ago

I _love_ assignment during comparison. shrug

I coded too much in C. I like all four!

ojbyrne2• 17 years ago

The particular comment about not enforcing private vs. protected reminded me of php4. People bitched and moaned about it.

hristov2• 17 years ago

I wonder why supporting TCO or not has anything to do with the language. I mean isnt it up to the compiler or interpreter? If a compiler can get the same final results with TCO, then why shouldn't it? And the definition of a language should not define how a compiler works internally only what the actual effect of the language instructions should be. Compiler writers should be free to do what they want to realize the defined effect.

BTW as someone that moved from Pascal to C and C++, I can appreciate the ugliness of a lot of C shorthand syntax. It is confusing and can cause a lot of bizarre and hard to catch bugs.

gaius4• 17 years ago

That's true; Guido only says that TCO isn't going to be written into the Python you download at python.org.

steveklabnik4• 17 years ago

As Guido says, TCO is not an optimzation, it's a language feature. Here's his reason, which I think is pretty sound:

"Second, the idea that TRE is merely an optimization, which each Python implementation can choose to implement or not, is wrong. Once tail recursion elimination exists, developers will start writing code that depends on it, and their code won't run on implementations that don't provide it: a typical Python implementation allows 1000 recursions, which is plenty for non-recursively written code and for code that recurses to traverse, for example, a typical parse tree, but not enough for a recursively written loop over a large list." - http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...

nostrademons4• 17 years ago

The problem with TCO is that it makes it impossible to get accurate stack traces for a function. If you optimize away the stack frame, there's no way to tell the user "this is what was running when the error occurred." You get odd behavior where a function may appear to call another function which never appears in its program text, because the intervening stack frame has been optimized away.

Stack traces are part of the Python language (besides looking pretty, the traceback module lets you inspect them), so it'd be really hard for a conforming implementation to include TCO - at least the type that actually has tail recursion run in constant space.

Java faces a similar problem with HotSpot's inlining, which is why you occasionally get <compiled code> in a Java stack trace instead a line and file number. They seem to have some hack in to avoid eliding the stack frame entirely though. This is probably what I'd do if I were designing language: push a bare-bones stack frame with just the debug info, but pop all the unused temporary working storage. Or punt on general TCO and just optimize tail-recursion - isn't that what Python was proposing to do with the @tailcall decorator anyway?

The languages I know of with TCO - gcc and Scheme - have really terrible debugging support. IMNSHO, I think that giving up debugging info for TCO is a poor tradeoff.

lux2• 17 years ago

You have no idea how much I wish I could do this. Just testing my code from PHP 5.2 to 5.3 and there are several serious problems now that I get to find workarounds for, all while maintaining backward compatibility too.

How is it that a minor upgrade changes functions and their behaviour so much that it breaks existing PHP5-compatible code? WTF is wrong with the PHP developers?

If I didn't have so much code (whole product with contracts to support) invested in PHP, I would switch in a heartbeat and never look back.

Maascamp• 17 years ago

Python 2.x -> Python 3 Ruby 1.8 -> Ruby 1.9

Do you actually know anything about languages other than PHP and want to change for legitimate reasons? Or are you just jumping on the bandwagon because it sounds cool?

lux2• 17 years ago

I'm perfectly aware 1.8 to 1.9 was a pretty big move for Ruby folks (maybe could've been called 2.0?), and 2.x to 3 in Python, that's the time for big changes. I've also written real production software in about half a dozen languages, so yes I do. I just happen to have a codebase of 100,000+ loc in PHP that I support, so I'm kinda heavily invested in it more than the others.

It sucked trying to rework so much PHP4 code for PHP5 while keeping b/c, since that felt like the slowest community migration to a new version I've ever seen... But it seems like each additional release from PHP changes and breaks something else. My codebase is older than many, so it's possible that's made it a bit more brittle over time, but things like completely changing the allowed characters in .ini file keys from 5.2 to 5.3 I find baffling. Yes, speed things up or improve things, but consider that existing liberties you've allowed may come to be relied on by your users. If you let them do something in 5.2, make sure they can still do it in 5.3. I'm always careful myself to make sure existing code will continue to work, and new features are offered as optional or via new APIs. Code from 3.x of my software continues to run fine on 5.x as a result, which lowers my support burdens.

So again, no I'm not just fanboying for other languages or falling for the "grass is always greener" line of thinking. PHP just has certain inelegant things that I find add to my overall frustration over time. I value terseness, so things like -> versus . for objects adds up, just like $ versus nothing for variables wears at the wrists too. I value consistency, so not remembering which parameter goes first for in_array() versus strpos(), or why the differences in naming add up too. Those are minor things that have been present from the start, but then when I start getting emails from people saying my software is messing up and I find out it's just that the latest version of PHP totally broke something I'd been relying on, that frustration is amplified tenfold.

ivankirigin• 17 years ago

I'm going in the other direction right now. I have a sheet of notes titled "PHP WTF". Seriously, PHP is such a mess. Thank Jesus for Thrift http://incubator.apache.org/thrift/

Joe Stump: Why I switched from PHP to Python

Related Stories