On Sun, Jan 19, 2014 at 3:24 PM, Alarm B. [email protected]
Joshua P. wrote in post #1128901:
However after chatting to my Dad who was a programmer during the 80’s
and 90’s he seemed to think I was jumping in at the deep end with Ruby
due to the fact that there is a lot going on “under-the-hood” of some
processes that I won’t understand, straight off the bat.
Not trying to intimidate Johusa’s dad here but this statement sounds
as if it comes from someone who loves details too much. You have to
stop digging deeper into details at some point otherwise you would
first have to study quantum physics to learn to program because then
“you can see everything that’s going on.” For learning basic concepts
of programming (control structures, functional decomposition, data
types) a more abstract language is better suited IMHO because it
avoids distraction by too many details.
I mention this because I believe this love of details is one of the
pertinent hazards we programmers face. I have seen it very often that
people feel uncomfortable at discussing programming problems at a
certain level of abstraction and dive down into details. By doing that
they lose oversight and burden their mind with too many information
which hinders proper understanding of what is going on on the more
abstract level. One of the most important traits we need to learn is
to resist diving into details too early where one feels comfortable
and stay in the colder heights of abstraction. Only if we have gained
a clear picture there we should allow ourselves to dive further in.
I am, of course, describing top down development. If we do not get the
most abstract concepts right then our programs are a mess right from
the start. If the abstract behavior is clear then readers of the
source code and documentation have a far better chance to understand
what’s going on. Errors in the lower levels are usually much easier to
fix than errors on the design level. This is why it is so important to
get that right before diving deeper.
I tend to agree with your Dad. I’m a firm believer that if you’re
looking for a programming language to learn as your first (not always a
choice, many get something foisted on them in school/college/work), the
ideal language is C. This is a great first language because
i. it’s the foundation of many other languages; if you understand C,
it’s pretty simply picking up most anything else like Jave, Obective-C,
C++, Python, Ruby, Perl, etc.
That’s like suggesting to learn physics if your intention is to
understand chemistry because physics is the basis. But that is not
needed when being introduced to chemistry. The abstractions provided
by chemistry work pretty well by themselves.
ii. It’s been around for ages, which means there’s loads of
internet-based material to help you with problems as you learn
That is certainly an advantage - although the age could also mean that
it’s difficult to find out whether the information you find applies to
your flavor of C (K&R, ANSI, which version of ANSI…).
iii. It’s a relatively compact language which you can learn fairly
Compare pointer handling (and arithmetic) with those in Pascal. In
Pascal it is much easier to understand what pointers are because there
is no pointer array ambivalence and no pointer arithmetic. A pointer
in Pascal is really just a pointer to a memory address.
If you can find a copy, start with Kernighan & Richie’s classic ‘The C
Programming Language’. It’s a simple, neat introduction to the language
in a couple of hundred pages (instead of the 500 page tomes by various
publishers) written by one of the languages founders.
It is my understanding that today the flavor of C used as changed
quite a bit. Does the old book still give a good introduction to the