Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What is Mainframe Culture?

Cliff posted more than 8 years ago | from the finding-common-ground dept.

Operating Systems 691

An anonymous reader asks: "A couple years ago Joel Spolsky wrote an interesting critique of Eric S. Raymond's The Art of Unix Programming wherein Joel provides an interesting (as usual) discussion on the cultural differences between Windows and Unix programmers. As a *nix nerd in my fifth year managing mainframe developers, I need some insight into mainframe programmers. What are the differences between Windows, Unix, and mainframe programmers? What do we all need to know to get along in each other's worlds?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


An idea... (5, Funny)

Anonymous Coward | more than 8 years ago | (#13099345)

"What do we all need to know to get along in each other's worlds?""

You could try exchanging porno links to one another, that seems to be the way nerds bond. Just a thought.

Re:An idea... (1)

RollTissue (896833) | more than 8 years ago | (#13099469)

LOLFTA: The very fact that the Unix world is so full of self-righteous cultural superiority, "advocacy," and slashdot-karma-whoring sectarianism while the Windows world is more practical ("yeah, whatever, I just need to make a living here")


Great suggestion! (4, Funny)

TiggertheMad (556308) | more than 8 years ago | (#13099610)

You could try exchanging porno links to one another, that seems to be the way nerds bond. Just a thought.

You are sooooo right, and if you handn't posted as an AC, I would have sent you this sweet link, called goatse.cx, to cement our friendship.

Easy (1, Insightful)

Anonymous Coward | more than 8 years ago | (#13099346)

Windows programmers program as fast as possible to maximize profit ignoring the reprecussions of bad programming while Unix programmers take pride in their product.

Re:Easy (0)

Anonymous Coward | more than 8 years ago | (#13099580)

Why was this modded flamebait? This fits my experience exactly. Every windows programmer I've ever met has been pretentiously arrogant.

first? (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#13099347)


I'm going to go with 'smell' (1)

Anonymous Crowhead (577505) | more than 8 years ago | (#13099354)

Or maybe beards?

Re:I'm going to go with 'smell' (4, Funny)

wft_rtfa (882194) | more than 8 years ago | (#13099413)

I think it's the beards. Windows programmers are usually cleanly shaved, unix programmers are usually bearded, and mainframe programmers usually have gray beards. They probably have a distinct smell, but I'm not going there.

A better name for this article... (4, Funny)

Sebastopol (189276) | more than 8 years ago | (#13099368)

"Giant Fucking Flamewar on /.: Story @ 11"

Re:A better name for this article... (5, Funny)

shigelojoe (590080) | more than 8 years ago | (#13099595)

Story @ 11 ...and 11:15, 12:15, and next Wednesday at 3:00. All worded slightly differently, of course. ;P

Answer: (2, Funny)

deutschemonte (764566) | more than 8 years ago | (#13099372)

What do you all need to know to get along in each other's worlds?

1. Windows bad
2. Unix good
3. Linux better

This is Slashdot, what kind of response did you think he was going to get?

What the hell, I'll byte... (5, Funny)

TiggertheMad (556308) | more than 8 years ago | (#13099581)

... I have plenty of karma to burn, and this looks to have been posted to start a huge flame war. Why fight fate?

1. Windows is teh bestest, like EVER!
2. Unix is ok, you get good at typing...
3. Linux stole from SCO!

I will now invite retorts. (ducks)

The Difference (2, Insightful)

Anonymous Coward | more than 8 years ago | (#13099373)

The difference is single threaded and multi threaded...Unix programmers know that they have to assume that they could be walking over someone else's session info.

Windows programmers always seem to assume they are alone in the computing ether.

Re:The Difference (4, Insightful)

Quantam (870027) | more than 8 years ago | (#13099519)

The word you're looking for is "user", not "threaded". From my experience, Windows coders are much more knowledgeable about threads than Unix programmers. Back when I was just learning some POSIX programming (I've been doing Windows programming forever) I'd ask even halfway experienced Unix programmers how to create a second thread in my program's process, and the usual response was "why on earth would you ever need to do that?"

Re:The Difference (4, Insightful)

cratermoon (765155) | more than 8 years ago | (#13099565)

"why on earth would you ever need to do that?"

That IS a good question. In Unix, creating a new process and using IPC is so simple, you almost don't need threads. In fact, before POSIX threads, Linux threads WERE processes. The advantage you got over threads was cleaner separation of memory and variables -- always worth a lot when programming in three-star C. The disadvantage, of course, was that same separation meant that everything you wanted to share had to go through IPC.

Not the best assumption. (4, Funny)

AtariAmarok (451306) | more than 8 years ago | (#13099546)

"Windows programmers always seem to assume they are alone in the computing ether."

That is not the best assumption, as the Windows app is likely to be running alongside Bonzi Buddie and at least 7,000 pieces of malware and virii.

Everything Old Is Old Again (4, Interesting)

JeiFuRi (888436) | more than 8 years ago | (#13099374)

The thing that's really preserved the mainframe over the past couple of years has not been performance; it hasn't been throughput, because those things turn out to be terrible. It's been the set of operational practices that have been codified around it. Mainframe culture and rigorous "change control," contrasts with the PC server culture of "whiz kids" who never learned the basic operational rules necessary to avoid costly mistakes.

Re:Everything Old Is Old Again (4, Insightful)

ScentCone (795499) | more than 8 years ago | (#13099409)

Why, in my day, we used stone punch cards we had to mine ourselves from the limestone quarry! Planning ahead made a lot of sense back then. Tell that to kids today, and they don't believe you!

Seriously, I think the real problem is management addicted to immediate change in production systems. This started when it was web content, and now they expect back-office stuff to change just as quickly.

Re:Everything Old Is Old Again (0)

Anonymous Coward | more than 8 years ago | (#13099478)

Everyone keeps making statements about corporate IT environments, and every time I read one, it just doesn't ring true. I work at web-development for a branch of a local university, and if anything, they are -very- much against large changes to a production system until it's gone through a fairly rigourous testing process. Even then, the old versions are kept for a long period afterwards.

Re:Everything Old Is Old Again (2, Insightful)

ScentCone (795499) | more than 8 years ago | (#13099564)

I'm guessing that you're only hearing these stories because people have actually experienced them (I know I have). Of course, these stick out because they are trouble, and the places that do it right are the ones you never hear about because there are no war stories involved (or PHBs).

Re:Everything Old Is Old Again (0)

Anonymous Coward | more than 8 years ago | (#13099616)

You work at a University. Not a corporation. Things are very very much different even though you don't know that yet. Some day you'll leave, and then you'll realize how bad it really sucked there.

I speak from experience...

Re:Everything Old Is Old Again (2, Insightful)

Jay Maynard (54798) | more than 8 years ago | (#13099492)

You got it. Unix shops are learning lessons now the hard way that mainframe shops learned the hard way 40 years ago, and they're evolving the same answers.

I agree (2, Interesting)

DogDude (805747) | more than 8 years ago | (#13099503)

I didn't get into the industry until 10 years ago, and I was amazed at this difference between the windows kids and the mainframe guys. I was a Windows/Oracle developer, but luckily I learned good practices from old MVS/greenscreen guys who taught me things that hold true no matter what kind of computer platform you're working with. I'm blown away to see some of the stupid things that new programmers/admins do. Blown away.

Re:Everything Old Is Old Again (1, Interesting)

Anonymous Coward | more than 8 years ago | (#13099572)

Fully support you JeiFuRi. In the management of UNIX and Windows world, a hot topic is ITSM (IT Service Management). It is about managing the quality, predictability and cost effectiveness of IT services. The key approach is based on some best practice material which was codified back in the '80s in mainframe environments (Google ITIL). It seemed "common sense" back then, but many Win/Unix environments have grown up without decent capacity management, change management, problem management etc. etc. etc.

The ITSM "industry" is growing 50-100%CAGR, and there are standards emerging (BS15000, AS8018, ISO20000) in this area.

I guess the key ideas in ITSM are that the primary focus is on the service, not on the technology that is used to deliver it, and that good consistent processes maximise service quality. These are ideas that have existed in the MF world for as long as I've worked in IT (+30 years), but are sometimes sadly lacking in "newer" environments.

Patrick Keogh posting as AC because I can't remember my password...

Re:Everything Old Is Old Again (1)

epiphani (254981) | more than 8 years ago | (#13099609)

I'm sorry - I'm one of those "PC server culture whiz kids". I'm 23, and I know all about change control. You're not talking about some cultural difference here, you're just talking about the influx of crappy and inexperienced management that flooded the industry when it exploaded. There are plenty of operational practices that have been codified around. Any company that runs a production system of any size should be using that software and operating by those practices.

Re:Everything Old Is Old Again (2, Informative)

BrynM (217883) | more than 8 years ago | (#13099626)

Mainframe culture and rigorous "change control,"
The best example of this is Documentation. From operator logs to the big IBM books - here you will find everything. Something named ICKDSF messing with your process? Go into the computer room or grab an IBM CD and look it up. Why did your process crash last night? Look at the operator log and find out it had to be killed because of a tape problem.

Lack of documentation is what irks me most about the PC world.

Now don't IEFBR14 reading Slashdot right after work so much ;)

I Know (0)

Anonymous Coward | more than 8 years ago | (#13099375)

Dupes and 404 errors!

The difference? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#13099376)

Simple! *nix programmers are fatter than M$ programmers and they use a different OS!

Faith Machine (4, Insightful)

Doc Ruby (173196) | more than 8 years ago | (#13099384)

This "anonymous poster" has been managing mainframers for five years, is a Unix nerd, and doesn't already know how the three cultures are different? Or are they just a Windows troll, stoking the flames of the OS holy wars?

Re:Faith Machine (0)

Anonymous Coward | more than 8 years ago | (#13099430)

A manager doesn't understand his employees, and you assume it's a troll?

How do I get to your planet?

One difference (5, Insightful)

Prof. Pi (199260) | more than 8 years ago | (#13099386)

Unix and mainframe programmers are more likely to know multiple systems, out of necessity, and consequently have a more general understanding of the commonalities of all computer systems. Windows-only programmers are more likely to know The Microsoft Way, and only The Microsoft Way. They're less likely to know standard terms, and will only know Microsoft's replacement terms. At least in my experience (and these are tendencies with plenty of exceptions).

Re:One difference (3, Interesting)

BrynM (217883) | more than 8 years ago | (#13099499)

Unix and mainframe programmers are more likely to know multiple systems, out of necessity, and consequently have a more general understanding of the commonalities of all computer systems.
You know, this is something that I have taken for granted for years. Thanks for making this point. Having done big iron, desktop and server programming has given me a definite edge in the past and I couldn't put my finger on it until your comment. The period I spent integrating some Alpha NT boxen to an S390 system (showing my age a little) really taught me a lot of versatility.

Re:One difference (0)

Anonymous Coward | more than 8 years ago | (#13099522)


Please stop using this word.

simple to explain (2, Informative)

Anonymous Coward | more than 8 years ago | (#13099389)

windows developers half ass everything. they curl up in a ball and cry if they cant use an IDE to do everything.

Unix programmers have to seperate the program into 60 different modules that all do their own thing and are called by a main program that uses all the modules to attempt to make the task work, they AVOID gui like it is walking death.

Mainfraime programmers will take weeks to decide how to start the project, endless flowcharts, argumetns about the architecture and finally when code is written it willtake months on end to test it well beyond reason before they let you even see it run.

good luck

Re:simple to explain (3, Insightful)

Wyatt Earp (1029) | more than 8 years ago | (#13099601)


The Windows Dev need a P4 with a gig of ram.
The Unix Programers can do it on a P4, but it'll work just fine on a Mot 68K or a 486.
The Mainframe Programmers think a Ti-92 has too much horsepower.

The difference (4, Insightful)

Jeffrey Baker (6191) | more than 8 years ago | (#13099391)

What are the differences between Windows, Unix, and mainframe programmers? What do we all need to know to get along in each other's worlds?

The difference is one programs Windows, one Unix, and one mainframes. As a fifth-year geek, you should take the rantings of Joel, ESR, and any other pointless windbag and send them to the bit bucket.

Good question. (5, Insightful)

BrynM (217883) | more than 8 years ago | (#13099395)

I'm a bit rusty on the mainframe side, but I'll give this a stab.

The main difference is one of resources. The mainframe folk utilize a shared resource: the Mainframe System. You may have parallel hardware, but from their point of view it's a single system. There's no ability to install a quick machine to use as a test server. Sure you can have test CICS regions or test OS partitions, but if you bring the hardware down you bring the datacenter to a screetching panic. Worse, you can piss off the operators and have 0.00001%CPU for the rest of your tenure. This keeps a certian unspoken level of panic about. Don't worry if you notice it bubble up when one of your coders fucks up. The panic symptoms will pass as it goes back down to it's normal level. It won't go away though. ;-)

Which brings me to scheduling. Remember that production=batch and batch knows no sleep. When code goes to production, it's just as bad for the stress level as a major version release of other software or a website launch. Unfortunately for the MF coder it happens a lot more often. Having to talk to your operators when you can't even see straight (from sleep or other things) takes something that is unique to this kind of coder. On-call programming takes talent and some craziness. If you can find where that is for each of them, you will realate to them well.

One last thing: make your coders work in operations for at least a week. They will have a better understanding of the hardware end and productivity will go up. There's a reason that the best coders are in the computer room a lot.

Re:Good question. (2, Funny)

Ann Elk (668880) | more than 8 years ago | (#13099487)

Unfortunately for the MF coder it happens a lot more often.

I'm curious as to which definition of MF you're using...

Re:Good question. (1)

BrynM (217883) | more than 8 years ago | (#13099537)

I'm curious as to which definition of MF you're using...
As in: I'm da mutha fukin coda - Biatch!

Yeah. That was lame. Would you believe an abbreviation for MILF? Coders i'd like to f*ck? CILF?

All right. I meant mainframe. ;)-~

A couple of comments (1, Informative)

Anonymous Coward | more than 8 years ago | (#13099584)

if you're from Windows or Unix you think of systems as I have this much data space, I write these programs, I execute this, etc.

MF world is very different.

Dataspaces are shared by default - and are often owned by the application type rather than a user. And space is measured very differently (often blocks rather than kbytes).

Not that this bothers the MF. Their job is to write a script (it's closer to a script than a program) to rip thus dataspace A, do something, and print the results to B.

Tools? Provided by the OS. And more study is needed to master than unix tools (imo).

If you think about data structures (or classes) you're in a different world the MF. They think about records (rows in that dataset).

Ever write a sort routine? Know the difference between bubble-sort and quick-sort? The average MF doesn't. He calls the system level command SORT and he's done.

And don't get me started on EBCDIC

never going to happen (0, Troll)

know1 (854868) | more than 8 years ago | (#13099398)

the reason this will never happen is the main difference is that windows programmers are used to working for an evil company that subverts your privacy, and don't care, not to mention anything about coding techniques, wheras the unix side of things is generally filled by people who found out all these things and did care. bill wants monopoly and will keep changing the goalposts of compatability to make things rough. And just like the terrible government you Americans have, i don't think the public is going to do anything about it, even though they are informed enough, mostly (admittedly more about the government than microsoft, but still..).

Typical Spolsky (1, Informative)

Anonymous Coward | more than 8 years ago | (#13099399)

It's a lot of great insights into something the author wasn't saying. He rips the idea that a program should output well formatted parsible text and be generous with what it accepts as a general rule and pretends it's seen as an absolute rule.
But this isn't always considered good, examples:
linux::rpm #provides a lot of pretty output options

In fact, in other chapters Raymond talks about the 7/10ths of a second rule. That says that the most time your program should be quiet, usually, is 7/10ths of a second. It makes sense, especially on the command line and slightly less in the gui, because that's about how much time the most impatient people can't stand to wait. And it's about how long it takes people to think "teh omg it's teh uberlox0red."

I've read Joel's book by the way; and he seems to contradict himself a lot with many great insights. In fact, he's a very smart guy with amazing insight; it's connecting it into a final conclusion and removing the thoughts that were just wrong that he's terrible at.
In other words: Provide your own conclusion for Joel's ideas; his conclusion is almost invariably based on an incomplete set of facts.

The difference between Unix and Windows cultures are many, and the technical differences show up. In fact, Joel talks about that in his book (which is just his blog on paper). But of course, here he says they're technically the same (sure, if you only look at kernel level things and gloss over higher stuff at such a distance that a dog looks like a cat).

By the way, this is so old it's in his book!

Re:Typical Spolsky (1)

kcurtis (311610) | more than 8 years ago | (#13099538)

I don't think he rips no-output programs. He just points out the contradictory uses of verbose vs. non-existant output. Some situations should see the command prompt as an indication of success -- much of *nix. Some should show a response -- telling grandmama that her mpeg of the grandkids is done downloading and ready to view.

On the other side of that argument is the fact that many of those progress bars in various apps aren't even linked to the underlying process -- they are just eye candy for those many impatient users you refer to. Nothing wrong with that imho either.

Criminal offence (0, Flamebait)

it_flix (808213) | more than 8 years ago | (#13099401)

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. - Edsger Dijkstra That said, mainframe/cobol programmers are just second grade grammar teachers posing as computer programmers

Decent programmers... (1, Insightful)

rbarreira (836272) | more than 8 years ago | (#13099403)

can easily program for all of those systems.

So there is no difference. There programmers and non-programmers. Some non-programemrs don't program at all, others pretend they do. Programmers will quickly adapt to any operating system. One of those groups has a future, and the other one does not.

Interoperability (1)

RollTissue (896833) | more than 8 years ago | (#13099408)

FTA: in the Unix culture, which Raymond calls "Silence is Golden," that a program that has done exactly what you told it to do successfully should provide no output whatsoever. It doesn't matter if you've just typed a 300 character command line to create a file system, or built and installed a complicated piece of software, or sent a manned rocket to the moon. If it succeeds, the accepted thing to do is simply output nothing. The user will infer from the next command prompt that everything must be OK.

This is *so* true of my UNIX brethren.

While windows programmers arguably have better tools with which to develop, the UNIX users rely on "just get it done and tell me if there are issues".

The most important quality IMO is to create an environment with HIGH interoperability. Let your Windows users do what they do, while giving your UNIX and mainframe users have their world like they want it.

You mix it all together and have a nice product.

Re:Interoperability (2, Informative)

$RANDOMLUSER (804576) | more than 8 years ago | (#13099485)

In my VAX/VMS days, we'd type these incredible "FOO /INPUT=BAR /OUTPUT=BAZ /NOEVERLASTINGGOBSTOPPER /COKEBOTTLE /SINCE=10-17-82" type commands, and when the DCL prompt came back, we'd scream "It Loves It!!!!!".

I finally understand (0, Offtopic)

Marxist Hacker 42 (638312) | more than 8 years ago | (#13099414)

The one thing I, as a microcomputer (not neccessarily limited to Windows, just forced there by the market) programmer have never understood: The propensity of mainframe programmers to output huge numbers of columns of text for import/export files. At the state agency that I currently am contracting at, I've seen 200-300 columns of data in basically position delimited flat file format, which gets imported into 20-30 tables of relational data. I never understood this until I RTFA'd- and now I understand- they're going for least common denominator probably due to the huge amounts of storage available on a mainframe.

it's easier than you think (3, Funny)

pikine (771084) | more than 8 years ago | (#13099419)

For Unix devs:

1. Learn to CamlCase your API, variable names, etc.
2. Turn all '-' or '--' into '/' in command line arguments.
3. Use 'dir' instead of 'ls -l'

For Windows devs:

1. Learn to lowercase all your API, variable names, etc.
2. Turn all '/' into '-' or '--' in command line arguments.
3. Use 'ls -l' instead of 'dir'

A summary: (5, Funny)

millennial (830897) | more than 8 years ago | (#13099422)

Windows programmers don't know how to program without a GUI.
Linux programmers don't know how to program with a GUI.
Mainframe programmers wonder what a GUI is.

end humor transmission.

Mod topic -10 Clueless (0)

Anonymous Coward | more than 8 years ago | (#13099425)

What are the differences between Windows, Unix, and mainframe programmers? What do we all need to know to get along in each other's worlds?"

The fact that you even have to ask shows that you haven't a clue. Linux and other hardcore Unix users will die wondering what it was all about and why things like command lines, /usr/bin/ and X11 never really caught on. If you don't know the answer to why Linux's giant wardrobe computiting mentality is not compatible with life for 99% of people then what is the point.

Um... (0)

Anonymous Coward | more than 8 years ago | (#13099593)

The fact that you even have to ask shows that you haven't a clue.

If he had a clue, he wouldn't be asking now would he?

Programmer generalizations (0)

Anonymous Coward | more than 8 years ago | (#13099429)

Windows: best-balanced
Unix: smarter
Linux: uglier
Mainframe: older

Re:Programmer generalizations (2, Insightful)

el-spectre (668104) | more than 8 years ago | (#13099508)

Whoa... MS folks are better balanced? Not trying to fan flames here, but I work with a lot of MS guys who don't understand basics of technology, but only the bloody MS API.

For example (I'm a web geek) we're trying to figure out why a HTTP request is getting garbled.

My first response: "ok, lets look at the whole request -it's just text- and see what it says"

MS-Guy's response: "I don't know... there's no method in the API for that..."

And that, kiddies, is why I try to remain skilled cross platform :)

Re:Programmer generalizations (0)

Anonymous Coward | more than 8 years ago | (#13099562)

Well, where I work, we develop UNIX applications but we use Visual C++ to program and debug 95% of the time. So my view might be a bit biased. I think I am smart and beautiful ;)

Mainframe programmers are *old* (4, Interesting)

billstewart (78916) | more than 8 years ago | (#13099431)

Hey, I was a TSO wizard back in ~1980, but fortunately I haven't had to use that stuff in ages :-) However, you'll find that mainframe programmers mostly look like Sid in Userfriendly.org - either grey hair or no hair. Mainframe programmers, like Unix and Windows programmers, range from the old wizard who can answer really arcane questions about JCL syntax from memory to some Cobol drone who went to trade school, like the Visual Basic trade school drones of today.

The reasons mainframes are interesting, to the extent that they are, is that they can handle very large databases with very high reliability, which is not the same as being fast (though some of IBM's newer mainframe products are also quite fast.) That means there's a heavy emphasis on building and following processes for deployment and operations so that things won't break, ever, at all, even when the backup system's down for maintenance, and on building processes to feed data in and out of this rather hostile box so every bit gets bashed like it's supposed to. The programming environments have gotten better, but you're looking at a level of flexibility like Debian's Oldest-and-most-stable releases, not like Debian sid.

Does it Measure Up? (5, Funny)

Sponge Bath (413667) | more than 8 years ago | (#13099440)

What are the differences between Windows, Unix, and mainframe programmers?

The length of the beard?

Simple. (0)

Anonymous Coward | more than 8 years ago | (#13099444)

Mainframe Programmers are RETAAAAADED!

Don't reboot (5, Funny)

HermanAB (661181) | more than 8 years ago | (#13099454)

Mainframers know that you cannot reboot a machine willy nilly, since someone may be running a simulation that takes 6 months to complete, he may be in month 5.5 now and on first name basis with the guy that normally signs your pay cheque...

Firmly in a closed box (0)

Anonymous Coward | more than 8 years ago | (#13099456)

Mainframe programmers are non-creative, repetitive programmers. They don't know how to do anything new. It is tha same rehshed, crappy stuffy code, over and over again. All they know are flat files and copybooks. Best thing to do is to unplug the mainframe. At least it will help stave off global warming.

simple (2, Funny)

b17bmbr (608864) | more than 8 years ago | (#13099461)

windows programmers have to learn completely new shit every two years. unix programmers keep programming the same shit year after year.

laugh. it's a joke.

Minicomputer culture (close) (1)

Frumious Wombat (845680) | more than 8 years ago | (#13099462)

My past experience was that you tend to think in terms of queues; you (physically) queue up for the keypunch, submit your job to a queue, and go find the appropriate print queue the data came back off from. The other experience has always been (Unicos, VM/XA or VM/CMS systems) that the software environment is antiquated to the point where you're encouraged to do as much off-line as possible. Get in, do work, get out.

The computer, therefore, is a far more abstract, remote, and non-interactive object. I remember what an unpleasant change moving from an 11/785 running VMS to a 3090/VF running VM/CMS. The programming tools were arcane, the OS didn't even have subdirectories (it did have minidisks; i.e. your own virtual pile of floppy disks), and the editors definitely underwhelming. On the other hand, like a VAX/VMS system, the queueing system was an integral part of the OS, so it worked smoothly, as opposed to the unix solutions that are bolted on the side as an after thought. Sun Grid Engine and LSF are pretty close to the old VAX queues, but still not quite as well integrated.

This, of course, is not entirely fair, as large VMS systems were used like mainframes, but still had good tools and a friendly user environment. In the end, think of it generally as a tightly-regulated, non-interactive environment. It's the kind of environment for utter reliability, where it's primarily computers talking to other computers.

On the difference (5, Insightful)

Tsiangkun (746511) | more than 8 years ago | (#13099465)

Unix programmers like their code like the old legos. Each piece might be a different size or shape, but the bottom of one snaps onto the top of another and the ordering and number of pieces used is left as an excercise for the reader. With experience, anything can be built with the pieces, and yet each piece is simple and easy to understand.

Windows is like the new lego sets. You get specialized premolded parts suitable for one specific task, plus two or three additional add-on pieces that give the illusion of being fully configurable for any task. You can build anything you want with the new legos, as long as you only want to build what is on the cover of the package.

Yeah, that's it in a nutshell.

Programming in COBOL (5, Interesting)

cratermoon (765155) | more than 8 years ago | (#13099479)

I've never actually written any COBOL myself, but here's what I've learned from trying to teach Java to former mainframe developers.
  • COBOL is actually remarkably like wordy assembly language
  • The typical mainframe programmer, being steeped in COBOL, will think of everything in "records".
  • Mainframes are case-preserving but case-insentive. Like DOS, a token can be any mixture of case an it will work. Thus, a mainframer might wonder why 'PRINTF' doesn't work for 'printf'.
  • On the same topic, a mainframer will assume that something like the Java type 'Account' and the variable 'account' actually don't distinguish anything, and will be confused when the compiler refuses to assign to a type.
  • MOVE CORRESPONDING is COBOL's big hammer. It will take all the values of the elements of one record and copy them to the "corresponding" fields of another record. There is nothing like type-checking for this. This will cause mainframers to be confused about why you can't assign a linked list to an array and have it "just work".
  • Not that mainframers will grasp "linked list" or "array". Actually, they won't really get any of what we call the standard data structures and algorithms learned in the first year of any CS program.
  • COBOL programs have no scoping rules. EVERYTHING is global. Thus, a mainframe programmer won't understand why an assignment way over in some little function in another library to a variable called "date" won't affect the "date" value in the code everywhere.

M/F is just a job (4, Interesting)

ThePolkapunk (826529) | more than 8 years ago | (#13099480)

As a *nix programmer forced into the mainframe world, I'd have to say that m/f programmers do not look at computers as a hobby or thing of interest. To them, programming and computers are just what they do to get paid. To the m/fers, a computer is just a tool that they have to use to do their job. They take no joy or pleasure in programming, it's just what they do.

On the other side of the coin, I think that *nix and Windows programmers tend to enjoy what they do. To them, programming is not just their job, it's enjoyable.

Honestly, I don't blame them. M/F sucks. As soon as you get your first compile error because your command isn't in the right column, or have JCL spit out a bunch of random nonsense because you didn't allocate the correct blocksize for your file you'll hate your job too.

Re:M/F is just a job (1)

cratermoon (765155) | more than 8 years ago | (#13099517)

Definitely true. They are ready to drop everything and head out the door at 5pm Friday (provided there are no "production issues") and not think about computers again until 9am Monday. The idea of software development as a profession that requires continuous learning is foreign to them.

Re:M/F is just a job (1)

Neil Blender (555885) | more than 8 years ago | (#13099627)

They are ready to drop everything and head out the door at 5pm Friday (provided there are no "production issues") and not think about computers again until 9am Monday.

There is something to be said about that. For me, computers are M-F (hobby stuff at night), and weekends are for anything but.

How to manage directories? (0)

Anonymous Coward | more than 8 years ago | (#13099506)

Not even the mainframe peeps seem to get this right!


Not a dupe! (0)

Anonymous Coward | more than 8 years ago | (#13099507)

With all the talk about dupes going around, I thought we should pat the editors on the back and proudly proclaim: This story is most decidedly not a dupe! It's the first story in hours that isn't, but... If we praise good story selection, they just might learn...

The differences . . . (1)

claywar1 (900809) | more than 8 years ago | (#13099513)

Windows Programmers are from Omicron Persei 7, as *nix users are from Omicron Persei 9?

Lean towards textual interfaces because of density (3, Insightful)

SuperKendall (25149) | more than 8 years ago | (#13099521)

From the article:

*Unix Programmers* don't like GUIs much, except as lipstick painted cleanly on top of textual programs, and they don't like binary file formats. This is because a textual interface is easier to program against than, say, a GUI interface, which is almost impossible to program against unless some other provisions are made, like a built-in scripting language.

I would disagree with this assesment, instead I would say people who prefer textual interfaces do so beacuse they often offer a much denser display of information. You can get a lot of information packed into text that may be quite spread out in a GUI.

Also I would say that people eventually come to favor programs with scripting interfaces.

It seems to me that as users grow more sophisticated eventually all users become programmers in at least a specific domain, or at least desire to. All users grow used to a tool, and after a while they start wanting more dense an informative displays.

Just look at PhotoShop, probably one of the longest running commercial applcations (i'm sure there are others that elude me but it's just a really good example). Does that even follow any kind of UI guideline? No it does not; there are so many users that have used it for so long, that they demand a richer and more complex interface. Over time they demanded plugins and then of course scriptability (through actions).

Yes Windows was a way to bring many people into computers that could not have come through UNIX. But in the long run users grow into wanting more flexible uses of the computer and they start leaning towards the "UNIX Way" and looking for apps that are pluggable and scriptable.

Command line apps are easy to use (1)

Archimboldo (847057) | more than 8 years ago | (#13099525)

- You can link them together.

- You have access to hundreds or thousands of commands in one window. No wending your way through endless menus and submenus.

Look in the trunk (3, Funny)

AtariAmarok (451306) | more than 8 years ago | (#13099526)

Just look at the tools in the trunk of their cars. The Linux and Windoze guys will have a few screwdrivers rolling around there. The mainframe guys have blowtorches.

From what I remember. (2, Funny)

GoofyBoy (44399) | more than 8 years ago | (#13099550)

Where the control-key modifier is in Unix, the Enter/Return (one of these) is in Mainframes, is the wavey flag is in Windows.

AHH (2, Funny)

Mozk (844858) | more than 8 years ago | (#13099555)

How do you post something from December 14, 2003, and get away with calling it news for nerds?

it's a state of mind (0)

Anonymous Coward | more than 8 years ago | (#13099557)

I don't know if you can. I don't think bellheads will ever get the nethead think. Same with mainframe retreads. Or stubborn UNIX heads. Or Windows lovers.

If you can understand the other side, the label doesn't fit in the first place. The label is an indication of narrowmindedness all in itself. My $.02.

So, rather than asking how to get along, be openminded enough about different ways of thinking (or not) and the world will sort itself out.

a few observations (3, Interesting)

porky_pig_jr (129948) | more than 8 years ago | (#13099566)

I was working with IBM MVS (batch oriented) and VM (interactive) for quite a while. At that time the main choice was between COBOL and Assembly Language (BAL/370). COBOL provided some basic routines, but do to something interesting (like asynch I/O, your own memory management, etc) you had to use BAL.

The following example might be interesting, not sure if helpful. On batch system you have many jobs executing concurrently. MVS (at that time) didn't have anything like preemptive multitasking. COBOL didn't have asynch I/O either, so when it issues I/O it just goes into a wait state, so another task is scheduled. So the bottom line was that your program won't be very efficient (e.g., won't be overlapping I/O and CPU activites), but that would create a nice (from MVS perspective) mix of jobs. Some are doing I/O, some are doing CPU, so MVS can accomodate many concurrent tasks.

Well, at that time I was budding assembly language programmer and even took a course at university where we had to write our own operating system, entirely in BAL/370, including the Initial Program Loader (boot, if you wish). I was working at the same time, and there was a problem at my job. They (John Hancock Insurance) had hundreds and hundreds of COBOL programs, and nothing like cross-referencing dictionary, like which program modifies some common record fields. So when something unexpected happened, they had to search through the source code, to find all the instances of such references and that was taking something like 5-6 hours. I've learned asynch I/O at school and how to overlap I/O and CPU activites, and I've ended up writing fairly efficient program. Program was reading large chunks of disk data into several buffers. As soon as the first buffer was full, that event was detected, and the program starts parsing that buffer for some keywords --- while continuing reading the tracks into other buffers. (it was a circular list of buffers). After some trials I got the execution time down to less than 20 minutes. Everyone in my area was happy.

Everyone except mainframe operators. I've been told they HATED my program to its guts. The problem was that the program didn't behave nice as far as 'good mix' is concerned. It grabbed the resources and hold them for a long time because it went to the wait state only occasionally. But that was a great help for production problems, so they had to let it run.

That was many years ago. I don't know if MVS got changed so to introduce preemptive multitasking. At that time it was a strictly batch-oriented system. All I/O was executed in a separate subsystems (channels). To run something interactive (like CICS) wasn't trivial at all. The best strategy was to dedicate entire mainframe to such task. Mixing CICS and batch jobs int the same machine was suboptimal solution. Of course, MVS scheduler got improved since, to provide better balancing between batch and interactive tasks, and yet, as I understand, MVS fundamentally remains batch operating system.

#1 Cultural Difference (3, Funny)

iamdrscience (541136) | more than 8 years ago | (#13099567)

Mainframe guys don't reboot their system. Unix guys reboot the system occasionally. Windows guys reboot their machine several times a week.

spoiled (1)

wardk (3037) | more than 8 years ago | (#13099573)

Mainframers are a sad lot, stuck with all those tools that actually work, and consistently.

summary (1)

slashdotnickname (882178) | more than 8 years ago | (#13099588)

So, basically, to summarize his blog entry...

linux for nerds, windows for dumbasses

Not to say it's was a bad article, it's a good read, but I couldn't find any new insights into this over-discussed topic.

Fucking jew fags... (-1, Troll)

Anonymous Coward | more than 8 years ago | (#13099608)

...typical jew faggot homosexual relations work. Just ask Ralph Nader!
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account