Re: Unix programmer definition
From: Richard B. Gilbert (rgilbert88_at_comcast.net)
Date: Tue, 04 Jan 2005 00:13:46 -0500
Michael Vilain wrote:
>In article <email@example.com>, Randy Yates <firstname.lastname@example.org> wrote:
>>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
>>>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.
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.