Android PHP option planned for Javaphobes
PHP is coming to Google's Android phones for those averse to programming in Java or going native. The PHP for Android (PFA) site says here that its goal is to make PHP development in Android "not only possible but also feasible providing tools and documentation." The project's main sponsor is open-source and Linux specialist …
I like PHP and everyone who hates it is just an elitist bandwagon jumper who probably has no clue what they are talking about.
Like anything in life: if you don't hate it, you don't know it well enough yet.
What a lovely motto to live your life by.
I'm a PHP developer too and I do like it but the idea of using it to write mobile apps still seems a little strange. Having real trouble understanding what the nub of the implementation's purpose is, other than saying "PHP devs are too thick to learn a new language".
A joke from the other side of the Iron Curtain circa 1980es:
Q: What is a pessimist?
A: A well informed optimist...
Q: What is an optimist?
A: A well instructed pessimist!
CLI PHP is a very good scripting language, so a GUI binding is all it needs.
PHP, C++ and Bourne shell. Anything else is superfluous.
Good job they hadn't originally named it the Android Rapid Scripting Environment
This could play a huge part in the iPhone vs Android battle.
It's a good move, very pleased with it. I will stop short of saying it can only be a good thing, but there will be a few bad apples produced by amateur 'developers' who don't really know what they are doing though admittedly these will be in the minority.
Is this really necessary? I code in both PHP and Java and spend a lot of time making the PHP code "work" like Java anyway. The languages are not a million miles apart really, just that Java is more "succinct" whilst PHP is the opposite (as, OT, is C#)
If you use OO heavily in PHP you just start to realise that you'd be better off with a "real" language anyway.
Of course, more choice is better for everyone in the end I guess.
"I code in both A and B and spend a lot of time making the A code work like B."
You're just a bad developer.
No. You're more than that. You're a bad Java developer, who'll do anything to pick up more work, including developing in languages you know very little about. The reason PHP ain't working for you, is you, not PHP.
"Is this really necessary?"
That is so completely besides the point it's not funny. The answer is a loud and shouted
BECAUSE WE CAN!
One of the things I dislike about PHP is that it's got almost everything but it's really mostly a big fat happy jumble. *Perl* looks sane in comparison. And more powerful. And faster. And so on.
"I code in both PHP and Java and spend a lot of time making the PHP code "work" like Java anyway."
Basically, you can write any language in almost any other language. Basically, if you find yourself doing that, you're doing it wrong. Of course, PHP has a habit of "acquiring support" for all the bad habits its many inexperienced users can come up with, so it doesn't particularly mind. In fact, the next major version will probably lend you a hand.
"Of course, more choice is better for everyone in the end I guess."
Many would guess so, so I'm not blaming you. But let me give you an example. Not (yet) on android, but bear with me. So, there's this network monitoring "framework" app. And it's open source. And to make it work on this here open source OS I need to install it and its dependencies. Fine. So, what are its dependencies? Let's see...
There's a sack of libraries, the inevitable xml stuff, some snmp handling, some stuff to generate pretty pictures. It also requires a C and a C++ compiler (yes you get them together nowadays). So far so good.
And it requires perl and a bag of cpan modules. Uh, ok.
And it requires java. Eh?
And it requires php. And a webserver. Er, are they sure they didn't forget anything?
And it requires ruby and a database server. Ah, there we are.
Since I'm recanting this from memory I'm sure I forgot something utterly vital like tcl or a specific version of awk, bash, m4, or something to that tune. You get the picture. My memory also refuses to tell me the name of the app and I can't be arsed to press the matter.
Bottom line: This thing is a complete nightmare to maintain nevermind upgrade. That's what *some* network admins get up to if you let them build their own systems. And then they release it as "open source". Thanks so much guys.
The point is that more choice might mean someone thinks it funny to choose *all of them*, succeeding in mooting the point quite handily. This is a bit of a cancer in the open source world, now that even things like Xorg video drivers written in C acquire runtime dependencies on python *and* perl for no discernible reason. That means it is probably time to admit the "improvements" aren't, get out the large cutlery and cut the alien vines down to size.
remember VB4? yeah, mock away but how many of you got started coding there?
Actually, there are tools like AppCellerator which offer a lot of that ease of use already (but Appcellerator comes with some strings and/or a pricetag that makes it less approachable than VB was back in the day)
AppCelerator is free and the source is available, but you are strongly advised to take the expensive premium support option. Basically it lets you create Droid, iPhone and iPad apps using JavaScript with essentially one codebase. The advantage over RhoMobile and the like is that the apps are native.
Nice tool. They need to sort out their premium support pricing model though.
So what does "BOFH" stand for in Android Terms?
A lot of PHP's OO design was based on Java so I think you're wrong there, it can be comfortably used similarly to Java a lot of the time.
Yeah, there are some syntactic similarities. There are also lots of differences. On any project larger than a Hello World, you should write code that makes the best use of the language to hand, not the way you're used to writing in another language.
How is that not obvious?
Pleas Java devs, stop writing god-awful PHP and giving it a bad name.
... honestly.
BUT it DOES have some growing up to do - it was never intended to be an OOP language originally and it shows. Look at the "libraries" - MySQLi for instance - the functionality can be accessed procedurally or in an OO manner. It's in a sort of halfway house state, migrating from a procedural to an OOP language.
There's some conformity issues that really should be sorted out as well, $_{EVERYTHING} except $GLOBALS.
Yes, these are both issues with a (fairly rapidly) evolving language and yes they can be mitigated by writing your own wrappers to abstract the core language itself but that's hardly optimal - it feels like the language could do with going over, carefully, cutting away the dead wood and rationalising the rest.
Thankfully, with version 6, they're heading in this direction; removing some of the deprecated features that should (really) never have been in the language in the first place - "register globals" and "magic quotes" for instance.
It's always been a good "quick and dirty" language but at least it's taking a bath once in a while now, putting on clean underwear and the acne is beginning to clear up - I'm still not convinced by loose typing however but that's not just a PHP thing.
very few developers actually know how to make the "best use of the language" which is a moving target anyway for a evolving language. The good ones will know how to make good use , the bad ones won't. and as things change the best use might not
it isn't Java developers that write bad php code - it is bad developers
