PHP allows me to practice my typing skills, ruby doesn't. As a touch-typing enthusiast, I like to practice typing. The problem with ruby is that it allows me to do the same things that I can do in PHP, but with much less typing. [..] If I could create classes with public getters/setters that easily in my day-job, my fingers would atrophe and I'd get no exercise at all. I want my keyboard smoking after typing out a class definition, and a paltry three lines of ruby fails to satisfy.
This is certainly the best designed troll blog post I've seen but far from the most subtle..
Really? Hating? Sweeping generalisations? Attempt at spreading said "popular view"? Misappropriations of words? All in a single sentence? On HN? With upvotes?
I am a long-time PHP programmer. I have first dabbled with PHP in 2000 when making a Page for my Quake2 gaming clans and i still love it. (yeah boo-hoo)
That said, the syntax and language inconsistencies that are already described in this post (which come from its origin as a website toolkit) are really laughable. However, i got used to it over time. I can still produce results much faster than say with Java.
Also PHP has matured alot. I use the symfony framework for all the projects i do and its awesome, i think in some respects its even better than ROR and the upcoming 2.0 version will raise the bar even further. If this awesome framework wouldnt exist i would probably have switched to Python and Django by now, but as things are now i have never really felt the need to.
I am tired of the never ceasing language wars. It's true that some languages are more elegant than others, but at the end of the day the only thing that really matters to any person other than the programmer is whether or not they create something inspiring and/or useful.
All this time railing against other languages could be spent making awesome things, rather getting the proverbial tape measure out (yet again).
I agree. The article I link below (and which I believe I first saw here on HN) should be closer to the model of what I would hope to see more of around here.
It gives you easy to read data which I believe is often more helpful than any opinions because at the end of the day you want to know, what are the trade-offs between performance and development time*, among other things. And it's also careful to point out many relevant caveats.
"Oh, look! An opinion that goes against the mainstream on the news.yc frontpage."
"Oh, got baited into another anti-PHP rant."
I know that PHP has tons of suckage but it's a point that's been made ad nauseum. No need to point out that Hitler wasn't that nice of a guy. We all know.
I long ago gave up trying to justify why I still use PHP as there will always be a counterargument (usually a long one) about how wrong I am. Once you get to that stage, there's a kind of serenity to be achieved :)
One I think is libraries for API's, sure this might not be the case among the latest breed of startups but I think overall your most likely to come across a PHP library and example code than Ruby.
I use php in my part time work every day, and I can honestly say this hilarious post made me consider using ruby. Unfortunately, I am the sole developer/maintainer on a huge project which languages don't stretch beyond php.
I came to this project in this state and I must say that clean code like demonstrated in this post, would have made the cleanup job I've attempted a heck of a lot easier.
Php is easy, but messy php code is not only extremely unsecure but also extremely hard for a new developer to adapt to.
My own PHP work where I have been the sole developer for most is great for me to work with. Having to mod a zen cart over the past week though makes me agree with you, that thing most be the kind of messy and obscure PHP open source projects.
The points the blogger touches are mostly three-fold:
* backward compatibility: a valid issue. Some of the APIs PHP exposes come from different backgrounds than others, and to serve the (un)holy cow of the backward compatibility, argument order is preserved. Regretably the PHP lang designers did not choose to deal with the issue, and instead fell for the trap of backward compatibility :-(
* syntax: conventions were carried from C and derivatives. Not a valid issue -- the syntax is perfectly OK for a language without macro capability. (should there be macro facilities like in LISP, complex syntax would be a no-no, but that's not the case in PHP).
* Java-isms like countless getter/setter methods: not a valid issue; nothing in PHP suggests that way of use. Merely bad habits on the part of the blogger. Get over it :-)
For the once-in-a-blue-moon need of real getter/setter, use __get(), __set(), _call() etc. methods.
> For the once-in-a-blue-moon need of real getter/setter, use __get(), __set()
Unless I am mistaken, __get and __set in PHP are similar to Python's __getattr__ and __setattr__: they are global to the instance and the dispatching has to be performed manually.
It can be used for properties, but it looks like shit, it feels like shit and you'll likely fail to match the language's own semantics when it's invoked with the "wrong" field name.
As far as I can see, the PHP convention on "static" getter and setters follows that of Java indeed, just as PHP's object system was lifted from Java.
Indeed, PHP's __get()/__set() behave the way you describe.
And if you have numerous getter/setters, it will feel and look like shit indeed -- in any language, no matter how terse the syntax. However, in that case the problem is with program design, not with the language itself. Ask your co-workers kindly not to carry over Java thinking into PHP world. Really, each language performs best when used in its default way.
Second, the PHP's ``own semantics when it's invoked with the "wrong" field name'' is simple: issue a warning with E_NOTICE level on read access. You implement that exactly with trigger_error("some msg", E_NOTICE). Same semantics, end of the story. Will be reported, or not reported, depending on error_reporting configuration.
> And if you have numerous getter/setters, it will feel and look like shit indeed -- in any language, no matter how terse the syntax. However, in that case the problem is with program design, not with the language itself.
You missed a core issue of the whole getter/setter/properties business: future-proofing/evolvability.
In Java, people generate bunches of getters/setters because if you ever need to create "virtual" members (add pre/post conditions) with public members you've just broken your interface (it's also used by technologies like Java Beans), you can't evolve gracefully from one to the other, hence Java IDEs having become very good at auto-generating getters and setters (including the type-induced naming variations). Likewise in C#, you can't replace a public member by a property without recompiling all clients (and if you follow the C# naming conventions, properties are PascalCased whereas members are camelCased), hence new syntactic forms having been introduced over time to make "direct proxy" properties easier and easier to create (last time I checked, creating a R/W property called Foo in C# is down to `public $type Foo { get; set; }`, and no field declaration at all as the field is implicitly generated by the property)
And so is it in PHP: if you use public members you can replace them by __get or __set, but if you ever need more than one or two fields you're fucked as you end up with a ball of mud of manual static dispatches. If you go the Java way, you get the Java result.
Now you assert that it's the same in every language. This is patently incorrect, and let me demonstrate it with two languages as far apart on this issue as they could be, Ruby and Python (very similar on most things, but not on this)
* Ruby has no public members. Period, end of the story. In Ruby, a public member is already a property, but because it's common to just expose a member without pre/post conditions it has accelerators for this such as `attr_accessor`. `attr_accessor :foo` creates a read/write property (actually a pair of methods) `foo` on the object which will proxy to the private member `@foo`. This means if it's exposed in Ruby, it's already a property. If you want to add pre/post conditions, remove the `attr_accessor` call and replace it with an explicit pair of `def foo` and `def foo= value`. This evolves gracefully and scales trivially, declaring a property in Ruby is as terse as (if not terser than) declaring a public member in PHP.
* Python goes the other way: everything is public. Period, end of the story. But it also has `property` which is an object implementing the descriptor protocol. Long story short, you can replace a public member `foo` by a property `foo` (created at the class level), and when accessed from the instance they will be indistinguishable. So in Python, just as in Ruby, you can trivially swap out a field for a property as needed without having to dispatch anything manually or defensively pre-generate a bunch of crap.
> Ask your co-workers kindly not to carry over Java thinking into PHP world. Really, each language performs best when used in its default way.
Getters and setters is the default PHP way. Hell, all of the Zend framework uses getters and setters everywhere[0]. __get and __set (and __call if you really want to talk about that one) are the special cases for dynamic fields and methods (e.g. in ORM), not for static properties.
As to my coworkers, they've switched well away from PHP a long time ago.
First off, thank you for the informative and balanced response.
Second, I agree with your reasoning chain, but I don't subscribe to the initial idea: accessors being about future-proofing. To me sprinkling accessors all around is more about focusing on the (safer, easier) `known unknowns' and satisfying kLOC metrics. And the assumption of being able to freely exchange code underneath as long as the objects stay the same.
So no, I haven't missed the whole accessor/mutator business -- I consider them special cases, to be used sparingly. And as such, I see no point in optimizing for them.
This is certainly the best designed troll blog post I've seen but far from the most subtle..