Re: Unix programmer definition
From: Michael Vilain (vilain_at_spamcop.net)
Date: Mon, 03 Jan 2005 20:29:36 -0800
In article <email@example.com>, Randy Yates <firstname.lastname@example.org> wrote:
> Hi jrefactors,
> As one who has done some programming on a unix platform (Sun/Solaris 8)
> for about 5 years now, I feel I can make an attempt at answering your
> question. I trust the knowledgable folks in this group will correct
> any errors I may make.
> When I hear the term "unix programmer" I think of someone who is a
> very good C/C++ programmer, as you say, but who is additionally
> familiar with the unix way of thinking. That is, they're not afraid of
> a command line prompt and don't need a GUI for every program they
> use. They're definitely familiar with grep (or egrep or fgrep), and
> probably sed, tr, and (gnu)make as well. They use an editor like vi
> or emacs or xemacs, yearn for the days when systems were open to the
> point where one could ftp or xterm just about anywyhere.
> They may also be up on X-windows programming (which I've never done).
> Just my $0.02.
You might want to take this top post with a grain of salt and "keep the
change". IMO, knowledge of the UNIX shell tools does not a UNIX
> email@example.com writes:
> > when people say unix programmer, does it mean they write programs in
> > unix environment,and those programs are run in unix platform? it is not
> > necessary they are using unix function calls? I heard most of the time
> > unix programmers are C and C++ programmers.
> > please advise. thanks!!
Whether you're using a UNIX variant or some other OS, most computers
have ways of doing things that are specific and optimized for that
Case in point--a company had a CASE tool that ran great on UNIX because
"forking a child process" on UNIX is quick and cheap. fork() and exec()
all you want. child does it's thing, then exit()s. Easy and fast.
On VMS, "spawning a subprocess" is slow and expensive, so you kept it
around and communicated with it using interprocess communication calls.
The VMS version of the CASE tool sucked. The UNIX programmers couldn't
find a way around their design to make it work effectively on VMS.
Eventually that branch of the product died.
A systems programmer would know this sort of thing about how UNIX or VMS
or TOPS-20 or RSX-11 or Solaris did it's thing. The language used is
irrelevant. Understanding how an OS works is more relevant. I've
written a tape copy program in FORTRAN which called VMS system service
calls. Applications programmers who work on programs that run on UNIX
or NT or MVS wouldn't need to know this nor do they tend to care.
-- DeeDee, don't press that button! DeeDee! NO! Dee...