M
Michael Mair
Mark said:
Good analysis, even though I am biased much more towards C as a first
language -- but I guess that is no crime around here...
Cheers
Michael
Good analysis, even though I am biased much more towards C as a first
language -- but I guess that is no crime around here...
Cheers
Michael
M
Mark F. Haigh
Michael Mair wrote:
I'd be willing to bet that most people claiming C was their first
language were programming *something* (A BASIC variant, batch files, TI
calculators, shell scripts, spreadsheets, whatever) beforehand. To
people like that, those "don't count". On the contrary, I maintain
that they do count. Heavily.
If a person can be dissuaded from learning C, the person probably
shouldn't be learning it anyways. On the other hand, if a person has a
burning need to learn C and it's their first language, then I certainly
sympathize and try to help when I can.
Mark F. Haigh
(e-mail address removed)
Good analysis, even though I am biased much more towards C as a first
language -- but I guess that is no crime around here...
I'd be willing to bet that most people claiming C was their first
language were programming *something* (A BASIC variant, batch files, TI
calculators, shell scripts, spreadsheets, whatever) beforehand. To
people like that, those "don't count". On the contrary, I maintain
that they do count. Heavily.
If a person can be dissuaded from learning C, the person probably
shouldn't be learning it anyways. On the other hand, if a person has a
burning need to learn C and it's their first language, then I certainly
sympathize and try to help when I can.
Mark F. Haigh
(e-mail address removed)
K
Kanthi Kiran Narisetti
Hi All,
Thank You all for your suggestions. I am sorry to say that this post
has became a debate rather than helping me out to make decision.
As a systems administrator I am aiming to learn programming which would
help to write programs or scripts to make my work simpler, rather than
becoming a C programmer or Perl programmer i want to learn programming
so that i should be able to make switch to new programming language
fast or with not much struggle.
Look i am looking to learn good programming rather than any specific
programming language, as said earlier in this post it would be better
to start of with some thing i will use in daily life, in this case
what would be best Language for Systems Administrator( irrespective of
OS).
Thank you once again.
Kanthi
Thank You all for your suggestions. I am sorry to say that this post
has became a debate rather than helping me out to make decision.
As a systems administrator I am aiming to learn programming which would
help to write programs or scripts to make my work simpler, rather than
becoming a C programmer or Perl programmer i want to learn programming
so that i should be able to make switch to new programming language
fast or with not much struggle.
Look i am looking to learn good programming rather than any specific
programming language, as said earlier in this post it would be better
to start of with some thing i will use in daily life, in this case
what would be best Language for Systems Administrator( irrespective of
OS).
Thank you once again.
Kanthi
M
Malcolm
The problem is, there is no consensus.Kanthi Kiran Narisetti said:
I learnt BASIC at school in the 8-bit microcomputer days. Computing was a
craze and pretty soon many of us were doing things way beyond what was
considered within a schoolchild's abilities.
I got a ZX81, a copy of Toni Baker's "Machine Code on your ZX81" and never
looked back.
However other people who are perfectly good maybe even better programmers
than me learnt in totally different ways, for instance by learning formal
methods, or through scripting languages.
The other factor is psychological. In the 1980s, a schoolchild could write a
game on a microcomputer that bore comparison with commercial products. Now
it is no longer possible to knock up the next rival to Doom in your spare
time. So the motivation to mess about is less. However a schoolchild can
maybe design a perfectly competent website with javascript and stuff.
G
gtippery
Kanthi said:
Debates aren't necessarily bad, if you want to hear more than one side
of an issue.
"make my work simpler"
In that case, definitely whatever shell / batch / Job Control
language your system supports, first. Then it depends on what
specific administrative tasks you want to do. As well as the other
considerations we've mentioned, of course. Specifically, "scripting"
and "interpreted" tend to go well with this goal.
"learn good programming" and "be able to make switch to new
programming language" do go together, but if they coincide with
quickly or easily making your work simpler, it'll just be luck.
Particularly, "scripting" tends not to match these requirements,
because scripting tools tend to (1) be optimized for small, ad-hoc
programs vs. well-designed ones, and (2) favor making specific
administration-type tasks (sorting, report generation, I/O, OS
interface) easier at the expense of readability, generality and/or
rigor.
As a compromise, you might try to find a scripting tool like perhaps
csh, which "resembles" a full-scale language -- C, in this case.
That may ease the transition. Or it might just confuse you -- people
differ. I've been told my wife's grandmother took courses in
multiple foreign languages simultaneously -- in her 60's. I think my
brain would implode if I tried that...
One last observation: if you want to be able to learn new languages
(computer languages, I mean) quickly, it's very helpful to have been
exposed to several widely-varying architectures. I believe the
trendy word is "paradigms". In this respect, FORTRAN, ALGOL, PL/1,
BASIC, C, Pascal and others are much more alike than they are
different. But COBOL or RPG will teach you different things than
APL, or Forth, or Smalltalk, or Prolog. A memory-oriented CISC CPU
will teach you different things than a register-oriented RISC CPU. A
microcontroller vs. a mainframe, etc. If you only experience one
kind of thing, it gets "embedded" in your mind as _the_ way things
ought to be. (You can find abundant samples of that in "certain"
newsgroups <grin>. See also "holy wars".)
Good luck in whatever path you take.
K
Keith Thompson
Kanthi Kiran Narisetti said:
<OT>
For Unix/Linux system administration, you definitely need to learn the
Bourne shell (and its descendents, bash and/or ksh). One thing that
will make this easier is that it's both a programming language and the
way you interact with the system. (Personally, I learned csh first,
and I still use its relative tcsh, which is ok for interactive use but
not so great for programming; if I were starting over, I might do
things differently.)
You also need to understand "make", used for building software.
I find Perl to be a good tool for Unix administrative work; Python is
probably cleaner and similarly powerful, but you'll almost certainly
have to deal with other people's Perl code anyway so you should learn
the language. The book "Learning Perl" is a good tutorial; there's
also a book called "Perl for System Administration". (O'Reilly
publishes a lot of excellent books and surprisingly few mediocre
ones.)
</OT>
You should definitely learn C eventually (after all, that's what the
OS and most software that runs under it are written in). Be sure to
keep in mind the difference between what's defined by the language
standard itself and what's defined by extensions such as POSIX.
Most of these things work under Windows as well, but Windows system
administration will require a different set of skills in some areas; I
can't help with the details.
E
Erik de Castro Lopo
Kanthi said:
Since you are targeting Linux and windows, I would say Perl and Python
over C for the following reasons:
- GUIs in Perl and Python are far easier than GUIs in C.
- Its far easier to write cross platform code in Perl and
Python than C.
I don't want to start yet another Perl V Python flameware, but I would
also suggest Python over Perl because Python is far more readable
than Perl and far better for beginning programmers.
There is also a very beginner friendly Python newsgroup while the Perl
group is far less forgiving of beginner questions.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo (e-mail address removed) (Yes it's valid)
+-----------------------------------------------------------+
When aiming for the common denominator, be prepared for the
occasional division by zero.
P
pepsikolanut
Kanthi
There's no straight answer, because everyone has their own opinion.
Personally, I say you should learn C, because once you learn C, you can
pick up other languages in no time, whereas I can't say the same the
other way around. Scripting languages in general are bad for learning
good programming.
While Perl is pretty handy for sys admin, there's really no reason you
can't use C to do the same job, so actually you can in fact use it a
lot in your daily life. A lot of times I use a combination of C, shell
scripts, and (not so much) Perl together to accomplish a task,
whichever makes things easier.
There's no straight answer, because everyone has their own opinion.
Personally, I say you should learn C, because once you learn C, you can
pick up other languages in no time, whereas I can't say the same the
other way around. Scripting languages in general are bad for learning
good programming.
While Perl is pretty handy for sys admin, there's really no reason you
can't use C to do the same job, so actually you can in fact use it a
lot in your daily life. A lot of times I use a combination of C, shell
scripts, and (not so much) Perl together to accomplish a task,
whichever makes things easier.
W
Walter Roberson
:While Perl is pretty handy for sys admin, there's really no reason you
:can't use C to do the same job, so actually you can in fact use it a
:lot in your daily life.
In practice, you have to be experienced with C in order to use non-trivial
perl CPAN (pre-written easily-downloadable library) modules. A number of
CPAN modules use C underpinings for speed reasons, or to do things that
perl cannot do itself. That C code isn't always particularily portable.
Also, when you install perl, it grots through your system include files
to turn some of them into [useful] perl include files, such as is done
local system definitions of permission bits and what-not.
Unfortunately, those transformation routines are not entirely adept at
working with conditional compilation, such as for headers that might be
included by both C and C++ routines, or headers that might make use of
pragmas, or headers that test which standards one has available (which
C, which POSIX 1003.1 edition, which XPG4, etc.) The result can be that
even what would seem to be simple matters such as extracting the exit
status of a process (i.e., <wait.h>) can blow up in perl
[Historically it has not been unusual for Unix systems to define
the wait() result in terms of a union of an integer type and a
structure of bitfields; perl doesn't always pick up on that...]
:can't use C to do the same job, so actually you can in fact use it a
:lot in your daily life.
In practice, you have to be experienced with C in order to use non-trivial
perl CPAN (pre-written easily-downloadable library) modules. A number of
CPAN modules use C underpinings for speed reasons, or to do things that
perl cannot do itself. That C code isn't always particularily portable.
Also, when you install perl, it grots through your system include files
to turn some of them into [useful] perl include files, such as is done
local system definitions of permission bits and what-not.
Unfortunately, those transformation routines are not entirely adept at
working with conditional compilation, such as for headers that might be
included by both C and C++ routines, or headers that might make use of
pragmas, or headers that test which standards one has available (which
C, which POSIX 1003.1 edition, which XPG4, etc.) The result can be that
even what would seem to be simple matters such as extracting the exit
status of a process (i.e., <wait.h>) can blow up in perl
[Historically it has not been unusual for Unix systems to define
the wait() result in terms of a union of an integer type and a
structure of bitfields; perl doesn't always pick up on that...]