5 ms·

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

by lux 19y ago

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.

cstejerean 19y ago
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.
wheels 19y ago
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. ;-)
- lux 19y ago
  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.
  - wheels 19y ago
    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.
    - lux 19y ago
      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 :)
SwellJoe 19y ago
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.
- aston 19y ago
  Fun is that PHP still lets you pretend it works functionally. http://php.net/array_map http://php.net/array_map http://php.net/array_reduce http://php.net/array_reduce http://php.net/array_filter http://php.net/array_filter http://php.net/array_walk http://php.net/array_walk http://php.net/call_user_func_array http://php.net/call_user_func_array (apply) http://php.net/create_function 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.
  - eru 19y ago
    You know that you have to supply the function by _name_ as a string?
    - sapphirecat 19y ago
      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.

by lux 19y ago

cstejerean 19y ago

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.

wheels 19y ago

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

lux 19y ago
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.
- wheels 19y ago
  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.
  - lux 19y ago
    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 :)

SwellJoe 19y ago

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.

aston 19y ago
Fun is that PHP still lets you pretend it works functionally. http://php.net/array_map http://php.net/array_map http://php.net/array_reduce http://php.net/array_reduce http://php.net/array_filter http://php.net/array_filter http://php.net/array_walk http://php.net/array_walk http://php.net/call_user_func_array http://php.net/call_user_func_array (apply) http://php.net/create_function 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.
- eru 19y ago
  You know that you have to supply the function by _name_ as a string?
  - sapphirecat 19y ago
    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.