Re: Which programming Language
On Mon, 9 Feb 2009 20:19:59 -0800
Daniel Burrows <dburrows@debian.org> wrote:
> I think one important thing is to learn more than one language. There
> are a couple reasons for this, but if I had to give you just one, here
> is what it would be:
>
From experience, after the third or so language it's easy to pick up anything
else. I've debugged and modified programs in languages that I never learned and
had no idea of the syntax.
[...]
>
> I was avoiding naming particular techniques here, but for instance, a
> lot of C++ programmers avoid templates -- functions that can operate on
> more than one type -- because they're considered "too hard". In
> Haskell, *every* function can operate on multiple types; there's no
> special syntax required to do it.
templates have great strengths, but some of the features can be very obscure.
It can also be somewhat difficult to debug and forcing template instantiation
and cross compiler compatibility can be a pain.
On the other hand c programmers have abused language constructs to get
inheritance, rtti, virtual functions and templates for years.
>
> I would advocate learning two languages early on: a lot of people
> invest much time and effort in just one, and then find it too difficult
> to learn a second. I'm not sure why this is, but my theory is that it's
> some combination of:
>
It should read two different languages. Learning c++ and java won't get you
much farther than either of them alone.
[...]
>
> and at least one of
>
> (2) a Lisp descendant such as Scheme or Common Lisp. Scheme is
> perhaps easier to learn; Common Lisp seems to have more "stuff"
> to get stuff done (although IIRC, drscheme/mzscheme has a pretty
> good environment and set of libraries). Lisp has some
> "interestingly different" ideas about how a programming language
> can be designed, like its powerful macros, and although it looks
> funny, it's actually not that different from
>
Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/
which uses scheme is an interesting book, at least if you take it for what it
is, a tool used to teach language design constructs and not just a book to
teach scheme (a mistake they made in my uni at the time).
I would also recommend picking up a good book on software engineering. Learn a
but about UML and SRS. I made a mistake once of telling a lab partner that the
problem was easy to code. He started programing without designing and got lost
after two weeks. With a proper design the while thing was rewritten from scratch
in a day and a half (including the time it took to do the design).
[...]
>
> However, these two languages also require you to ask the system for
> memory when you need to store some data, and to give it back when
> you're done. It might be surprising, but this turns out to be rather
> difficult -- in fact, until you become quite skilled with the language,
> most of the bugs you write will be related to memory management. And
> TBH, I think the main "skill" C/C++ programmers learn around memory
> management is how to avoid writing programs in which memory management
> is difficult. :-) However, it's useful to have some understanding of
> how this works, because memory handling can cause problems for you in
> higher level languages if you don't understand how it works. And, of
> course, because then you can do stuff that requires working in a
> language with manual allocation (for whatever reason).
>
Also learn to use the tools. Get proficient with a debugger from the start.
Will save a lot of headache. For c and c++ learning to use valgrind can also
save days of banging your had against the wall
> Daniel
>
>
Reply to: