Page 2 of 2 First 12
  • Jump to page:
    #16
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2010
    Posts
    153
    Rep Power
    5
    Originally Posted by requinix
    Go ahead and we'll see what happens. I'm sure all of us here are capable of allowing someone to voice their opinion without harsh criticisms, right? There aren't too many very vocal people here and not as much fanatical love of PHP as you might think.
    OK then, I'll bite; but first, what I do like about PHP:

    - Its "one file=one url" paradigm is conceptually very approachable.
    - It's fast and relatively frictionless to get a smallish application up and running
    - I can count on my stuff running no matter what kind of ISP the client is using.
    - PDO is nice; especially how it makes things like parameterization work the same across all db's.
    - I don't have to know much about HTTP to use PHP.


    Now, a non-exhaustive list of what I like better about Python:

    - It's more object oriented from top to bottom; everything, from collections to integers, are objects, and have methods. Which means, e.g., that functionality related to strings or collections can be encapsulated in the string or collection object instead of cluttering up the global namespace with 100's of str_do_foo() or array_bar_baz() functions.

    - PHP has arrays, which are useful and I use the heck out of them. Python's collection types are more varied, more powerful and have cleaner syntax. PHP has nothing comparable to Python's list, set, and dict comprehensions, which are awesome for manipulating SQL query output. Python collections also alloww slicing ("somecollection[2:5]"), which is a very convenient way of doing substrings or grabbing parts of a collection.

    - The total absence of "->" and "=>" as operators. My right hand wants to go on strike every time I do heavily object-oriented PHP.

    - Overall more naming and syntax consistency. Python2 is not as good as Python3 in this regard, but there are published guidelines for naming conventions and so forth, and most libraries comply with them. Even PHP builtins can't decide if functions are underscore or camelcase, if search arguments are ($needle, $haystack) or ($haystack, $needle). I've been writing PHP since 2005 and I still have to pull up the docs for most string/array functions just to get things right.

    - methodThatReturnsACollection()[index] actually works as expected.

    - Python functions and methods can have keyword arguments, so if I have a function with a lot of optional arguments and want to change the value of the Nth argument, I can just specify it as a keyword argument instead of having to specify all N default arguments.


    The grass isn't all greener, and moving from PHP to Python is a paradigm shift; I blogged about my thoughts on the move here:

    http://www.alandmoore.com/blog/2013/02/02/from-php-to-python-things-i-wish-id-known/

    Originally Posted by dmittner
    For me the criteria would be:
    - Features
    - Readability
    - Syntax consistency with other languages
    - Portability
    - Performance
    - Level of support
    Without going into detail, I'd say IMHO Python beats PHP in Features and Readbility, is comparable in Performance and Level of support, and is beaten by PHP's ubiquity on cheap webhosting (I'm guessing this is what you had in mind for Portability?) and it's similarity to other languages. I don't consider the latter an issue, personally; I would rather have a unique syntax that is readable, predictable, and *internally* consistent than one that looks incidentally like C or Java.
  2. #17
  3. Transforming Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,294
    Rep Power
    9400
    Originally Posted by admoore
    - It's more object oriented from top to bottom; everything, from collections to integers, are objects, and have methods. Which means, e.g., that functionality related to strings or collections can be encapsulated in the string or collection object instead of cluttering up the global namespace with 100's of str_do_foo() or array_bar_baz() functions.
    Yes. PHP was originally procedural and added in OOP as an afterthought so languages where OOP is a large part or has had longer to mature (Python, Ruby, not to mention Java and C#) will beat out PHP there.

    Originally Posted by admoore
    - PHP has arrays, which are useful and I use the heck out of them. Python's collection types are more varied, more powerful and have cleaner syntax. PHP has nothing comparable to Python's list, set, and dict comprehensions, which are awesome for manipulating SQL query output. Python collections also alloww slicing ("somecollection[2:5]"), which is a very convenient way of doing substrings or grabbing parts of a collection.
    Really? Arrays encompass every collection-based pattern I can think of: arrays/lists, stacks (array_push/array_pop or array_shift/array_unshift), queues (array_push/array_shift or array_unshift/array_pop), sets/dictionaries/hashes (using array keys)... Then there's the SPL objects too. What else is left?
    And yeah, slicing in the syntax is often requested on the bug list.

    Originally Posted by admoore
    - The total absence of "->" and "=>" as operators. My right hand wants to go on strike every time I do heavily object-oriented PHP.
    Like I said, afterthought, and for accessing instance members period had already been claimed. No doubt they borrowed -> from C/C++, and I'd guess they used => because it looked like an actual arrow. Eh, I'm probably just used to it anyways for all the other symbols.

    Originally Posted by admoore
    - Overall more naming and syntax consistency. Python2 is not as good as Python3 in this regard, but there are published guidelines for naming conventions and so forth, and most libraries comply with them. Even PHP builtins can't decide if functions are underscore or camelcase, if search arguments are ($needle, $haystack) or ($haystack, $needle). I've been writing PHP since 2005 and I still have to pull up the docs for most string/array functions just to get things right.
    No surprise that's the #1 complaint about PHP. Problem is it's too late to start changing things around without huge backwards compatibility and portability problems.

    Originally Posted by admoore
    - methodThatReturnsACollection()[index] actually works as expected.
    Available in PHP 5.4

    Originally Posted by admoore
    - Python functions and methods can have keyword arguments, so if I have a function with a lot of optional arguments and want to change the value of the Nth argument, I can just specify it as a keyword argument instead of having to specify all N default arguments.
    The subject has come up a few times in the bug list. The RFC was rejected on grounds of violating KISS.
    Personally I'd avoid long parameter lists anyways - surely an object or array would work better?
  4. #18
  5. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Originally Posted by admoore
    - It's more object oriented from top to bottom; everything, from collections to integers, are objects, and have methods. Which means, e.g., that functionality related to strings or collections can be encapsulated in the string or collection object instead of cluttering up the global namespace with 100's of str_do_foo() or array_bar_baz() functions.
    Agreed. PHP has a lot of old functions, but I do think it's getting better about moving such logic into objects. I like having the option, though; functions for quick scripts, objects for longer-term applications.

    - The total absence of "->" and "=>" as operators. My right hand wants to go on strike every time I do heavily object-oriented PHP.
    Agreed, 100%. This touches on both my Readability and Consistency criteria. I'd love it if PHP eventually got smart enough to realize you're dealing with an object (vs. a concat'able value) and accepting . instead of ->.

    - Python functions and methods can have keyword arguments, so if I have a function with a lot of optional arguments and want to change the value of the Nth argument, I can just specify it as a keyword argument instead of having to specify all N default arguments.
    Nice. Long argument lists is definitely a pain. I've taken on the habit of using Poltergeist "request" objects (or nearly Poltergeists) to pass sets of variables into complex methods. That way you can set whatever parameters are relevant, possibly have methods to set things in bulk, and can add new parameters without changing the method definition.

    It can also be a functional substitute for overloading, which PHP doesn't support (in the conventional sense).
    Last edited by dmittner; August 21st, 2013 at 03:53 PM.
    LinkedIn: Dave Mittner
  6. #19
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2010
    Posts
    153
    Rep Power
    5
    Originally Posted by requinix
    Really? Arrays encompass every collection-based pattern I can think of: arrays/lists, stacks (array_push/array_pop or array_shift/array_unshift), queues (array_push/array_shift or array_unshift/array_pop), sets/dictionaries/hashes (using array keys)... Then there's the SPL objects too. What else is left?
    And yeah, slicing in the syntax is often requested on the bug list.
    PHP arrays are versatile, and FWIW it's arguably nicer to have one type of object that does everything than half a dozen with fine shades of differentiation. I'll confess I never really got into the SPL classes; I never found anything there that seemed more fitting or functional than a plain array().

    I guess my prefrence goes back again to the basic syntax/design element here, as well as features like slices and comprehensions.

    Good; I can finally quit creating chains of throwaway variables to extract one value from a PDO query.

    The subject has come up a few times in the bug list. The RFC was rejected on grounds of violating KISS.
    Personally I'd avoid long parameter lists anyways - surely an object or array would work better?
    I find it quite useful in languages that have it; why not have long parameter lists, particularly in (for example) a constructor for some very configurable generic class? I mean, it only takes six or seven parameters before remembering them in the right order becomes cumbersome, and that's not an unreasonable amount of data to want to pass to an object constructor.
  8. #20
  9. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124

    Lightbulb


    I like JavaScript's object model - especially for passing long argument lists to methods. With php's new short array syntax something like this is now possible

    IMO PHP is great because it serves so many purposes. It's entry barrier is so low it allows people who aren't programmers to easily create simple tools to automate tasks ( this is how I adopted it, a brief intro to C a few years before helped a bit too).

    The problem is the mind shift needed to go from simple tools to big apps (or, in rare cases, the other way round). Some people can do it, some can't (I'm just about getting there). It's not the fault of the language that it works well at both ends of the spectrum it's a problem with the programmers' mentality while looking towards the other end from where they currently are.

    The decades of out of date tutorials ignoring security concerns don't help - but so what? There was a time I didn't know about SQL injection but by the time I was building something important enough to worry about I had heard of it, researched it and started writing preventative measures into my code. I expect a lot of other people have gone through the same learning.

    Comments on this post

    • kicken agrees : JS is great. And a large part of the problem with PHP is just perception due to the vast amount of crap out in the wild.
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  10. #21
  11. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Dec 2004
    Posts
    3,027
    Rep Power
    377
    Originally Posted by requinix

    No surprise that's the #1 complaint about PHP. Problem is it's too late to start changing things around without huge backwards compatibility and portability problems.
    i dont understand why we use backward compatability as an excuse to not redefine function names?

    1. Mysql_ extenstion is being used but is phased out so surely they could do the same with functions names?

    2. php 4 is dead so people suggest to move to 5.3 and that hasnt caused any confusion with backward portability?

    3. certain features have been turned off DESPITE the backward portability problems

    so i dont see why we use that arguement for function renaming?

    having said that, why cant developers write their own Wrapper functions with names they like? would that be a good or bad thing?


    In addition what does . & =? signfiy in OO
  12. #22
  13. Transforming Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,294
    Rep Power
    9400
    Function renaming happens, though not very often, by using aliases. join(), for instance. The problem with the functions is not the name but the arguments.

    The mysql extension and bad php.ini settings can be phased out over time because it's possible to deprecate them and allow code to move over to something different.
    You couldn't do that with functions because it's not possible to have the old and new versions available concurrently: either the first argument is the haystack or it's needle and with many functions there's no way to know which is which.

    So there would have to be a hard cutoff point: before version X the functions are one way, after version X they're another way. But that doesn't address the problems of readability and portability, and writing wrappers that do version detection is an outrageous requirement to push onto developers. And it's hard enough to get people to upgrade versions now without those kinds of major breaking changes.

    It's just a lot of hassle for little gain: "in_array() is needle/haystack" is unfortunate but "in_array() is needle/haystack up to version X and then haystack/needle after" is worse.

    Originally Posted by paulh1983
    In addition what does . & =? signfiy in OO
    Neither are object-oriented operators: . is still string concatenation (so $object . $object == $object->__toString() . $object->__toString()) and => is still related to arrays and their key=>value syntax (like in array definitions or foreach loops).
  14. #23
  15. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Dec 2004
    Posts
    3,027
    Rep Power
    377
    thanks. i didnt mean write an if/else scenario for functions i.e detect version. that was a general SOLUTION for everyone who moans about inconsistent naming convention. so if you just have a functions.php file where you have a wrapper taht does nothing but changes the name to how you LIKE it.
  16. #24
  17. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Posts
    10
    Rep Power
    0
    If I could pipe up and say that I stopped being a fanboy of X language years ago. Both languages have their ups and downs, and when coding, I usually choose the language that is appropriate for the task.

    I could never really get into Python frameworks for web development, so I stick to PHP there, but I use Python for all my GUI stuff. I use both languages for cron job scripts, depending on what the job is, and I really like using both languages. In fact, many of my larger home-projects are web-based(for the quick and easy interface) and call scripts from both languages, among others.

    Couple of things I dont like about both languages:

    PHP
    I do admit, even though I'm so used to it, if I'm tired or been coding for hours, I occasionally get annoyed with the dollar signs and the OOP => operator. I also dislike the way PHP normally ships, which is to not show most warnings, etc in "white page" mode.

    Python
    The use version 2 or 3 thing is kind of getting old. Most Python devs that Ive run into say I should be using Python 3, when Ive yet to do a SINGLE project in Python3. All scripts I've been required to write in Python in a professional environment have required me to write them for 2.6 or 2.7
  18. #25
  19. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2012
    Location
    Ithaca
    Posts
    68
    Rep Power
    3
    Originally Posted by Northie
    It's entry barrier is so low it allows people who aren't programmers to easily create simple tools to automate tasks ( this is how I adopted it, a brief intro to C a few years before helped a bit too).
    Actually some people consider PHP's ease of entry as its undoing, as more non-programmers and newbie programmers also mean more spaghetti code. Anyway, there are pros and cons in PHP. I'd agree with what those advanced programmers have pointed out earlier, simply choose whatever that works for your project. There really isnt a remedy for everyone.
  20. #26
  21. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2010
    Posts
    153
    Rep Power
    5
    I could never really get into Python frameworks for web development, so I stick to PHP there, but I use Python for all my GUI stuff.
    It's a major paradigm shift to go from PHP to just about anything else. I really think anyone doing significant web development owes it to himself to try at least one other server-side language just to have a frame of reference for where PHP stands. If not Python, then RoR, node.js, Java, Perl, etc.

    Python
    The use version 2 or 3 thing is kind of getting old. Most Python devs that Ive run into say I should be using Python 3, when Ive yet to do a SINGLE project in Python3. All scripts I've been required to write in Python in a professional environment have required me to write them for 2.6 or 2.7
    Oh my yes. I recently had another go at converting everything to Python 3, and got stymied by various libraries that *still* have not been ported. Which is sad, because there are some killer features in Python 3.

    On the upside, there appeared to be working code on github for all but one of the things I needed, the ports just haven't made it to Pipi / Linux repos / etc. yet.
  22. #27
  23. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Posts
    10
    Rep Power
    0
    Originally Posted by admoore
    It's a major paradigm shift to go from PHP to just about anything else. I really think anyone doing significant web development owes it to himself to try at least one other server-side language just to have a frame of reference for where PHP stands. If not Python, then RoR, node.js, Java, Perl, etc.
    I 100% agree with you. I was a JSP developer for about 6 months, and that was a great experience. I have been meaning to get into RoR though, and will probably test it out sooner than later.


    Originally Posted by admoore
    Oh my yes. I recently had another go at converting everything to Python 3, and got stymied by various libraries that *still* have not been ported. Which is sad, because there are some killer features in Python 3.

    On the upside, there appeared to be working code on github for all but one of the things I needed, the ports just haven't made it to Pipi / Linux repos / etc. yet.
    I know, and it's too bad really. I want to move forward and am willing to use Python3 but am not willing to make the switch yet. I look forward to the day that I can, though. I love this language.
Page 2 of 2 First 12
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo