4 ms·

Because COBOL is the PHP of the 60s, and mainframes are slow and expensive. Also, too many of the talents are stuck in a blocked I/O mindset somehow. Some are

by kpil 10y ago

Because COBOL is the PHP of the 60s, and mainframes are slow and expensive. Also, too many of the talents are stuck in a blocked I/O mindset somehow. Some are wizards though, writing assembly and making raspberry pi sized systems blazingly fast. OK a couple of raspberry pi:s

tyingq 10y ago
As a counterpoint, many very well funded and talent rich organizations have failed to retire what TPF mainframes do every day for airlines, banks, and credit card companies. Cobol isn't involved, but those slow mainframes are.
- kpil 10y ago
  To be fair, rewriting huge mission critical systems is hard, no matter of what kind of system it is and what you are changing to.
- deleted 10y ago
  [deleted]
devwastaken 10y ago
There was never an excuse to not document PHP functionality. Infact, its quite easy to document now, just the same as any other language. Devs simply argue that the 'system is still changing', and so nothing is documented.
bpicolo 10y ago
Non-Blocking i/o isn't really some miracle new-age programming drug. Doesn't change the equation much.
SmellTheGlove 10y ago
Our mainframe is expensive but it isn't slow. It's not exactly sitting on the same hardware from the 70's.
- Arizhel 10y ago
  The amount of performance (particularly CPU) you get per dollar is very low. Mainframes are all about lots of I/O with ridiculously high reliability and availability, but for an absurd amount of money.
  - SmellTheGlove 10y ago
    Right, but that's our use case and it also happens to run our legacy applications! IBM's support is also very good. We're not running our modeling engines and that stuff on it. We have HPC for that.
chiph 10y ago
Mainframes aren't hotbeds of compute power - they are all about the I/O. Your typical COBOL program reads a record, does some moderate processing, and writes a record out. Over and over. So keeping the input and output channels full so processing wouldn't stall was a key design goal.

by kpil 10y ago

tyingq 10y ago

As a counterpoint, many very well funded and talent rich organizations have failed to retire what TPF mainframes do every day for airlines, banks, and credit card companies. Cobol isn't involved, but those slow mainframes are.

kpil 10y ago
To be fair, rewriting huge mission critical systems is hard, no matter of what kind of system it is and what you are changing to.
deleted 10y ago
[deleted]

devwastaken 10y ago

There was never an excuse to not document PHP functionality. Infact, its quite easy to document now, just the same as any other language. Devs simply argue that the 'system is still changing', and so nothing is documented.

bpicolo 10y ago

Non-Blocking i/o isn't really some miracle new-age programming drug. Doesn't change the equation much.

SmellTheGlove 10y ago

Our mainframe is expensive but it isn't slow. It's not exactly sitting on the same hardware from the 70's.

Arizhel 10y ago
The amount of performance (particularly CPU) you get per dollar is very low. Mainframes are all about lots of I/O with ridiculously high reliability and availability, but for an absurd amount of money.
- SmellTheGlove 10y ago
  Right, but that's our use case and it also happens to run our legacy applications! IBM's support is also very good. We're not running our modeling engines and that stuff on it. We have HPC for that.

chiph 10y ago

Mainframes aren't hotbeds of compute power - they are all about the I/O. Your typical COBOL program reads a record, does some moderate processing, and writes a record out. Over and over. So keeping the input and output channels full so processing wouldn't stall was a key design goal.