Michael said:
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
programmer make.
--RY
(e-mail address removed) writes:
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
platform.
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.
[/QUOTE]
Indeed! Designs that work under one O/S can seem incredibly bizarre in
the context of another O/S. I recall, years ago on comp.os.vms, people
from the Unix world wondering why their programs that created 150,000
twenty-three byte files ran like a dog on VMS. File creation is slow
and expensive and creating them all in the same directory made it even
slower and more expensive. A VMS programmer would have created a single
indexed sequential file with 150,000 records; what would have been
filenames in the original design would become keys in the indexed file.
That would have been blazingly fast under VMS but could not have been
done in a native Unix filesystem without writing or buying the software
to create and manipulate an indexed sequential file.
Unix function calls tend to be part of the C runtime library under any
O/S; in other than Unix O/Ss, some parts of the C library form an
"abstraction layer" that maps to the native system services.
