z/OMG
qntm.org
qntm.org
After all, you can happily run DB2 on Z/OS, and access everything via stored procs from smaller machines. his gives you external access to data without going through green screens.
Writing software for microcomputers that sells is for chumps. Mainframes are where it's at, if for no other reason than the fact that "relabel[ing] one line of [a] procedure between one software version and the next will break somebody else's program."
Most people using mainframes don't make money off of their IT department, their programmers are expensive and don't produce profits. Investing in a large change from "what works and has a fixed cost" to something new and possibly troublesome or more expensive (initial cost) just isn't a priority for them.
Not to mention the retraining you'd have to do. A lot of these programmers are either old and unwilling to learn, or just uninterested in rocking the boat. So is it worth it to have to fire people or get subpar code, or just stick with what's working that keeps you generating a profit and keeps your current programmers job security?
ICBM System z is the Stonehenge of computing platforms.
I grew very fond of JCL, EBCDIC and the text editor despite, or perhaps due to, their idiosyncrasies. Not that I would ever go back ;)
I heart my graphical IDE.
I'm very fluent in vi(m), but I still end up going back to Emacs (well, MicroEmacs) every time for anything beyond doing hacks to configuration files. Why? I like having a heavily extensible development environment.
I also write Scheme, but that's another thing altogether.
But I still love vim...although Ive forgotten more bindings than other editors have features.
That said, I also have a preference for Lua when it comes to more maintream languages, and to boot, there's a project called LuaJIT that performs just-in-time compilation of Lua to native code.
There's also MetaLua, which adds the feature of macros to the language.
Better still, there's lua-Coat, which is a port of a subset of Moose from Perl (which is, in turn, a port of CLOS and other things to Perl) to Lua.
Consider also just using Python or Io or any number of other languages.
I guess my point is that it really doesn't depend on the language. If the environment isn't going to be extensible within reason, I probably won't use it.
(Did you know that vim lacks the functionality to emulate Emacs' `create-frame`? That's a huge turn-off for me personally.)
Running.
Choose your poison and all that.
We're talking about systems designed for throughput. For processing huge amounts of data in overnight batch processes. For five nines uptime. And for still being compatible with the code you wrote 30 years ago that still manages millions of customers.
It IS incredible - but modern Computers are even more incredible.
The reason why these are kept around is that the custom software that runs on them often implements very complex business rules that are otherwise undocumented (the code is the documentation). If you're talking about a financial institution, the mainframe IS the business.
As far as reliability, these things are rock-solid and proven, but mainstream distributed systems design has pretty recently surpassed the mainframe model IMHO. It's relatively simple (compared to just a few years ago) to implement clustered data processing using MapReduce, replicate the data across multiple datacenters, and not care about individual node failure.
You have every piece of I/O handled by its own subsystem; in the old days when they had lots of green screens they had FEPs, front end processors, that took care of all the busywork for displaying and accepting data - the main CPU never saw any of that. Same thing with networking, with disk I/O, you name it.