4 ms·

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

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

Gigablah 13y ago
Maybe someone would like to post a link to the veekun article for the umpteenth time.
- ColdHawaiian 13y ago
  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-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
mappu 13y ago
> 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?
- someone13 13y ago
  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 :)
nodesocket 13y ago
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.
- dan15 13y ago
  Anything in particular about this code that makes you cry and cringe?
  - nodesocket 13y ago
    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': ...
- eurleif 13y ago
  >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.
- _pmf_ 13y ago
  > Because I happen to know two very large payments company using them. For the purpose of short selling: who are they?
  - nodesocket 13y ago
    I bet you can guess, both bay area YC companies.
    - xytop 13y ago
      Stripe?
- brianpgordon 13y ago
  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.
RossM 13y ago
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 https://packagist.org/search/?q=bundle
- bunderbunder 13y ago
  > 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.

Gigablah 13y ago

Maybe someone would like to post a link to the veekun article for the umpteenth time.

ColdHawaiian 13y ago
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-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

mappu 13y ago

> 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?

someone13 13y ago
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 :)

nodesocket 13y ago

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.

dan15 13y ago
Anything in particular about this code that makes you cry and cringe?
- nodesocket 13y ago
  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': ...
eurleif 13y ago
>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.
_pmf_ 13y ago
> Because I happen to know two very large payments company using them. For the purpose of short selling: who are they?
- nodesocket 13y ago
  I bet you can guess, both bay area YC companies.
  - xytop 13y ago
    Stripe?
brianpgordon 13y ago
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.

RossM 13y ago

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 https://packagist.org/search/?q=bundle

bunderbunder 13y ago
> 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.