Re: What things should successful programmers-to-be learn right now?
- From: dj3vande@xxxxxxxxxxxxxxxxxxx (Dave Vandervies)
- Date: Tue, 9 Aug 2005 23:56:07 +0000 (UTC)
[Coming back into this rather late; real life has an annoying habit of
getting in the way of usenet participation.]
In article <1122475287.499966.100830@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Rob Thorpe <robert.thorpe@xxxxxxxxxxxx> wrote:
>wee wrote:
>> I do understand that I'm vaguely new to the industry.
>>
>> However, more to the point: In what industries are the languages used
>> that I listed above from Dave Vandervies' post? Perhaps an answer to
>> that would be more helpful to all of us than your unfortunately snide
>> comment.
>
>Dave's list is not targetted at learning programming languages it's
>targetted at learning about programming.
Exactly. The OP was asking what you need to learn to "have a shot at
a great career"; you need a lot more than just knowledge about one or
two tools for that, no matter what field you're working in.
More importantly, the list of languages I gave is only the last on a
list of things that it's important to know to be good at programming,
and it's probably the least important; if you can master the rest of
the list, you won't have much trouble learning how to work with any tool
that gets thrown your way.
The key point here is: You'll never become a good programmer by learning a
single tool, or by focusing on skills that directly apply to programming.
The way to become good at anything, and especially highly creative things
like computer programming, is to become good at *thinking* and then
learn how to focus those skills on the task at hand. The list of other
skills I gave is intended to reflect that, and the list of languages
is intended to avoid the "every problem looks like a nail" mindset.
But what you're really *learning* while you're studying these things,
and what you need to learn to be a good (rather than merely "adequately
competent") programmer, is something that's hard to quantify or describe
- it's treating all of the individual things as more than just a set of
unrelated factoids, and to do that requires a set of skills and a view
of the world that most people have to work on developing.
>Repeating Dave's list below:
[which I'm re-ordering a bit for my additional commentary]
>> At least one of:
>> Scheme
>> Haskell
>> SML
>> CAML
>
>These teach you about the power of higher-order programming, lists and
>sophisticated data structures.
>
>> At least one of:
>> Smalltalk
>> Java
>> Objective-C
>
>These teach you about dynamic all-encompassing object-orientation.
>
>> At least one of:
>> Perl
>> Python
>> sh+awk+sed
>
>These teach you about throw-away programming and text processing.
All of these, besides being useful skills on their own when they're
applied appropriately, also teach you (when taken collectively) to not
take a one-size-fits-all approach to solving problems; once you've gotten
your brain wrapped around two or three different programming paradigms,
you'll have had a lot of "This would be a lot easier in $other_language"
or "$other_task would have been a lot easier if I'd known this when
I was doing it" moments, and those are probably the most important
tool-specific things you'll ever learn.
You'll also, if you're like most people, have written your share of
"language X in language Y"-type code, and have figured out why that's
usually not a good idea and how to do it properly when it actually is,
by the time you've learned three or four completely different languages.
>> At least one of:
>> Forth
>> Prolog
>> Postscript
>
>These teach you about stacks.
More than stacks (what little I know about Prolog indicates that it's
not actually stack-based, though I could very well be wrong about that),
these will introduce you to a way of looking at things that is thoroughly
wierd compared to the world-view most programming languages are based on.
Even if you never actually use them (and there's a good chance you won't;
they tend to only be found in specialized environments that they fit
well), having managed to twist your mind up into a form that lets you
truly understand them is an extremely useful horizon-expanding exercise.
>> At least two of:
>> FORTRAN
>> C
>> C++
>
>These are very common languages that a programmer should know at least
>a little.
Yep. Even if specific tool-based knowledge isn't sufficient to make
a good programmer, you still need to know specific tools to actually
get anything done, and most real-world jobs will at least touch one of
these three.
(I almost added COBOL to that list, too, and it wouldn't be inappropriate
to do so.)
> C and Fortran are traditional structural programming
>languages.
Learning languages for reasons like that is less important for
structural/procedural than for most other paradigms; it's an important
skill to have, but it seems to be the one that most people understand
intuitively (and shows up in small pieces in a few of the others),
so it's likely to end up being reasonably well-developed even without
consciously focusing on it.
> C++ is an attempt to integrate many different paradigms
>together into one language.
....and is worth learning if only to see what a monstrosity you end up
with when you try that.
>Some of the above are in heavy commercial uses, some aren't, but much
>can be learnt from each of them that can be applied to other programs
>in other languages.
Yep, and even more so, the process of learning them will teach you
things that can be applied to other programs in other languages, and
to programming-in-general.
>The languages you learn every last detail of should be those that are
>commercially used. But it's very educational to learn the principles
>of many others.
Well, sort of. The languages you learn every last detail of should
be those that *you* use; but you won't know what those are until you
start using them (and they'll probably change over time anyways), and
learning the principles of a bunch of others makes it a lot easier to
pick up the ones you need when you need them.
dave
--
Dave Vandervies dj3vande@xxxxxxxxxxxxxxxxxxx
> Genghis Khan, Immanuel Kant.
In today's lesson, we learn that brute force is more productive than thinking.
--Chris Suslowicz and David P. Murphy in the scary devil monastery
.
- Prev by Date: Re: Presenting a new(?) idea for free open source software development.
- Next by Date: Re: What things should successful programmers-to-be learn right now?
- Previous by thread: Help needed in printing wide characters in C
- Next by thread: Re: What things should successful programmers-to-be learn right now?
- Index(es):
Relevant Pages
|
