7 ms·
z/OMG
- seldo 17y agoThe thing that struck me about his awestruck description of the awfulness of System Z and its editor was "hey, that sounds a lot like vi". I heart my graphical IDE.
- DannoHung 17y agoTake a week to learn modal editing and you'll never go back.
- nrr 17y agoI am a counterexample to your claim; hence, it is false. 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.
- gord 17y agoIt is a minor sadness that Bram didn't choose a lisp as the vim macro language. But I still love vim...although Ive forgotten more bindings than other editors have features.
- nrr 17y agoI'm not actually all that certain I want Lisp as my extension language. Lisp is very, very nice, and while I may have a preference for it, someone else might not. FWIW, MicroEmacs uses an in-house extension language that, while really repulsive to look at at times, gets the job done. 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.)
- aerique 17y agoEditing isn't modal for everyone. I've used vi and Vim for years but I don't use them for more than a quick edit in a file these days.
- lucumo 17y agoI did for a year. I went back. Running.
- gloob 17y agoHeh. I'm about the opposite. Even when I have to work in an IDE (or pretty much anything that's not vim or a roguelike, for that matter), I become annoyed quite quickly that I can't navigate "properly" and how limited (in the case of many IDEs) or "backwards" (in the case of, e.g. emacs (I'm perfectly aware this is all entirely subjective, of course)) the editing capabilities are. Choose your poison and all that.
- maigret 17y agoWell they are graphical IDEs for mainframes. Java is also running very well on mainframes, as well as many web/appservers. This article makes a simplistic, though a bit funny image of the mainframe. Yes, the core and old stuff looks like that - no, there is also modern software running on the mainframe, else companies would stop investing in it.
- nrr 17y agoThis account right here makes me want to be a mainframe programmer for a living. 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."
- tsally 17y agoThe same author wrote a really great piece on gay marriage from a database engineering perspective: http://qntm.org/?gay http://qntm.org/?gay
- tdoggette 17y agoHe's also active on everything2.com, a Slashdot sister site from way back, as sam512. If you poke around on his site that's linked here, you'll also find some excellent science fiction and various other entertaining bits of writing, including that set of essays on how to destroy the Earth that I'm sure you've read at some point.
- mrlebowski 17y agoThe author paints too grim a picture of mainframes. Isn't legacy code supposed to be that way? As far as I know, not many new code projects are being done on mainframes. But whatever is there, has to be maintained/upgraded. Mainframes are NOT as difficult to use as the author says. They power most of the big life/general insurance companies, and they do interface well with front-ends [with XSLs in middle to convert from/to string streams]. I have worked for two years on mainframes, and loved the simple editor. Like with any command-line type editor, it has its quirks, but once you learn it, it is very fast. Also, z/OS has some version control systems (Endevour), and really good debuggers.
- AndrewDucker 17y agoAbsolutely. 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.
- thismat 17y agoSome people still refuse to invest in DB2 though, and so you're stuck with VSAM/Flatfiles for your data. It's a horrible time sink.
- cturner 17y agoI like this guy's witty banter, and his substitution of acronyms. But I particularly like this: ICBM System z is the Stonehenge of computing platforms. You go to the wiki page and look at the picture of the system and think "I can actually imagine a circle of these systems being set up and seeming very very much like stonehenge".
- 83457 17y agoLooks like an over-sized gaming console to me -- like if someone created 10 times larger PS3 for a videogame store display.
- ahlatimer 17y agoReminds me of working on HP's MPE OS (I believe I was using an HP 3000) in COBOL to keep a couponing system up and running. I won't say it was a terrible experience, but I certainly wasn't a fan of MPE or COBOL by the time I left.
- djehuty 17y agoI get the impression that moving away from COBOL, "Big Iron", and such dinosaurs has, after the initial wrench, made companies more productive. All of which makes me wonder what part the army of salesmen that go with these things play in their continued existence. (And the executive-ego-stroke of having an impressive room dominated by a bond-villianesque monolith.)
- thismat 17y agoIn my experience, the reasons are mostly just because it's been the standard for so long at said shop. 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?
- Tichy 17y agoWhat are these things used for? Why can't they ever go away? I don't really believe it...
- AndrewDucker 17y agoThey're used by people running massive systems that want all of their data to be accessible at incredibly high speeds. 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.
- thismat 17y agoRight, and incredibly high speeds is definitely accurate. I can't remember the amount of instructions/second our mainframe can handle, but I remember it being in the multiple hundreds of thousands.
- Tichy 17y agoSeveral hundred Kilohertz? :-) It IS incredible - but modern Computers are even more incredible.
- GeneralMaximus 17y agoHow fast would one of those monsters be compared to, say, a modern day Mac Pro?
- baxter 17y agoA couple of years ago I spent just over a year working as a mainframe developer on a System/360 set of mainframes and the author's description of mainframe development seems accurate. 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 ;)
- rman666 17y agoNice clean blog pages. I don't care as much for the home page, but the individual article pages are easy on the eyes.