Re: Book questions
Quoting Petter Adsen (petter@synth.no):
> I do know a little Perl, I learnt it back when I used it for some CGI
> work. This was many years ago, and I haven't really kept it up to date,
> but it has come in very handy many times when I don't know how to do
> what I need in a shell script.
I learnt Perl4 on DOS because AFAIK it was about the first decent
scripting language available on that platform (and ran in extended
memory). It *was* my shell. IIRC the DOS versions of sed etc were much
less like their unix originals than Perl was.
> My understanding is that learning C might give me a better insight into
> how Unix-like systems work, and be a tool to interact with them. There
> are other languages I want to learn, like Lisp and maybe Python, but I
> need to start somewhere. I'm not hoping to be writing device drivers
> next month,
Coming from a background of Fortran and OS/360 Assembler, I didn't
find writing a simple device driver for linux too daunting. With
Rubini's book, it's was a matter of programming by example. However,
the idea of writing anything more than trivial programs in C *is*
daunting to me.
I did use Richard Stevens's books (APUE and UNP1) when I was writing
socket programs, even though I was writing in Python, he in C.
Brilliantly written and a joy to read (the books, not my code).
> but I hope to learn enough that when a program does
> something unexpected I can have a look at the source and try to learn
> what is going on.
You can probably learn a lot by reading selections of the kernel
source, /etc/init.d scripts and so forth, or some recently
well-written/re-written packages. But I think that to become a good C
programmer requires the sort of mind that enjoys focussing on and
perfecting details. There are more than enough ways of hanging
yourself in C, and the language does little to hold your hand.
But I think it might help to decide what your problem area is. To do
"real work" and achieve results, I would have thought a much
higher-level language than C would likely be preferable.
The big switch in my computing career came when someone thrust
Griswold's book on Snobol4 into my hands, and I discovered I could
process text like I had been processing numbers. (Even though Phil
Hazel's editor "Zed" was a brillant tool, it wasn't a general purpose
language.)
Over the years I pursued associative arrays (Snobol's tables, Python's
dictionaries, the killer structure that I had been missing) through
Spitbol and Perl4 to Python which is where I am today. What I lost on
the way was Snobol's pattern matching which was even more flexible
than regular expressions, but the danger was that programs could start
to look like something out of Perl's Obfuscation Contest.
(Notwithstanding the fact that every Snobol statement can be a two
branch!) It was also the first language I'd met (apart from Assembler)
that could write code and then execute it.
> While I don't know much about it, C seems to be quite flexible and also
> quite embedded in the Unix world. I guess those are two of the main
> reasons I want to learn it.
But I think you have to have something you really need to do with C
in order to motivate you to keep on trying when it gets difficult.
Which it will do, if you try to do non-trivial tasks. I've sat through
many a class (years ago) and done the exercises, and thought "So what?"
> I can understand that :) What I mean by "portable", is "can be compiled
> on many/most Unices". I used to work with Solaris, Irix and HP-UX, and
> very quickly saw the value in being able to compile the same tools on
> different platforms.
A lot of these implementation details just evaporate with a good
choice of high-level language. That's Guido's job (Python).
Learning a language is great fun, but especially if you've got a good
reason/motivation for learning it and trying it out. I can still
recapture the excitement of devouring Griswold, Schwarz and Lutz.
Cheers,
David.
Reply to: