Hacker News new | ask | show | jobs
by shalmanese 4491 days ago
For a bank?

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

4 comments

An argument, since it's Monday and I'm grumpy:

1. As in any language,

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,

4. Opinion.

[0]: https://packagist.org/search/?q=bundle

> 2. As in any interpreted language.

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.

Maybe someone would like to post a link to the veekun article for the umpteenth time.
I'm assuming that you're referring to "PHP: a fractal of bad design"[1]?

[1]: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

> You're exposed to any upstream bugs in the language and interpreter

How would you mitigate that, and how is the mitigation process any different for PHP?

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.

> Because I happen to know two very large payments company using them.

For the purpose of short selling: who are they?

I bet you can guess, both bay area YC companies.
Stripe?
>Because I happen to know two very large payments company using them.

Using them for what though? I doubt they use them for their transcation money handling code.

You'd be wrong.
Pics or it didn't happen.
Anything in particular about this code that makes you cry and cringe?
Lot's, but perhaps most obvious, not using a routing engine or framework, simply spaghetti code case statement:

      public static function _Route_getStats($path) {
                switch($path) {
                        case 'version':
                          ...