2. As in any interpreted language. Yes PHP has the gag operator (@) but it's use is discouraged (and not used in this example),
3. Not in my opinion. The Symfony framework alone has a ton of well used packages[0]. It does look like someone's decided to build their own framework from this example though,
Scheme, Standard ML, very early versions of Java, and BASIC come to mind.
Static typing really does seem particularly important in this domain, to the point that if an engineer is unable to find a suitable interpreted static language then the prudent choice would be to start looking at compiled langauges before relaxing the static typing requirement. Even implicit type conversion seems like a pretty questionable idea in this sphere. You really would want to be keenly aware of when you're doing something that might add or remove numerical precision.
Not to say whether PHP is in fact a good idea or not, but at least in a statically-compiled language, once you've got a "working binary", however you accomplish that, it will presumably continue to function that same way indefinitely. Obviously barring OS-level problems, of course :)
Would you consider Python and Ruby strongly typed? Because I happen to know two very large payments company using them. However if that is indeed their code, it makes me cry and cringe, even though PHP is my strongest language and I'm proud to admit it.
>Would you consider Python and Ruby strongly typed?
Did you mean statically typed? There are two dichotomies: static vs. dynamic, and weak vs. strong. Ruby and Python have strong dynamic typing. PHP has weak(-ish) dynamic typing.
Python and Ruby are great for building an MVP, and they'll take you a long way, but they're probably unsuitable for a high-stakes codebase like a financial system. When bugs are absolutely unacceptable, you need all the help you can get from static analysis.
And (don't crucify me HN) I think dynamic typing rapidly loses its allure as your codebase grows large and "enterprise." The advantages in rapid prototyping and easy changes start to be overshadowed by the increasing burden added by unexpected side effects any time you change something. In Java, if I change an interface then I can find every client of that interface with one click and make sure each one is not broken by the change. The same is not true of JavaScript code; changing the valid inputs of a function can break things scattered around the code, and you won't notice unless you use a particular feature 3 times in a row on a waning gibbous moon.
There are a lot of great responses (and counter responses) here already as to why PHP is a surprising choice, but primarily my objection is one of misapplication. PHP is a scripting language for fast creation of web sites. It grew organically and consequently has a lot of weird gotchas that make it easy to write in bugs. Its floating point is poor, which you would think would be a detriment in financial use.
Want to get a web site up like right now, get some PHP. Want to run the largest Bitcoin exchange in the world, maybe not so much.
It looks $ugly, $code is read more $often than its $written. This $ everywhere hurts the eyes.
Its syntax is bad and inconsistent, before 5.4 you couldnt have a function return an array and call it and access array contents like this funcName()['blah']. What the.
PHP only has one data type for structures, array, which in various ways pretends to be every data type, stack, queue, tree, hashmap, list, fuck it all, lets just call it array everywhere!
Anyway, everything else is implicitly converted as well, strings, integers, fuck it all, lets ouput 0 or 1 who cares.
PHP is basically not a language, its a clusterfuck of copy-pasted code everywhere, I bet its runtime, Zend, is as a copypaste of various C-libraries cobbled together.
I feel sorry for all the PHP lovers, must be stubborn ones, just like VisualBasic people 10 years ago when it was dying. PHP-lovers have the same argument now as VisualBasic did 10-15 years ago.
EDIT: Where and when I would use PHP. Never. There is always a better alternative. This talk about how easy it is to host, blah blah, then you never had to compile php and set its config flags and include dumb oci8 modules, pear or pecl files or whatever, or see it fail and no logs anywhere but you have to have system-level access to some ini files. Ugh... I think people have just learned to live with that crap, and the more sane languages and web frameworks like Flask or Grails are much easier.
One advantage it does have is apps can auto update and extend themselves. Eg, wordpress makes extending it with 3rd party plugins extremely painless from a user perspective.
As for not being able to access a array directly from a function which returns the array. It's just syntactical sugar. Yes long over due syntactical sugar however.
Yeah, Hack for HHVM adds a bunch of stuff to PHP to make it better, including:
- Collection classes like Vector (which is like an array in every other programming language ever) and Map (associative array or hashtable)
- Generics
- Lambda functions
- Asynchronous functions
- Type hinting for intrinsic types (int, string, bool)
Not much public documentation yet, but most bits are in the open source HHVM release, and there are a few blog posts on it (eg. http://www.sitepoint.com/hhvm-hack-part-1/)
I can think of lots of reasons.
* You're exposed to any upstream bugs in the language and interpreter
* Dynamic typing and silent errors mean you're far more likely to make a mistake and not realize it
* It's missing a lot of battle tested libraries and frameworks
* It's PHP