> Thanks for everybody who replied to my question, it was very
> interesting reading the discussion that followed. Programming
> languages, much like Linux distributions, have their own strengths and
> weaknesses and also come with their evangelists and detractors, it
> would seem.
Most assuredly you are correct.
> From what I've been reading here and elsewhere what language is used
> for any particular project can depend greatly on the problem to be
> had, the organization working on said problem and the preferences of
> the people working on the problem.
In many cases the coding style changes just as frequently, too.
For instance, the GNU C folks have a particular coding style, but the
Linux kernel people (who also write in C) say to print it out and burn
it as it is total crap. They have their own coding style.
This isn't limited to C/C++. It is an issue in most languages. Some
languages (such as Python) have gone so far as to try to standardize
on official recommendations for style, but there is always a stickler
somewhere that wants some back-asswards method of structuring their code
because they think it looks better for some reason. (Number one being
exposure to another language.)
If you contribute to someone else's code, try to follow their coding
style. Never, *ever* make style changes in someone else's code. In your
patches, do everything you can to obey their coding style, even if you
think it makes absolutely no sense. Changing coding style (even in files
you write from scratch) it is a sure-fire way to have all your patches
ignored.
> I also liked what Jeffery said about fundamentals of programming.
> Perhaps it isn't that similar [...]
As an anecdote: I don't write PHP. I've never written PHP. I've never
read anything about PHP. I've never wanted to write anything in PHP.
A product I was using (which was written in PHP) had an annoying bug.
I used my general source skills to find the proper region of code,
and once I found the location, knowing the expected behavior, and the
produced behavior, I instantly knew the problem and how to fix the
problem. I had to scan other regions of the code to find how the author
was doing things, as I didn't really know how anything was done in PHP,
let alone the which of any two common options the author favored. (I
didn't even know the name of the else-if construct.) I did, however,
solve the issue quickly and accurately.
The fundamentals matter. As others have said, with the right
fundamentals and a good core understanding of general language features,
you can fairly easily move from one language to another as needed.
> This leads me to another question: What are some of your favorite
> resources for programming fundamentals? Books, blogs, websites?
For programming *fundamentals* I always found nothing beat good printed
documentation, some well-written examples, and a lot of practice. If
you're in doubt as to the accuracy of the documentation or quality of
the examples, I recommend leaning more heavily on the practice.
But what are programming fundamentals? In part, these are broad
programming features found in every language (like functions and
variable scoping). In part, these are programming techniques used for
any language (like object-oriented design (which you can do in any
language -- even assembly), rapid-prototyping, "agile" development,
etc). In part, these are specific core language features found in a
specific language (Pointers and Lvalues in C, function decorators in
Python, the $/@ variable prefixes in Perl). In part, these are specific
technologies usable in any language, but with differing semantics and
APIs (like network code -- while "BSD-style networking" is frequently
available, most of the time higher libraries are built up which are
preferred instead -- and required if you want to be cross-platform).
So many languages draw from C syntax, and/or directly from C libraries
that knowing enough about C to read an example and interpret it to your
language can be considered a fundamental skill if API documentation for
your chosen language is lacking.
I'm biased toward practice primarily because I'm self-taught. Certain
things work well from books. Book learning should cover all of the
fundamentals in principle, but only practice will prove whether you
understand things when you need them.
Don't worry about memorizing APIs. APIs always change. All you
really care about is that you remember enough to easily look up
the documentation in the future. That and you do care about the
fundamentals, of course.
> Or perhaps I can also ask what are important fundamental concepts
> I should grasp? I am eager to start practicing in any number of
> different languages, but I really want to make sure I understand
> why things work the way they do. I don't want to end up a mediocre
> programmer, slaving away in Java day after day building ucky software
> because I didn't build a solid base.
Heh. I covered an overview of the things I think are core concepts.
The same things apply with regards to learning programming as apply with
learning anything: Don't settle for rote answers. Ask questions until
you fully understand things. When you have documentation available, read
it for fun and not just to get a better grade.
In general, a brilliant example of your work always trumps school
grades. In the real world no one cares about your GPA, they only care
about whether or not you know your stuff. Unfortunately there are many
cases of people with "book smarts" who know everything on paper and got
great grades, but they're still crappy programmers. Having a degree does
help -- I won't deny that -- but only the most horrible work places care
more about that than about practical skills.
My father considers programming a fine art. There isn't a single one
of the arts, whether it be creative writing, playing music, painting,
sculpting, etc. where they don't lean heavily on understanding first the
basic principles, and secondly practice, practice, practice.
Cheers,
Steven Black
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
No comments:
Post a Comment