[lug] Learning to code on Linux.
David Morris
lists at morris-clan.net
Sat Mar 28 20:20:41 MDT 2009
On Sat, Mar 28, 2009 at 19:00, Bear Giles <bgiles at coyotesong.com> wrote:
> I'm going to take a contrary voice here.
>>
>> A friend called me today to ask about getting the source for libc. I
>> installed Linux for him but didn't include the source packages. He wants to
>> rewrite a FORTRAN app in C, so that it will be more portable and
>> maintainable down the road. He has little experience with Linux.
>
> I think the key words here are PORTABLE and MAINTAINABLE. Like many other
> people here I have worked with scientists who picked up a C book and were
> convinced they could write C apps just because they got their stuff to
> compile. It might have compiled, but it was clearly "Fortran in C". It was
> just as bad as "Pascal in Ada" (1980s) and even, shudder, the "Fortran in
> Ada" I saw a few times at a defense contractor.
(Shudder) I've seen that too. It can get very ugly at
times!
> Anyone with experience in one procedural language can write something that
> compiles in another procedural language in a few days to a few weeks. But
> it's at least six months until you write stuff that doesn't consistently
> make you flinch later, and probably at least two years until you can do
> something truly portable and maintainable. You can't do the latter until
> you understand at a deep level how other people will approach the code.
I agree with you to some extent.
Many people do write code stylistically wrong for a
language, no question. I've even done it myself from time
to time. However in my experience this isn't so much about
time using the language as the attitude of the programmer.
I've seen people use a language wrong ten years after they
learned it, and others who use a language perfectly days
after they start using it.
I'm not certain what makes the difference. Perhaps in how
the language is learned? Perhaps the attitude of the
person? Perhaps simply how much experience the person has?
No clue.
I've certainly used languages wrong and written production
code that makes me flinch to this day. Since then I've had
to learn *many* new languages and have refined a process for
picking them up quickly, including using them appropriately.
The key (for me, at least) is to find suggestions on when to
and *not* to use various aspects of a language, then play
around with prototype code until I understand why. I find
this helps me use the language appropriately right from the
start.
As for writing "PORTABLE and MAINTAINABLE" code, I cannot
agree that you can only do this after years of using the
language, though it is certainly easier. I could agree,
however, that it takes years of experience as a "Software
Engineer" before you can easily apply the knowledge to a new
programming language. (Side note: In my opining, you can
be a talented programmer your entire life and yet never do
any "Software Engineering". Nothing wrong with that at
all, the world needs both types to write applications.)
First, "Maintainable" code. The key question is
"maintainable by who?" Code that is maintainable by one
person experienced in the language can be incomprehensible
by another equally experience person. A program structure
which can be easily modified and extended by one person
might be so opaque to another (again equally experienced in
the language) that the only option is to rewrite it from
scratch. I've encountered both these situations.
The best "maintainable" code I've come across (as the
maintainer) had extensive comments detailing (1) why the
code was designed as it was and (2) how to make changes to
the code which the design was planned to accommodate. This
doesn't require experience with the language, just
dedication to describing what you are doing as you write the
application.
"Portable" code I personally have found to be mostly about
dedication to cleanly separating the non-portable sections
of the code from the portable sections. Some languages make
this easier than others, but such functionality should have
been discovered when learning the language.
--David
More information about the LUG
mailing list