Hacker News new | past | comments | ask | show | jobs | submit login

Python is certainly the more flexible of the two languages, but if you're really familiar with PHP you may be able to write your app faster in it and get it out there faster. But there's also long-term time savings to consider as well...

I haven't really done much in Python yet unfortunately, but I've worked quite a bit in Perl, PHP and Ruby, and personally I don't find any of them mind-blowingly different from one another, syntax aside. Some have more succinct syntax for looping and other things, but no major paradigm-shift IMO (like the one from imperative to functional).

Most of the complaints against PHP (just like MySQL) are about things that were solved years ago, but continue to linger on anyway. I like to think of PHP not so much as a language though, but more as a wrapper around C with memory management and a more flexible type system. Looking at PHP that way shows why many of its inconsistencies exist (e.g., in function names). It's also of the "structure is optional" philosophy, which requires more discipline to code well in.

Anyway, I think it comes down to figuring out whether it would save time now and later to use PHP or Python.




PHP doesn't have first class functions (and all of the stuff that sort of naturally flows from closures and all of the other nice bits that make dynamic languages so very nice to work with). It is a pretty dramatic difference between PHP and Python, Ruby, and Perl. Idiomatic usage of the latter three are, on the whole, similar to one another, but idiomatic usage of PHP is dramatically different. I think if you don't see "paradigm shift" differences, then you're writing PHP code in Perl and Ruby. In other words: You're doing it wrong.

PHP isn't really even in the same branch of languages as the three popular dynamic languages. It's like a fork off from C in the same way that chimps and humans shared a common ancestor 8 million years ago. So, one could say, "chimps are to PHP as humans are to Perl", if one wanted to be inflammatory...and in this case, one does. Both are pretty flawed as creatures go, but one flings poop and the other drives cars and builds roller coasters.


Fun is that PHP still lets you pretend it works functionally.

http://php.net/array_map

http://php.net/array_reduce

http://php.net/array_filter

http://php.net/array_walk

http://php.net/call_user_func_array (apply)

http://php.net/create_function (lambda)

PHP is a language that encompasses all useful things in all other languages. Which, I guess, makes it inferior.


Please don't call "create_function" a "lambda". That's a parody of anonymous function. You have to escape (\") your source code, function is registered in the global scope, and the only reference you get on it is... a string with generated, unique function name.


Yeah create_function is a half ass attempt for the use of lambda functions. I would not recommend using it.


You know that you have to supply the function by _name_ as a string?


I don't get what you're saying. aston did say pretend.

Once you have the function name (or an object method array) it can be stored in a variable with any name you want, passed around, etc. You can pretend it's a function all you want; you can check whether it seems like a real function with is_callable; and you can call it via call_user_func or call_user_func_array (this distinction made necessary because PHP lacks Python/Ruby *array unpacking syntax).

Somewhere I have a PHP class that lets you fake closure. You call Closure::Create($real_cb, $state_data) and it gives you a callback that, when called, calls $real_cb with $state_data plus all arguments that it was called with. And if $state_data is an array whose elements were assigned by reference, the 'closed-over' state is mutable.

So overall, it's a good pretense, even if foreach will always be faster than functional style.


Simulating closures? that seems pretty clever I've just recently integrated a functional extension into our private web application framework a few months ago. Perhaps we can share notes?


Well, since PHP by default reinterprets bare-strings as actual strings, you can just type the name without quotes, and things should still work. Until you define() a constant with the same name.


I do not mind the inconvenience of typing in quotes. I just do not like that function are not treated as first class citizens in this respect. There may be ways around this in newer versions of PHP, though.

By the way - can someone please try something like the following: $width = getimagesize($filename) [0];

The last time I checked, PHP threw a _Parser_Error_ for indexing an array that you just got from a function. Not even arrays feel like first class citizens.

(Pardon me, if this ward has been eliminated in the mean time. I just vividly remember losing some time hunting for a bug because of this 'feature'.)


Yeah, the [] operator works on a variable name, not on the variable itself. Kind of silly.


PHP is sloppy and messy, and say what you will, but the first time I tried writing something like the below code I definitely had one of those "Woah. That is cool." moments like first-time experience with lambdas:

   $a = 'var';
   $b = 'iable';
   $variable = 'var';
   echo ${$a.$b};
Useful? Sure it is:

   $filter = array("name", "email");
   foreach($filter as $v) $$v = $_POST[$v];


I did a lot of this when I built a form templating engine a few years back. When I came back to the code a year later, I had no idea what I was doing.

Python syntax is much cleaner, and with only one way to do things, it's almost always easier to read. I'm a Pythonista now.


Python‘s way of accomplishing this is as easy, although the use of `locals` should indicate that this isn’t generally something you should be doing:

    post = {'name': 'ijoshua', 'email': 'spam@example.com', 'extra': 'data'}
    
    filter = ['name', 'email']
    
    for k in filter: locals()[k] = post[k]
    
    print name, email


I've touched a nerve, it seems.

I was, of course, joking. Having a laugh at some of the obvious weaknesses in PHP, and pointing out that the other three popular dynamic languages go about things differently.

But, all but one of our world-facing websites are PHP applications (we run Wordpress, Joomla, FlySpray, and DokuWiki, our other wiki is the Perl-based TWiki). I'm actually a grudging fan of the language. It does a few things extraordinarily well, and I've been known to recommend that everyone building installable web applications ought to be writing them in PHP because of its pervasive availability.

Don't take it personally, folks. You're not going to convince me that create_function gives PHP first class functions (maybe if you squint a little), but you also don't need to convince me that it serves a niche very well. I don't have to like it, but I certainly have to use it, because it is currently the best tool for a large class of problems.


That's pretty funny! I got a good laugh out of the chimps image :)

I actually started in Perl about 8 years ago (well, before that it was just little Galaga and Snake clones in DOS :), so it's kinda my first love. But Perl was eventually too punk rocker for me...

I drank the Ruby kool-aid for a while too (mmm, pickaxe flavour :), and if I were to start fresh in a language without the framework I'm used to now, I would definitely be seriously weighing Ruby vs Python (or maybe finally get up on the functional languages).

Maybe I'm writing Ruby like PHP, but I probably write PHP more like Perl anyway. When I first came to PHP I was disgusted at ideas like "register_globals" and immediately ported CGI.pm and DBI over so I would have something sane to work with in PHP. This was long before PHP had its "superglobals" and even PEAR didn't exist yet back then.


That has always been my gripe with PHP. Perhaps by PHP8 we will begin to see things differently. That being said you just have to exercise some restraint so that the "monkey" behaves properly.


Given your comparison of PHP and C I assume you think of an aircraft carrier as a canoe with more guns and metal and stuff. ;-)


Not quite ;)

I just mean that really if you look at PHP's function list, it really is just a wrapper around C libraries. Many functions map 1-1 from the C lib to the PHP function. That's where it gets its string function names, many of the original database libraries were exactly that (which is why there was no built-in abstraction layer for so long), and you can look at GD or any other extension for more examples.

When you take that into consideration, you can see what the language designers were thinking in the decisions they made for PHP. They aren't necessarily the ideal choices, but the rationale does make sense.


I see what you're getting at, but I think it's better said like you did in the comment above. The standard library wraps a lot of C libraries. I however suspect that more came by way of Perl, which PHP was somewhat based on.

As a language, aside from the fact that they're from the same syntactic family, one is a compiled, low-level iterative language, the other is an (semi-) object oriented, dynamic, garbage collected, interpreted language. In terms of language features, it's a lot closer to the Python, Ruby, Perl clan than C.


Feature-wise, yes it's obviously closer to those, but what PHP did originally was wrap a Perl-esque syntax and dynamic environment (dynamic typing, interpreted code, GC, etc.) around C libraries as its "standard library". It's grown a lot since then, but the C connection still accounts for PHP's standard libraries, despite the big improvements in OOP and newer libraries in the last few years (SPL for example).

That is where many design limitations come from, and it's why PHP's standard library is still mostly just a collection of a million functions instead of something more OOP like the Python or Ruby :)


I'm a bit surprised you don't find any big differences between Ruby and PHP. But then again it might be that I haven't looked at PHP in the last 4 years.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: